在声称任务完成、修复或通过前，如何用新鲜验证证据支撑结论

当你准备宣称工作已完成、已修复或测试通过，或准备提交/创建 PR 时，必须先运行验证命令并确认输出，再做出任何成功声明。

适用场景

解决思路

1. 识别：明确哪条命令能证明该声明。
2. 运行：执行完整命令（新鲜、完整地跑一遍）。
3. 读取：查看完整输出，检查退出码，统计失败数。
4. 验证：判断输出是否支持该声明；若否，则带证据说明实际状态；若是，则带证据陈述声明。
5. 只有完成以上步骤后，才做出声明；跳过任一步都等于撒谎而非验证。
6. 测试通过：需测试命令输出 0 失败，不能依赖上次运行或“应该会通过”。
7. Linter 干净：需 linter 输出 0 错误，不能靠部分检查或外推。
8. 构建成功：需构建命令退出码为 0，不能靠 linter 通过或日志看起来正常。
9. Bug 已修复：需测试原始症状通过，不能只靠改了代码就假定修好。
10. 回归测试有效：需验证 red-green 循环，不能只跑一次通过就算数。
11. Agent 已完成：需 VCS diff 显示变更，不能只信 agent 报告“成功”。
12. 需求已满足：需逐行核对清单，不能只靠测试通过。
13. 出现“应该”“可能”“似乎”等措辞时停止。
14. 在验证前表达满意（如“太好了！”“完美！”“搞定！”等）时停止。
15. 未验证就准备 commit/push/PR 时停止。
16. 信任 agent 成功报告时停止。
17. 依赖部分验证时停止。
18. 想“就这一次”时停止。
19. 因疲惫想赶紧收工时停止。
20. 任何暗示成功却未运行验证的措辞都要停止。
21. “现在应该能跑了”→ 去运行验证。
22. “我有信心”→ 信心不等于证据。
23. “就这一次”→ 没有例外。
24. “Linter 过了”→ Linter 不等于编译器。
25. “Agent 说成功了”→ 独立验证。
26. “我累了”→ 疲惫不是借口。
27. “部分检查够了”→ 部分检查证明不了什么。
28. “换个说法规则就不适用”→ 精神重于字面。
29. 测试模式：运行测试命令，看到 34/34 通过，再说“所有测试通过”；不要只说“现在应该能过”或“看起来没问题”。
30. 回归测试（TDD Red-Green）：写测试 → 运行（通过）→ 回退修复 → 运行（必须失败）→ 恢复修复 → 运行（通过）；不要只写回归测试而不做 red-green 验证。
31. 构建模式：运行构建，看到退出码 0，再说“构建通过”；不要说“Linter 过了”（linter 不检查编译）。
32. 需求模式：重读计划 → 创建清单 → 逐项验证 → 报告缺口或完成；不要只说“测试通过，阶段完成”。
33. Agent 委派模式：Agent 报告成功 → 检查 VCS diff → 验证变更 → 报告实际状态；不要直接信任 agent 报告。
34. 在任何成功/完成声明、任何满意表达、任何关于工作状态的正向陈述之前都要应用。
35. 在提交、创建 PR、任务完成、进入下一任务、委派给 agent 之前都要应用。
36. 规则适用于：原话、转述和同义词、成功暗示、任何暗示完成/正确的沟通。
37. 核心原则：证据先于声明，始终如此；违反规则字面就是违反规则精神。
38. 铁律：没有新鲜验证证据，不得声称完成。
39. 如果本条消息中没有运行过验证命令，就不能声称它通过。