核心用法
该技能是一种强制性的自我检查协议，要求在声称工作完成、修复或通过之前，必须执行验证命令并确认输出结果。其核心流程为：识别验证命令 → 完整执行 → 读取输出 → 核实确认 → 才允许声明。
关键执行模式：
- 测试通过：必须运行测试命令，确认 0 失败
- 回归测试：必须完成红-绿周期验证（写测试→运行通过→回退修复→必须失败→恢复→通过）
- 构建成功：必须确认 exit 0，而非仅看 linter
- 需求完成：逐行核对清单，而非仅测试通过
- 代理完成：必须检查 VCS diff 独立验证
显著优点
- 根本性防错：从流程上消灭"应该有效"的幻觉，将诚实嵌入工作流
- 信任修复：解决"我不相信你了"的历史信任破裂问题
- 成本前置：避免"虚假完成 → 重定向 → 返工"的浪费循环
- 非例外设计：明确"违反字面即违反精神"，封堵所有绕行借口
- 多场景覆盖：涵盖测试、构建、回归、代理委托等全部宣称场景
潜在缺点与局限性
- 执行摩擦：每次声称前强制等待验证，可能打断心流
- 疲惫冲突：明确标注"累了想结束"是红旗场景，需对抗人性
- 无豁免机制：即使"就这一次"也不允许，极端情况可能僵化
- 代理开销：代理报告必须独立核实，增加协调成本
- 工具依赖：需有可行的验证命令，某些探索性工作可能难以定义
适合人群
- AI 助手/Agent：防止幻觉性完成声明
- 开发者：养成证据驱动的工作习惯
- 团队协作场景：建立可验证的交付标准
- 高信任要求环境：如安全关键、金融系统开发
常规风险
- 认知过载：24 条失败记忆的心理负担
- 规则绕过：尝试用"不同措辞"规避监管（已被封堵）
- 执行衰减：长期可能松懈，需持续强化
- 验证盲区：若验证命令本身设计不当，可能产生虚假安全感