LLMs 可能会让人感到疲惫

Source: Hacker News

有些日子，我在与 Claude 或 Codex 进行了一场痛苦的 4‑5 小时会话后，躺在床上，想到底发生了什么。很容易把责任归咎于模型——可供选择的选项太多了：

• 他们在降级模型以节省成本。
• 上下文腐化！
• Codex/Claude 代码/[插入工具] 正变得臃肿。

我常常会在第二天重新回到问题上，经过休息后我的上下文窗口已经清空，并在 LLM 的帮助下找到一条快速且令人满意的前进路径。这是怎么回事？

我感到疲惫，实验进展太慢

随着疲劳加重，我的提示质量下降

如果我精神上感到疲惫，我写的提示会变得更差，因而 AI 的表现也会更差。例如，我在使用约 30 % 的上下文与 AI 对齐问题后，启动了一个相当有分量的提示，却在提交后立刻意识到遗漏了关键上下文，于是中断 LLM，提供缺失的上下文，然后让它继续。中断 Claude Code 或在 Codex 中进行“引导”往往会导致更差的结果。

反馈回路太慢且上下文膨胀

我现在正在做的部分工作需要解析大型文件。解析逻辑中的错误需要通过 LLM 来逐步排查。每一次微调都需要重新解析，这个过程非常慢——我把它比作需要 10 分钟才能转动一次的老虎机。到了解析任务结束时，LLM 已接近其上下文限制，这要么导致一个非常笨拙的 AI，要么让 AI 假装了解最近实验的情况。

与 AI 的顺畅路径

避免因糟糕提示导致的厄运循环精神错乱

如果我发现自己已经不再从写一个好提示中获得乐趣，那就是该休息的第一个信号。当我敷衍了事、言简意赅、打断思路并感到沮丧时，我需要离开一下。

需要进行元认知：我是否因为没有真正思考清楚问题而变得描述不够详细，寄希望于 AI 填补空白？这种陷阱很诱人。AI 正在变得擅长填补未定义的需求，但它们仍未完美。

有时我会写出一个非常清晰的提示，明确描述期望的最终状态，以至于在提交时已经在为结果庆祝，因为我知道 AI 能完美实现。那种自信的感觉就是我在每个提示中都应寻找的。如果感觉是“不确定”或“急躁”，那么提示很可能无法如愿。

识别缓慢的反馈回路并将其视为问题

在上面提到的解析问题中，反馈回路痛苦地慢。我要让我的“老虎机”在几秒或几分钟内完成，而不是 15–30 分钟。在这种情况下，我会开启一个新的 LLM 会话，重点放在反馈回路速度上，阐明希望实现“5 分钟以内”的回路，给出一个失败案例的示例，并要求模型尽可能快地复现该失败。听起来有点熟悉……有人想做 TDD 吗？

我一直是个爱折腾的工程师。我会写测试，但对为特定问题创建复杂的测试用例或集成测试持保留态度，因为它们感觉耗时。使用 LLM 改变了这种计算方式。如果你给模型明确的成功标准——例如，“复现此特定失败案例，并确保执行时间低于 5 分钟。可以尝试优化或省略不必要的部分”——AI 不仅会复现问题（第一次可能较慢），还会提出加速反馈循环的杠杆。更快的反馈循环消耗更少的上下文，使 LLM 更聪明，从而节省数小时的调试时间。

结论

当我因与 LLM 工作而感到精疲力竭时，这实际上可能是“技能问题”。我需要识别自己何时疲惫并进入厄运循环的精神错乱。将需求的认知外包给模型很诱人，但这是一种陷阱。如果我不享受编写完美提示的过程，也不确信能得到至少让我满意 95 % 的结果，我就需要休息，或重新考虑是否真的彻底思考过问题。如果进展缓慢且上下文消耗过快，我应该把这当作要解决的问题：在 LLM 的帮助下，找到一种路径，以更快迭代并使用更少的上下文。