信任它：验证无人监督的运行
您把一项任务交给了Claude，并让它在没有您全程盯着每一步的情况下运行。现在它说任务完成了。在您交付这项工作之前，您需要一种方法来检查一个您甚至都没有监督过的过程。正是这种检查，才让无人值守的Claude Code变得可以放心依赖。
这里的思路很简单：按照您给这次运行多大的自由度，来相应地进行验证。如果您在一个短会话中看着消息滚动而过，那么快速浏览一下就够了。但一次无人看管的运行，或者一个在持续集成中触发、没有人在场的任务，就需要一次真正的检查。没有人看到发生了什么，所以您必须在事后把它重建出来。
这里有一种理解方式：您观察得越少，就越需要验证。
让无人值守的运行保持在自动模式下
当工作中的一次运行处于无人值守状态时，让它保持在自动模式下，而不是绕过权限。在自动模式下，分类器仍会审查大多数操作是否存在危险。这是一张值得保留的安全网。
但要清楚这张网能做什么、不能做什么。分类器从不判断代码是否真的正确，它只标记危险操作。所以您的验证标准应保持不变。根据这次运行的无人监督程度来设定这个标准。
从diff开始，而不是从摘要开始
不要从Claude对其所做工作的摘要开始。要从diff本身开始。
- 运行
/code-review来走查变更并标记问题。 - 然后亲自审视
git diff。
陷阱在于：一份读起来完全合理的整洁摘要，而实际的diff却改动了一个您根本没想到它会改动的文件。摘要不会告诉您这一点，diff会。
所以要阅读发生了什么变化。先阅读计划内的文件，然后再寻找计划之外的任何内容。一份干净的说明并不能证明代码是干净的。
把测试变成一道关卡，而不是一句承诺
对一次无人监督运行而言，真正的关卡在于测试是否通过了，以及Claude是否真的运行了测试，还是只是声称运行了。不要把这件事交给信任去判断。把它接成一个hook，让Claude无法跳过它。
有几个hook可以完成这项工作：
- 一个stop hook，运行您的测试，并在失败时拒绝结束这一轮。
- 一个post-tool-use hook，在每次编辑后进行lint检查和类型检查。
关键细节在于退出码。一个以exit 2退出的hook会把失败信息直接反馈给Claude。Claude读取到这个失败信息后，会在您不用开口的情况下自行修复。最妙的是，这项检查会在每次运行时触发，无论您是否记得要求它这样做。
获取一个冷静的第二意见
您在提交pull request之前会运行的子代理代码审查，在这里同样适用。把它指向一次无人监督的运行。
打开一个全新的会话或子代理，让它在不知道代码是如何构建出来的情况下审查变更后的代码。正因为它对所采用的方法没有任何利害关系，它能发现原始运行过程中自我说服而忽略掉的问题。一个带着全新视角的第二审查者，能发现作者为自己找借口开脱的地方。
把这些整合起来
让检查的严格程度与这次运行的无人监督程度相匹配：
- 亲自阅读diff。
- 把测试变成一个能卡住这一轮的hook。
- 通过JSON结果和退出码来验证无头运行。
- 对任何重要的事情，获取一个冷静的第二意见。
做到这些，"Claude在我没看着的时候完成了它"就不再需要凭信念去相信了。