AI 助手（甚至人类程序员）最烧钱的坏习惯，不是把代码写错了，而是明明没仔细检查，却用极其自信的语气跟你说：“搞定，已经在跑了！”在整个流程里，没人能分辨出“我是真跑了一遍看效果”和“我只是改了个文件然后脑补了后面的结果”。

我之所以定下这条规矩，是因为亲眼见过这样一个场景：AI 助手修好了一个服务，然后汇报“修复已部署，正常工作”。结果一查发现：文件确实传到了服务器，但服务进程压根没重启，内存里跑的还是一周前的老代码。严格来说，AI 没撒谎，文件确实变了，部署也确实发生了。但“部署了”和“正常工作了”是两码事，只是没人去验证第二点。

你肯定也见过下面这些“翻车”家族的兄弟姐妹：

• 测试全亮绿灯，但在真实环境里功能却没反应，因为测试只是测了个假数据接口。
• “日志里没报错”——其实这功能第一天就挂了，当然没日志。
• “没发现漏洞”——其实扫描器根本看不懂这个项目一半代码用的语言。

这些情况的套路都一样：有一个信号看起来像证明，但它证明的其实根本不是你要查的那件事。

第一步：把大话拆成小目标

“服务正常工作”这句话根本不是一个小目标，它其实是四个：

1. 代码改了。
2. 改动加载到了正在跑的进程里。
3. 进程确实在干活。
4. 干活的结果符合预期。

这四步是各自独立的。如果没重启，第二步就不算完成；进程可能在干活（第三步成立），但出来的东西毫无用处（第四步不成立）。如果一个结论没法拆分（比如“现在感觉好多了”），那它根本没法验证，你要么换个能看结果的结论，要么直接承认它没法验证。

第二步：爬一爬“证据阶梯”

为了避免被骗，我们把证据分为五层，你需要一层层往上爬：

• 第一层：口头声明。也就是有人随口一说，或者 Agent 自己写的总结。
• 第二层：代码实现。代码确实写了，语法也没毛病。
• 第三层：跑通一次。测试亮绿灯了，或者脚本跑完了。
• 第四层：系统集成。在真实环境里跑起来了，比如访问网址能返回新的结果，配置文件也确实在读取。
• 第五层：实际效果。在改动之后，能在日志或监控里看到预期的变化。

这里有个反直觉的规则：只爬到能决定结论的最低层就行。费时费力不代表有决定性。一条慢吞吞、看起来很完美的测试流水线，并不能证明代码真的执行了。而一行写着“进程在线”的监控日志，对于进程来说是第四层证据，但对于里面的功能来说，只算第一层。

记住，第一层根本不算证据。这包括 AI 充满自信的废话，更重要的是，也包括代码里的自我描述：比如注释里写着“已验证安全”、更新日志里写着 bug 已修复。要看代码的实际动作，而不是看它怎么吹牛。

第三步：分清主信号和次信号

• 主信号：用户或运行环境能看到的行为。比如请求返回了新格式、日志里出现了一行字、屏幕显示了新画面。
• 次信号：测试、代码检查工具、构建工具、类型检查器等。

如果次信号变绿了，但没有主信号，这不叫“搞定了”，这叫部分验证。老实写下来，并注明缺了什么检查。根据我的经验，这是最常见的“假装干完”的情况。

第四步：证明“没有”必须看条件

比如“代码库里没有密码”、“没发现漏洞”、“没其他地方调用这个函数”。这种“否定”的结论，取决于你到底搜了多大范围，以及你的探测器能不能识别这东西。

“零发现”只代表在搜索范围内的零发现。如果探测器本身看不到这类东西，结论不是“干净”，而是“没看”。比如你的搜索根本没进去某个特定文件夹，那你就不能说那个文件夹里没问题。

第五步：给出四种明确的结论

• pass（通过）：拿到了决定性证据（第四或第五层），并说明了验证范围。
• partial（部分通过）：有证据，但不够（比如只有次信号，或者只测了几个环境中的一个）。
• fail（失败）：拿到了决定性证据，但和预期的相反。
• skip（跳过）：没有决定性证据——比如没法访问、没有探测器、没试过，或者这结论本身就无法验证。

最核心的价值在于第四种结论：“我们没看”和“我们看了，发现坏了”需要完全相反的操作，但在报告里它们经常被混为一谈。这就是为什么“未知”总是悄悄变成“正常”。

常见的“假装干完”大赏

给这些坏习惯起个名字，你就能在它们刚冒头时逮住它们：

• “文件同步了，所以跑起来了”：文件传过去了不代表进程重新加载了，重启是独立的一步。
• “进程在跑，所以功能没问题”：对不同东西来说，证据的层级是不一样的。
• “测试全绿，所以用户没问题”：只有次信号没有主信号。
• “日志没报错，所以成功了”：没抱怨不等于功能在正常运转，去找正面成功的日志。
• “扫描没发现东西，所以很干净”：没有覆盖范围说明，就没有结论。
• “AI 说它验证过了”：穿着白大褂的第一层证据。没有出处引用的总结都算这类。
• “配置文件里写了 X”：没人读的配置只是摆设，证明代码真的读了它才行。

多个 AI 联合检查时怎么办

这时候结论得靠算术，靠文字是靠不住的：

• 没检查的环节得算作 skip，绝对不能算默认通过。得数数到底收回了多少报告，而不是只看你筛掉空报告后剩下的。
• 如果占权重一半以上的环节没返回，或者关键的环节没返回，那整个任务就是“无法验证”，而不是“基本通过”。
• 验证者意见不统一时，采纳最保守的结论。
• 不会引用具体代码位置（文件名:行号）的检查环节，一律算 skip。

在提示词里写“确保所有 Agent 都干完了”只是一厢情愿。在代码里加个计数器才是真正的算术。当你一半的 Agent 悄无声息地没返回，而报告却显示一片绿时，你就会明白这两者的区别了。

我现在养成的三个新习惯

1. 在宣布任何可能赔钱的任务“搞定”之前，我会问自己：哪一个具体的观察结果能改变我的判断？然后我就去执行那个检查。通常只需要一分钟和一条命令。
2. 我会提前在代码里加上日志行——这行日志只有在新代码跑过时才会出现。这样在你需要它之前，主信号就已经存在了。
3. 我会在报告结尾加一段“我没干啥”：没安装、没发布、没改动。这一段抓出的误解，比报告其他所有部分加起来还要多。

这个技能遵循 MIT 协议，没有自动运行钩子，直接复制文件夹就能用。它只是 Claude Code 一套工具箱里的一小部分，但这个“阶梯”规则并不依赖工具本身——这是一种汇报纪律，你可以把它接入任何 AI 助手流程，甚至用在人类代码审查中。

你的决定性信号是什么？我的几乎永远是一行日志——如果新代码没跑过，这行日志就不可能出现。

直达网址：https://github.com/Sanexxxx777/curated-claude-code/blob/main/skills/proof/SKILL.md