在宣称完成/修复/通过前，如何用可复现的验证证据支撑结论

任何变更在说“done/fixed/passing/shipped”之前，先在其真实运行表面驱动变更、运行验证命令并如实报告结果。

适用场景

解决思路

1. 在变更的真实表面驱动它并捕获其行为：运行在运行系统中执行被改代码的最小路径（见“在表面验证”一节）。
2. 运行验证命令并粘贴其输出：验证命令来自变更前的检查点，用于证明各关卡成立，其真实输出支撑结论；引用前先对输出中的敏感值做脱敏（密钥卫生由 operating-safely 负责）。"已验证"永远是 "PASS（检查了 X 和 Y）"，绝不是光秃秃一个对勾。
3. 如实报告，双向都要：失败测试连同输出一起报告，跳过的步骤明确标注为跳过，已验证的工作平实陈述、不要含糊其辞。低报已验证的工作会像高报一样浪费读者的重新验证成本。
4. 不信任绿色：一个不可能工作的代码却套着绿色测试套件，说明套件没跑、没覆盖或不会失败。当结果对于变更规模来说过于干净时，确认测试确实执行了（单独运行它、看它出现），并确认它能失败（破坏代码、看它变红、再恢复）。从未运行的测试和从未触发的关卡会产出自信的错误“完成”。
5. 区分层级：已实现（在仓库里）≠ 已部署（上线）≠ 已外部验证（在外部系统中确认）。绝不能用较早层级的证据去声称较晚层级。
6. 宣布完成前做回看：扫一遍 diff——没有无关改动、代码或注释中没有规划残留、文档在同一次变更中更新、每条验收标准都真正满足而不是近似满足。
7. 顶级变更需独立验证：变更作者是最不适合验证它的人。对于项目声明的关键路径（资金、销售、存储数据、安全，以及系统绝不能出错的任何部分）和不可逆迁移，验证者必须是没有写这段代码的人或物。若无法及时找到独立验证者，就用最接近的替代方案，并明确说明它是较弱形式；悄悄降级检查才是失败，显式降级则是一个决策。
8. 在表面验证：在运行系统中驱动执行被改代码的最小路径。用设置好的标志运行被改的标志、给被改的处理器发送请求、触发被改错误路径的错误。内部函数不是表面：它的调用方终止于某个表面，所以要在那里观察。
9. 把测试当作作者提供的证据，而不是验证本身。测试说明该驱动什么；关卡会重新运行它。
10. 在变更旁边探测：快乐路径确认结论；邻近情况检验它——空值、重复调用、冲突选项、变更未触及的相邻错误。至少探测一个超出结论的点；即使探测通过也要报告，因为它说明了覆盖了什么。
11. 引用系统实际产生的内容：响应体、终端输出、渲染出的屏幕支撑结论。引用前先脱敏：令牌、连接字符串、认证头。把含糊的输出当作失败并附上脱敏后的原始捕获，绝不把它解读成通过。
12. 没有运行时表面时就明说“无运行时表面”：文档、注释、类型声明不产生行为，就以这一点作为验证，绝不用替代的关卡运行来填空。
13. 绝不实时驱动破坏性路径：当被改代码会删除或写入工作区之外且没有安全目标时，绕开它验证并点名未执行的路径（防护由 operating-safely 负责）。
14. 自己负责失败的关卡：先归因来源，然后无论测试是谁的都要修。"预先存在"是报告里的脚注，绝不是关卡里的借口。唯一例外是流程性的：主分支上预先存在的红色阻塞了一个无关的绿色修复时，把它暴露出来并提议仍然合并绿色修复，由操作者决定。
15. 避免常见错误：不要因为 diff 看起来对就宣布完成（diff 是假设，表面运行才是实验）；不要跑整个套件而不是针对性验证命令并把“没有新失败”读成“我的变更有效”；不要重跑关卡就称之为验证；不要验证风险在失败路径的变更的快乐路径；不要用“本地测试通过”作为风险在环境（配置、迁移、权限、生产数据形态）的变更的最终结论；不要因为红色不方便就改测试而不是改代码。

适用边界 · 注意事项

• 变更没有运行时表面（如纯文档、注释、类型声明）时，不要用替代的关卡运行来充当验证。
• 被改代码会删除或写入工作区之外且没有安全目标时，不要实时驱动破坏性路径。
• 无法及时找到独立验证者时，不要悄悄降级检查；可以显式降级并说明它是较弱形式。