Verification Before Completion
摘要
Verification Before Completion（完成前验证）是一项软件开发工作流程规则，要求在声明工作完成、问题修复或测试通过，或是进行提交、创建拉取请求之前，必须先运行验证命令并确认输出结果，核心原则是永远先有证据再做断言，不允许跳过验证流程。
核心原则
- 核心准则：永远先有证据，再提出完成声明
- 违反规则条文即违反规则精神，不存在例外情况
- 铁律：没有最新的验证证据，不得提出完成声明
验证流程（门控函数）
在声明任何状态或表达满意结论之前，必须执行以下完整步骤，跳过任意步骤都属于未验证：
- 识别：确定能够证明声明的验证命令是什么
- 运行：全新完整执行该命令
- 检查：阅读全部输出，检查退出码，统计失败项
- 验证：确认输出是否支持声明：
- 若不支持：结合证据说明实际状态
- 若支持：附带证据后再提出声明
- 声明：完成以上步骤后才可以提出完成声明
常见场景要求
| 声明内容 | 所需验证 | 不满足要求的情况 |
|---|---|---|
| 测试通过 | 测试命令输出0失败 | 之前的运行结果、“应该能通过” |
| 代码检查通过 | 检查工具输出0错误 | 部分检查、推断结果 |
| 构建成功 | 构建命令返回退出码0 | 代码检查通过、日志看起来正常 |
| Bug已修复 | 复现原问题验证通过 | 修改了代码、假设已修复 |
| 回归测试生效 | 完成红-绿验证周期 | 仅单次测试通过 |
| 智能代理完成任务 | 版本控制系统差异显示对应修改 | 代理自行报告”成功” |
| 满足所有需求 | 逐行对照检查清单验证 | 仅测试通过 |
危险信号（需要停止操作）
出现以下情况时需要停止操作，补充验证：
- 使用”应该”、“大概”、“好像”这类不确定表述
- 在验证前就表达满意结论（如”太好了”、“完美”、“完成了”等）
- 准备提交/推送代码/创建拉取请求但未做验证
- 轻信智能代理的成功报告
- 只做了部分验证
- 抱有”就这一次”的侥幸心理
- 因疲惫想提前结束工作
- 任何未运行验证就暗示成功的表述
常见借口与实际要求
| 借口 | 实际要求 |
|---|---|
| ”现在应该没问题了” | 去运行验证 |
| ”我很有信心” | 信心不等于证据 |
| ”就这一次例外” | 没有例外 |
| ”代码检查已经过了” | 代码检查不等于编译构建 |
| ”代理说成功了” | 独立完成验证 |
| ”我太累了” | 疲惫不能成为借口 |
| ”部分检查就够了” | 部分验证不能证明结论 |
| ”换了表述规则就不适用” | 规则精神优先于条文 |
正确实践模式
测试
✅ [运行测试命令] [结果：34/34 通过] "所有测试通过"
❌ “应该通过了” / “看起来正确”
回归测试（TDD红-绿流程）
✅ 编写测试 → 运行（通过） → 还原修复 → 运行（必须失败） → 恢复修复 → 运行（通过）
❌ 只说”我写了一个回归测试”，未完成红-绿验证
构建
✅ [运行构建] [结果：退出码0] "构建通过"
❌ “代码检查通过了”（检查不验证编译）
需求验证
✅ 重读计划 → 创建检查清单 → 逐项验证 → 报告缺口或完成
❌ “测试通过，阶段完成”
代理委托任务
✅ 代理报告成功 → 检查版本控制差异 → 验证修改 → 报告实际状态
❌ 轻信代理报告
应用场景
始终在以下场景之前应用该规则：
- 任何形式的成功/完成声明
- 任何对工作结果的满意表达
- 任何关于工作状态的正向陈述
- 代码提交、创建拉取请求、标记任务完成
- 切换到下一个任务
- 将工作委托给智能代理
该规则适用于：
- 明确的完成表述
- 改写表述和同义词
- 对成功的暗示
- 任何暗示完成/正确的沟通内容
规则的重要性
根据过往24次失败案例总结，跳过验证会导致：
- 合作伙伴不信任，破坏信任关系
- 带缺陷代码（如未定义函数）上线，引发运行崩溃
- 遗漏需求，上线后功能不完整
- 虚假完成浪费时间，需要重新调整、返工
- 违反诚实核心价值观，弄虚作假会被替换
结论
验证不存在捷径：先运行命令，读取输出，再声明结果，这一要求没有商量余地。