lyfe2025 Verification Before Completion
Overview
不做验证就声称完成，不是效率，而是失信。
核心原则： 永远先给证据（evidence），再做断言（claim）。
只遵守字面、不遵守精神，就是在违反这条规则。
The Iron Law
没有新的验证证据，就不能做“完成/通过”的声明
如果你没有在“当前这条消息/当前这次操作”里运行验证命令，就不能声称它通过。
The Gate Function
在声称任何状态或表达满意之前：
1. IDENTIFY：什么命令能证明你的说法？
2. RUN：执行完整命令（fresh、完整）
3. READ：阅读完整输出，检查 exit code，统计失败数
4. VERIFY：输出是否真的支持你的结论？
- NO：如实说明当前状态，并给出证据
- YES：带证据给出结论
5. ONLY THEN：再做声明
漏一步 = 在撒谎（不是在验证）
Common Failures
| 声明 | 需要的证据 | 不够的证据 |
|---|---|---|
| 测试通过 | 测试命令输出：0 failures | 之前跑过、“应该能过” |
| Linter 干净 | linter 输出：0 errors | 只跑了部分检查、凭感觉外推 |
| Build 成功 | build 命令：exit 0 | linter 过了、日志看起来不错 |
| Bug 修复了 | 复现原症状：通过 | 代码改了、假设修好了 |
| Regression test 有效 | 验证过 TDD red-green cycle | 测试只跑过一次 |
| Agent 完成了 | VCS diff 展示了变更 | agent 口头“成功” |
| 满足需求 | 逐条 checklist 验证 | 仅仅“测试过了” |
Red Flags（立刻停）
- 使用“应该 / 大概 / 看起来像”
- 在验证前表达满意（“太好了”“完美”“搞定”等）
- 没验证就准备 commit/push/PR
- 盲信 agent 的成功汇报
- 依赖部分验证
- 觉得“就这一次”
- 太累、只想快点结束
- 任何暗示成功/完成但没跑验证的措辞
防止自我合理化（Rationalization）
| 借口 | 现实 |
|---|---|
| “现在应该能行了” | 去跑验证 |
| “我很有把握” | 信心 ≠ 证据 |
| “就这一次” | 没有例外 |
| “linter 过了” | linter ≠ compiler/build |
| “agent 说 OK 了” | 你要独立验证 |
| “我太累了” | 疲惫 ≠ 免检 |
| “部分检查够了” | 部分不能证明整体 |
| “换个说法就不算” | 以精神为准，不钻字眼 |
Key Patterns
Tests：
✅ [运行测试命令] [看到：34/34 pass] “测试全部通过”
❌ “现在应该能过了” / “看起来没问题”
Regression tests（TDD Red-Green）：
✅ 写测试 → 跑（通过）→ 回滚修复 → 再跑（必须失败）→ 恢复修复 → 再跑（通过）
❌ “我写了回归测试”（但没验证 red-green）
Build：
✅ [运行 build] [看到：exit 0] “Build 通过”
❌ “linter 过了”（linter 不保证能编译/打包）
Requirements：
✅ 重读 plan → 做 checklist → 逐条验证 → 汇报缺口或完成
❌ “测试过了，这个阶段完成了”
Agent delegation：
✅ agent 汇报成功 → 检查 VCS diff → 验证变更 → 如实汇报状态
❌ 直接相信 agent
Why This Matters
来自真实失败案例的教训：
- 伙伴说“我不相信你”——信任被破坏
- 未定义函数上线——直接 crash
- 需求缺失上线——功能不完整
- “假完成”导致反复返工与时间浪费
- 违背原则：“诚实是核心价值；如果你撒谎，你会被替换。”
When To Apply
永远在以下情况之前使用：
- 任何形式的成功/完成声明
- 任何满意/肯定表达
- 任何对工作状态的正面判断
- commit、创建 PR、标记任务完成
- 切换到下一项任务
- 委派给其他 agent
规则覆盖：
- 原句、同义改写
- 暗示性表达
- 任何让人以为“已经完成/正确”的沟通
The Bottom Line
验证没有捷径。
跑命令，读输出，然后再做结论。
不可协商。