反馈循环设计

反馈循环设计

官方 best-practices 里有条铁律被反复强调：

Give Claude a way to verify its work.

为什么是铁律？因为 Claude 最危险的失败模式不是「不会写」，而是「写完了自信地说『搞定了』，你一跑发现崩了」。它没有恶意，只是没有客观信号告诉自己做得对不对。反馈循环就是给 Claude 装上「自我纠错机制」——让它拿到证据，自己判断做没做对。

这一篇讲透四种验证强度，从轻到重，按场景挑。

强度 1：In one prompt——单条消息里跑检查

最轻的反馈循环：在同一条 prompt 里要求 Claude 跑检查并迭代。

> 修这个 bug。改完跑一遍 npm test，如果有失败的测试，分析原因继续修，
> 直到全部通过。把最后的测试输出贴给我看。

关键点：

• 改完就跑——不让它说「应该没问题」就收工。
• 失败就继续修——形成循环：改 → 跑 → 修 → 跑。
• 贴出测试输出——证据而非断言。

适合：单步任务、改完就能跑测试的场景。 不适合：跨多步、需要外部验证（如截图）的复杂任务。

强度 2：Across a session——/goal 条件，每轮检查

跨整个会话的反馈循环：用 /goal 设一个完成条件，每轮对话都让一个独立的 evaluator 检查是否达成。

/goal 所有测试通过 + lint 零警告 + 文档更新

设了 goal 之后，Claude 在每轮动作后会检查这个条件是否满足。没满足，继续干；满足了，宣告完成。

这种做法比强度 1 强在哪？goal 是独立的、可重复检查的——不是 Claude 凭感觉说「差不多了」，而是它每轮都跑一遍客观检查。模糊的「差不多」被具体条件替代。

适合：多步骤任务、需要多个条件同时满足的场景。 不适合：单步任务（杀鸡用牛刀）。

强度 3：Stop hook 做确定性闸门

更强的一种：挂一个 Stop hook 脚本，运行确定性检查（跑测试、lint、build），不通过就阻断结束，让 Claude 继续修。

{
  "hooks": {
    "Stop": [
      {
        "matcher": "",
        "hooks": [
          {
            "type": "command",
            "command": "npm test || exit 1"
          }
        ]
      }
    ]
  }
}

工作原理：

• Claude 想结束时，Stop hook 触发。
• 脚本跑 npm test。
• 测试挂了 → 脚本 exit 1 → 阻断结束，Claude 看到失败信息继续修。
• 测试过了 → 脚本 exit 0 → 允许结束。

官方有个机制：连续 8 次 Stop hook 阻断后，Claude Code 接管结束——避免无限循环。这是个安全阀，防止 hook 配错导致死循环。

为什么叫「确定性闸门」？因为脚本是100% 必运行的——不靠 Claude 自觉，靠机制。这就是 9 步循环 第 5 步「Hooks 强制规则」的具体应用。

适合：必须保证质量门槛的任务（合并前必过测试）。 不适合：探索性任务、写作任务（没有客观 pass/fail 标准）。

详见 Hooks 深入与实战 的 Stop 事件章节。

强度 4：By a second opinion——verification subagent 反驳

最贵也最强的一种：派一个验证子代理，让一个「不同意它」的 Claude 来挑刺。官方称之为 adversarial review——对抗式审查。

> 派一个 verification subagent，独立读这次改动的所有代码和测试，
> 挑出：逻辑漏洞、未覆盖的边界、与项目公约冲突的地方。
> 只读不改，给出审查清单。如果清单里有「严重」级问题，继续修。

为什么这一招强？因为写代码的 Claude 已经「沉浸」在自己刚写的逻辑里，对盲点视而不见。一个干净上下文的验证代理，带着批判眼光重新读一遍，反而能看出问题。

这就是官方 best-practices 里说的对抗式审查。它不是走过场，是真的找一个「不同意你」的人来挑刺——这种对抗心态能挖出自我审查永远发现不了的盲点。

四种强度对照

强度从 1 到 4 越来越贵，也越来越可靠。

强度	机制	谁来验证	适合场景
1 单 prompt	同条消息里跑检查	Claude 自己	单步任务
2 跨会话	/goal 条件，每轮检查	Claude 自己	多步任务
3 Stop hook	脚本运行检查，阻断结束	确定性脚本	质量门槛
4 第二意见	子代理独立审查	另一个 Claude	复杂改动

简单任务用强度 1，关键任务用强度 3，复杂改动用强度 4——按风险选，不是越强越好。改 typo 用强度 1 都嫌重，挂 Stop hook 是浪费；但合并前必过测试，强度 3 是底线。

让 Claude 拿证据，而非断言成功

四种强度背后是同一条心法：让 Claude 拿出证据，而不是断言成功。

Before（断言）	After（证据）
「我改完了」	「跑过测试，输出贴给你看」
「应该没问题」	「npm test 全绿，截图如下」
「修好了」	「修完跑了一遍 reproduce 脚本，错误不再复现」
「性能优化了」	「lighthouse 跑分 LCP 从 4.2s 降到 1.8s」

差别就一个动词：show vs say。Say 是断言，show 是证据。Claude 很会 say，但只有 show 才靠得住。

验证标准的 Before vs After

光说「跑测试」不够，得说测试什么算通过。验证标准越具体，反馈循环越有用。

Before（模糊）	After（具体）
「跑下测试」	「npm test – –grep “auth” 全绿」
「看下能不能用」	「跑 curl localhost:3000/login，返回 200 且 body 里有 token 字段」
「修好了吗」	「跑 reproduce.sh，exit code 0 算修好」
「性能好点了吗」	「lighthouse 跑 3 次取平均，LCP < 2.5s」

具体到「什么命令、什么输出、什么数字」——这是反馈循环能跑起来的前提。模糊的「看下」等于没标准，Claude 只能凭感觉判断，结果就是「看起来不错」糊弄。

反馈循环让无监督运行正确完成

为什么四种强度都重要？因为它们共同回答一个问题：怎么让 Claude 在没人盯着的时候，正确地完成？

无监督运行（headless、auto mode、CI）是 Claude Code 的进阶用法。但你敢让它自己跑，前提是它有客观信号判断自己做得对不对——不然它自信地跑歪了，你第二天早上才发现一片狼藉。

四种强度就是四种「让它有客观信号」的方式：

• 强度 1：单 prompt 里就闭环，不用人盯。
• 强度 2：跨会话自动检查 goal。
• 强度 3：hook 强制门槛，过不去不让结束。
• 强度 4：第二个代理挑刺，对抗盲点。

配上 Plan-first 模板 和 9 步循环，无监督运行就有了完整的安全网。这也是「智能体工程」区别于「氛围编程」的核心——前者靠机制保证结果，后者靠运气。

一句话总结

反馈循环是 Claude 的自我纠错机制：四种强度从轻到重——单 prompt 内跑检查、/goal 跨会话条件、Stop hook 确定性闸门（8 次阻断后接管结束）、verification subagent 第二意见。让 Claude 拿证据而非断言成功，验证标准要具体到命令和数字。这是无监督运行正确完成的前提。

---

下一步，去看 上下文工程——反馈循环跑起来后，怎么保证 Claude 的「短期记忆」不爆。🚀