一个人的 AI 开发团队：五智能体协同实战

我在做一个纯离线的冥想 App「静境 · Sanctuary」，SwiftUI 和 Jetpack Compose 双端同步开发。一个人维护两个平台的成本众所周知，但我的解法不是加班，而是给自己配了一支随仓库迁移的 AI 开发团队：五个各司其职的子智能体，加上主会话里那个担任 Lead 的我。

这篇文章复盘这套体系怎么搭、怎么运转，以及它最近一次实战——双端并行修复 28 张工单、零退回——的完整过程。

团队编制：五个角色，一条铁律

五个子智能体的定义就是五个 Markdown 文件，放在仓库的 .zcode/agents/ 目录里，跟随 git 一起提交。每个文件三段式：frontmatter 声明身份与可用工具，正文写项目画像、铁律、本仓库已验证的实现约束、验证命令、汇报格式。

核心是一条铁律：测试与修复分离。QA 智能体发现问题只能开单，代码修改权只归平台开发智能体；git 提交和沟通档案维护则由 Lead 亲自执行，任何子智能体不得越权。听起来繁琐，但它消灭了「测试的顺手把自己测出的问题改了」这类最隐蔽的质量黑洞——裁判不能下场踢球。

有意思的是，这些定义文件不是一次写好的。每次实战踩坑，坑就固化回定义里：iOS 的测试命令不能带 CODE_SIGNING_ALLOWED=NO（会让测试宿主无签名崩在 Keychain）、必须带 -parallel-testing-enabled NO（否则并行 clone 必现崩溃）；Android 禁止在主线程直写加密数据库；混音引擎的渲染回调是实时线程、零同步原语。配置文件成了团队记忆的载体，新会话、新机器、新环境，克隆仓库即继承全部经验。

三种流水线

编排文档（.zcode/agents/README.md）里定义了三种标准作业模式。

缺陷闭环：UI 核对 → 双端开发并行修复 → QA 回归 → 建单 → 再修 → 复跑。适合小批量、已知范围的问题。

新功能流水线：产品专家出需求（带 FR 编号和验收标准）→ 双端开发并行实现 → UI 视觉核对 → QA 回归。适合从零加功能。

连续联动流水线是最近才成型的，也是本文主角——它解决的是大规模质量排查的场景：问题很多、边界未知、修复要走起来不能等。

连续联动流水线：28 张工单的双线实战

起因是一次大规模功能更新：几个智能体分别完成了 GRDB + SQLCipher 加密迁移、声景资源包系统、图标替换，改动三千多行。功能是好的，但引入了不少回归。我的指令是：QA 全面走查，出一个问题就立即联动派给开发修，不要攒。

工单文件：唯一的共享态

流水线的地基是一个约定格式的工单文件，QA 坐实一个问题就立即追加一块：

## QW-1 · P0 · Keychain 密钥丢失场景启动必崩 · 状态: 待派发
- 发现: 00:17
- 位置: Core/Database/SanctuaryDatabase.swift:125-169
- 证据: 口令不匹配误入明文迁移分支，throw 后 fatalError...
- 建议修复方向: 迁移前先探测是否真为明文库

这个文件是 QA 和开发之间唯一的共享通信信道。状态字段（待派发 / 已修复·待回归 / 已关闭）由 Lead 用脚本批量刷新，格式保持机器可解析。QA 在后台持续走查，开发在并行修复，互相不等待、不阻塞——QA 按「发现问题当时的状态」记录并注明时间戳，哪怕下一分钟代码已经被改掉。

Lead 的三件事

我在流水线里只做三件事：轮询、派发、裁定。

轮询工单文件，新单一出现就派给对应平台的开发智能体（后台并行执行，iOS 和 Android 互不阻塞）。这里有个基础设施细节：两个开发同时跑构建会争抢磁盘——本机只剩 1GB 余量，所以约定各自的构建缓存分目录、构建前检查磁盘、低于阈值就停下来报告而不是硬扛。资源编排是 Lead 的职责，不是每个智能体自己的事。

裁定是真正需要人（或主会话）判断力的环节。走查暴露了一批双端契约分歧：白噪轨的标识一边是 whitenoise 一边是 white_noise，资源包 id 校验正则两端各写各的，删除资源包时对用户配方的处理策略完全相反。这些没有客观对错，我的裁定惯例是默认以 Android 实现为契约基准（项目本就以它为参照端），例外时显式说明——比如删包策略最终采用了 iOS 的保守方案（保留配方、重装即恢复），因为它不会不可逆地删掉用户数据。裁定结果随工单下发给开发，两端镜像执行。

总回归：三层口径

全部修复落地后，用 SendMessage 把 QA 智能体唤回来做总回归（它带着走查时的完整上下文，不用重新熟悉工程）。回归不是把 28 项重测一遍那么简单，而是三层：

1. 逐单核验，含方案偏差评审——开发的实际实现与工单建议方向有出入时，QA 要判断偏差是否可接受并记录理由（比如工单建议 computeIfAbsent，开发用了双检锁，理由是解码可能失败且失败不应入缓存——可接受）；
2. 双端契约终验——十项跨端契约（id 正则、sha256 形态、白噪标识、勿扰默认值、呼吸轮次口径……）逐项验证两端一致，这是本轮修复最大的收益；
3. 构建、测试、红线、i18n 终态复扫——双端零警告构建、单测全绿、Manifest 无 INTERNET、227 个文案键三方一致。

结果：28/28 关闭，0 退回。附带产出还包括两个此前完全没发现的问题——白噪轨因为大小写不匹配在 iOS 上从来就没法起播，以及 UI 测试根本不在 scheme 里、日常 test 命令给出的绿灯是假的。

这套体系的边界

它不是万能的。几个诚实的观察：

裁定不可自动化。跨端契约分歧、默认值取舍、产品语义，这些决策的质量取决于对项目的理解，子智能体给证据，拍板还是 Lead 的事。

动态验证仍受环境限制。没有真机时，音频听感、勿扰实际行为、锁屏场景只能静态核验后挂起待办。本轮就有若干「待真机通道」的尾巴。

上下文成本真实存在。每个子智能体都是独立会话，背景要靠定义文件和派单指令传递。好在定义文件沉淀得足够厚，大部分项目事实不用重复交代。

文档必须跟着代码走。28 单修完的当天，我另外派产品专家把七份项目文档（PRD、双端技术方案、i18n 对照、资源包契约）全部回写到实态——代码跑在前面时，文档同步是独立工序，不会自动发生。

小结

一个人带一支 AI 开发团队，真正值得投入设计的是三样东西：角色边界（谁能改代码、谁只能开单）、共享协议（工单文件的格式与状态机）、决策机制（什么默认基准、什么例外上浮）。这三样都落在仓库里、跟随 git 迁移，而不是活在某次对话的记忆里。

至于效果，28 张工单、双线并行、28/28 关闭零退回，中间还顺手修好了两个存在已久的隐性缺陷——这个模式的产出密度，是一个人单打独斗很难达到的。