Claude Code Agent Team协作全记录：3个AI如何串起需求、开发与审查闭环

原始内容整理自飞书文档：Claude Code Agent Team 协作全记录。本文已按 Hexo 博客格式重构，并将飞书中的字符画流程图改写为 Mermaid。

三个 AI，一条心，从需求到代码到审查，全自动串联工作流。

这篇文章记录的是一次很典型、也很有代表性的多 Agent 协作实战：一个需求进来后，不再由单个 AI 从头干到尾，而是拆成三个角色分别负责分析、开发和审查，然后在 Team Lead 的协调下，串成一条完整闭环。

如果只看一句话，这次实验验证的是：

AI 真正有价值的地方，不只是“会写代码”，而是能不能把分析、实现、审查、修复和验证这一整条链路接起来。

一、先看全景

1. Team 角色分工

  flowchart LR
    analyst["🟩 analyst<br/>需求分析专家<br/>brainstorming<br/>Tmux %2"]
    developer["🟨 developer<br/>代码实现专家<br/>sdd-dev-workflow<br/>Tmux %3"]
    reviewer["🟦 reviewer<br/>代码审查专家<br/>full-review<br/>Tmux %1"]
    lead["🫵 Team Lead<br/>就是本 AI"]

    lead --> analyst
    analyst --> developer
    developer --> reviewer
    reviewer --> lead

2. 一张表看懂这支 Team

角色	定位	主要 Skill	主要职责
`analyst`	需求分析专家	`brainstorming`	理清需求、拆解目标、识别风险
`developer`	代码实现专家	`sdd-dev-workflow`	按规范建提案、写代码、补测试
`reviewer`	代码审查专家	`full-review`	做深度审查、提问题、验证修复
`Team Lead`	协调者	编排与调度	分派任务、推进流程、触发闭环

二、这次任务是什么

用户原始需求非常直接：

“新增一个预约单完成以后会发 NSQ topic：booking_appointment_completed。进行消息推送。”

翻译成更业务化的话，就是：

预约做完了，要给商家发一个通知。

这看起来像一个小需求，但一旦往工程里落，就会立刻带出一串问题：

事件从哪里来
用哪条消费链路接
如何复用已有通知架构
是否会有重复消息
异常怎么兜底
配置降级怎么做
改完之后怎么确认没有副作用

也正因为如此，这种任务很适合用来验证多 Agent 串联工作流是否真的能跑通。

三、三类 Skill 是怎么配合的

1. `brainstorming`：先把需求想清楚

这是 analyst 的核心工具，重点不是直接产出代码，而是先把问题想清楚。

项目	内容
装备者	`analyst`
用途	在动手之前先做需求探索
触发时机	收到新需求时
关注点	目标、边界、方案、风险

本次实战里，analyst 主要完成了三件事：

识别核心功能：预约完成通知推送
设计技术方案：复用现有消费者架构
发现 4 类风险：事务丢失、消息重复、异常处理、配置降级

2. `sdd-dev-workflow`：按规范把代码写出来

这是 developer 的核心工具，强调的是规范化和工程化，而不是“想到哪写到哪”。

项目	内容
装备者	`developer`
用途	按标准流程推进开发
触发时机	需求分析完成后
关注点	OpenSpec、任务拆解、实现顺序、单测补齐

本次实战里，developer 交付了这些结果：

创建 OpenSpec 提案，形成 13 个任务
实现预约完成消费者与订阅器
补充单元测试，新增 4 个用例

3. `full-review`：把质量关守住

这是 reviewer 的核心工具，目标不是“简单看一眼”，而是系统性地扫出问题。

项目	内容
装备者	`reviewer`
用途	多维度做代码审查
触发时机	代码开发完成后
关注点	代码质量、安全、性能、架构、测试、配置、文档等

本次实战里，reviewer 的产出是：

第一轮审查发现 1 个 High 和 2 个 Medium 问题
推动修复闭环继续向下执行
第二轮复审确认问题已解决
输出完整审查报告

4. 三个 Skill 放在一起，形成的不是功能集合，而是工作流

  flowchart TD
    req["用户需求输入"] --> a["🟩 analyst<br/>brainstorming"]
    a --> d["🟨 developer<br/>sdd-dev-workflow"]
    d --> r["🟦 reviewer<br/>full-review"]
    r --> check{"发现问题？"}
    check -- "是" --> loop["进入修复闭环"]
    check -- "否" --> done["🎉 交付完成"]
    loop --> a

这张图最关键的点在于：

需求不是直接丢给开发
开发完成不代表流程结束
审查结果会反向驱动修复
修复完成后还会再次回到审查

也就是说，这不是线性流水线，而是一条可以回环的链路。

四、完整协作流程是怎么跑起来的

第一幕：需求分析

流程的第一步，是由 Team Lead 把需求派发给 analyst。

analyst 启动 brainstorming 后，主要完成以下动作：

理解这次需求到底要解决什么问题
判断是否可以复用现有消费者架构
识别实现过程中的关键风险
输出一份结构化的需求分析结果

这一阶段的价值不在“写了什么文案”，而在于它把原本藏在人脑里的隐性判断显式化了。

第二幕：代码实现

拿到分析结果后，developer 启动 sdd-dev-workflow，正式进入开发阶段。

这一阶段不是直接开写，而是先：

创建 OpenSpec 提案
生成变更目录和任务清单
跑 openspec validate --strict
按任务顺序推进开发

随后才进入具体编码，实现：

Scene.COMPLETED 枚举
AppointmentCompletedConsumer
AppointmentCompletedSubscriber
对应单元测试

第三幕：代码审查

开发完成后，任务切换到 reviewer。

reviewer 启动 full-review 后，并不是简单给一句“LGTM”，而是进行系统性审查，包括：

代码质量
安全性
性能
架构
兼容性
测试覆盖
错误处理
配置管理
依赖管理
文档完整性

第一轮审查结果并不完美，发现了：

1 个 High 问题：硬编码维护风险
2 个 Medium 问题：测试覆盖不足、摘要格式不匹配

这也是这次实验最有意思的地方：流程没有停在“发现问题”，而是继续往下走。

五、真正关键的部分：自动修复闭环

1. 闭环是怎么工作的

  flowchart LR
    issue["发现问题 ❌"] --> confirm["analyst 确认问题 🤔"]
    confirm --> repair["developer 修复问题 🔧"]
    repair --> recheck["reviewer 复审 ✅"]
    recheck --> pass{"通过了吗？"}
    pass -- "否" --> confirm
    pass -- "是" --> done["🎉 广播完成"]

2. 这次闭环里具体修了什么

在这次实战中，修复动作主要包括：

给 Scene 枚举新增模板字段
消除 switch-case 的硬编码风险
补充缺失的单元测试用例
统一消息摘要格式

修完之后，再次触发 reviewer 复审，确认：

High 问题已解决
Medium 问题已解决

这才算真正结束。

3. 为什么这个闭环比“AI 写完代码就停”更有意义

很多 AI 开发演示，只展示“从需求到代码生成”这一段，看起来很顺，但真实研发里最容易出问题的，恰恰是后半段：

写完以后有没有遗漏
改动有没有隐藏风险
问题发现后谁来确认
修完以后谁来验证

这次流程最有价值的地方，就是把这些后续动作也纳入了自动串联。

六、一张图看完整执行路径

  flowchart TD
    user["用户需求"] --> analyst["analyst<br/>需求分析"]
    analyst --> plan["📄 技术方案"]
    plan --> developer["developer<br/>代码实现"]
    developer --> code["💻 7 个代码文件"]
    code --> reviewer["reviewer<br/>代码审查"]
    reviewer --> report["📋 审查报告"]
    report --> problem{"发现问题？"}
    problem -- "YES" --> fix["闭环修复"]
    fix --> analyst
    problem -- "NO" --> finish["🎉 完成"]

如果把它抽象成一句话，就是：

analyst 负责想清楚，developer 负责写出来，reviewer 负责看仔细，而 Team Lead 负责让这条链路不停下来。

七、最终交付了什么

1. 代码交付物

文件	类型	状态
`AppointmentMessageConstant.java`	修改	新增 `COMPLETED` 枚举与模板字段
`BizScenarioConstant.java`	修改	新增 `APPOINTMENT_COMPLETED`
`UserNotificationCenterMaterial.java`	修改	新增 `APPOINTMENT_COMPLETED` 素材
`BaseAppointmentSubscriber.java`	修改	重构为枚举关联模式
`AppointmentCompletedConsumer.java`	新增	预约完成消费者
`AppointmentCompletedSubscriber.java`	新增	预约完成订阅器
`AppointmentCompletedConsumerTest.java`	新增	单元测试，新增 4 个用例

2. 过程文档产出

OpenSpec 提案

retail-trade-event/openspec/changes/
└── add-appointment-completed-notification/
    ├── CHANGELOG.md
    ├── manifest.json
    └── tasks.md

代码审查报告

.doc/appointment-completed-feature/
└── full-review-20260303-120000.md
    ├── 一、基本信息
    ├── 二、变更说明 + 架构图
    ├── 三、影响面分析 + 调用链路图
    ├── 四、问题清单
    └── 五、集成测试用例清单

协作总结文档

1
2
3

memory/
├── agent-team-collaboration-report.md
└── agent-team-collaboration-story.md

八、这套工作流的几个亮点

1. 自动发现问题

不是人工 review 才能往后走，而是 reviewer 可以主动把问题抛出来，继续驱动后续链路。

2. 自动确认修复

发现问题后，不是直接让开发盲改，而是先由 analyst 确认问题成立，再把修复任务交给 developer。

3. 自动验证闭环

修复动作做完后，不是默认“应该没问题了”，而是重新交回 reviewer 做复审。

4. 人工干预被压到最低

这次流程里，人工更多是做启动和协调，而不是每一步手动盯进度。只要框架搭好了，后面就可以顺着链路自己往前滚。

九、这次实战的性能数据

指标	数值
Team 成员	3 个 AI
总耗时	约 40 分钟
消息交互	20+ 次
代码文件	7 个
单元测试	4 个新增用例
审查轮次	2 轮
修复问题	`1` 个 High + `2` 个 Medium
文档产出	3 份

十、最后总结一下

Team 分别做了什么

成员	核心动作	Skill	结果
`analyst`	想清楚	`brainstorming`	需求分析与风险识别
`developer`	写出来	`sdd-dev-workflow`	代码实现与问题修复
`reviewer`	看仔细	`full-review`	代码审查与质量把关

Team Lead 做了什么

搭团队：创建 3 个 Agent，并配置各自 Skill
分任务：把需求按分析、开发、审查分段派发
协调流：推动“发现问题 -> 确认 -> 修复 -> 复审”
写报告：沉淀过程与结果

最值得记住的一点

这次实验最酷的地方，并不是“AI 会写代码”。

真正值得记住的是：

当 brainstorming、sdd-dev-workflow、full-review 这些 Skill 被串成一条工作流后，AI 开始不再只是一个点状工具，而更像一个能持续推进任务的协作系统。

换句话说，这套 Team 的意义，不在于把某一次需求做完，而在于它证明了一件事：

发现问题、确认问题、修复问题、验证修复，这整条闭环，是可以被多 Agent 协作稳定接住的。

十一、下一步还能做什么

这支 Team 后面还可以继续用在：

新需求开发
Bug 修复
性能优化
文档补齐

只要任务边界足够清楚，角色足够明确，Skill 足够稳定，这种多 Agent 串联模式就可以继续往更复杂的研发场景延伸。

生成时间：2026-03-03
Team：dev-collaboration
模式：tmux + agent collaboration
Team Lead：就是本 AI