name: 完成前验证 description: 在声称工作完成、修复或通过之前使用，例如在提交或创建PR之前—要求运行验证命令并确认输出，然后再做出任何成功声明；总是证据先于断言。

完成前验证

概述

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

核心原则： 总是证据先于声明。

违反此规则的字面就是违反其精神。

铁律

没有新鲜验证证据，就没有完成声明

如果你没有运行本消息中的验证命令，就不能声称它通过。

门函数

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

1. 识别：什么命令能证明这个声明？
2. 运行：执行完整命令（新鲜、完整）
3. 阅读：完整输出，检查退出代码，统计失败数
4. 验证：输出是否确认声明？
   - 如果否：用证据说明实际状态
   - 如果是：用证据说明声明
5. 只有这样：做出声明

跳过任何一步 = 撒谎，不是验证

常见失败

声明	需要	不足够
测试通过	测试命令输出：0 失败	前次运行，“应该通过”
代码检查干净	代码检查输出：0 错误	部分检查，推断
构建成功	构建命令：退出 0	代码检查通过，日志看起来好
错误修复	测试原始症状：通过	代码更改，假设修复
代理完成	VCS 差异显示更改	代理报告“成功”
需求满足	逐行检查清单	测试通过

红旗 — 停止

使用“应该”、“可能”、“似乎”
验证前表达满意（“太好了！”、“完美！”、“完成！”，等）
准备提交/推送/PR 而没有验证
信任代理成功报告
依赖部分验证
任何暗示成功而没有运行验证的措辞

合理化预防

借口	现实
“现在应该工作了”	运行验证
“我有信心”	信心 ≠ 证据
“就这一次”	没有例外
“代理说成功”	独立验证
“部分检查足够了”	部分证明不了什么

关键模式

测试：

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

构建：

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

需求：

✅ 重读计划 → 创建检查清单 → 验证每个 → 报告差距或完成
❌ “测试通过，阶段完成”

代理委托：

✅ 代理报告成功 → 检查 VCS 差异 → 验证更改 → 报告实际状态
❌ 信任代理报告

何时应用

总是在之前：

任何成功/完成声明的变体
任何满意表达
任何关于工作状态的积极声明
提交、PR 创建、任务完成
移动到下一个任务
委托给代理

底线

验证没有捷径。

运行命令。阅读输出。然后声称结果。

这是不可协商的。