一人一角色，逐级上报，闭环交付：我用 7 个 AI 智能体做了一个博客
问题：一个 AI 为什么不够用
用 AI 写代码已经不新鲜了。但当一个项目的复杂度超过"一个脚本"或"一个页面"的量级时，单个 AI 的问题就暴露出来了。
我最近做了一个博客系统——支持登录注册、Markdown 编辑、评论、点赞、后台管理、三层权限，部署到自有服务器。如果用传统方式，就是一个 AI 一边想需求一边写代码，写完了自己试一下，能跑就行。但这样做出来的东西往往：
需求不完整——AI 会下意识地回避复杂功能，因为它知道后面还要自己实现
代码质量参差不齐——同一个 AI 既写后端又写前端，API 路径对不上是常态
测试形同虚设——自己写的代码自己测，能放过就放过
问题反复修不好——没有升级机制，修了测、测了修，陷入死循环
这个问题本质上是角色冲突。一个人的大脑要在"想需求"和"写代码"和"找 bug"之间反复切换，顾此失彼是必然的。
"当你让同一个 AI 既当产品经理又当工程师，需求会不自觉地迁就实现难度。"
解法：把 AI 当成一个团队来用
我的思路很简单：模拟一个真实的软件团队。每个角色用独立的 AI 智能体扮演，有自己的专业领域、职责边界、以及"不能做什么"的硬约束。
这套方法论有五个核心原则：
| 序号 | 原则 | 说明 |
|---|---|---|
| ① | 角色分离 | 每个智能体只扮演一个角色，不越界 |
| ② | 单向汇报 | 甲方只与经理对接，经理是唯一信息汇集点 |
| ③ | 直接闭环 | 开发与测试直接对接，不经中间层 |
| ④ | 逐级升级 | 问题先内部解决，不行再上报 |
| ⑤ | 甲方解耦 | 老板只提需求、做决策、最终验收，不参与过程 |
团队组成：7 个角色，各司其职
我模拟了一个 7 人团队，每个角色都有明确的能力边界：
| 角色 | ✓能做什么 | ✗不能做什么 |
|---|---|---|
| 产品经理 | 把甲方大方向细化成完整 PRD | 不写代码、不做设计 |
| 经理 | 分活、收活、汇报，团队唯一对外接口 | 不递活、不写代码、不测试 |
| 架构师 | 技术选型、架构设计、数据库设计、API 设计 | 不写业务代码、不做 UI |
| 设计师 | 视觉规范、页面原型、走查开发实现 | 不写代码、不做后端 |
| 开发 | 按方案和设计稿写代码，修复缺陷 | 不改方案、不做设计 |
| 测试 | 验证功能、反馈缺陷、线上回归 | 不修代码、不做部署 |
| 运维 | 环境搭建、部署上线、配置域名和 SSL | 不写业务代码、不测功能 |
这种设计的核心价值在于自然制衡。当架构师定方案、开发实现、测试验证是三个不同的人在做事时，每个环节都有独立的专业判断，不会"自产自销"。
协作流程：8 个阶段
Plain Text
阶段一：需求规划
甲方提需求 → 经理转达 → 产品经理细化 PRD → 甲方确认
阶段二：并行启动
├─ 架构师：技术方案 + 数据库设计 + API 设计
├─ 设计师：视觉规范 + 页面原型
└─ 运维：服务器环境准备（提前启动）
阶段三：开发实现
开发：按架构方案 + 设计稿编写代码
阶段四：设计师视觉走查
设计师检查实现与设计稿一致性 → 不合格退回开发
阶段五：测试闭环（3 轮升级机制）
测试发现问题 → 开发修复 → 测试验证（最多 3 轮）
3 轮未通过 → 架构师换方案 → 再测 3 轮
仍未通过 → 经理处理 → 再不行 → 甲方决策
阶段六：部署上线
运维部署 → 配置域名/SSL
阶段七：线上回归测试
测试在真实域名上验证
阶段八：交付汇报
经理汇总结果 → 甲方验收这里有三个关键设计：
1. 运维提前启动。 架构师和设计师出方案的同时，运维就开始准备服务器环境。不等开发完成，节省整体时间。
2. 开发与测试直接对接，不经过经理。 这就是"经理只分活和收活，不递活"的原则。开发写完后直接把代码交给测试，测试发现 bug 直接退回开发。经理不参与中间传递，减少沟通损耗。
3. 设计师在测试之前先做视觉走查。 开发完成、进入测试之前，设计师先检查一遍界面实现是否跟设计稿一致。如果等到测试阶段才发现"长得不对"，测试往往不会标记为缺陷——因为测试只管功能对不对，不管好不好看。
核心机制：四级升级
这套流程里最关键的创新是问题升级机制。它解决了一个根本问题：如果开发反复修不好怎么办？
| 层级 | 负责人 | 触发条件 | 处理方式 |
|---|---|---|---|
| 第一级 | 开发 + 测试 | 测试发现缺陷 | 直接修复，最多 3 轮 |
| 第二级 | 架构师 | 3 轮未修复 | 换技术方案，同步通知设计师 |
| 第三级 | 经理 | 架构师新方案也未通过 | 重新评估任务，调整安排 |
| 第四级 | 甲方（老板） | 经理判断超出能力范围 | 甲方做最终决策 |
升级逻辑简单到一句话就能记住：
开发能修的，不麻烦架构师。 架构师能换方案的，不麻烦经理。 经理能协调的，不麻烦老板。 都搞不定的，才上报甲方。
为什么是 3 轮？太少开发来不及修，太多浪费时间和 Token。3 轮是一个平衡点——足够让开发认真对待，又不会陷入无限循环。这个数字经过了实际项目的验证。
实战数据
说千道万，不如看数据。下面是我用这套方法论实际完成博客项目的真实数据：
| 智能体数量 | 项目周期 | 测试用例 | 发现缺陷 |
|---|---|---|---|
| 7 个 | 3 小时 | 105 个 | 24 个 |
| 回归轮次 | 最终通过率 | 功能项交付 | 文档份数 |
|---|---|---|---|
| 2 轮 | 100% | 28 项 | 15 份 |
24 个缺陷中，14 个是前后端 API 路径不一致，这是最典型的"一个人写前后端"不会发现的问题——因为同一个人写的路径自己以为对上了。角色分离后，测试从第三方视角发现了这些系统性偏差。
另外，设计师在视觉走查中发现了 14 处不符合野兽派设计规范的问题。如果这些问题留到测试阶段，测试大概率不会标记——因为测试只验证功能，不关心界面是否"野兽派"。
与传统方式的对比
| 维度 | 传统：一个AI包办 | 多智能体协作 |
|---|---|---|
| 需求 | 自己写需求，下意识回避复杂功能 | 产品经理独立细化，不迁就实现 |
| 代码 | 自己写代码，前后端路径可能对不上 | 测试独立验证，API 路径不一致全部发现 |
| 测试 | 自己测试，能放过就放过 | 每轮有测试文档，缺陷可追溯 |
| 升级 | 问题反复修，没有升级机制 | 3 轮修不好升级架构师换方案 |
| 界面 | 界面好不好看，没人检查 | 设计师独立走查，不走眼的缺陷不放行 |
| 部署 | 部署靠自己摸索 | 运维提前输出完整部署方案 |
什么时候用这套方法
这套方法不是万能的，但它有明确的适用场景：
项目有明确的交付物——网站、应用、文档等，功能可以用清单描述
技术边界清晰——角色可以独立工作，不需要频繁交叉依赖
甲方愿意接受"只跟经理对接"——这是整个流程的前提
反过来，如果项目极小（一个脚本），或者需求高度不确定需要快速试错，这套方法就太重了——2-3 个角色足够。
总结
这次实践让我确信一件事：AI 的能力边界，不取决于单个模型有多强，而取决于你怎么组织它们协作。
七个角色、八个阶段、四级升级、一百零五个测试用例、单次会话约 3 小时——这个博客系统的交付质量，已经超过了我过去用传统方式做的任何 AI 辅助项目。
不是 AI 变强了，是我学会怎么让它们配合了。
一人一角色，各司其职，逐级上报，闭环交付。
—— 这就是我总结的 AI 多智能体协作十六字诀
评论