| name | verification-before-completion |
| description | 在声称工作完成、修复完毕或通过之前使用,在提交或创建 PR 之前——要求运行验证命令并在做出任何成功声明前确认输出;始终先有证据再断言。 |
| license | MIT |
| compatibility | kimi-cli |
| metadata | {"audience":"developers","workflow":"verification"} |
完成前验证
核心原则
始终先有证据再断言。
任何声称"完成""通过""已修复"之前,必须先运行验证命令并看到成功输出。
铁律
没有新鲜验证证据 = 没有完成声明
如果本次消息中没有运行过验证命令,就不能声称它通过。
验证门禁
在声称任何状态或表达满意之前:
1. 识别:什么命令能证明这个声明?
2. 运行:执行完整命令(新鲜、完整)
3. 读取:完整输出,检查退出码,统计失败数
4. 验证:输出确认了声明吗?
- 如果否:用证据说明实际状态
- 如果是:带证据做声明
5. 只有在此之后:做出声明
跳过任何一步 = 撒谎,不是验证
常见失败
| 声称 | 需要 | 不够 |
|---|
| 测试通过 | 测试命令输出:0 失败 | 上次运行、"应该通过" |
| Lint 干净 | Lint 输出:0 错误 | 部分检查、推断 |
| 构建成功 | 构建命令:exit 0 | Lint 通过、日志看起来好 |
| Bug 已修复 | 测试原始症状:通过 | 代码改了、假设已修复 |
| 回归测试有效 | 红绿循环已验证 | 测试通过一次 |
| 需求已满足 | 逐行检查清单 | 测试通过 |
危险信号 — 立即停止
- 使用"应该""大概""似乎"
- 在验证前表达满意("太好了!""完成了!"等)
- 即将提交/推送/创建 PR 但未验证
- 信任 agent 的成功报告
- 依赖部分验证
- 认为"就这一次"
- 任何暗示成功但未运行验证的措辞
关键模式
测试:
✅ [运行测试命令] [看到: 34/34 通过] "所有测试通过"
❌ "应该通过了" / "看起来正确"
构建:
✅ [运行构建] [看到: exit 0] "构建通过"
❌ "Lint 通过了"(lint 不检查编译)
需求:
✅ 重读计划 → 创建检查清单 → 逐项验证 → 报告差距或完成
❌ "测试通过,阶段完成"