子代理驱动开发Skill：一任务一子代理 + 任务间代码审查，实现高质量快速迭代
核心结论速览
- 它是什么：子代理驱动开发Skill（英文名
subagent-driven-development，技能ID 13647）是一个「执行实施计划」的工作流技能，核心是在同一个会话里为每个任务分发一个新的子代理，并在每个任务完成后自动做一次代码审查。 - 解决什么问题：长会话里连续做多个任务时，上下文污染、任务互相干扰、问题发现太晚、任务之间还得等人介入——这三四件事是这个技能主要针对的痛点。
- 差异化在哪：与「执行计划（并行会话）」相比，它不换会话、不交接；与「手动一个个做」相比，它自带质量门控和修复闭环。
- 谁最适合用：手上已有一份写好的实施计划、任务之间大多独立、希望连续推进又要质量兜底的开发者。
- 前置条件：需要配套的写计划、代码审查、分支收尾等技能，以及 git 提交记录（审查要对比提交区间）。
一、该技能叫什么？如何一键安装 AI 技能提升开发效率？
基本信息
| 项目 | 内容 |
|---|---|
| 技能中文名 | 子代理驱动开发Skill |
| 技能英文名 | subagent-driven-development |
| 技能ID | 13647 |
| 技能类型 | 开发工作流 / 流程编排类技能 |
| 核心原则 | 每个任务新子代理 + 任务间审查 = 高质量，快速迭代 |
它到底解决什么问题
在没有这类技能之前，让 AI 编码助手「连续做完一整份实施计划」通常是两种结局：
- 一个会话一口气做完：上下文越滚越长，前面的任务信息干扰后面的任务，越往后越容易改错文件、漏掉要求，等发现问题时已经改了一大片。
- 每个任务换一个会话：上下文干净了，但要反复交接、反复贴计划，人工等待成本高。
子代理驱动开发Skill 走的是第三条路：会话不换（没有交接成本），但每个任务由全新的子代理来做（没有上下文污染），任务之间插一道代码审查作为质量门控。
一键安装思路与步骤
由于技能详情中未给出具体的安装命令与下载地址，以下按通用流程描述，具体命令、安装目录与入口请以官方说明为准。
第一步：确认安装前提
- 你的 AI 编程环境需要支持「技能（Skill）」加载机制，并具备任务分发（子代理）能力——因为整个流程依赖「分发实施子代理」和「分发代码审查者子代理」。
- 需要有 git 版本控制：代码审查环节要对比任务前的提交与当前提交（
BASE_SHA与HEAD_SHA），没有提交记录就无法定位改动范围。 - 建议同时安装它的配套技能：写计划（writing-plans）、请求代码审查（requesting-code-review）、收尾开发分支（finishing-a-development-branch），子代理侧还需要测试驱动开发（test-driven-development）。缺一环，流程就会在某个步骤断掉。
第二步：从技能入口安装
在技能市场/技能库中找到「子代理驱动开发Skill」（技能ID 13647），按其提供的安装方式添加到本地技能目录或当前工作区，然后新开一个会话，让技能配置重新加载生效。
第三步：验证是否生效
在会话里输入类似这样的指令：
我正在使用子代理驱动开发来执行这份计划：
docs/plan/xxx.md
如果安装成功，代理应当表现出以下行为特征，可据此判断是否生效：
- 先读取计划文件，并创建一份包含全部任务的 TodoWrite（任务清单）；
- 然后只分发一个实施子代理（而不是同时分发多个）；
- 子代理返回报告后，接着分发代码审查者子代理，并带上
WHAT_WAS_IMPLEMENTED、PLAN_OR_REQUIREMENTS、BASE_SHA、HEAD_SHA、DESCRIPTION这几项信息； - 审查完成后才把当前任务标记为完成，再进入下一个任务。
如果它直接开始写代码、跳过了审查环节，说明技能没有被正确加载，需要回到官方说明检查安装路径与启用方式。
二、该技能的主要功能和特点
1. 同会话连续执行，零交接成本 与「执行计划（并行会话）」不同，它坚持在当前会话内推进，不需要新开会话、不需要再贴一遍背景，进度是连续的。
2. 每个任务一个全新子代理，杜绝上下文污染 每做一个任务就分发一个新子代理，前一个任务的试错、废弃方案、临时上下文不会污染下一个任务。这是它区别于「一个会话做到底」最本质的地方。
3. 任务之间强制代码审查，问题早发现 每个任务结束都分发「代码审查者」子代理，按模板返回优点、问题（关键/重要/次要）、评估三级结论。这是整个技能的质量门控核心。
4. 分级反馈处理机制 关键问题立即修复；重要问题在本任务进入下一个任务之前修复；次要问题记录在案、注意即可。规则清晰，不需要每次自己判断优先级。
5. 修复闭环：用子代理修，而不是自己上手改 如果子代理任务失败或审查发现问题，技能要求分发带具体指令的修复子代理，明确禁止手动修复——因为手动介入会把上下文污染带回来，破坏这套机制的根基。
6. 进度可视化 全程用 TodoWrite 维护任务清单，任务何时开始、何时标记完成一目了然，适合长流程执行。
7. 显式红线（红旗警告） 技能明确列出四条禁令：不跳过任务间审查、不带着未修复的关键问题继续、不并行分发多个实施子代理（会冲突）、不读计划任务就直接实施。这类「负向约束」在同类工作流里并不常见，但对稳定性很关键。
8. 收尾可衔接 所有任务通过最终审查后，会声明并调用 finishing-a-development-branch 技能完成分支收尾，把「开发」和「合并/交付」串成一条线。
和普通工具比强在哪：普通 AI 编码助手是「你问一句它写一段」，质量靠你自己盯；这个技能把「拆任务 → 实施 → 审查 → 修复 → 收尾」变成了一条有门控的流水线，你只在关键节点介入。
三、如何使用该技能？
以下是完整的操作步骤，可直接照着执行。
步骤 1：先有一份可执行的计划
这个技能不负责写计划，它只负责执行计划。前置动作是用 writing-plans 类技能产出一份实施计划文件，任务粒度尽量拆到「一个子代理一次能做完」的程度。任务越独立，这个技能效果越好。
步骤 2：加载计划并建立任务清单
用一句自然语言声明你正在使用该技能，并给出计划路径，代理会读取计划并生成 TodoWrite。
我正在使用子代理驱动开发执行
docs/plan/payment-refactor.md，请先加载计划并创建任务清单。
输出：一份按顺序排列的任务列表，每个任务带名称与状态。
步骤 3：分发实施子代理（每个任务一次）
代理会为任务 N 分发一个实施子代理，提示内容大致如下（这是技能内置模板的中文示意）：
你正在实施来自
[计划文件]的任务 N。 请仔细阅读该任务，你的工作是：
- 精确实施任务指定的内容
- 编写测试（如任务要求，遵循 TDD）
- 验证实施效果
- 提交你的工作
- 报告返回 工作目录：
[目录]报告内容：实施了什么、测试了什么、测试结果、更改的文件、遗留问题。
输出：子代理返回一份工作摘要，例如「实现了钩子安装脚本，测试 5/5 通过」。
步骤 4：分发代码审查者子代理
实施完成后，代理会自动分发审查子代理，并填入五类信息：实现了什么、对应的计划要求、任务前提交、当前提交、任务摘要。审查者返回优点、问题分级与评估结论。
步骤 5：按级别处理审查反馈
- 关键问题 → 立即修复，不能拖；
- 重要问题 → 进入下一个任务前修完；
- 次要问题 → 记录，自行判断是否顺手处理。
如果需要修复，就分发一个修复子代理，指令要具体，例如：
修复代码审查中的问题：缺少进度报告，请每 100 次对话输出一次进度。
步骤 6：标记完成，进入下一个任务
当前任务在 TodoWrite 中标记完成，然后回到步骤 3，循环执行下一个任务。
步骤 7：全部任务完成后做最终审查
所有任务结束后，分发一个最终代码审查者，检查整体实施情况、所有计划要求是否满足、整体架构是否合理。
步骤 8：收尾
最终审查通过后，代理会声明使用 finishing-a-development-branch 技能，按该技能的流程验证测试、给出选项并执行选择，完成开发分支的收尾。
一句话总结调用方式：你只需要说清「用子代理驱动开发执行哪份计划」，剩下的分发、审查、修复、标记由技能按步骤推进。
四、同类型竞品对比分析
| 方案名称 | 定位 | 核心功能 | 安装/使用门槛 | 适用场景 | 优势与不足 |
|---|---|---|---|---|---|
| 子代理驱动开发Skill（subagent-driven-development） | 同会话内、带质量门控的计划执行工作流 | 每任务新子代理、任务间代码审查、审查分级、修复子代理闭环、最终整体审查 | 需支持技能机制与子代理分发能力，需 git 提交记录，需配套写计划/审查/收尾技能；以官方说明为准 | 任务大多独立、希望连续推进又要质量兜底的开发计划 | 优势：上下文干净、问题早发现、无需人工在任务间介入。不足：子代理调用次数多、token 成本上升；任务强耦合时反而不如手动 |
| 手动执行（人 + AI 对话逐个任务） | 最原始的方式 | 人自己拆任务、自己盯质量 | 零门槛 | 任务少、耦合度高、需要边做边改计划 | 优势：灵活、可控。不足：质量全靠人盯，长任务容易疲劳漏检，进度不可视 |
| 执行计划（executing-plans，并行会话） | 换会话推进计划 | 每个任务在独立会话中执行 | 需要频繁切换会话与交接上下文 | 需要任务之间完全隔离、或需要人工在会话间隔中复核 | 优势：隔离彻底。不足：有交接成本，任务之间要等待人工介入，连续性差 |
| 单一 AI 编码助手（无技能流程） | 通用编码辅助 | 直接写代码、改文件 | 门槛最低 | 单点问题、临时修改、探索性编码 | 优势：上手快。不足：缺少审查门控与任务清单，多任务连续执行时容易上下文污染、问题发现晚 |
怎么选：任务独立 + 有明确计划 + 想要连续推进 → 选子代理驱动开发；任务强耦合或计划本身还没想清楚 → 先回到头脑风暴/写计划，或直接手动执行。
五、该技能的典型应用场景与实际体验情况
场景一：后端工程师执行重构计划
角色与痛点：后端工程师已经写好一份「支付模块重构」计划，包含拆解、替换、补测试等十几个任务。过去在一个会话里做，做到第八个任务时模型已经开始忘记前面的约定。
使用方式：加载计划 → 每个任务分发新子代理 → 任务间审查 → 关键问题当场修。
实际体验：上手难度不高，会写自然语言指令即可；效果主要体现在「后期不失控」——每个任务都在干净上下文里完成，审查又在任务边界上截住了问题。注意事项：必须先提交每个任务的代码，否则审查拿不到 BASE_SHA 与 HEAD_SHA，审查质量会大打折扣。
场景二：全栈开发批量实现独立功能点
角色与痛点：独立开发者手上有一份功能清单（列表页、导出、权限校验……），这些任务彼此独立，但一个个做要反复向 AI 解释上下文。
使用方式：一次性把清单写成计划文件，交给技能连续执行，只在审查报出重要问题时介入。
实际体验：连续性是最大收益，任务之间不需要人工等待。注意事项：绝不要让它并行分发多个实施子代理，技能本身也把这条列为红线——并行会冲突。
场景三：小团队的自动化质量门控
角色与痛点：小团队没有专职代码评审，AI 生成的代码直接进主干，风险高。
使用方式：把「任务间必须审查」固化成流程，审查者按模板输出优点、问题分级、评估三项结论，作为进入下一任务的前置条件。
实际体验：审查分级（关键/重要/次要）让处理优先级不再靠感觉。注意事项：审查者子代理依赖 requesting-code-review/code-reviewer.md 模板，如果模板缺失，审查结论会变得笼统。
场景四：遗留系统迁移的清单式任务
角色与痛点：平台工程师面对几十条迁移清单，任务独立但重复度高，人工做既慢又容易漏。
使用方式：写计划 → 技能逐条执行 → 每条任务后审查 → 全部完成后做最终整体审查，确认所有计划要求都满足。
实际体验：最终审查这一环价值很高，它检查的是「整体架构与计划要求是否对齐」，而不只是单个任务对错。注意事项：子代理任务失败时，不要自己上手改，而是分发带具体指令的修复子代理——手动修复会把上下文污染带回来，这是技能明确警告的一点。
六、该技能能为用户带来的价值
1. 效率：把「任务之间的等待」消掉 传统多任务开发里，任务与任务之间要人来看一眼、确认一下、再交代下一件事。这个技能把审查做成自动检查点，任务间无需人工介入，整体推进是连续的。
2. 质量：把问题拦在任务边界上 每个任务后审查一次，等于把一个长流程切成若干短反馈环。技能里那句「早期发现问题，比后期调试更便宜」正是它的成本观：多花的是子代理调用，省下的是后期排查与返工。
3. 门槛：不用自己搭多代理框架 想实现「一任务一子代理 + 审查」，通常要自己写编排逻辑。这个技能把它变成了一句自然语言指令 + 一套固定步骤，个人开发者也能用上团队级的流程约束。
4. 可追溯：进度与决策都有记录 TodoWrite 记录任务状态，审查记录保留每个任务的优点与问题，最终审查再对整体做一次校验。事后复盘「哪一步埋了雷」是有据可查的。
5. 长期价值：流程标准化 「每任务新子代理 + 任务间审查 + 红线和禁令」是一套可以反复套用的工作方式。用得越久，越能把「靠人盯质量」变成「靠流程保证质量」。
成本提示：技能本身也坦率说明了代价——子代理调用次数更多。所以它更适合「任务独立、计划明确」的中大型实施计划，而不是三五行代码的小改动。
七、常见问题 FAQ
Q1：这个技能怎么安装？装完没反应怎么办？
A：在技能库中找到「子代理驱动开发Skill」（技能ID 13647），按官方说明添加到本地技能目录或工作区，然后新开会话加载。具体命令与目录以官方说明为准。装完没反应，优先检查三件事：当前环境是否支持子代理/任务分发；是否已有一份可读取的计划文件；配套的写计划、代码审查、收尾技能是否也装了。可以先用「复述这个技能的 7 个步骤」来验证它是否真的被加载。
Q2：使用这个技能收费吗？
A：技能详情中没有涉及价格信息，是否收费取决于你获取它的平台与所依赖的模型服务，以官方说明为准。需要留意的是隐性成本：它会调用更多子代理（实施、审查、修复、最终审查），token 消耗会高于单会话直做，这属于「用成本换质量」的取舍。
Q3：它适合谁用？什么情况下不该用？
A：适合「已经有一份写好的实施计划、任务大多独立、希望在当前会话里连续推进且要有质量门控」的开发者。不适合三种情况：计划本身还需要先评审（应改用执行计划类流程）、任务之间紧密耦合（手动执行更好）、计划需要修订（先做头脑风暴）。技能里明确写了「何时不使用」，建议照着判断。
Q4：它和执行计划（并行会话）到底怎么选？
A：看你要「隔离」还是要「连续」。执行计划用并行会话，隔离更彻底但要交接、要人工在任务间介入；子代理驱动开发在同一会话内推进，没有交接成本、任务间自动审查，但要求任务相对独立。一句话：想省交接选它，想彻底隔离选并行会话。
Q5：子代理把任务做失败了，我能自己上手改吗？
A：技能明确要求不要手动修，因为手动介入会污染上下文，破坏「干净上下文 + 审查门控」的前提。正确做法是分发一个修复子代理，并把问题列具体，例如「修复代码审查中的问题：缺少进度报告，请每 100 次对话输出一次进度」。同理，也绝不要并行分发多个实施子代理，会互相冲突。