LLM 编程可能让人精疲力尽：识别疲劳信号和改进反馈循环

评分 6.8 · 来源：Hacker News · 发布于 2026-03-15

评分依据：真诚的个人经验反思，指出了 LLM 编程中容易被忽视的问题（疲劳导致 prompt 质量下降、慢反馈循环消耗 context），提供了可操作的改进建议

要点

作者分享了与 Claude/Codex 编程 4-5 小时后精疲力尽的经历，反思发现问题不在模型，而在自己的工作方式。

疲劳的两大原因：

疲劳导致 prompt 质量下降
- 越累，写的 prompt 越差，AI 的输出质量也越差
- 典型场景：发送一个复杂 prompt（已用 30% context 对齐问题），提交后立刻意识到漏了关键信息，打断 LLM，补充信息，让它继续
- 打断或「steering」几乎总是导致更差的结果
反馈循环太慢 + context 膨胀
- 当前任务需要解析大文件，每次调试需要重新解析，过程很慢
- 就像一个需要 10 分钟才能转一次的老虎机
- 每次实验需要大量 context 铺垫，解析完成时 LLM 已经接近 context 压缩边界（2% 剩余）
- 结果：要么 AI 变笨，要么假装知道最近实验的结果

改进方法：

避免 doom-loop 精神错乱
- 第一信号：如果写 prompt 不再有乐趣，立刻停止
- 如果在敷衍、简短、打断、沮丧，就该休息了
- 元认知检查：是因为没想清楚问题，希望 AI 填补空白吗？这是诱人的陷阱
- 目标状态：写 prompt 时对结果充满信心，知道 AI 会 CRUSH IT
识别慢反馈循环，让它成为要解决的问题
- 希望反馈循环在秒/分钟级别，而不是 15/20/30 分钟
- 开新 session，向 LLM 描述反馈循环慢的问题，要求优化到 5 分钟以内
- 给出失败案例，让 LLM 尽快复现失败
- 这听起来很熟悉……TDD（测试驱动开发）！
- 作者以前是「scrappy engineer」，觉得写详细测试太耗时
- 但与 AI 协作时，写详细测试反而节省时间：给 LLM 明确的成功标准（「复现这个失败，确保时钟时间少于 5 分钟，可以优化代码路径或省略不必要的部分」），LLM 不仅会复现问题，还会创建更快反馈循环的杠杆
- 快速反馈循环 → 消耗更少 context → AI 更聪明 → 节省数小时调试时间

结论：

当与 LLM 协作感到精疲力尽时，可能是「skill issue」（技能问题）。需要识别疲劳信号、避免认知外包陷阱、优化反馈循环。

这篇文章的价值在于「自我反思」——不是抱怨工具不好用，而是反思自己的使用方式。

「疲劳 → prompt 质量下降 → 输出质量下降 → 更疲劳」是一个很容易陷入的负反馈循环。关键洞察是：如果写 prompt 不再有乐趣，就该停止了。这个信号比「AI 输出不对」更早、更可靠。

慢反馈循环的问题在传统编程中也存在，但在 LLM 编程中被放大了——因为每次迭代都在消耗 context，而 context 是有限资源。作者的解决方案（让优化反馈循环本身成为任务）很聪明，本质上是把 TDD 的思想应用到 LLM 协作中。

「以前觉得写测试耗时，现在发现给 LLM 写测试反而省时间」这个转变很有意思。因为 LLM 写测试的成本比人低得多，而测试带来的快速反馈循环对 LLM 的价值比对人更大（context 限制）。

这篇文章和前面的「How I write software with LLMs」形成了有趣的对比：一个强调架构和多模型协作，一个强调自我状态监控和反馈循环优化。两者都指向同一个结论：LLM 编程不是「让 AI 替你写代码」，而是「建立一个可靠的人机协作系统」。