子代理驱动开发Skill：用「新鲜子代理 + 两阶段审查」把实现计划跑成高质量流水线
- 核心机制：为每一个任务派遣一个全新的子代理，从根源上避免上下文污染。
- 质量保障：每个任务完成后执行两阶段审查——先审「规格符合性」，再审「代码质量」，顺序不可颠倒。
- 审查闭环：审查者提出问题，实现者（同一子代理）修复，审查者重新审查，直到批准为止。
- 进度可控：控制器（你）一次性读取计划并提取全部任务文本，用 TodoWrite 管理进度，任务之间无需人工介入。
- 适用边界：有明确的实现计划、任务大部分彼此独立、并且想留在当前会话中执行时最合适。
一、该技能叫什么？如何一键安装 AI 技能提升开发效率？
技能中文名：子代理驱动开发Skill 技能英文名：subagent-driven-development 技能ID：12121
它解决的是一个非常具体的问题：当你手里已经有一份写好的实现计划（例如一份拆成了 5 个任务的功能计划），并且这些任务相对独立时，如何让 AI 稳定、可控地把计划「跑完」，而不是越跑越乱。
手动在同一个会话里连续做任务，容易出现两类典型故障：
- 上下文污染：做完任务 1 后，任务 1 的实现细节会一直占用上下文，导致做任务 3 时被前面代码风格或假设「带偏」；
- 规格漂移：写着写着就多写了自己觉得好用的功能（过度构建），或者漏掉了规格里明确要求的细节（不足构建）。
子代理驱动开发的思路是：每个任务都换一个干净的、只带着该任务完整文本与上下文的子代理去实现，实现完立刻由两个独立审查子代理把门，一个查「你有没有按规格做」，一个查「你做得好不好」。
一键安装的思路与步骤
该技能以技能包的形式提供，通常包含一个 SKILL.md 主文件以及配套的提示模板文件：./implementer-prompt.md（派实现者）、./spec-reviewer-prompt.md（派规格审查者）、./code-quality-reviewer-prompt.md（派代码质量审查者）。
- 确认安装前提：你的 AI 编码助手/代理环境支持「技能（Skill）」机制，允许加载外部技能目录；并且你所在的工作流中已具备写计划的环节，因为本技能不负责从零构思需求，它执行的是已有计划。
- 执行安装：在技能市场/技能管理入口搜索技能英文名
subagent-driven-development，或上传技能包完成安装。具体命令、入口位置与目录约定以官方说明为准，不同平台差异较大。 - 确认文件完整：安装后检查三个提示模板文件是否随主文件一起落盘。缺了模板，审查环节就派不出对应的审查子代理，流程会退化。
- 验证是否生效：回到会话中给出一个触发语境，例如「我有一个实现计划，任务基本独立，希望就在当前会话里逐个执行」。如果技能已生效，助手应当先读取计划、提取全部任务文本、创建 TodoWrite，然后才派第一个实现者子代理——而不是直接开始写代码。
- 失败排查：若助手直接开写，说明技能未被加载或未被识别；若助手要求你「换一个并行会话执行」，说明它走的是另一条替代工作流（执行计划），注意区分。
二、该技能的主要功能和特点
- 每任务一个新鲜子代理：任务之间不共享上下文，杜绝「上一个任务的假设污染下一个任务」。
- 两阶段审查，顺序固定：先做规格符合性审查，通过后才允许进入代码质量审查；规格未通过就去做质量审查属于明确的错误顺序。
- 审查循环机制：审查者发现问题 → 同一实现者子代理修复 → 审查者重新审查 → 重复直至批准，不允许「差不多就行」。
- 实现者可以提问：子代理在动工前可以就模糊点提问（例如「钩子安装在用户级还是系统级？」），控制器必须清晰完整地回答并提供上下文，不允许催促其直接开工。
- 控制器负责「喂料」：控制器一次读取计划文件、提取全部任务完整文本与上下文，子代理不读计划文件，避免每个子代理重复读取与误读。
- TodoWrite 全程可视：所有任务一次性建入待办清单，完成一个标记一个，进度一目了然。
- 自我审查 + 外部审查双保险：实现者提交前先自我审查，但自我审查不能替代规格审查与质量审查。
- 最终整体审查：全部任务完成后，再派一个最终代码审查者子代理审视整个实现，确认可以合并。
- 失败转交而非手动修补：子代理失败时派「修复子代理」并给具体指令，控制器不亲自下场改代码，避免上下文污染。
- 并行安全：因为子代理互不干扰，所以设计上可并行；但绝不允许并行派遣多个实现子代理，避免写冲突。
和普通「让 AI 一次写完」相比强在哪：普通做法是「一个大代理从头写到尾」，问题是越写越贵、越写越糊；本技能把长任务切成短任务，每个短任务都有明确的输入、明确的质量门，问题在任务边界处被拦截，而不是等全部写完再调试。
三、如何使用该技能？
步骤 1：准备一份可执行的实现计划
先用写计划类工作流产出一份拆好任务的计划文件，例如 docs/plans/feature-plan.md，每个任务应说明要做什么、验收标准是什么。
步骤 2：一次性读取并提取任务
会话开场明确声明：「我正在使用子代理驱动开发来执行这个计划。」然后只读一次计划文件，提取全部任务的完整文本与上下文，创建 TodoWrite。
步骤 3：派实现者子代理
按 ./implementer-prompt.md 模板派遣，附带该任务的完整文本 + 场景上下文（这个任务在整个功能中的位置）。子代理若提问，先回答再放行。
步骤 4：实现者实现、测试、提交、自我审查
子代理完成编码、跑测试、提交，并做一次自我审查（例如发现漏了 --force 标志并补上）。
步骤 5：规格符合性审查
派 ./spec-reviewer-prompt.md 对应的审查者。输出形如「✅ 规格符合：所有要求满足，无额外」，或指出「❌ 缺失：进度报告（规格要求每 100 项报告一次）；额外：新增了未被请求的 --json 标志」。有问题则回到实现者修复并重新审查。
步骤 6：代码质量审查
规格通过后，取 git SHA，按 ./code-quality-reviewer-prompt.md 派代码质量审查者。它可能给出「问题（重要）：魔数 100」这类意见，实现者提取 PROGRESS_INTERVAL 常量后再次送审。
步骤 7：标记完成，进入下一任务
两项审查均批准后，在 TodoWrite 中标记该任务完成，回到步骤 3 处理下一个任务。
步骤 8：收尾
所有任务完成后派最终代码审查者子代理做整体审查，然后使用 superpowers:finishing-a-development-branch 完成开发分支收尾。
输入示例：一句「任务 2 的完整文本 + 上下文」+ 提示模板。输出示例：一个已提交的代码变更、测试结果（如 8/8 通过）、规格审查结论、质量审查结论。
四、同类型竞品对比分析
| 方案名称 | 定位 | 核心功能 | 安装/使用门槛 | 适用场景 | 优势与不足 |
|---|---|---|---|---|---|
| 子代理驱动开发（本技能） | 同会话内的多任务计划执行流水线 | 新鲜子代理 + 规格审查 + 质量审查 + 审查循环 + 最终整体审查 | 需支持技能机制；需先有实现计划；需安装三个提示模板 | 任务相对独立、要求质量门、想留在当前会话 | 优势：上下文干净、质量门前置、问题早发现；不足：子代理调用次数多，控制器准备工作量大 |
| 执行计划（executing-plans，替代工作流） | 并行会话执行同一份计划 | 每个会话承担部分任务 | 需多会话/多窗口协作 | 任务之间耦合紧密、需要人工切换审查 | 优势：天然隔离；不足：有交接成本，进度不连续 |
| 纯手动逐任务执行 | 人工驱动，让助手一个个做 | 无审查门禁 | 门槛最低 | 任务少、需求还在变 | 优势：灵活；不足：无规格校验、易上下文污染、易过度构建 |
| 单一大代理一次性完成 | 一把梭完成任务 | 一次性生成实现 | 门槛低 | 小改动、原型验证 | 优势：省事；不足：任务一多就糊，问题晚发现、返工成本高 |
五、该技能的典型应用场景与实际体验情况
场景一：后端工程师的多任务重构 手里有一份拆成 5 个任务的重构计划，任务之间只共享少量接口约定。用本技能逐个任务派子代理，每个任务后过两道审查。实际体验：任务 1 的子代理主动追问「钩子安装在用户级还是系统级」，提前消解了一个会导致返工的分歧点。
场景二：独立开发者的功能开发 一个人既要写又要审，最怕「自己审自己」。规格审查子代理会指出「规格要求每 100 项报告进度，但你没做」这类硬缺口，质量审查再抓出魔数一类问题。实际体验：上手难度中等偏高，主要门槛在于必须先有一份合格的计划，计划写得含糊，审查就会变成各说各话。
场景三：需要严格 TDD 的团队 子代理会自然遵循测试驱动开发，先写测试再实现，提交前自我审查。实际体验：测试覆盖明显比手工驱动更稳定，因为每个子代理都从干净上下文开始，不会被上一个任务的「图省事」带偏。
场景四：遗留系统的批量修补 同类修复重复多次、彼此独立，非常适合本流程。注意事项：不要并行派多个实现子代理，否则会在同一批文件上产生冲突；同时要保证每个任务都提供场景上下文，否则子代理不知道这段修补在整个系统里的位置。
整体注意事项：成本确实更高——每个任务是「1 个实现者 + 2 个审查者」，还有审查循环带来的迭代；但问题在任务边界被拦下，通常比事后集中调试更便宜。
六、该技能能为用户带来的价值
- 效率：控制器一次性提取任务文本，子代理无需反复读文件；任务之间无人工介入，迭代更快。
- 质量：规格符合性审查防止「多做」和「少做」，代码质量审查保证「做得好」，两层门禁都不可跳过。
- 可控性：TodoWrite 让多任务执行过程完全可见；最终整体审查给出可合并的明确结论。
- 降低门槛：把「怎么组织一次长任务」的经验固化成流程，新手也能按流程走；子代理可提问的机制，让不确定性在动工前暴露。
- 长期价值：流程强调「不跳过审查」「不让子代理读计划」「不手动修补失败任务」，这些约束会沉淀为团队的执行规范。
七、常见问题 FAQ
Q1：怎么安装这个技能？
在支持技能机制的平台中搜索技能英文名 subagent-driven-development 安装，或上传技能包。安装后务必确认三个提示模板文件齐全，具体命令与入口以官方说明为准。
Q2：什么时候不该用它？ 没有实现计划、或任务之间紧密耦合时不该用，此时应手动执行或先头脑风暴；如果你希望跨会话并行推进，应改用「执行计划（executing-plans）」这条替代工作流。
Q3：为什么要先规格审查、后质量审查？能不能反过来？ 不能。规格符合性没通过就去做代码质量审查属于错误顺序——代码可能写得很漂亮，但根本不是规格要的东西，等于白审。
Q4：审查者提出问题后谁来改？ 由同一个实现者子代理修复，修完再由审查者重新审查，循环到批准为止。子代理整体失败时，派专门的修复子代理并给具体指令，控制器不要亲自改代码。
Q5：适合谁用？成本高吗？ 适合手里有计划、任务较独立、对代码质量有要求的开发者与小团队。成本上确实比一次性生成更高（每任务 3 次子代理调用起步，外加审查循环），但换来的是问题早发现和更少的返工。