AI 协作开发五步闭环：从模糊需求到验证清单逐项落地

适用场景：需求还不够清晰、改动范围可能较大、希望借助 AI 提升开发效率，同时尽量减少返工。
核心目标：把「先聊清楚 → 再做方案 → 再审方案 → 再执行 → 最后逐项验收」固化成一套可复用的 AI 协作开发流程。

---

前言：这套流程是怎么形成的

上周我在自己的 AI 智能助手平台 项目中，已经按类似的方式完整跑过一轮。

实践仓库：zengyirong/ai-assistant-platform
项目状态：目前仍在持续开发中，暂未正式部署上线。

这个项目不是为了专门验证这套流程而临时创建的 Demo，而是我正在实际推进的 AI 应用项目。

也正是在真实需求、真实代码和真实改动中，我逐渐形成了下面这套协作方式：

1. 先和 AI 讨论模糊需求；
2. 让 AI 总结并产出修改方案；
3. 使用不同模型交叉审查方案；
4. 把定稿方案交给执行侧落地；
5. 最后重新对照验证清单检查代码是否真的完成。

后来在课程中，我遇到了一套与自己实践高度相似的方法。

这件事对我来说很有意思：不是听完课程之后照着做，而是自己先在真实项目里自然走到了类似的方法，再从课程中验证了这条路径是合理的。

课程中真正让我觉得值得吸收的一点，是老师在「审查」阶段做得更彻底：不是只审一两次，而是会反复审查多轮，直到方案趋于稳定。

所以我把自己的实践重新整理了一遍，并把「多轮审查」正式加入规则中，最终形成了下面这套五步闭环。

---

一、为什么不能直接把模糊需求丢给 AI 写代码

现在使用 Cursor、Claude Code、Codex、Copilot Agent 等 AI 编程工具，最容易犯的一个错误是：

需求刚说完，就让 AI 开始改代码。

这在需求非常小的时候问题不大。

但只要涉及：

• 多模块修改
• 数据结构变化
• 接口调整
• 权限逻辑
• RAG / Agent / Workflow
• 状态流转
• 复杂前后端联动

直接让 AI 开写，很容易出现几个问题。

1. AI 理解错需求

需求本身还是模糊的，但 AI 会主动补全缺失信息。

结果看起来写了很多代码，实际上方向一开始就偏了。

2. 方案看起来完整，但落地时漏步骤

例如方案里只写：

新增知识库权限

但真正落地可能涉及：

菜单权限
按钮权限
接口权限
角色授权
前端路由
前端按钮显示
后端鉴权
测试账号验证

如果一开始没有拆清楚，执行过程中就很容易遗漏。

3. 做完之后不知道怎么验收

AI 可能告诉你：

已完成。

但“已完成”到底是什么意思？

是：

• 页面能打开？
• 接口能调用？
• build 能通过？
• 权限真的生效？
• 原来的功能有没有被影响？
• 所有计划项是不是都实现了？

如果没有提前定义验证方式，最后只能凭感觉判断。

所以这套流程的核心不是：

如何让 AI 写更多代码。

而是：

如何管理 AI 完成一次软件工程任务。

---

二、AI 协作开发五步闭环

整个流程可以概括为：

① 模糊需求讨论
        ↓
② 方案 + 分步验证清单
        ↓
③ 多轮审查
   自审 + 异模型交叉审查
        ↓
④ 按定稿方案执行
        ↓
⑤ 按验证清单验收
   + 定位对应代码范围

如果在执行或验收阶段发现设计问题，则重新回到第 2 步或第 3 步。

所以它不是一条单向流水线，而是一个真正的闭环。

---

第 1 步：模糊需求先和 AI 讨论

这一阶段不要急着写代码。

目标是先把下面几件事讨论清楚：

需求
边界
约束
成功标准
风险

1.1 先回答：到底要解决什么问题

例如不要只说：

优化知识库。

这种需求几乎没有可执行性。

应该逐渐讨论成：

当前知识库只支持上传和删除文件，希望补充知识库详情、文档管理、解析状态、向量化状态、失败重试，并且不修改现有 RAG 检索流程。

这样 AI 才知道：

要做什么
不做什么
哪些模块不能碰

1.2 明确需求边界

建议把需求拆成两部分。

本次要做

知识库详情
文档列表
文档状态
失败重试
删除文档

本次不做

不修改 Embedding 模型
不修改 Chunk 算法
不修改 RAG Pipeline
不做知识库分享

这一步非常重要。

因为 AI 最大的问题之一就是：

很容易顺手扩大修改范围。

1.3 定义“成功是什么样”

不要写：

功能正常

应该写成可以观察、可以检查的结果。

例如：

创建知识库后可以进入详情页

上传 PDF 后文档状态依次显示：
UPLOADING → PARSING → EMBEDDING → READY

解析失败时显示 FAILED

FAILED 状态可以点击重新解析

删除文档后：
MySQL 数据删除
Qdrant Vector 删除
页面列表同步更新

这样后面才能真正验收。

第 1 步验证清单

• [ ] 已用一句话说明当前要解决的问题
• [ ] 已明确本次「做什么」
• [ ] 已明确本次「不做什么」
• [ ] 已确认技术约束
• [ ] 已定义可观察的成功标准
• [ ] 已列出未知问题
• [ ] 未把未知问题当成已确定事实

---

第 2 步：让 AI 总结，并产出修改方案和计划

需求讨论清楚之后，不要马上进入实现。

先要求 AI 把前面的讨论整理成一份正式方案。

我现在会要求方案至少包含：

1. 背景
2. 目标
3. 非目标
4. 现状分析
5. 修改方案
6. 分步实施计划
7. 每一步验证清单
8. 风险
9. 回滚方案

其中最重要的一条规则是：

没有验证清单的步骤，不算完整计划。

2.1 为什么每一步都必须有验证清单

假设 AI 给出的计划是：

Step 1 修改数据库

Step 2 修改后端 API

Step 3 修改前端页面

Step 4 联调

这看起来有计划，但其实还是很模糊。

更好的方式应该是：

Step 1：数据库

修改：
document 表增加 parse_status 字段

验证：
- migration 执行成功
- 原数据不丢失
- 新字段默认值正确

再例如：

Step 2：后端

修改：
新增 retry document parse API

验证：
- READY 状态禁止 retry
- FAILED 状态允许 retry
- 不存在的 document 返回 404
- 单元测试通过

这样执行侧才知道：

做到什么程度，这一步才算完成。

2.2 验证项最好分层

我现在倾向把验证清单拆成几个维度：

业务验证
接口验证
自动化测试
工程验证
回归验证
变更范围验证

例如：

### Step 3 验证

#### 业务
- [ ] FAILED 文档显示“重新解析”
- [ ] READY 文档不显示重新解析

#### 接口
- [ ] retry API 正常返回
- [ ] 非法状态返回预期错误码

#### 自动化
- [ ] service test 通过

#### 工程
- [ ] pnpm typecheck 通过
- [ ] pnpm build 通过

#### 回归
- [ ] 原知识库查询功能正常

#### 变更范围
- [ ] 没有修改计划之外的模块

第 2 步验证清单

• [ ] 方案覆盖了全部已确认需求
• [ ] 没有偷偷扩大范围
• [ ] 每一个实施步骤都有验证方式
• [ ] 验证项可以实际执行
• [ ] 步骤之间的依赖关系明确
• [ ] 执行侧拿到方案后不需要重新猜需求
• [ ] 风险与回滚方式已考虑

---

第 3 步：方案必须经过多轮审查

方案生成之后，我不会马上交给 AI 开发。

先审。

我目前使用两种方式。

3.1 第一层：原模型自审

直接让当前 AI 重新审查自己的方案。

重点看：

有没有遗漏需求
有没有错误假设
有没有不必要的改动
步骤顺序是否合理
验证清单是否真的能验证
有没有潜在兼容问题

可以直接要求：

不要实现代码，只审查方案。请站在架构、业务、测试、安全、维护成本几个角度寻找问题。

3.2 第二层：换一个模型交叉审查

这是我自己实践时就在使用的方法。

例如：

Claude 生成方案
        ↓
GPT 审查
        ↓
Claude 修改

或者：

GPT 生成
        ↓
Gemini / Claude 审查

为什么要换模型？

因为同一个模型在同一上下文里，很容易继续沿用自己最开始的假设。

换一个模型，相当于重新引入一个独立视角。

3.3 审查不应该只做一次

这是我在课程中觉得最值得吸收的地方。

以前我的做法更多是：

模型 A 生成
模型 B 审
修改

以后我会倾向：

Round 1
方案生成

Round 2
原模型自审

Round 3
模型 B 交叉审查

Round 4
根据问题修改后再次复审

Round 5
复杂需求再做最后一次稳定性审查

但这里有一点很重要：

3～5 轮不是为了机械凑次数。

真正的停止条件应该是：

关键问题基本收敛
需求边界稳定
没有新增重大设计问题
验证项已经可执行
方案不再频繁变化

所以：

• 小改动可能 2～3 轮已经足够；
• 普通需求建议至少完成「自审 + 异模型审查 + 修订后复审」；
• 大改动可以靠近 5 轮甚至更多。

核心目标不是次数，而是：

让方案在真正动代码之前尽可能稳定。

3.4 审查阶段只允许两种输出

为了避免 AI 在审查阶段偷偷开始改代码，我会限制：

只输出：
1. 问题列表
2. 修改建议

不要：

直接实现
大段生成代码
顺手修改项目

先把方案审稳定，再进入开发。

第 3 步验证清单

• [ ] 原模型完成至少一次自审
• [ ] 至少有一个不同模型进行交叉审查
• [ ] 审查发现的问题已经进入方案
• [ ] 被拒绝的问题写明拒绝原因
• [ ] 关键设计问题已基本收敛
• [ ] 验证项可以实际执行
• [ ] 最终方案有明确版本
• [ ] 执行阶段只认最终版本

---

第 4 步：把定稿方案交给执行侧，严格按计划落地

方案稳定之后，再交给执行侧。

这里的执行侧可以是：

Cursor Agent
Claude Code
Codex
另一个 AI 会话
自己手写

工具并不是重点。

重点是：

执行侧拿到的是已经审查完成的方案，而不是一句模糊需求。

4.1 执行时不要现场扩大 Scope

例如原方案只要求：

新增文档重试

执行侧突然发现：

这里的整个 Repository 写得不漂亮

这时候不能顺手重构整个 Repository。

应该先记录：

偏差 / 新发现

再判断。

情况 A：不影响本次需求

记录，后续处理。

情况 B：影响方案正确性

暂停当前步骤。

回到：

Step 2 修改方案
        ↓
Step 3 重新审查

再继续。

4.2 每完成一步，就立即验证

不要等所有代码写完之后再统一测试。

应该：

Step 1
实现
↓
验证
↓
通过

Step 2
实现
↓
验证
↓
通过

如果 Step 2 出问题，很快就能定位。

否则十几个步骤一起完成之后再测试，很难知道问题从哪里开始。

第 4 步验证清单

• [ ] 执行侧拿到的是最终方案
• [ ] 按方案顺序实施
• [ ] 没有静默扩大修改范围
• [ ] 每完成一步立即运行对应验证项
• [ ] 验证失败先修复再进入下一步
• [ ] 计划外问题已记录
• [ ] 重大偏差已经重新走方案审查

---

第 5 步：最终验收——逐项确认“真的做了”

全部实现完成之后，我不会直接相信 AI 的：

已完成。

还需要再做最后一次验收。

这时候重新拿出第 2 步制定的验证清单，逐项检查。

每一项至少回答三个问题：

1. 做了吗？
2. 证据是什么？
3. 代码在哪里？

5.1 推荐输出格式

验证项	状态	证据	代码范围
FAILED 文档可以重新解析	已完成	接口测试通过	document.service.ts · retryParse()
READY 文档禁止 retry	已完成	返回 400	document.controller.ts
删除文档同步删除向量	已完成	Qdrant 数据确认删除	vector.service.ts
前端显示解析状态	已完成	页面验证	DocumentList.vue

状态建议统一：

已完成
部分完成
未完成
不适用
故意不做

如果是：

故意不做

必须写原因。

不要让任何验证项悬空。

5.2 最后再做一次 Diff Review

这一点我认为非常重要。

因为：

功能测试通过，不代表代码修改就是合理的。

AI 为了完成一个需求，有可能：

顺手重构无关代码
引入新依赖
删除边界处理
重复已有工具方法
改动计划外文件

所以最后还需要看：

git diff

检查：

实际修改文件
计划修改文件

是否一致。

Diff Review 重点检查

• [ ] 是否出现计划之外的文件
• [ ] 是否存在不必要的大范围重构
• [ ] 是否新增不需要的依赖
• [ ] 是否重复实现已有工具
• [ ] 是否删除原有边界处理
• [ ] 是否破坏兼容逻辑
• [ ] 是否留下调试代码
• [ ] 是否留下 TODO / FIXME
• [ ] 是否存在明显安全问题
• [ ] 是否存在临时代码

第 5 步验证清单

• [ ] 所有计划验证项都有状态
• [ ] 已完成项都有证据
• [ ] 已完成项都能定位到代码范围
• [ ] 未完成项有明确原因
• [ ] 偏差项有最终处理结果
• [ ] 已执行自动化测试
• [ ] 已执行 typecheck / lint / build
• [ ] 已完成必要的回归测试
• [ ] 已完成 git diff 审查
• [ ] 实际修改范围与方案基本一致

---

三、真实项目里，我是怎么跑这套流程的

前面的五步不是为了写文章才总结出来的。

在 AI 智能助手平台 里，我已经实际经历过一轮类似过程。

项目一期的目标，是先搭建一个可复用的 AI 应用底座，并完成文档 RAG 智能查询主链路。

真正开始开发之前，需要先回答很多并不只是“写代码”的问题：

Chunk 正文到底存在哪里？

MySQL 和 Qdrant 分别负责什么？

Embedding 是每个知识库自己配置，
还是平台统一？

多知识库检索应该怎么做？

Space / Organization 边界怎么定？

API 和 SSE 契约先做到什么程度？

哪些能力一期做，哪些暂时不做？

如果这些问题没有先拍板，后面直接让 AI 开发，很容易在数据库、向量库、权限、API 和前端之间反复推翻。

所以实际过程更接近下面这样：

五步闭环	AI 智能助手平台中的实际实践
1. 需求讨论	明确一期先做 AI 平台底座和 RAG 主链路，不直接进入 Hospital / HR Agent
2. 形成方案	产品规划、Phase 0 系统设计、Phase 0.5 UI/UX 设计
3. 多轮审查	R1～R6 规划审查、UI/UX Review、不同模型交叉审查
4. 执行落地	Auth/RBAC → KB/Document → Embedding/Qdrant → Conversation/RAG SSE → 前端业务 UI
5. 验收复盘	M1 阶段总结、问题与修复记录、真实 Embedding + LLM 主链路演示

其中一个很典型的审查结果，是重新明确了数据真源职责：

FileStorage
= 原始文档真源

MySQL document_chunk
= Chunk 正文真源

Qdrant
= 向量检索索引，不保存正文全文

同时还在审查中逐步明确了：

平台级统一 Embedding

统一 Collection + KB Filter

多知识库 Global Top-K

Default Space

SSE 协议先行

系统管理部分能力暂缓

这些决策的价值，并不是“文档写得更完整”。

真正的价值是：

把本来可能在编码过程中反复争论和返工的问题，提前放到了方案和审查阶段解决。

后面的 M1 复盘也验证了这一点：

先契约后编码
先 fake 后真实
先小闭环再扩能力

主链路从：

登录
↓
知识库
↓
TXT / MD 入库与向量化
↓
真实检索
↓
真实 LLM 流式回答
↓
Citation

逐步闭环。

这也是为什么我越来越认可这套方法：

方案阶段多花一点时间，并不一定会让开发变慢。

很多时候，它只是把“编码之后的返工”，提前变成了“编码之前的讨论”。

---

四、最终形成的闭环

整理之后，我目前实际使用的流程更接近：

需求
 ↓
需求讨论
 ↓
方案设计
 ↓
验证标准
 ↓
原模型自审
 ↓
异模型交叉审查
 ↓
方案修订
 ↓
再次审查
 ↓
执行
 ↓
分步验证
 ↓
自动化测试
 ↓
Diff Review
 ↓
最终验收
 ↓
完成

如果中途发现问题：

设计问题
  ↓
回方案阶段

实现问题
  ↓
留在执行阶段修复

需求变化
  ↓
重新回需求讨论

这才是真正的闭环。

---

五、一页纸速查

阶段	主要产出	通过标准
1. 需求讨论	问题、边界、成功标准	已明确“要什么”和“不做什么”
2. 方案设计	分步计划 + 验证清单	执行侧可以直接照着实施
3. 多轮审查	问题列表 + 修订方案	关键问题收敛、方案稳定
4. 执行落地	实际代码改动	每一步完成后立即验证
5. 最终验收	状态、证据、代码范围	每一个验证项都有结论

---

六、这套方法真正改变了什么

最开始使用 AI 编程时，我关注的是：

AI 写代码快不快？

后来开始关注：

Prompt 应该怎么写？

再往后发现真正重要的问题其实是：

AI 如何理解需求？

AI 为什么这样设计？

方案有没有遗漏？

怎么证明代码真的做对了？

怎么避免 AI 越改越多？

怎么让另外一个 AI 检查第一个 AI？

这时候 AI 的角色已经发生变化。

它不只是：

代码生成器

而是逐渐被拆成不同角色：

需求讨论者
方案设计者
Reviewer
执行 Agent
测试者
验收者

而人真正需要做的是：

定义问题
控制边界
判断方案
组织审查
决定取舍
确认结果

所以我现在越来越确定一件事：

AI 协作开发的核心，不是 Prompt → Code，而是 Requirement → Plan → Review → Execute → Verify。

代码只是其中一个执行结果。

真正决定项目质量的，仍然是：

需求有没有理解对
架构有没有设计对
边界有没有定义对
验证标准有没有定义对
最终有没有认真验收

AI 可以大幅提升执行速度。

但也正因为它执行得越来越快：

需求、方案、审查和验证反而变得更重要。

因为如果方向错了，AI 只会更快地把错误实现出来。

---

七、结语

这套五步闭环来自我在 AI 智能助手平台 中的一次真实实践，也在后续课程中得到了进一步验证和补充。

我不会把它当成一套永远不变的固定公式。

随着项目继续推进，我还会继续观察：

哪些步骤确实能减少返工
哪些审查值得保留
哪些流程太重
哪些验证应该自动化
哪些工作应该继续交给 AI
哪些判断必须由人来做

但至少在现阶段，我已经形成了一个比较明确的原则：

不要追求一句话让 AI 把代码全部写完。

追求的是：可讨论、可审查、可执行、可验证、可追踪。

这才是我目前理解的 AI 协作开发。