| name | dev-verification |
| description | 在声称工作完成、修复或通过前使用,在提交或创建 PR 前 - 要求运行验证命令并在做任何成功声称前确认输出 |
完成前验证
概述
未经验证声称工作完成是不诚实,不是效率。
核心原则: 证据先于声称,永远。
违反此规则的文字就是违反规则的精神。
铁律
没有新鲜验证证据就没有完成声称
如果你在本消息中还没有运行验证命令,你不能声称它通过。
门控函数
在声称任何状态或表达满意前:
1. 识别:什么命令证明这个声称?
2. 运行:执行完整命令(新鲜、完整)
3. 阅读:完整输出,检查退出码,计数失败
4. 验证:输出是否确认声称?
- 如果不:用证据陈述实际状态
- 如果是:用证据陈述声称
5. 只有这样:做出声称
跳过任何步骤 = 撒谎,不是验证
常见失败
| 声称 | 需要 | 不足够 |
|---|
| 测试通过 | 测试命令输出:0 失败 | 之前运行,"应该通过" |
| Linter 干净 | Linter 输出:0 错误 | 部分检查,外推 |
| 构建成功 | 构建命令:exit 0 | Linter 通过,日志看起来好 |
| Bug 修复 | 测试原始症状:通过 | 代码更改,假设修复 |
| 回归测试有效 | 红-绿循环验证 | 测试通过一次 |
| Agent 完成 | VCS diff 显示更改 | Agent 报告"成功" |
| 需求满足 | 逐行检查清单 | 测试通过 |
红旗 - 停止
- 使用"应该"、"可能"、"似乎"
- 验证前表达满意("太好了!"、"完美!"、"完成了!"等)
- 未经验证就提交/推送/PR
- 信任 agent 成功报告
- 依赖部分验证
- 想"就这一次"
- 累了想结束工作
- 任何暗示成功而没有运行验证的措辞
合理化预防
| 借口 | 现实 |
|---|
| "现在应该有效" | 运行验证 |
| "我有信心" | 信心 ≠ 证据 |
| "就这一次" | 没有例外 |
| "Linter 通过了" | Linter ≠ 编译器 |
| "Agent 说成功" | 独立验证 |
| "我累了" | 疲惫 ≠ 借口 |
| "部分检查就够了" | 部分证明不了什么 |
| "不同措辞所以规则不适用" | 精神高于文字 |
关键模式
测试:
✅ [运行测试命令] [看:34/34 通过] "所有测试通过"
❌ "现在应该通过" / "看起来正确"
回归测试(TDD 红-绿):
✅ 编写 → 运行(通过)→ 恢复修复 → 运行(必须失败)→ 恢复 → 运行(通过)
❌ "我已经写了回归测试"(没有红绿验证)
构建:
✅ [运行构建] [看:exit 0] "构建通过"
❌ "Linter 通过"(linter 不检查编译)
需求:
✅ 重读计划 → 创建检查清单 → 验证每个 → 报告缺口或完成
❌ "测试通过,阶段完成"
Agent 委派:
✅ Agent 报告成功 → 检查 VCS diff → 验证更改 → 报告实际状态
❌ 信任 agent 报告
为什么重要
失败记忆:
- 用户说"我不相信你" - 信任破裂
- 未定义函数发布 - 会崩溃
- 缺失需求发布 - 功能不完整
- 错误完成浪费时间 → 重定向 → 返工
- 违反:"诚实是核心价值观。如果你撒谎,你会被替换。"
何时应用
总是在以下情况前:
- 任何成功/完成的变体声称
- 任何满意的表达
- 关于工作状态的任何正面陈述
- 提交、PR 创建、任务完成
- 移动到下一个任务
- 委派给 agent
规则适用于:
- 确切短语
- 改写和同义词
- 成功的暗示
- 任何暗示完成/正确性的沟通
底线
验证没有捷径。
运行命令。阅读输出。然后声称结果。
这是不可协商的。