完成前的验证

概述

未经验证即宣称工作已完成，是不诚实行为，而非高效表现。

核心原则：先有证据，再作声明，始终如一。

违反本规则的字面表述，即等于违背其精神内核。

铁律

未提供最新验证证据，不得宣称完成

若你尚未运行本消息中指定的验证命令，则不得宣称其通过。

门控函数（Gate Function）

在宣称任何状态或表达满意之前：

1. 识别：哪条命令可证实该主张？
2. 运行：完整执行该命令（必须为全新、完整执行）
3. 阅读：完整查看输出，检查退出码，统计失败项数量
4. 验证：输出是否确凿支持该主张？
   - 若否：如实陈述当前状态，并附上证据
   - 若是：在陈述主张的同时，附上对应证据
5. 仅在此之后：方可正式作出该主张

跳过任一环节 = 撒谎，而非验证

常见失效情形

红色预警信号 —— 立即停止

• 使用“应该”、“大概”、“似乎”等模糊措辞
• 在验证完成前表达满意（如“太好了！”、“完美！”、“完成了！”等）
• 尚未验证即准备提交（commit）、推送（push）或创建 PR
• 轻信 Agent 的成功报告
• 依赖部分验证结果
• 心存侥幸：“就这一次而已”
• 因疲惫而急于收工
• 任何暗示成功但未实际运行验证的表述

规避合理化借口

关键实践模式

测试：

✅ [运行测试命令] [观察输出：34/34 通过] → 宣称“所有测试均通过”
❌ “现在应该能通过” / “看起来正确”

回归测试（TDD 红-绿循环）：

✅ 编写测试 → 运行（应失败）→ 实现修复 → 运行（应通过）→ 回退修复 → 运行（MUST FAIL）→ 恢复修复 → 运行（应通过）
❌ “我已编写了回归测试”（未执行红-绿验证流程）

构建：

✅ [运行构建命令] [观察输出：exit 0] → 宣称“构建成功”
❌ “Linter 通过了”（Linter 不检验编译过程）

需求达成：

✅ 重读方案 → 制作逐条清单 → 逐项验证 → 报告缺口或完成状态
❌ “测试通过，阶段完成”

Agent 协作委托：

✅ Agent 报告成功 → 检查 VCS diff → 验证变更内容 → 报告真实状态
❌ 直接采信 Agent 报告

为何如此重要

源自 24 次失败经验教训：

• 你的真人协作方说：“我不相信你”——信任已然崩塌
• 上线了未定义函数——将导致崩溃
• 遗漏需求被发布——功能不完整
• 因误判完成而浪费时间——被迫转向、返工
• 违反公司准则：“诚实是核心价值观。若你撒谎，将被替换。”

适用时机

ALWAYS 在以下操作前执行：

• 任何形式的成功/完成宣称
• 任何形式的满意表达
• 任何关于工作状态的正面陈述
• 提交（commit）、创建 PR、标记任务完成
• 转入下一任务
• 向 Agent 委派任务

本规则适用于：

• 完全一致的措辞
• 同义转述与近义表达
• 隐含的成功含义
• 任何暗示完成/正确性的沟通内容

根本结论

验证不可取巧。

务必运行命令，仔细阅读输出，然后——才可宣称结果。

此为不可协商的底线要求。