完成前的验证

概述

未经验证就声称工作已完成，这不是效率，而是不诚实。

核心原则：始终用证据说话，再下结论。

违背此规则的文字表述就是违背此规则的精神。

铁律

没有全新的验证证据，就不能声称工作已完成

如果你没有在当前消息中运行验证命令，就不能声称测试通过了。

关卡功能

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

1. 识别：哪个命令可以证明这个主张？
2. 运行：执行完整的命令（全新的、完整的）
3. 读取：完整输出，检查退出代码，统计失败数量
4. 验证：输出结果是否证实了该主张？
   - 如果否：用证据说明实际状态
   - 如果是：用证据来支持主张
5. 只有这样：才能做出该主张

跳过任何一步 = 撒谎，而非验证

常见失败案例

危险信号 – 停止

• 使用“应该”、“可能”、“看起来”这类词语
• 在验证前表达满意（“太好了！”、“完美！”、“完成了！”等）
• 即将在未经验证的情况下提交/推送/创建拉取请求
• 相信智能体的成功报告
• 依赖部分验证
• 心想“就这一次”
• 感到疲惫，希望工作赶紧结束
• 任何在未运行验证的情况下暗示成功的措辞

防止找借口

关键模式

测试：

✅ [运行测试命令] [看到：34/34 通过] “所有测试通过”
❌ “现在应该能通过了” / “看起来正确”

回归测试（TDD 红-绿）：

✅ 编写 → 运行（通过）→ 撤销修复 → 运行（必须失败）→ 恢复 → 运行（通过）
❌ “我已经写了一个回归测试”（未经红-绿验证）

构建：

✅ [运行构建] [看到：退出码 0] “构建通过”
❌ “代码检查通过了”（代码检查不检查编译）

需求：

✅ 重新阅读计划 → 创建清单 → 验证每一项 → 报告差距或完成情况
❌ “测试通过，阶段完成”

智能体委派：

✅ 智能体报告成功 → 检查版本控制系统差异 → 验证更改 → 报告实际状态
❌ 相信智能体的报告

为何这很重要

来自 24 次失败教训：

• 你的伙伴说“我不相信你” – 信任破裂
• 未定义的函数被发布 – 会导致崩溃
• 缺失的需求被发布 – 功能不完整
• 时间浪费在虚假完成上 → 重定向 → 返工
• 违反了：“诚实是核心价值观。如果你撒谎，你将被替换。”

何时应用

在任何情况下，始终在以下操作之前进行验证：

• 任何形式的成功/完成主张
• 任何形式的满意表达
• 任何关于工作状态的正面陈述
• 提交、创建拉取请求、任务完成
• 进入下一个任务
• 委派给智能体

规则适用于：

• 确切的词语
• 同义词和转述
• 暗示成功的含义
• 任何暗示完成/正确的沟通

底线

验证没有捷径。

运行命令。读取输出。然后，才能声称结果。

这一点没有商量余地。