完成前验证

在声称 「已完成」「已修复」「测试通过」，或在 提交、发 PR、结束任务 之前，必须先 在本轮对话中运行完整验证 并 根据实际输出 下结论。先有证据，再断言。

核心： 没有当次跑命令的证据，就不能声称成功。钻文字空子 = 违背精神。

铁律

没有本轮新鲜验证输出，不得声称完成或通过。

门禁（每条声称前）

认定：哪条命令能证明这句话？
执行：完整跑一遍（不是半截、不是记忆里的旧结果）。
阅读：完整输出、退出码、失败条数。
核对：输出是否支持你的说法？不支持 → 如实报告并贴证据；支持 → 再下结论并可引用关键输出。
跳过任一步 = 未验证 = 不可声称成功。

声称 vs 证据

| 声称 | 至少需要的证据 | 不能代替 | |------|----------------|----------| | 测试全过 | 测试命令显示 0 失败 | 上次跑过、「应该」能过 | | Lint 干净 | Linter 0 错误 | 只扫了部分文件 | | 构建成功 | 构建 exit 0 | Lint 通过 | | Bug 已修 | 复现用例已绿 | 只改了代码没跑 | | 回归测试有效 | 红—绿—再红—再绿验证过 | 只写测没走循环 | | 代理干完了 | 看 VCS diff 并验证 | 代理口头成功 | | 需求满足 | 逐条对照清单 | 仅「测试过了」 |

红旗

「应该」「大概」「似乎」配合成功结论；验证前就「太好了」「搞定」；信代理报告不独立跑命令；部分验证当全部；「就这一次」；累了想收工；任何暗示成功却未跑命令。

借口 vs 现实

「应该好了」→ 去跑。「我有信心」→ 信心不是证据。「只此一次」→ 没有例外。「Lint 过了」≠ 编译过。「代理说成了」→ 自己验证。「累了」→ 不是理由。

模式示例

测试：✅ 贴命令与「34/34 通过」再说话。
回归：✅ 写测 → 绿 → 故意拆掉修复 → 必须红 → 恢复 → 绿。
构建：✅ 跑构建见 exit 0。
需求：✅ 重读计划做清单逐项打勾。
代理：✅ 看 diff + 自己跑验证。

为何重要

虚假完成会破坏信任、把未定义函数/缺需求上线、浪费返工时间；诚实是底线。

适用范围

任何暗示完成、正确、满意、进展顺利的说法（含换种说法）；提交、PR、切任务、再派代理之前。同义改写也算，不要玩文字游戏。

结论

验证没有捷径。 跑命令、读输出、再下结论。不可协商。