三种模式同时跑是什么感觉
三种协作模式并行运转
Mio v0.0.3 的待办清单：给 Telegram bot 的 onboarding 流程加分级输入验证、部署、根据实际使用反馈调整限制、更新六个文档、写 changelog、打 tag、跑一遍完整代码审计、修掉审计发现的所有问题、全部推到生产环境。
传统流程下这些会排成流水线：写代码、测试、提交、写文档、跑 linter、修 lint、开 PR、等 review、改 review 意见、合并、打 tag、发 release。认真做一整天，偷懒两天。
这次全部在大约 26 分钟内完成。不是在一条流水线上跑得更快——是把三种完全不同的协作模式同时跑起来了。
模式一：说哪里不对，看着它改
Session 从一个具体需求开始：给 Mio 的 onboarding 流程加输入验证。Bot 会问用户昵称、爱好、性格偏好——全是自由文本输入，共享一个 500 字的上限。
昵称字段能输 500 个字。这也太离谱了。
跟 Claude Code 说了需求。读了 onboarding 的代码，识别出所有输入字段，实现了一个双层方案：SHORT_INPUT_KEYS 里的字段限制 50 字（昵称、爱好），其他长文本字段保持 500 字。
然后 build Docker 镜像、push registry、部署到 Cloud Run。Revision 44。从读代码到实现到部署，大约 14 分钟。
这就是直接模式：你和 Claude Code 在同一个问题上协作，AI 处理机械性工作（Docker build、gcloud run deploy），你负责设计决策。
500 → 50 → 10 → 6
测试了部署后的 bot。50 字还是太多了，空白输入没有被拦截。
"50 chars feels too much for name.. doing a one fit all max is bad, also validate blanks"
Claude Code 立刻调整。不再用双层方案，改成按字段配置：昵称 10 字。风格/性格选项 30 字。爱好 50 字。长文本 500 字。
加上空白拦截——空输入被弹回来，附带一句"不能空着哦~"。Build、push、deploy。Revision 45。从反馈到上线，大约两分钟。
然后又看了一眼昵称限制。10 个字？中文名字一般 2-4 个字，昵称都很少超过 6 个。
"max 10 char seems still a lot for chinese chars?"
Claude Code 改成 6。再部署一次。
昵称上限经历了四个阶段，每一轮从"这不对"到"上线了"大约两分钟。跟传统开发完全是两种体感。反馈循环不是"提 ticket、等下个 sprint、staging 环境测"。是"说哪里不对，看着它被修，线上测，重复"。三次生产部署，全凭一段对话驱动。
模式二：踢个任务出去，自己继续干
有意思的来了。还在给昵称限制提反馈（10 → 6 那一轮），文档也需要更新。六个 docs 文件、一条 changelog、一个 v0.0.3 的 git tag。
传统流程只能排后面——先改完代码，再写文档。更常见的是"文档回头再补"，然后就没有然后了。
说了一句："spawn subagent to update all docs in docs/, todo, etc, and update changelog and tag v0.0.3 release"
Claude Code 启动了一个后台 agent，然后继续跟我讨论昵称限制。后台 agent 在读文档、更新六个文件、写 changelog、创建 git tag——与此同时，我还在跟主 session 迭代实现。
几分钟后，后台 agent 汇报：六个文档更新完毕、changelog 写好、v0.0.3 tag 已打。有个小偏差——用的旧 10 字限制，因为跟最后的改动词并发跑的，它先跑完了。记下来回头改就行。
这就是后台模式：启动一个 agent 做不需要你盯着的工作，自己继续干主线任务。AI 版的"踢掉一个 CI pipeline 继续写代码"。
模式三：定好目标，让它自己收敛
实现做完了，文档更新了。接下来要一次完整代码审计——不是随便扫一眼，要彻底审查并修复问题。
"spawn agent team to do full review and audit of current codebase, then fix any issues. Do this iteration until review agent cannot find issues"
Claude Code 创建了一个团队：一个审查 agent、一个修复 agent，用依赖链串起来。
第一轮。审查员扫描了整个代码库，产出 22 条发现——安全问题、可靠性隐患、正确性 bug。修复员接手，解决 21 条。一条被搁置：内存累加器的批处理效率优化，LOW 优先级，合理的技术债。
第二轮。审查员在修复后的代码库上重新跑了一遍。发现 3 个新问题——第一轮修复引入或暴露出来的。修复员全部解决。
第三轮。最终验证。审查员没有发现新问题。结论：APPROVED。
三轮总计：25 个问题中解决了 24 个。剩下那条是性能优化，不是 bug，不是安全风险，现在改的收益不值得增加的复杂度。
这就是团队模式：定义目标（"审查到干净为止"），Claude Code 创建 agent、设置依赖链，agent 自主迭代。没有审查任何中间结果——只看最终总结。
跟第五篇的区别在迭代循环。第五篇是单次审查：四个审查员找问题，三个修复员改完，结束。这次跑了三轮——审查员检查修复员的工作，发现遗漏，修复员再改。不只是并行审查，是收敛性审查：迭代直到增量为零。
三种模式交叠运行
实际发生的事情：
0:00 开始实现输入验证
├── 直接模式：读代码，实现分级限制
14:00 部署 revision 44
├── 直接模式：用户测试，给反馈
├── "50 字太多了，要拦空白"
16:00 部署 revision 45（按字段限制 + 空白拦截）
├── 直接模式：继续反馈
├── "10 个字对中文名还是太多"
├── 后台模式：文档 agent 启动 ← 并发
17:00 部署 revision 46（昵称 → 6 字）
├── 后台 agent 还在跑文档/changelog
19:00 后台 agent 完成（6 个文档、changelog、v0.0.3 tag）
├── 团队模式：审查团队启动 ← 并发
├── 第一轮：22 条发现 → 修复 21 条
├── 第二轮：3 条新发现 → 全部修复
├── 第三轮：验证通过 → APPROVED
26:00 全部提交、推送、gh release 创建完毕
跟主 session 结对编程的时候，文档 agent 在后台更新文档。审查团队在自主迭代的时候，在处理发布事务。
串行流程至少五个阶段：实现 → 迭代 → 文档 → 审查 → 发布。这里，阶段 2-3 重叠了（边改代码边后台更新文档），阶段 4 完全自治（审查团队自己迭代，不需要我介入）。
发布
审查团队 approve 之后，提交并推送：
git push origin main --tags
gh release create v0.0.3 --title "v0.0.3: Multimodal Input, Enhanced Onboarding, Selfie Generation"
从第一行代码到 GitHub release，一个 session。这次工作的产品视角单独写了——这篇纯粹讲工作流。
直接模式给你紧密的反馈循环——说哪里不对，看着它变。需要你的注意力。
后台模式释放注意力——启动任务，忘掉它，完成了通知你。不能响应你的反馈。
团队模式给你自治迭代——定义目标，让 agent 收敛。对快速修改来说太重了。
没有哪种模式能覆盖所有场景。真正的威力在同一个 session 里流畅地切换，有时候同时跑两三种。第四篇暗示过这一点。Agent Team 展示的是并行执行，这篇展示的是混合模式编排——人类在结对编程、委派后台任务、跑自治循环，全部同时进行。
机械性工作跑在并行流里，编排但不执行。瓶颈从执行时间移到了决策时间——做什么、限制多少合适、什么时候发布。