什么是Verification Before Completion
Verification Before Completion（提交前验证）是一套严格的开发行为规范，其核心原则是‘证据优先于声明’——任何关于工作完成、问题修复或功能通过的断言，都必须以实际运行验证命令后的输出结果作为依据。这一规则强调在代码提交、创建拉取请求（PR）或声称任务完成之前，开发者必须首先执行完整的验证流程，确认所有测试通过、构建成功、需求满足等关键指标，才能做出相应的成功声明。它并非追求效率而牺牲诚信，而是将诚实作为开发过程中的基石：没有经过验证的证据，就不应做出任何关于工作状态的正面论断。该规范适用于所有涉及质量保障的场景，从单元测试到回归测试，从代码静态检查到编译构建，确保每一次进展都有可验证的事实支撑。
核心功能特点
- 在提交代码或创建PR前，必须先运行验证命令并检查其完整输出，才能声称工作已完成或问题已修复。
- 强调‘证据先于论断’的核心原则，禁止在没有实际验证的情况下做出任何关于成功的声明。
- 提供了一套具体的验证步骤：识别验证命令、执行完整命令、读取全部输出、检查结果，最后才允许做出声明。
- 列举了常见失败模式，如依赖之前的运行结果、部分检查、代理报告的成功等，这些都不足以作为验证证据。
- 包含多种场景下的正确实践示例，如测试通过、回归测试的红绿循环、构建成功和需求逐项核对。
适用场景
这套规范尤其适用于需要高度可靠性和可追溯性的软件开发场景。例如，在编写单元测试时，开发者不能仅凭感觉认为代码‘应该能过’，而必须在本地运行完整的测试套件，看到明确的‘0 failures’或类似的成功输出后，才能宣称‘所有测试通过’。对于采用测试驱动开发（TDD）的团队而言，规范的回归测试流程至关重要：在修复一个bug后，必须首先确保新编写的测试能捕捉到该bug（红色阶段），然后修复代码使测试通过（绿色阶段），最后再撤销修复以确认测试确实能检测到问题——这一红绿循环的验证过程是保证回归测试有效性的关键。在构建和部署环节，开发者也不能仅因静态分析工具（如linter）报告无错误就认为编译会成功；正确的做法是独立运行构建命令，检查其退出码是否为0，并确认最终产物符合预期。此外，当使用AI助手或自动化代理完成任务时，绝不能盲目信任其‘成功’报告，而应主动检查版本控制系统（VCS）中的实际变更，并重新验证相关功能是否按预期工作。这些场景共同体现了‘Verification Before Completion’规范的价值：它通过强制性的验证步骤，将主观臆断转化为客观事实，从而显著降低因虚假声明而导致的生产环境故障、时间浪费和团队信任危机。