AI助手多轮分工协作完全指南

你是不是也这样过？

把一份写了三天三夜的需求文档发给AI，说"帮我全部做完"。等了一个小时，AI吐出一大坨代码，看着挺像那么回事。一跑——数据库表少了字段，前端页面没响应式，支付接口根本调不通。你想改一个小问题，AI说"改这一行会影响另外五个文件"。

然后你陷入了无穷的返工循环。

这不是你笨。这是用错了方法。

这篇文章不讲虚的，直接给你一套经过验证的方法论——多轮分工协作法。哪怕你对编程一窍不通，照着做，也能让AI助手帮你把项目稳稳当当地做出来。

为什么"一口气做完"是最大的坑？

很多人第一次用AI做项目，习惯把全部需求一次性扔过去。这就像：

你把一整栋楼的图纸拍给施工队队长，说"明天我来看房"。队长一个人从头干到尾——打地基的时候想着装窗户，装窗户的时候想着刷漆。最后地基歪了，窗户关不上，漆也刷花了。

AI也是一个人，它只有一个"大脑"（上下文窗口）。当你把几十页需求一次性塞给它：

问题	后果
上下文爆炸	做到第5个模块时，已经忘了第1个模块的结构
自己审自己	AI默认自己写的没错，边界情况漏一堆
牵一发动全身	想改一个字段，AI要重读全部代码，改着改着把别的地方搞坏了
返工成本极高	做完了才发现方向不对，等于全部重来

那正确姿势是什么？分轮迭代，每轮只做一件事，做完审查再下一轮。

三种协作模式，选最适合你的

方案A：AI全包内循环（⭐⭐⭐⭐⭐ 推荐）

一句话描述：AI一个人当项目经理+程序员+QA，每干一步自己审查自己，不通过就循环修，修到满意再下一步。

适合：大多数项目，不需要额外的工具链。

工作流程：

你 → 发第1轮任务
  ↓
AI拆解 → 派coding小工A → A写完
  ↓
AI审查A的代码 → 发现问题
  ↓
AI派fix小工B → B修完
  ↓
AI再审查 → 通过了 ✅
  ↓
汇报给你："第1轮完成，请确认"
  ↓
你说"通过" → AI进第2轮

优点：全自动化，你只需要发任务+确认结果，不用在中间传话。每轮交付的都是经过审查的成品。

缺点：需要AI平台本身支持"派子任务"能力（如 Hermes Agent 的 delegate_task）。

方案B：跨profile文件协作（⭐⭐⭐）

一句话描述：让不同的AI机器人各管一摊，通过共享文件夹交换成果。

适合：不同机器人有不同配置（比如一个有自己的API key，一个有自己的工具链）。

工作流程：

AI-A（蜜）："我写好商品管理了，放 shared/ 目录"
  ↓
你告诉 AI-B（佬）："去 shared/ 目录检查蜜写的代码"
  ↓
AI-B审查 → 写报告放 shared/review/
  ↓
你告诉AI-A："有3个问题要改"
  ↓
AI-A改完 → 放回 shared/

优点：可以发挥不同机器人的特长。缺点：需要你中间传话，不能全自动。比方案A慢。

方案C：同一群聊协作（⭐⭐）

一句话描述：两个AI机器人都在同一个群里，你@谁谁干活。

适合：临时需要不同机器人配合的场景。

优点：直观，看得见两个AI在聊。缺点：需要你一直盯着群，手动@、手动传话。效率最低。

推荐方案A详解：AI全包内循环

下面用一个真实项目案例，手把手教你怎么操作。

案例：做一个烧鸡商城系统

假设你要做一个卖烧鸡、卤味的在线商城，包含：

商品管理（分类、上下架、图片上传）
用户下单购买
配送员抢单/派单
微信支付宝支付
管理后台看板

这是个大项目。按"一口气做完"的方式，结果一定是稀碎。按多轮分工协作法，我们拆成6轮：

第1轮：搭骨架

你发给AI：

第1轮：搭项目骨架。按需求文档第六章，建数据库建表SQL，配 docker-compose.yml（MySQL+后端+前端三个容器），配好数据卷挂载。先不写业务代码。做完汇报。

为什么这一轮单独做？

数据库表设计决定了整个项目的根基
Docker环境决定了后续能不能跑起来
这些出错了，后面全白做

交付物：

✅ 建表SQL文件
✅ docker-compose.yml
✅ 项目目录结构

第2轮：商品管理核心

你发给AI：

第2轮：做商品分类和商品管理。按需求文档第一章，实现分类CRUD、商品CRUD、一键上下架、软删除。前后端一起做，跑通测试再汇报。

交付物：

✅ 商品分类后台管理页面
✅ 商品添加/编辑表单（含图片上传）
✅ 上下架开关
✅ 软删除（不是真删）
✅ 全部跑通

第3轮：用户端前台

你发给AI：

第3轮：做用户端前台。按需求第七章第1节，实现商品按分类浏览、购物车加减、下单流程。必须手机端适配（响应式）。做完让我看看效果。

交付物：

✅ 商品展示页（按分类筛选）
✅ 购物车（加/减/清空）
✅ 下单页面
✅ 手机端适配

第4轮：配送员系统

你发给AI：

第4轮：做配送员系统。按需求第七章第2节，实现配送员上下班切换、抢单/派单、确认送达、业绩统计。前后端都做，跑通汇报。

第5轮：支付接口

你发给AI：

第5轮：接支付。按需求第五章，集成微信支付和支付宝双通道，后台可配置商户号（不硬编码）。用户取消订单自动原路退款。跑通汇报。

第6轮：看板+整合测试

你发给AI：

第6轮：做管理后台看板。按需求第七章第3节，实时销量金额统计、商品上下架状态、10秒轮询刷新。最后全量跑一遍完整流程——从添加商品到下单到配送完成。

改东西怎么说？不用按轮次

上面说的是"从0建项目"时的分轮法。但如果项目已经建好了，你想改样式、调布局，就不要用"第N轮"了，直接说：

商品列表的卡片间距太大了，左右留白也宽。参考美团外卖的紧凑风格。改完给我截图。

或者一次说几处：

几个UI调整：

购物车按钮从绿色改成烧鸡主题的橙红色 #FF6B35

商品卡片圆角从12px改成8px

手机端底部导航栏图标放大到24px 改完一个发我一个截图。

核心原则：

盖楼时 → 分轮（第1层→第2层→第3层…）
装修时 → 直接说（这面墙刷白，那个灯换掉）

两种模式可以随时切换。

AI内部发生了什么？（不用懂技术也能看）

当你对AI说"第2轮：做商品管理"时，AI（如果支持内循环模式）内部其实是这样的：

第2轮开始
  │
  ├─ ① 拆解任务
  │   把"商品管理"拆成：
  │   - 建商品表Service
  │   - 写CRUD API接口
  │   - 写前后端联调
  │   - 写测试
  │
  ├─ ② 派coding小工
  │   小工A去写商品Service + 测试
  │   A跑完测试，返回结果
  │
  ├─ ③ 规格审查
  │   审查员B看："需求说要软删除，A实现了吗？
  │   分类ID外键建了吗？图片URL字段有了吗？"
  │   通过了 ✅
  │
  ├─ ④ 质量审查
  │   审查员C看："代码写得规不规范？边界情况测了吗？
  │   空分类的时候会不会崩溃？库存为0能下单吗？"
  │   发现问题：库存为0还能加购物车 ❌
  │
  ├─ ⑤ 派fix小工
  │   小工D去修："库存≤0时禁用加购按钮"
  │   D修完、跑测试
  │
  ├─ ⑥ 再审查
  │   审查员C再看：库存为0不能加购了 ✅ 通过
  │
  └─ ⑦ 汇报给你
       "第2轮完成。已实现商品CRUD、上下架、软删除。
       修复了库存为0仍可加购的bug。测试17/17通过。"

注意：这些"小工"“审查员"不是真人，也不是不同的机器人。它们是AI临时生出来的子任务，干完就消失，不影响后面的工作。好处是每个任务都是从零开始的，脑子干净，不串味。

小白避坑清单（建议收藏）

❌ 不要做的事

不要把整个需求文档一次扔给AI让它全做完
- 正确：分6-8轮，每轮只做一个模块
不要跳过审查步骤
- 正确：让AI每轮做完先自己检查一遍再汇报
不要在AI做第3轮时临时要求改第1轮的东西
- 正确：等这一轮做完，下轮再改。或者先暂停当前轮
不要说"随便"“你看着办”
- 正确：给明确边界，比如"参考美团外卖的风格”

✅ 一定要做的事

每轮开始时，明确范围
- “第2轮只做商品管理，不做订单，不做支付”
每轮结束后，明确说过才能下一轮
- “通过了，进第3轮” 或 “商品列表缺个搜索框，补上再进下一轮”
改东西时，一次说清楚几处
- 别改一处说一处，效率低。攒3-5处一起说
如果AI做偏了，及时喊停
- “停，这个做偏了。我的意思是… 重新来”

这些话术可以直接复制用

开局定调（第一次跟新AI合作）

下面这份需求是项目总纲，你先读完消化。不要一次全做。我们按轮次来，我说一轮你做一轮。每轮做完先自己审查一遍再汇报，我说"过"才进下一轮。拿不准的问，别猜。

—–（粘贴需求文档）—–

明白回复。

发每一轮任务

第N轮：做XX模块。范围：需求文档第X章第X节。要求：前后端做完，自己能跑通，测试通过，做完汇报。不要多做，不要少做。

确认通过

过了，进第N+1轮。

要求重做

这轮不行。具体问题：1… 2… 3… 修完再审，过了再进下一轮。

改东西（已有成品后）

几个调整：

…

…

… 改完发我截图/效果。

多机器人实战：Telegram 工作群搭建指南

上面说的都是"一个人搞定一切"的模式。但如果你手里有多个 AI 机器人（比如蜜负责日常、佬负责写代码、烧鸡负责查订单），想把它们拉到一起配合，怎么办？

方案一：建一个 Telegram 工作群（推荐起步）

空降到 @BotFather，建一个新的 Telegram 群，把蜜、佬、烧鸡等所有 bot 都拉进去。这是最直观的协作方式。

配置步骤：

① 关掉每个 bot 的 Privacy Mode（最关键一步） 默认情况下 Telegram bot 看不到群消息。必须手动关掉：

去 @BotFather
输入 /mybots
点选你的 bot
点 Bot Settings → Group Privacy → 点 Disable

每个 bot 都要关一次。 不关的话，bot 在群里就是个"哑巴"——你@它它也收不到消息。

② 把 bot 拉进群 在群里添加成员，选你的 bot 就行。

③ 配置 Hermes 的 Telegram 设置 在各 profile 的 config.yaml 中，只需确保 allowed_chats 为空（表示全部放行），bot 就能在群里工作了：

telegram:
  reactions: false
  allowed_chats: ''

④ 测试 在群里@bot 说句话，比如 @蜜 hi~，它应该会回复。

协作方式： 其他 bot 加入同一个群后，同样完成步骤①和④，就可以在群里@它们干活了：

@蜜帮佬审一下刚写的代码
@佬把测试跑一下
@烧鸡查查今天订单数

优点：

所有 bot 的工作进度透明——你能看到它们互相的对话
每个 bot 只听自己的 @mention，不会抢答
不需要复杂的后台配置
可以随时加新 bot 进来

各 profile 的 Gateway systemd 服务名：

profile（角色）	服务名	bot 昵称
default（蜜）	`hermes-gateway.service`	蜜
code（佬）	`hermes-gateway-code.service`	佬
shaoji（烧鸡）	`hermes-shaoji.service`	烧鸡

重启 gateway 的命令：

systemctl --user restart hermes-gateway-<profile>.service

⚠️ 注意： 不要从 Hermes 会话内部（比如在对话中）执行 hermes gateway restart——它会被阻止以防止重启循环。始终用 systemctl 或在 shell 中操作。

旧方法	新方法
一次扔全部需求	分6-8轮逐轮进行
AI自己写自己审	AI写+独立审查员审
做完才发现问题	每轮审查拦截问题
改一处影响全局	每轮独立，互不干扰
你只能等结果	你每轮都能看、能改、能打回

核心就一句话：

让AI当你的项目经理，别让它当你的替身。

你把项目拆成轮次发过去，它自己派小工、自己审查、自己循环修到满意——你只需要在每一轮结束时点个头或摇个头。

下次手里有项目，试试这个方法。你会发现AI突然变得靠谱多了。

这篇文章基于 Hermes Agent 的 delegate_task 内循环模式编写。其他AI平台如果支持子任务调度，也可以参考同样的思路。