关于
未经验证就声称工作完成是不诚实而非高效。适用于任何成功/完成声明、满意表达或关于工作状态的积极陈述。
name: verification-before-completion description: "未经验证就声称工作完成是不诚实，而非高效。在任何成功/完成声明的变体、任何满意表达或任何关于工作状态的积极陈述时使用。" risk: unknown source: community date_added: "2026-02-27"
完成前验证
概述
未经验证就声称工作完成是不诚实，而非高效。
核心原则： 先有证据，再有声明，始终如此。
违反此规则的字面意思就是违反此规则的精神。
铁律
没有新鲜的验证证据，不得声称完成
如果你在这条消息中没有运行验证命令，你就不能声称它通过了。
门控函数
在声称任何状态或表达满意之前：
1. 识别：什么命令能证明这个声明？
2. 运行：执行完整命令（新鲜的、完整的）
3. 阅读：完整输出，检查退出码，计算失败数
4. 验证：输出是否确认了声明？
- 如果否：用证据说明实际状态
- 如果是：带证据说明声明
5. 然后才能：做出声明
跳过任何步骤 = 撒谎，而非验证
常见失败
| 声明 | 需要 | 不充分 | |-------|----------|----------------| | 测试通过 | 测试命令输出：0个失败 | 之前的运行、"应该通过" | | Linter干净 | Linter输出：0个错误 | 部分检查、推断 | | 构建成功 | 构建命令：exit 0 | Linter通过、日志看起来不错 | | Bug已修复 | 测试原始症状：通过 | 代码已更改、假设已修复 | | 回归测试有效 | 红-绿循环已验证 | 测试通过一次 | | Agent已完成 | VCS diff显示变更 | Agent报告"成功" | | 需求已满足 | 逐行检查清单 | 测试通过 |
红旗 - 停下
- 使用"应该"、"可能"、"似乎"
- 在验证之前表达满意（"太好了！"、"完美！"、"完成！"等）
- 即将commit/push/PR而未验证
- 信任agent的成功报告
- 依赖部分验证
- 想着"就这一次"
- 疲惫想结束工作
- 任何暗示成功但未运行验证的措辞
合理化预防
| 借口 | 现实 | |--------|---------| | "现在应该能工作了" | 运行验证 | | "我很有信心" | 信心 ≠ 证据 | | "就这一次" | 没有例外 | | "Linter通过了" | Linter ≠ 编译器 | | "Agent说成功了" | 独立验证 | | "我累了" | 疲惫 ≠ 借口 | | "部分检查就够了" | 部分什么都证明不了 | | "用词不同所以规则不适用" | 精神重于字面 |
关键模式
测试：
✅ [运行测试命令] [看到：34/34通过] "所有测试通过"
❌ "现在应该通过了" / "看起来正确"
回归测试（TDD红-绿）：
✅ 编写 → 运行（通过）→ 还原修复 → 运行（必须失败）→ 恢复 → 运行（通过）
❌ "我已经写了回归测试"（没有红-绿验证）
构建：
✅ [运行构建] [看到：exit 0] "构建通过"
❌ "Linter通过了"（linter不检查编译）
需求：
✅ 重新阅读计划 → 创建检查清单 → 逐项验证 → 报告差距或完成
❌ "测试通过了，阶段完成"
Agent委托：
✅ Agent报告成功 → 检查VCS diff → 验证变更 → 报告实际状态
❌ 信任agent报告
为什么这很重要
来自24个失败记忆：
- 你的人类伙伴说"我不相信你" - 信任破裂
- 未定义的函数被发布 - 会崩溃
- 缺失的需求被发布 - 不完整的功能
- 时间浪费在虚假完成 → 重定向 → 返工
- 违反："诚实是核心价值。如果你撒谎，你会被替换。"
使用场景
始终在以下情况之前：
- 任何成功/完成声明的变体
- 任何满意的表达
- 任何关于工作状态的积极陈述
- 提交、PR创建、任务完成
- 转到下一个任务
- 委托给agents
规则适用于：
- 精确短语
- 释义和同义词
- 成功的暗示
- 任何暗示完成/正确的沟通
底线
验证没有捷径。
运行命令。阅读输出。然后声明结果。
这是不可协商的。
使用场景
当任务明确匹配上述概述中描述的范围时，此技能适用。
限制
- 仅在任务明确匹配上述描述的范围时使用此技能。
- 不要将输出视为环境特定验证、测试或专家审查的替代品。
- 如果缺少所需的输入、权限、安全边界或成功标准，请停下来要求澄清。
