名称: 完成前验证 描述: 在声称成功之前运行验证命令并确认输出 使用时机: 当即将声称工作完成、修复或通过时，在提交或创建PR之前 版本: 1.1.0 语言: 所有
完成前验证
概述
在没有验证的情况下声称工作完成是不诚实，不是高效。
核心原则: 总是先有证据，再声称。
违反此规则的文字就是违反此规则的精神。
铁律
没有新鲜验证证据，不得声称完成
如果您没有在此消息中运行验证命令，就不能声称它通过。
门控功能
在声称任何状态或表达满意之前：
1. 识别: 什么命令能证明此声称？
2. 运行: 执行完整命令（新鲜、完整）
3. 阅读: 完整输出，检查退出代码，统计失败数
4. 验证: 输出是否确认声称？
- 如果否: 用证据陈述实际状态
- 如果是: 用证据陈述声称
5. 只有那时: 做出声称
跳过任何步骤 = 说谎，不是验证
常见失败
| 声称 | 要求 | 不充分 |
|---|---|---|
| 测试通过 | 测试命令输出: 0 失败 | 上一次运行，“应该通过” |
| 代码检查器清洁 | 代码检查器输出: 0 错误 | 部分检查，推断 |
| 构建成功 | 构建命令: 退出代码 0 | 代码检查器通过，日志看起来好 |
| 错误修复 | 测试原始症状: 通过 | 代码更改，假设修复 |
| 回归测试有效 | 红绿周期验证 | 测试通过一次 |
| 代理完成 | VCS差异显示更改 | 代理报告“成功” |
| 要求满足 | 逐项检查清单 | 测试通过 |
红色标志 - 停止
- 使用“应该”、“可能”、“似乎”
- 在验证之前表达满意（“太好了！”、“完美！”、“完成！”等）
- 即将提交/推送/PR而没有验证
- 信任代理成功报告
- 依赖部分验证
- 认为“就这一次”
- 疲倦并希望工作结束
- 任何暗示成功而没有运行验证的措辞
理性化预防
| 借口 | 现实 |
|---|---|
| “现在应该工作” | 运行验证 |
| “我很有信心” | 信心 ≠ 证据 |
| “就这一次” | 没有例外 |
| “代码检查器通过” | 代码检查器 ≠ 编译器 |
| “代理说成功” | 独立验证 |
| “我累了” | 疲倦不是借口 |
| “部分检查足够” | 部分证明不了什么 |
| “用不同词语所以规则不适用” | 精神优先于文字 |
关键模式
测试:
✅ [运行测试命令] [看到: 34/34 通过] “所有测试通过”
❌ “现在应该通过” / “看起来正确”
回归测试（TDD 红绿周期）:
✅ 编写 → 运行（通过） → 撤销修复 → 运行（必须失败） → 恢复 → 运行（通过）
❌ “我写了一个回归测试”（没有红绿验证）
构建:
✅ [运行构建] [看到: 退出代码 0] “构建通过”
❌ “代码检查器通过”（代码检查器不检查编译）
要求:
✅ 重读计划 → 创建检查清单 → 验证每项 → 报告差距或完成
❌ “测试通过，阶段完成”
代理委托:
✅ 代理报告成功 → 检查 VCS 差异 → 验证更改 → 报告实际状态
❌ 信任代理报告
为什么这很重要
来自 24 次失败记忆：
- 您的人类伙伴说“我不相信您” - 信任破裂
- 未定义的函数被交付 - 会崩溃
- 缺失的要求被交付 - 不完整的功能
- 时间浪费在虚假完成上 → 重定向 → 返工
- 违反：“诚实是核心价值观。如果您说谎，您将被替换。”
何时应用
总是在之前:
- 任何成功/完成声称的变体
- 任何满意表达
- 任何关于工作状态的积极陈述
- 提交、PR 创建、任务完成
- 移动到下一任务
- 委托给代理
规则适用于:
- 确切短语
- 转述和同义词
- 成功的暗示
- 任何建议完成/正确性的通信
底线
验证没有捷径。
运行命令。阅读输出。然后声称结果。
这是不容谈判的。