说清验收条件，比让 AI 快速动手更重要

这是我对过去几个月实践的一个明确结论：在 AI 编程里，说清楚比做得快更重要。很多时候，问题并不在模型不够强，而在任务一开始就没有把交付标准定义清楚。

快速动手不等于快速交付

我现在越来越少一上来就让 AI 直接开写。因为一旦需求边界、接口约束和完成标准没有说清楚，模型确实可以很快产出内容，但这些内容往往只是“开始了”，不等于“做完了”。

我更认可的流程是先做原型，等需求确认后，再把接口契约和数据模型补齐。原型工程、前端工程、后端工程放在同一个目录里，各自维护自己的 agent.md，前端复用原型组件，后端按接口契约开发。这样做的核心，不是流程更完整，而是让后续每一步都有明确的参照物。

验收条件才是 AI 持续迭代的锚点

我对方法也有一个认知更新：传统 SDD 这类做法已经不是我现在的重点。新一代大模型已经把很多通用的软件设计思路内化了，真正更有效的方式，是先生成技术方案，再用 go 或目标模式围绕明确的验收条件循环执行。

我现在越来越确定，验收条件本身就是提示词质量的一部分。验收条件越清楚，模型越能持续沿着同一个目标修正；验收条件模糊，模型就容易在看似努力的情况下不断偏题。

所以我会把“做到什么算完成”写得尽可能具体，而不是只说“你先做一个版本看看”。这两种说法带来的结果差异非常大。

交付标准必须落到可验证的结果

如果验收条件只是抽象描述，最后还是容易变成主观判断。所以我现在会把标准尽量落到可验证的层面。

例如，原型技术栈必须和生产前端一致，否则前面省下来的时间，后面会用重写成本补回来。再比如，每个接口的交付标准不能只是“能请求通”，而应该是单元测试和接口测试全部跑通。

这些约束看起来更慢，但它们实际上是在减少反复修改。只有当交付标准可以验证，AI 的输出才真正有收口点。

复杂任务先拆分，再逐步执行

这也影响了我怎么给 AI 分配任务。我会先按复杂度和改动量分类。

低复杂度但改动量大的任务，我更倾向先让 AI 生成待办清单，再逐项修改。高复杂度且改动量大的任务，则必须拆分，而且最好分到不同对话窗口分别处理。

原因很简单：复杂任务如果不先拆开，验收条件就很难写清楚；验收条件写不清楚，模型就很难稳定完成。先拆分任务，本质上也是在为更清楚的验收条件创造条件。

Skill 的价值，是把清楚的方法沉淀下来

我现在把 Skill 看成方法论沉淀的最小单元。无论是手动跑通后再提炼，还是先搜索最佳实践再生成，核心都一样：把已经验证有效的任务边界、执行步骤和验收标准固化下来。

对我来说，这件事的价值不只是复用效率，更重要的是避免下次又从模糊描述开始。只要方法能沉淀，AI 协作就不再只靠临场发挥，而会越来越稳定。

回头看，这几个月最重要的经验不是“怎么让 AI 更快开始”，而是“怎么让 AI 在明确标准下把事情真正做完”。