AI 说“做完了”，就真的做完了吗？

上几篇文章讲了，我如何用 clarifier 和 todos 把一个模糊想法变成项目里的任务。

但任务文档写好之后，接下来怎样让 AI 真正按照文档实施？

我在使用各类 Agent 的过程中，最怕的就是它经常信誓旦旦告诉我：文件已经生成了，代码已经验证并运行了，任务已经完成了。

但实际检查时，文件没找到；代码可能根本也没有跑；所谓的验证也可能只是根据代码进行推测。

虽然随着模型能力不断提高，这类问题确实越来越少了。现在只要任务文档足够清楚，很多事情模型已经可以直接完成。但这并不意味着我们可以跳过检查。任务越复杂，越需要一个稳定的执行、验证和收口流程。

所以，我整了一个 implement Skill。

Part 1｜如何使用 implement Skill

clarifier 负责把问题想清楚，todos 负责把问题记录下来，但它们都不负责证明任务已经完成。而 implement 通过新开一个对话、@对应的任务文档并发送“开始实施”，让 Agent 进入一套持续实施、验证和收口的流程，直到得到可供人审查的结果。

新开一个对话的原因是，计划阶段往往会有很多探索性的内容：不同方案的比较、被放弃的想法、还没有答案的问题，以及大量来回确认的过程。这些内容对形成计划很有价值，但未必有助于后续 Agent 执行已经确定的任务。

因为对 Agent 来说，对话历史里的噪声越多，真正重要的目标和约束就越容易被淹没，执行时也更容易出现理解偏差甚至幻觉。从上下文窗口和注意力机制的工作方式看，保留大量无关对话还会增加每次调用的 token 成本。

所以我建议的做法是：计划阶段可以充分讨论，实施阶段就直接新开一个对话，只让 Agent 读取已经确认过的任务文档并开始实施。

那么，实施过程中如何确保任务真的完成，下面就讲三个门控。

前面说到，当我 @代办文档并发送“开始实施”后，就开始实施了。具体来说，Agent 第一步会按照 implement Skill 的约定，不会立即写代码，而是先审阅任务文档。

Agent 需要判断三件事：任务是否足够清楚，是否存在歧义，以及文档能否直接指导文件创建、代码编写、配置修改和验证工作。

如果答案是否定的，就回到 clarifier 继续澄清，而不是让 AI 自己胡乱猜测一个看起来合理的方案。

文档确认可以执行后，才进入真正的落地实施阶段。

但实施并不等于仅仅把文件写出来就结束了。implement Skill 要求完成修改后，先做低成本的冒烟测试，再补充独立脚本的使用说明，最后在真实环境中完成全量测试。

拿我自己的实际例子来说，我创建微信公众号发布 Skill 时，Agent 遵循 implement Skill 的要求，先进行快速冒烟测试，检查缺少环境变量、缺失图片等错误情况，之后才进行真实接口验证。

这个门控的目的，是把“看起来完成”变成“有证据证明已经完成”，即使现实与预期不一致。

如果是科研或数据任务，真实运行结果经常会和原本预期不一致。这个时候，明确的运行证据至少可以证明“任务完成了，但结果不符合预期”。Agent 应该如实告诉你这个结果，因为它至少证明了某条路暂时不可信。

验证结束后，implement 会在 todo/reviews/ 目录生成一份与原任务同名的审查摘要。

它会简要记录本次任务做了什么、是否存在影响交付的偏差，以及关键文件和验证结论在哪里。这个摘要不是完整日志，而是专门给人准备的审查入口。

最后一道门控由人来把关。

只有我检查过审查摘要，并明确确认任务完成，给 Agent 发送“归档此次任务”时，任务文件才会从 pending/ 移到 done/。如果验证结果和原任务不一致，就把偏差记录下来，任务继续留在 pending/，等待后续更新，而不是由 AI 自己宣布“已完成”。

使用 implement 之后，我并没有把所有决定都交给 AI。相反，我只是把过去容易遗漏的几个环节固定了下来：先判断能不能做，再执行；执行之后要测试；测试之后要留下审查入口；最后由人确认是否归档。

我也不再把 AI 的一句“完成了”当作完成证明，而是去看它实际改了什么、测试了什么、还有哪些没有解决的问题。

对于科研、数据分析和工程任务来说，“当前无法完成”同样是一种有效结果。只要原因和影响被记录下来，下一步就有继续推进的依据。

implement 不能保证每个任务都成功，也不能替我做最终判断。它真正解决的是另一件事：让每个结果都尽可能被验证、被解释、被审查。

回头看，这三个 Skill 刚好组成了一个完整的工作流：

clarifier 负责把问题想清楚；

todos 负责把问题留下来；

implement 负责确认问题是否真的得到了结果。

我真正想自动化的，不是让 AI 替我做所有决定，而是让执行、验证和记录这些容易遗漏的环节，变成一套稳定的习惯。

附：clarifier、todos 和 implement 的完整内容，统一维护在 GitHub 仓库 easy-simple-skills。