完成前验证：让「已完成」三个字，先有证据再出口
- 一句话定位：这不是一个写代码的技能，而是一个「管住嘴」的技能——在你说出「完成、修好了、测试通过了」之前，强制先跑一遍验证命令并把输出读清楚。
- 核心铁律：没有新鲜的验证证据，就不能声称完成。信心、推测、之前跑过一次，统统不算数。
- 可执行流程：技能内置「门函数」五步法（识别 → 运行 → 阅读 → 验证 → 声明），把模糊的自我感觉变成可核对的输出与退出码。
- 防自欺设计：附带了红色信号词清单、常见借口与现实对照表，专门堵住「应该没问题」「就这一次」「代理说成功了」这类合理化借口。
- 适用对象：AI 编程助手、独立开发者、带 AI 代理干活的工程师，以及任何需要向他人交付「已完成」结论的人。
1. 该技能叫什么？如何一键安装 AI 技能提升开发效率？
技能中文名：完成前验证 技能英文名：verification-before-completion 技能ID：13640
它要解决的问题非常具体：「未经验证的完成声明」。在 AI 辅助编程的场景里，这个问题被放大了——模型很容易在没跑测试、没编译、没检查依赖的情况下，用「现在应该可以了」「看起来没问题」收尾；人类开发者累了想收工的时候，也会犯同样的错。这个技能做的事情，就是在「做出任何成功声明」与「提交代码 / 创建 PR / 宣布任务结束」之间，插入一道强制验证的门。
一键安装的思路与步骤
「一键安装」的本质，是把这套验证纪律从一个「需要人记住的原则」变成「AI 一开工就自动加载的行为准则」。通用流程如下（具体命令与入口请以官方说明为准）：
- 确认安装前提：你的 AI 编程客户端 / Agent 运行环境需要支持 Skill（技能包）机制，能在会话中加载并遵循技能说明。若你的工具支持技能市场或技能目录，通常可以直接搜索技能ID
13640或英文名verification-before-completion定位。 - 执行安装入口：通过技能市场的「安装 / 添加」按钮，或把技能目录放入本地技能文件夹，完成一次性安装。多数环境支持一键添加，无需手工改配置。
- 确认加载生效：安装后新开一个会话，让助手先说明它在「声称完成前」会执行哪几步。如果它能完整复述「识别验证命令 → 运行 → 阅读输出 → 验证 → 再声明」这条门函数，说明技能已生效。
- 做一次冒烟测试：给它一个小任务，比如「修一个明显的空指针」，然后观察它在说「修好了」之前，是否真的跑了测试或编译命令、并引用了输出结果。这是最直接的验证方式。
- 纳入日常流程：把它设为常驻技能，而不是临时启用——因为最容易出问题的时刻，恰恰是你（或 AI）最想快点结束的时刻。
至于安装命令、支持的客户端列表、是否有付费档位，本技能详情中并未给出，请以官方说明为准。
2. 该技能的主要功能和特点
- 铁律约束：技能开篇即立下不可协商的规则——没有新鲜的（本次会话内新跑的）、完整的验证证据，就不允许声称完成。这条规则同时约束字面表述与所有同义改写。
- 门函数五步法：在表达任何状态、任何满意度之前，必须依次完成「识别证明命令 → 完整执行 → 读完输出并检查退出码与失败计数 → 判断输出是否真的支撑该声明 → 最后才开口」。跳过任一步，性质就从「验证」变成「说谎」。
- 常见失败对照表：把七类高频误判摊开——测试通过要有「0 失败」的输出，代码检查干净要有「0 错误」，构建成功要有退出码 0，错误修复要回到原始症状去测，回归测试必须走完红绿循环，代理完成要看版本控制差异，需求满足要逐条对清单。它明确告诉你：上一轮的运行记录、代码检查通过、代理的自我报告，都不能替代验证。
- 红色标志清单：一旦出现「应该」「可能」「似乎」、在验证前说「太棒了」「完美」「完成」、准备不验证就提交 / 推送 / 建 PR、信任代理的成功报告、依赖部分验证、心想「就这一次」、或者单纯因为累了想收工——立刻停下。
- 合理化预防表：把常见的自我辩解逐条驳倒，比如「我有信心」→ 信心不等于证据；「代码检查通过」→ 代码检查不等于编译器；「我写了一个回归测试」→ 没做红绿验证就等于没验证。
- 关键模式模板：给出可直接照抄的「正确 / 错误」对照句式，覆盖单元测试、TDD 红绿回归、构建、需求核对、代理委派五类场景。
- 与普通工具的区别：测试框架、Lint、CI 解决的是「如何检查」，而这个技能解决的是「检查之后，你有没有资格说那句话」。它管的是声明纪律，是流程之上的元规则——这一点是绝大多数工具不覆盖的空白地带。
3. 如何使用该技能？
安装并生效后，使用方式不是「调用一个函数」，而是「按一套流程说话」。以下是可直接参照的步骤：
- 识别证明命令。在准备说任何结论前，先问自己：什么命令能证明这句话？测试通过 → 测试命令；构建成功 → 构建命令；错误修复 → 复现原始症状的测试。
- 完整运行，不用缓存。执行完整命令，不裁剪、不跳过、不拿历史结果顶替。要求是「新鲜」且「完整」。
- 读完输出。不要只看最后一行。检查退出码是否为 0，统计失败数量，确认没有跳过的用例。
- 做判定。问一句：这份输出真的确认了我的声明吗？如果不是，就按证据描述实际状态；如果是，再引用证据做出声明。
- 带证据开口。把「结论 + 依据」一起说出来，而不是只说结论。
示例一：单元测试
正确：[运行测试命令] [看到：34/34 通过] 「所有测试通过」
错误：「现在应该能过了」「看起来是对的」
示例二：缺陷修复的回归验证 正确：写测试 → 运行（应通过）→ 撤销修复 → 运行（必须失败）→ 恢复修复 → 运行（通过），四步走完才算验证。 错误：「我补了一个回归测试」（没做红绿验证）。
示例三：构建
正确：[运行构建命令] [看到：退出码 0] 「构建通过」
错误：「代码检查是绿的」（代码检查不负责编译，二者不等价）。
示例四：委派给代理 正确：代理报告成功 → 查看版本控制差异 → 逐项核对改动 → 再报告真实状态。 错误：直接把代理的「成功」转述给用户。
示例五：需求验收 正确：重读计划 → 建立检查清单 → 逐条验证 → 报告差距或完成。 错误：「测试都过了，这个阶段算完成了」。
4. 同类型竞品对比分析
| 方案名称 | 定位 | 核心功能 | 安装/使用门槛 | 适用场景 | 优势与不足 |
|---|---|---|---|---|---|
| 完成前验证（本技能） | 声明纪律层：管住「说完成」的时机 | 门函数五步法、红色标志、合理化预防、五类场景模板 | 低：随技能包加载即生效，无需改代码 | AI 助手收尾、提交前自查、代理委派验收、需求核对 | 优势：零侵入、覆盖人与 AI 双重场景、直击虚假完成；不足：靠自觉与纪律执行，不自动跑命令 |
| CI 流水线（如 GitHub Actions 等） | 自动化执行层：在服务端跑检查 | 自动触发构建、测试、静态检查并给出状态 | 中：需编写配置文件与维护运行环境 | 团队协作、合并前的强制门禁 | 优势：强制性最强、不可绕过；不足：反馈有延迟，本地会话内不生效 |
| 静态检查与类型检查工具 | 代码质量层：检查语法、风格、类型 | 报告错误数量与规则命中项 | 低：接入项目配置即可 | 编码阶段即时纠错 | 优势：即时、细粒度；不足：检查通过≠能编译、≠功能正确，无法替代行为验证 |
| 测试框架（如单元测试/端到端测试） | 行为验证层：提供可运行的证据来源 | 执行用例并输出通过/失败统计 | 中：需编写与维护用例 | 逻辑校验、回归防护 | 优势：证据最硬；不足：只提供证据，不约束你是否在声明前使用了它 |
| 人工代码评审 | 人际校验层：他人复核 | 阅读改动、提出质疑 | 高：依赖评审者时间 | 架构决策、复杂改动 | 优势：能发现设计问题；不足：评审者也常被「已完成」的措辞带偏 |
可以看出，这四类方案分别解决「自动执行」「代码质量」「行为证据」「他人复核」，而本技能补的是最上游的一环：在证据产生之后、结论说出之前的那道闸门。它与上述方案是互补关系，而非替代关系。
5. 该技能的典型应用场景与实际体验情况
场景一：AI 编程助手长任务收尾 角色：使用 AI 助手完成多文件重构的开发者。 痛点：模型在改了七八个文件之后，用一句「重构已完成，功能保持不变」收尾，实际上项目根本编译不过。 使用方式：技能生效后，助手必须先跑构建与测试并引用输出，才允许做完成声明；用户的追问也从「做完了吗」变成「把验证输出贴出来」。
场景二：Bug 修复后的回归确认 角色：独立开发者或小团队工程师。 痛点：改完代码后凭直觉认为「肯定修好了」，结果同一个 Bug 在下个版本复现。 使用方式：按技能给出的红绿循环执行——写测试、跑通、撤销修复看它失败、恢复再看它通过，四步齐全才敢说「已修复」。
场景三：多代理协作中的验收 角色：把子任务分派给多个 AI 代理的工程师。 痛点：代理回报「任务成功」，实际改动缺失或半途而废。 使用方式：技能明确要求「代理报告成功 → 检查版本控制差异 → 验证更改 → 报告实际状态」，把代理的自述从「证据」降级为「线索」。
场景四：提交代码与创建 PR 前的自查 角色：准备提 PR 的开发者。 痛点：PR 描述写得漂亮，CI 一跑红一片。 使用方式：把门函数作为提交前的固定动作，逐条核对测试、构建、需求清单。
实际体验情况：上手难度很低——它不需要你学新命令、不改变项目结构，只需要在每次想说「完成」时多停三秒。效果上，最明显的改变是「返工率」下降：原本「宣布完成 → 用户发现不对 → 重定向 → 返工」的循环被提前掐断。需要注意的是两点：一是它依赖执行者的诚实，若环境不加载技能或执行者刻意绕过，规则不会自动生效；二是验证本身要花时间，短期内看起来「变慢了」，但这部分时间本来就是返工要付出的。
6. 该技能能为用户带来的价值
- 把「感觉」换成「证据」：每一次完成声明都附带可核对的输出，沟通成本显著下降，协作方不必再问「你确定吗」。
- 切断返工链条：虚假完成最贵的不是那一句话，而是它引发的「重定向 → 返工 → 再次返工」。技能详情中提到的失败记忆里，未定义函数被发布、缺失需求被发布，都会在真实环境中直接变成故障。
- 降低 AI 协作门槛：非资深用户很难判断 AI 说的「已完成」是真是假。这个技能把判断标准显式化——看输出、看退出码、看失败计数，让不懂代码细节的人也能验收。
- 建立可复用的团队纪律：门函数五步法、红绿循环、需求清单核对，都是可以直接写进团队规范的动作，长期沉淀为工程文化。
- 守住信任这条底线：技能详情把「未经验证就声称完成」直接定义为不诚实，并指出信任一旦破裂，代价远高于多跑一次命令。
7. 常见问题 FAQ
Q1：这个技能怎么安装？需要改项目代码吗？
不需要改代码。它属于技能包，通过支持 Skill 机制的 AI 编程客户端或技能市场添加即可，搜索技能ID 13640 或英文名 verification-before-completion 通常能定位到。具体安装命令与入口以官方说明为准。
Q2：它是收费的吗？ 技能详情中未涉及定价信息，请以官方说明为准。从功能形态看，它是一份行为准则类技能，不依赖外部服务。
Q3：只有用 AI 编程的人才需要吗？人类开发者用有用吗？ 人类开发者同样适用，而且往往更需要——「我累了想收工」「就这一次」「代码检查是绿的所以没问题」这些念头与 AI 无关。技能里的合理化预防表就是为人类准备的。
Q4：它和 CI、单元测试有什么区别，会重复吗？ 不重复。CI 负责「自动跑检查」，测试框架负责「提供证据」，而这个技能负责「在你说出结论之前，是否真的用了这些证据」。三者是流水线上的不同环节，可以叠加使用。
Q5：每次都要跑完整验证，会不会太慢？ 会慢一点，但这是把返工成本前置。技能的态度很明确：验证没有捷径，运行命令、阅读输出、然后才声称结果，不可协商。真正浪费时间的是「宣布完成后被打回重做」。