AI 辅助开发流程（二）：单功能闭环原则
上一篇讲了如何用提示词方法论和 AI 高效对话。这一篇进入实战——当你真正开始用 AI 做一个项目时，怎么保证进度和质量。
我见过很多人用 AI 开发项目的样子：
"帮我做一个博客系统，要有用户登录、文章管理、评论系统、SEO 优化、RSS 订阅、邮件通知……"
AI 噼里啪啦写了一堆代码，跑起来一看——登录有问题，文章保存不了，评论功能报错，RSS 格式不对。十个功能，十个都有 bug。
这不是 AI 的问题，是你的工作方式有问题。
为什么"同时铺开"必然失败
同时让 AI 做多个功能，有三个致命问题。
第一，上下文会混乱。 AI 在同一轮对话里处理十个功能，它会搞混不同功能之间的变量名、函数名、数据结构。你以为它在做功能 A，其实它偷偷用了功能 B 的变量。
第二，bug 会叠加。 功能 A 的 bug 可能影响功能 B。你修功能 B 的时候，不知道问题出在 B 本身还是 A 的副作用。越修越乱。
第三，你没法验收。 十个功能同时做出来，你根本不知道从哪个开始验。每个都试一下，每个都有问题，最后全部推翻重来。
单功能闭环：做完一个，再做下一个
解决方案很简单：一次只做做完一个功能，验证通过，再开始下一个。
我把这个叫做"单功能闭环"。每个功能经历四个阶段：
设计 → 实现 → 验证 → 锁定
设计阶段，你和 AI 讨论这个功能的需求和实现方案。实现阶段，AI 写代码。验证阶段，你测试功能是否正常。锁定阶段，确认功能没问题，不再改动。
只有走完这四个阶段，才进入下一个功能。
这样做的好处是：每个功能都是独立的、可验证的。出了问题，你知道问题就在这个功能里，不会牵连其他功能。
先做框架，再写血肉
在每个功能内部，还有一个顺序问题：先做框架，再写血肉。
不要一上来就写细节。先把骨架搭起来——数据结构定义好、接口定义好、主要函数的签名写好。让 AI 先把这个框架跑通，哪怕里面的实现是空的或者假的。
比如你要做用户登录功能，先让 AI 搭出这个框架：
用户输入用户名密码 → 验证逻辑 → 生成 token → 返回登录成功
每个步骤的函数都先定义好，但函数体可以先返回一个假数据。让整个流程能跑通。
然后，再一个函数一个函数地填充真实实现。每填完一个，验证一下。
这样做的好处是：你永远有一个"能跑"的版本。哪怕某个函数还没实现，整体流程是通的。你不会陷入"什么都写了但什么都跑不起来"的困境。
验证必须认真
单功能闭环最关键的一步是验证。
很多人觉得"差不多就行了"，看到 AI 说"应该没问题"就直接进入下一个功能。这是大忌。
验证要做到三点：
自己测一遍。 不是随便点几下，而是按照你设计的测试用例，每个场景都测到。正常流程要测，异常流程也要测（比如输入空密码、输入错误密码）。
看日志。 不要只看页面上有没有报错。打开控制台，看有没有警告、有没有报错、网络请求有没有异常。
确认边界。 功能的边界条件是什么？最大输入多少？最小输入多少？空值怎么处理？这些边界不测，上线后一定会出问题。
验证通过了，这个功能才算"锁定"。锁定的功能，后续开发中不再改动。
你当架构师，AI 当执行者
整个流程中，你的角色是架构师，AI 的角色是执行者。
你定需求、定方案、定标准、验收结果。AI 负责把你的想法翻译成代码。
不要试图让 AI 自己决定"这个功能怎么做"。它可以提建议，但最终方案必须你来定。因为只有你自己知道项目的整体方向，AI 只看到你告诉它的那一点上下文。
当你觉得一个功能太复杂，不知道怎么拆的时候，可以给 AI 一个核心框架，让它帮你完善：
我要做一个评论系统的后端 API。核心需求是：用户可以发表评论，可以回复评论，管理员可以删除评论。数据结构你来设计，但要支持无限层级回复。接口风格参考 RESTful。
这就是上一篇说的"给框架不给答案"——你定了核心需求和约束，AI 负责填充实现细节。
小结
AI 辅助开发的核心节奏：
- 一次只做一个功能——不要同时铺开
- 每个功能走闭环——设计、实现、验证、锁定
- 先框架后血肉——骨架优先，逐步填充
- 验证必须认真——自己看日志，测边界条件
- 你当架构师——AI 是执行者，不是决策者
这套流程看起来慢，实际上比"同时铺开"快得多。因为你永远不用回头修一堆互相牵连的 bug。
下一篇，我会讲当项目大到一个人（一个 AI）忙不过来时，怎么用多 Agent 协作模式——让多个 AI 同时干活，但又要保证质量和一致性。