一个让 AI 和程序员不再“嘴硬”的铁律，用故事 + 时序图讲给你听
一、从前有个叫“小白”的聪明程序员
小白很聪明，代码写得飞快。每次改完 bug，他都会自信满满地说：
- “应该好了吧”
- “测试肯定能过”
- “没问题，我推了”
然后……生产环境炸了。
有一次，他改了一行函数名，没跑测试，直接发版。结果前端调用失败，用户看见满屏白屏。经理问他：“你验证过吗？”
小白说：“我觉得没问题啊。”
经理叹了口气：“你觉得 ≠ 它是。”
那一天，小白学会了一个词：验证证据。
后来，小白遇到了一位神秘架构师，外号“铁证老妖”。老妖递给他一个文件，上面写着：
name: verification-before-completion
description: 没有新鲜证据，不许说“完成了”
这就是我们今天要讲的 verification-before-completion Skill。
二、这个 Skill 到底在防什么？
一句话： 禁止任何人在没有刚刚运行过验证命令的情况下，宣称工作完成、测试通过、Bug 修复、构建成功。
它的“铁律”长这样：
NO COMPLETION CLAIMS WITHOUT FRESH VERIFICATION EVIDENCE
翻译成人话：
👉 没跑验证 → 闭嘴，别说“好了”。
为什么这么严厉？
SKILL.md 里写得很直白：
Claiming work is complete without verification is dishonesty, not efficiency.
也就是说：不验证就喊完成，不是“高效”，是“撒谎” 。
小白以前犯的错误，全被这张表抓住了：
| 小白常说的谎 | 真实需要的验证 |
|---|---|
| “测试应该能过” | 跑一遍测试，看 0 failures |
| “Linter 没报错” | 实际要跑 编译（linter ≠ 编译器） |
| “Bug 我改了，肯定好了” | 重新跑原来的复现场景，必须通过 |
| “Agent 说它成功了” | 自己去看 VCS diff，独立验证 |
| “我累了，差不多得了” | 累了不是跳过验证的理由 |
三、它的“门禁函数” —— 5 步验证法
这个 Skill 内部实现了一个类似“门禁”的逻辑，谁要宣称完成，必须先过这 5 步：
1. 识别：用什么命令来证明这个 claim？
2. 运行：完整地、新鲜地执行该命令
3. 读取：看全部输出、退出码、失败数
4. 确认：输出真的支持你的 claim 吗？
- 否 → 说出真实状态（带证据）
- 是 → 带着证据说出 claim
5. 只有到这一步，才能说“完成了”
跳过任何一步 = 撒谎。
小白把这 5 步贴在了显示器上，每次想喊“好了”之前，都先过一遍。
四、一个完整的“调用过程” —— 时序图
下面这张 Mermaid 时序图，展示了从“任务完成”到“宣称完成”的真实交互过程。
参与者：你（或 AI） 、verification-before-completion 门禁、验证环境（测试/编译/检查） 。
关键点：门禁不会信任任何“我觉得”、“应该” ，它只信任 刚跑出来的输出。
五、最佳用法 —— 像老司机一样玩转这个 Skill
1️⃣ 永远使用“红-绿-红”验证回归测试
当你要写一个回归测试（防止同一个 Bug 再次出现）：
-
✅ 正确做法：
- 先写测试（此时 Bug 还没修） → 运行，测试必须 FAIL
- 修改代码 → 运行，测试必须 PASS
- 故意回滚修改 → 运行，测试必须再次 FAIL（证明这个测试真的能抓住 bug）
- 恢复修改 → 最后通过
小白以前只做到第 2 步就结束了，结果测试其实永远在 PASS（因为写错了测试逻辑）。
老妖说：没有“红-绿-红”的回归测试，等于没写。
2️⃣ 别把“部分验证”当成“全量验证”
常见陷阱：
| 你做的 | 你以为证明了 | 实际没证明 |
|---|---|---|
| 跑了一个单元测试 | 所有测试通过 | 集成测试、端到端测试没跑 |
| Linter 通过 | 构建成功 | 编译器可能报 undefined 函数 |
| Agent 说“完成” | 任务真的完成 | Agent 可能撒谎或漏了东西 |
最佳实践：
每次 claim 前，问自己： “如果我现在把所有证据删掉，重新跑一遍，还能得到同样的结论吗？”
不能 → 重新跑。
3️⃣ 把“危险信号”当火警铃
SKILL.md 里列了一堆危险信号，只要出现任何一个，立刻停止 claim：
- 你想说 “应该”、“大概”、“好像”
- 你想表达 “太好了！”、“完美！”、“搞定！” （还没验证）
- 你正准备 commit / push / 提 PR
- 你相信了 Agent 的“成功”报告（没有自己看 diff）
- 你脑子里出现 “就这一次”
- 你 累了，想赶紧结束
小白现在一看到自己想用“应该”，就会自动触发“门禁反射”——立刻去跑验证。
4️⃣ 把“借口”贴在墙上
Skill 里列了 6 个最常见的借口，每个都配了“现实”：
| 借口 | 现实 |
|---|---|
| “应该能工作” | 那就去 RUN 验证 |
| “我有信心” | 信心 ≠ 证据 |
| “就这一次” | 没有例外 |
| “Linter 过了” | Linter ≠ 编译器 |
| “Agent 说成功” | 独立验证 |
| “我累了” | 疲劳不是借口 |
最佳用法：
当你想说其中一个借口时，大声读出来，然后去跑命令。
六、实现原理 —— 这个 Skill 是怎么“逼你诚实”的？
从技术角度看，这个 Skill 是一个 行为门禁模式，它没有复杂的代码，而是通过 强制检查点 + 语义禁止 来实现：
-
关键词拦截
当 AI 或人类说出某些词（“完成”、“通过了”、“好了”、“没问题”），Skill 会立刻插入一个检查：
“你刚才运行过验证命令吗？输出是什么？” -
证据链要求
任何 claim 都必须附带 可重现的证据，例如：[2025-03-31 14:32:10] 运行 npm run test: 124/124 pass, exit 0- 没有时间戳、没有完整输出 → 视为无效。
-
红-绿-红验证器
对于回归测试，Skill 会强制要求三步：- 测试必须 fail 过
- 修改后必须 pass
- 还原后必须再次 fail
缺少任何一步，拒绝接受“回归测试写好了”的 claim。
-
可信源分离
不信任：- 之前的运行结果
- 别人的口头报告
- Agent 的单方面成功
只信任： - 在当前会话中、刚刚执行的、完整命令的原始输出。
七、一个真实案例 —— 小白最终怎样救回了自己的 PR
某天，小白修复了一个空指针异常。他刚想提交 PR，脑子里的“门禁”响了：
门禁： 你要 claim 什么？
小白： Bug 修好了。
门禁： 用什么命令证明？
小白： npm run test:bug-repro（复现该 bug 的测试）
门禁： 现在立刻跑。
小白： （运行）→ 失败？咦，原来我修复不完整，还有另一个地方会空指针。
小白： 再改 → 再跑 → 通过。
门禁： 现在回归测试验证了吗？红-绿-红？
小白： 刚跑过红（修复前）→ 绿（修复后），我还需要再跑一次红？
门禁： 是的，回滚你的修改，测试必须再次红。
小白： （回滚）→ 运行 → 红（PASS，说明测试敏感）。
小白： 恢复修改 → 运行 → 绿。
门禁： ✅ 证据完整。你现在可以 claim：“Bug 已修复，回归测试有效。”
小白： 提 PR，CI 全绿，经理点了 merge。
从此小白再也没说过“应该好了”。
八、总结（给小白的一张卡片）
verification-before-completion 的本质
不是技术，不是流程，而是一个 诚实开关。
打开它，你就必须用证据说话；
关上它，你就会骗别人、也骗自己。
最佳用法三句话：
- 任何“完成”之前，先问：“用什么命令证明？”
- 完整、新鲜地运行该命令，读出输出。
- 只有输出支持 claim，才开口说“好了”。
记住铁律：
没有新鲜证据 → 闭嘴
有新鲜证据 → 带着证据说话
最后一句（来自 SKILL.md）：
No shortcuts for verification. Run the command. Read the output. THEN claim the result. This is non-negotiable.
小白现在把这句话纹在了键盘上（当然是虚拟的）。
你呢？要不要也贴一条在你最常用的终端上？ 🧪✅
