Plan 模式 & Agent Team
🎯 学完这课你能
- 用 Plan 模式让 CC "先写方案再动手"
- 理解 Agent Team 的分工协作模式
- 知道什么场景该用 Plan、什么场景该用 Agent
Plan 模式不是显得专业用的，Agent Team 也不是为了炫并行。它们分别解决两个现实问题：需求没对齐就开干，和一个大任务全压在一个 AI 身上导致又慢又乱。
📊 你的 CC 数据说：你从未使用过并行 Agent（multi-clauding = 0）。你的会话风格是"单线程"——一次只跑一个 CC。学完这课，试试用 Agent Team 让多个 Agent 同时干活，比如一个写代码、一个做翻译、一个做文档——你的飞书+e签宝集成项目就很适合这种并行模式。
你有没有遇到过这种情况：让 CC 做一个功能，它一上来就开始写代码，结果做出来的完全不是你想要的，来回改了好几轮？
这就像你直接跟设计师说"帮我做个海报"，没给 brief 就让人开工——大概率要推倒重来。
Plan 模式：先写方案再动手
Plan 模式 = 先写 JD、定方案、对齐需求，再开始干活
正常模式：你说需求 → CC 直接写代码 → 改来改去
Plan 模式：你说需求 → CC 先研究、写方案 → 你确认 → CC 再动手
就像招聘：先写 JD 对齐岗位需求，再发布招聘——不是一上来就面试。
如果只是改一处文案、修一个明显 bug，直接执行往往最快，不需要什么都先进 Plan。
一旦需求会牵扯多个页面、多个接口、多个做法，先让 CC 出方案，通常比先写再返工省时间得多。
多个 Agent 最适合“各改各的文件、各查各的事”。如果大家都要碰同一块核心文件，单线程反而更稳。
Agent Team 不是把任务一丢就结束了，CC 主体或你自己仍然要负责整合结果、检查冲突、决定最终版本。
怎么触发 Plan 模式？
在 CC 对话中按 Shift+Tab（或点击 Plan 按钮）切换到 Plan 模式
在消息里加 "先做个计划" 或 "plan first" 这样的提示
Plan 模式下 CC 会做什么？
- 新功能开发（不是简单修 bug）
- 要改多个文件的大改动
- 你对技术方案不确定时
- CC 之前做错过、你想这次先对齐
Agent：CC 的分身术
CC 可以派出"分身"（Agent）来并行处理任务。每个 Agent 是一个独立的 AI 实例，有自己的上下文和工具。
Agent = CC 派出去的专员
你（项目经理）不需要亲自做每件事：
- 派一个专员去调研竞品 → Explore Agent（只读，不改代码）
- 派一个专员去写方案 → Plan Agent（只规划，不执行）
- 派一个专员去写代码 → General-purpose Agent（全能型）
CC 本体负责协调，Agent 负责执行——就像你不需要亲自跑各部门，派 HR BP 去就行。
常用 Agent 类型
快速搜索代码库、找文件、理解架构。不能改代码。像派人去图书馆查资料。
设计实现方案、考虑架构取舍。不能改代码。像请咨询顾问出方案。
能读、能写、能跑命令。像全职员工。用于复杂的多步骤任务。
Agent Team：组建项目组
当任务很大时，可以同时派出多个 Agent 并行工作——这就是 Agent Team。
三个 Agent 同时工作，CC 主体负责协调和合并结果。就像你做一个大的招聘项目时，派三个 HR BP 分别负责技术岗、运营岗、管理岗，你做总协调。
实战技巧
大功能先用 Plan 模式确认方案，再让 CC 执行。小 bug 直接修就行。
不要说"帮我做完这个功能"，而是说"在 src/components/ 下创建 Rating 组件，参考 Button 组件的结构"。
CC 有内置的 Todo 功能，大任务拆成小步骤，每完成一步打勾——你能清楚看到进展。
在 Plan 审批阶段，你可以修改方案、要求重新规划、或只保留部分。CC 不会介意。
什么时候 Plan，什么时候直接做
如果只是修一个文案、改一个明显 bug、补一处样式，直接执行通常比先进 Plan 更有效率。
只要你脑子里已经出现“有几种做法”“改动会不会影响很多地方”，那就值得先让 CC 出方案。
前端、后端、测试、文档各做各的文件时，并行最划算；如果大家都抢同一个核心文件，就别硬并行。
真正的标准不是“任务大不大”，而是“如果直接开工，会不会很可能做错方向”。会的话，就先 Plan。
📝 小测验
你要给绩效系统加一个"AI 自动写评语"功能，涉及前端界面和后端 API。以下哪种方式最高效？
📝 小测验 2
Explore Agent 和 General-purpose Agent 的区别是？