Subagents：并行分析和审查

Subagents 适合把一个大问题拆成多个只读分析或审查任务。新手不要一上来让多个 agent 同时改代码。

适合什么

Subagents 的价值是并行看问题，不是并行乱改代码。新手第一次使用时，只让它们做只读分析和审查。

• 大型项目的架构阅读。
• 前端、后端、测试分别审查。
• 复杂 Bug 的多方向原因分析。
• 提交前多角度风险审查。
• 长任务前的风险扫描。

Subagents 适合“一个问题需要多个视角”。如果只是普通小任务，主线程直接处理更快。

不适合什么

• 小任务。
• 第一次使用 CC。
• 并行修改同一批文件。
• 权限、安全、数据库还没搞清楚的任务。
• 需求还没讲清楚，只想让多个 agent “自己发挥”。

第一次只读使用

请使用 Subagents 做一次只读评审，不要修改文件。

请拆成 3 个方向：
1. 架构和目录结构。
2. 代码风险和可维护性。
3. 测试、构建和交付风险。

要求：
1. 每个方向只读分析。
2. 最后汇总成一个结论。
3. 标出高风险、中风险、低风险。
4. 不要让任何 agent 修改文件。

适合拆成哪些 agent

• 架构阅读 agent：看目录、入口、依赖和模块关系。
• 前端审查 agent：看页面、组件、响应式和交互。
• 后端审查 agent：看接口、数据流、错误处理。
• 测试交付 agent：看测试、构建、CI、发布风险。
• 安全审查 agent：看密钥、权限、数据边界、危险操作。

拆分时要按“视角”拆，不要按“人数”拆：

并行分析模板

请用 Subagents 做并行只读分析。

任务背景：
【写任务或项目问题】

请拆成 4 个方向：
1. 架构和影响范围。
2. 代码风险。
3. 测试和交付风险。
4. 安全和权限风险。

要求：
1. 所有 agent 只读，不修改文件。
2. 每个 agent 输出事实、推测、风险。
3. 最后主线程汇总成一个优先级清单。
4. 标明哪些问题必须先处理，哪些可以暂缓。

汇总结果怎么看

不要接受一堆报告堆在一起。需要一个统一结论。

请把所有 Subagents 的结果汇总成决策清单。

请输出：
1. 共同确认的事实。
2. 分歧点。
3. 高风险问题。
4. 建议的最小下一步。
5. 不建议现在做的事情。

处理分歧

Subagents 可能给出不同判断。分歧不是坏事，但要让主线程做决策：

这些 Subagents 的结论有分歧，请统一判断。

请输出：
1. 分歧点是什么。
2. 每个观点的依据。
3. 哪个观点证据更强。
4. 是否需要补充只读检查。
5. 当前最稳妥的下一步是什么。

什么时候可以让 Subagent 改代码

只有在这些条件都满足时才考虑：

• 任务已经拆成互不冲突的小块。
• 每个 agent 修改不同文件或不同模块。
• 有明确验收方式。
• 主线程能审查每个 diff。
• 不涉及密钥、生产数据、数据库迁移、Git 高风险操作。

即使满足这些条件，也建议第一次并行改代码只做低风险任务。比如文档拆分、测试补充、独立模块说明，不要一上来并行改核心业务。

并行改代码的限制模板

如果需要使用 Subagents 修改代码，请先给出隔离方案。

要求：
1. 每个 agent 负责哪些文件。
2. 文件之间是否会冲突。
3. 每个 agent 的验收标准。
4. 主线程如何汇总 diff。
5. 如果冲突，如何停止并回退。

在我确认前，不要让 agent 修改文件。

Subagents 验收标准

常见误区

• agent 越多越好。
• 并行修改一定更快。
• 每个 agent 都能独立做最终判断。
• 汇总报告越长越专业。
• 不需要人工审查 diff。

什么时候不要用 Subagents

如果任务能在 10 分钟内读清楚，就不要为了“高级”而拆 Subagents。它适合复杂问题，不适合所有问题。

不建议使用的情况：

• 只是改一段文案。
• 只是解释一个文件。
• 问题边界还没描述清楚。
• 项目很小，拆分比分析更费事。
• 没有时间审查多份报告。

Subagents 的成本

使用 Subagents 会带来额外成本：

• 需要更清楚的任务拆分。
• 需要阅读多份报告。
• 需要处理分歧。
• 需要主线程做最终决策。
• 如果让它们改代码，还要处理冲突和 diff 汇总。

所以它是复杂任务的工具，不是每次都要开启的高级模式。

验收结果

• 你知道 Subagents 适合并行分析。
• 你知道新手先只读，不并行改代码。
• 你知道最后要汇总风险，而不是堆报告。
• 你知道并行修改必须先隔离文件和验收标准。