Anthropic 官方最新发布的《Best practices for Claude Code》指南开篇就点出了一个核心矛盾——Claude Code 是一个能自主读文件、跑命令、改代码的智能体环境，但如果没有一个客观的"完成"标准，Claude 只能凭"看起来做完了"来判断自己是否该停下，而这恰恰是最不可靠的信号。本文详解官方给出的验证闭环设计模式。
问题的本质
Claude stops when the work looks done. Without a check it can run, "looks done" is the only signal available, and you become the verification loop: every mistake waits for you to notice it.
翻译过来就是：如果你不给 Claude 一个能跑的检查，你自己就会变成那个检查——每一个错误都要等你亲自发现。这也是为什么很多人用 Claude Code 时觉得"不敢完全放手"，因为潜意识里知道没有闭环，出了问题只能靠自己盯着。
解决方案：给它一个能产出 pass/fail 的信号
官方给出三个具体改写示例，核心思路是把模糊的目标改写成可验证的目标：
改写前：implement a function that validates email addresses
改写后：write a validateEmail function. example test cases:
user@example.com is true, invalid is false,
user@.com is false. run the tests after implementing
改写前：make the dashboard look better
改写后：[粘贴截图] implement this design. take a screenshot
of the result and compare it to the original.
list differences and fix them
改写前：the build is failing
改写后：the build fails with this error: [粘贴报错]. fix it and
verify the build succeeds. address the root cause,
don't suppress the error
三个例子背后是同一个模式——提供验证标准、用截图做视觉核对、要求定位根因而非掩盖症状。这个检查可以是测试套件、构建退出码、Linter、比对基准输出的脚本，或者一张对比设计稿的浏览器截图，任何能返回 Claude 能读懂的 pass/fail 信号的东西都算。
验证闭环的四种落地强度
官方按"设置成本 vs 省心程度"给出了四档选择：
1. 单次提示内完成
在同一条消息里让 Claude 跑检查并迭代（如上面三个例子）
2. 贯穿整个会话
把检查设为 /goal 条件，一个独立的评估器在每轮结束后
重新核查，Claude 会持续工作直到条件成立
3. 确定性硬门禁
用 Stop hook 把检查脚本作为强制关卡，检查不通过就
不允许结束当前轮次（Claude Code 会在连续 8 次拦截后
强制放行，避免死循环）
4. 第二意见交叉验证
用一个验证子代理（verification subagent）或动态工作流，
让一个"新鲜"的模型去反驳前一个模型的结论，
避免"既当运动员又当裁判"
越往后设置成本越高，但换来的是无人值守运行时依然能正确收尾的可靠性——前两档适合你还在旁边盯着的场景，后两档才是真正支撑"我可以去干别的事了"的关键。
一个容易被忽略的细节：要证据，不要断言
Have Claude show evidence rather than asserting success: the test output, the command it ran and what it returned, or a screenshot of the result.
官方特别强调，要让 Claude 展示证据而不是简单地说"完成了"——测试输出、实际跑过的命令和返回结果、结果截图。这一点在实际使用中体验差异很大：
Claude 说："已经修复完成，测试通过"
→ 你需要自己再跑一遍才能确认
Claude 展示："运行 npm test 输出：15 passed, 0 failed"
→ 你扫一眼输出就知道是不是真的通过了
审阅证据比你自己重新跑一遍验证要快得多，这个习惯对于事后回看那些你没有全程盯着的会话尤其重要。
实战建议
1. 交代任务时，尽量在第一条消息里就带上验证标准，
而不是等 Claude 做完再补充要求
2. 涉及多文件改动或长任务时，优先考虑 /goal 或 Stop hook，
把验证做成硬约束而不是软建议
3. 涉及 UI/视觉改动，善用截图对比这个模式，
比纯文字描述"好不好看"精确得多
4. 养成让 Claude 展示证据的习惯，尤其是在后台/无人值守场景
总结
这条最佳实践的本质，是把"我信不信 Claude 做对了"这个主观判断，转化成"有没有一个客观信号能证明它做对了"这个工程问题。花几分钟在提示词里加上验证标准，换来的是从"必须全程盯着"到"可以放心走开"的体验跃迁——这也是官方指南把它放在第一条最佳实践的原因。
来源：Best practices for Claude Code — Claude Code 官方文档，Anthropic