在声称「已完成/已修复/已通过」之前…

当你即将提交、建 PR、宣布任务完成，或想表达「应该能过/没问题」时，先运行能证明该声明的命令并读出结果，再下结论。

适用场景

解决思路

1. 在任何完成声明前执行门控函数五步：① IDENTIFY：确定哪个命令能证明这条声明；② RUN：完整、重新地执行该命令（不用旧结果、不做部分检查）；③ READ：读完整输出，检查退出码，统计失败数；④ VERIFY：判断输出是否支持该声明——不支持就只陈述实际状态+证据；支持才带着证据陈述；⑤ ONLY THEN：此时才做出声明。跳过任何一步都等于撒谎而非验证。
2. 遵守铁律：NO COMPLETION CLAIMS WITHOUT FRESH VERIFICATION EVIDENCE——如果本条消息里没有跑过验证命令，就不能声称它通过；没有新鲜验证证据就不能声称完成。
3. 按声明类型准备对应证据，不充分证据一律不采信：测试通过 → 需要测试命令输出 0 failures（上次运行结果、「应该能过」不算）；linter 干净 → 需要 linter 输出 0 errors（部分检查、外推不算）；构建成功 → 需要构建命令 exit 0（linter 通过、日志看起来不错不算）；Bug 已修复 → 需要测原始症状的测试通过（改了代码就假定修好不算）；回归测试有效 → 需要验证过 red-green 循环（测试只通过一次不算）；Agent 已完成 → 需要 VCS diff 显示改动（agent 自报 success 不算）；需求满足 → 需要逐行 checklist 核对（测试通过不算）。
4. 遇到红旗信号立即停止：使用 should / probably / seems to；验证前就表达满意（Great!、Perfect!、Done! 等）；未验证就要 commit/push/PR；信任 agent 的成功报告；依赖部分验证；心想「就这一次」；因为累了想把活赶紧结束；任何暗示成功却没有跑验证的措辞。
5. 用借口对照表自我纠正：想「现在应该能跑了」→ 去跑验证；想「我有信心」→ 信心不等于证据；想「就这一次」→ 没有例外；想「linter 过了」→ linter 不等于编译器；想「agent 说成功了」→ 独立验证；想「我累了」→ 疲惫不是借口；想「部分检查够了」→ 部分检查证明不了任何事；想「换个说法规则就不适用了」→ 按精神执行而非字面。
6. 测试场景写法：运行测试命令并看到 34/34 通过后，才说「全部测试通过」；不要说「现在应该能过了」或「看起来是对的」。
7. 回归测试场景（TDD red-green）：写测试 → 运行（通过）→ 回退修复 → 运行（必须失败）→ 恢复修复 → 运行（通过），完成这个 red-green 循环验证后，才声称写了有效的回归测试。
8. 构建场景：运行构建命令并看到 exit 0 后，才说「构建通过」；不要拿「linter 通过」当作构建通过的证据。
9. 需求场景：重读计划 → 建 checklist → 逐项验证 → 报告缺口或完成情况；不要用「测试通过，本阶段完成」代替逐条核对。
10. 委派 Agent 场景：agent 报告成功后，检查 VCS diff → 验证改动 → 报告实际状态；不要直接信任 agent 的报告。
11. 按精神扩大适用范围：对精确措辞、同义改写、暗示成功、任何暗示完成/正确的沟通都同样适用；在提交、创建 PR、任务完成、进入下一个任务、委派 agent 之前都要执行此流程。
12. 守住底线：验证没有捷径——跑命令，读输出，然后才说结果，这一点不可协商。

适用边界 · 注意事项

• 当环境中确实无法运行任何验证命令时（缺少依赖、无构建/测试工具、无网络等），不要退化为凭推断或凭自信下结论，也不能套用「验证后再声明」的流程；此时只能如实报告『未验证』及原因。