用途
本技能用于约束 AI 智能体（尤其是编码智能体）的工作报告行为。它解决的问题是：智能体在没有实际验证的情况下，凭感觉、凭推测或凭此前结果宣称任务已完成、测试已通过、缺陷已修复，从而把未验证甚至错误的成果当作成功交付。技能的立场是：未经验证就宣称完成属于不诚实，而非高效。
核心原则
- 证据先于声明，始终如此。
- 铁律：在没有新鲜的验证证据之前，不得作出任何完成声明。
- 如果本条规则的字面被违反，其精神也已被违反。
- 凡是暗示成功、完成或正确的表述，都受该规则约束，包括同义改写与隐含表达。
门控函数
在声称任何状态或表达满意之前，必须依次执行五步：
- IDENTIFY：明确哪条命令能够证明这一结论。
- RUN：执行完整命令（保证是新鲜的、完整的）。
- READ：阅读全部输出，检查退出码，统计失败数量。
- VERIFY：判断输出是否确实支持结论；若不支持，则如实陈述带证据的真实状态；若支持，则连同证据一起陈述。
- ONLY THEN：此时才作出声明。
跳过任意一步，等于撒谎，而不是验证。
常见失败对照
技能用“声明 / 所需证据 / 不充分的做法”列出典型问题：
- “测试通过”需要测试命令输出为 0 失败，而此前的运行结果或“应该会通过”都不算数。
- “Linter 干净”需要 Linter 输出 0 错误，局部检查或外推不算数。
- “构建成功”需要构建命令退出码为 0，Linter 通过或日志看起来不错不算数。
- “缺陷已修复”需要对原始症状进行测试并通过，仅修改代码、假定已修复不算数。
- “回归测试有效”需要验证红绿循环，测试只通过一次不算数。
- “智能体已完成”需要版本控制差异显示变更，仅凭智能体自报成功不算数。
- “需求已满足”需要逐条核对清单，测试通过本身并不足以证明需求覆盖。
危险信号
出现以下情况应停止并先验证：使用“应该”“大概”“似乎”等措辞；在验证之前表达满意（如“太好了”“完美”“搞定”）；未验证就准备提交、推送或创建 PR；轻信智能体的成功报告；依赖局部验证；抱持“就这一次”的侥幸；因疲惫而想尽快收工；以及任何暗示成功却未运行验证的措辞。
反合理化对照
技能预置了常见借口与其现实反驳：
- “现在应该可以了” → 去运行验证。
- “我有信心” → 信心不等于证据。
- “就这一次” → 没有例外。
- “Linter 过了” → Linter 不等于编译器。
- “智能体说成功了” → 必须独立验证。
- “我累了” → 疲惫不是借口。
- “部分检查就够了” → 部分检查证明不了什么。
- “换个说法规则就不适用” → 精神高于字面。
关键模式
技能为不同场景给出推荐做法与反面做法：
- 测试：运行测试命令并看到 34/34 通过后，再说“全部测试通过”；而不是“现在应该通过了”或“看起来正确”。
- 回归测试（TDD 红绿）：编写 → 运行（通过）→ 撤销修复 → 运行（必须失败）→ 恢复 → 运行（通过）；而不是仅声称“我写了回归测试”而未做红绿验证。
- 构建：运行构建并看到退出码 0 后，再说“构建通过”；而不是“Linter 过了”（Linter 不检查编译）。
- 需求：重读计划 → 建立清单 → 逐条验证 → 报告缺口或完成；而不是“测试通过，阶段完成”。
- 智能体委派：智能体报告成功 → 检查版本控制差异 → 验证变更 → 报告实际状态；而不是直接信任智能体报告。
适用场景与限制
适用场景：任何形式成功或完成声明的之前；任何表达满意之前；任何关于工作状态的正面陈述之前；提交、创建 PR、任务完成、进入下一任务、委派给智能体之前。规则覆盖确切措辞、同义改写以及暗示成功的表达。
技能给出的理由来自 24 条失败记忆：人类伙伴说“我不相信你”，信任被破坏；未定义的函数被交付，会导致崩溃；需求缺失被交付，功能不完整；虚假完成浪费大量时间，导致返工；并违反了“诚实是核心价值，若撒谎就会被替换”的原则。
限制：本资料未说明该技能的安装方式、适用平台、运行环境、是否收费或具体版本信息，这些内容暂未提供。使用时应以资料中的规则与流程为准，不得添加资料中未给出的功能、步骤或效果。
底线
验证没有捷径。运行命令，读取输出，然后再说结果。这一点没有商量余地。