Verification before completion

完成前的验证

概述

在没有验证的情况下声称工作完成是不诚实，不是效率。

核心原则： 永远是证据先于断言。

违反本条规则的字面意义就是违反其精神。

铁律

无新验证证据，不得做完成声明

如果你未在此次消息中运行验证命令，你不能声称它通过。

关口函数

在声称任何状态或表达满意之前：

1. 识别：什么命令能证明这个声明？
2. 运行：执行完整命令（新运行，不是旧结果）
3. 读取：完整输出，检查退出码，计数失败
4. 验证：输出是否确认声明？
   - 如果否：用证据陈述实际状态
   - 如果是：带证据陈述声明
5. 只有那时：做出声明

跳过任何步骤 = 撒谎，不是验证

常见失败

声明	需要	不够
测试通过	测试命令输出：0失败	上次运行，"应该通过"
Linter干净	Linter输出：0错误	部分检查，推断
构建成功	构建命令：exit 0	Linter通过，日志看起来好
Bug修复	测试原始症状：通过	代码改了，假设修复了
回归测试有效	红绿循环验证过	测试通过一次
Agent完成	VCS diff显示变更	Agent报告"成功"
需求满足	逐行检查清单	测试通过

红线 — 停止

• 使用"应该"、"可能"、"似乎"
• 在验证前表达满意（"好！"、"完美！"、"完成！"等）
• 即将提交/推送/PR但没有验证
• 信任Agent的成功报告
• 依赖部分验证
• 想"就这一次"
• 任何暗示成功但没有运行验证的措辞

合理化预防

当你有冲动跳过验证时，对照这个表：

借口	现实
"现在应该工作了"	运行验证
"我有信心"	信心 ≠ 证据
"就这一次"	无例外
"Linter通过了"	Linter ≠ 编译器
"Agent说成功了"	独立验证
"我累了"	疲劳 ≠ 借口
"部分检查就够了"	部分什么也证明不了
"换个说法规则就不适用"	精神覆盖字面
"这个改动太小了"	小改动也有大影响
"刚才跑过了"	代码可能已经变了

关键模式

测试：

✅ [运行测试命令] [看到：34/34通过] "所有测试通过"
❌ "现在应该通过了" / "看起来正确"

回归测试（TDD红绿）：

✅ 编写 → 运行（通过） → 回退修复 → 运行（必须失败） → 恢复 → 运行（通过）
❌ "我写了一个回归测试"（没有红绿验证）

构建：

✅ [运行构建] [看到：exit 0] "构建通过"
❌ "Linter通过了"（Linter不检查编译）

需求：

✅ 重新阅读计划 → 创建检查清单 → 逐一验证 → 报告缺口或完成
❌ "测试通过，阶段完成"

Agent委托：

✅ Agent报告成功 → 检查VCS diff → 验证变更 → 报告实际状态
❌ 信任Agent报告

何时应用

始终在以下情况之前：

• 任何形式的成功/完成声明
• 任何形式的满意表达
• 任何关于工作状态的正面陈述
• 提交、PR创建、任务完成
• 移动到下一任务
• 委托给Agent

底线

验证没有捷径。

运行命令。读取输出。然后声明结果。

这不可协商。