Appearance
subagent-driven-development 的核心思路是：每个任务用一个上下文干净的子代理来执行，执行完毕后先审查"是否按规格实现"，再审查"代码质量是否过关"，两道关卡都通过才标记完成。相比直接让 AI 在同一对话里连续干活，这种方式能避免上下文污染、防止实现偏离规格，并且可以连续工作数小时而不"跑偏"。
subagent-driven-development：每个任务用独立子代理执行，双阶段审查
做过较大功能开发的人都有一个痛点：让 AI 连续执行十几个任务时，到后面它会开始"记混"——把之前任务的代码风格带进来、在新文件里引用不存在的变量、或者悄悄给你多实现几个"顺手"的功能。subagent-driven-development 就是为解决这个问题而设计的工作流。
核心机制：三个角色，两道关卡
整个流程由三类子代理协作完成：
实现代理（Implementer）：接收单个任务的完整描述，在隔离的上下文中完成代码编写、测试和提交。如果有疑问，在开工前提问，而不是做完之后说"我假设你的意思是……"。
规格审查代理（Spec Reviewer）：不看实现代理的"自述报告"，直接读代码，对照原始规格逐条核对。目标很明确：有没有漏实现的需求？有没有多余的功能？有没有理解偏差？
代码质量审查代理（Code Quality Reviewer）：在规格审查通过之后才介入，检查代码的可读性、可测试性、文件职责是否清晰、是否遵循了现有代码库的模式。
这两道审查的顺序不能颠倒。先确认"做了正确的事"，再确认"事情做得正确"。
与普通执行方式的本质区别
普通方式：同一上下文，连续执行
把计划丢给 AI，让它一口气执行，或者人工逐步指令。问题在于：
- 越往后，上下文里积累的历史信息越多，AI 开始受之前决策的干扰
- 任务之间没有隔离，Task 3 的代码很可能受 Task 1 遗留问题的影响
- 没有结构化的审查，"感觉没问题"就过了
- 人需要频繁盯着，稍不注意就跑偏了
subagent-driven-development：隔离上下文，双重验证
每个子代理只知道自己这个任务需要知道的事情。主控代理（也就是你在对话里操控的这个 AI）负责从计划里提取任务文本和上下文，精确地喂给实现代理，而不是让实现代理自己去翻计划文件。
这意味着：
- 实现代理不会被 Task 1 的遗留问题影响 Task 5 的实现
- 规格审查代理独立核对代码，不受实现代理"乐观陈述"的影响
- 每个任务完成后都有双重质量门禁，不符合才进入下一个
完整执行流程
读取计划，提取所有任务：主控代理一次性读取计划文件，提取所有任务的完整文本和上下文，建立 TodoWrite 任务列表。
派发实现代理：按任务顺序，将完整任务描述 + 上下文传给新的实现代理。
处理实现代理的反馈：
DONE：继续进入审查流程DONE_WITH_CONCERNS：先读它的顾虑，必要时处理后再进入审查NEEDS_CONTEXT：补充信息后重新派发BLOCKED：判断是上下文问题、模型能力问题还是任务拆分问题，对症处理，不要强行重试
规格合规审查：派发规格审查代理，让它读实际代码，对照原始需求核对。发现问题则由实现代理修复，修复后再次审查，循环直到通过。
代码质量审查：规格通过后派发代码质量审查代理，检查代码质量。同样循环直到通过。
标记完成，进入下一个任务。
所有任务完成后：派发最终审查代理对整体实现做一次总览，然后进入收尾流程。
模型选择策略
子代理调用有成本，选对模型可以节省大量开销：
- 单文件、规格清晰的机械性任务：用快速廉价模型
- 多文件、需要跨模块协调的任务：用标准模型
- 架构设计、需要全局代码理解的审查任务：用最强模型
大多数实现任务在计划写得好的情况下属于"机械性任务"，可以用便宜模型处理。审查任务则值得用更强的模型。
适合使用的场景
- 有一份完整的实现计划，任务之间相对独立
- 需要连续执行多个任务（5 个以上），不想一直盯着
- 对代码质量有要求，不能"差不多就行"
- 在同一个会话里执行，不需要切换到独立终端
如果任务之间高度耦合（比如任务 B 的接口完全取决于任务 A 的内部实现），或者还没有完整计划只是在探索，这个工作流就不太适合，应该先去做计划或用手动方式探索。
关键注意事项
几条不能违反的红线：
- 不能并行派发多个实现代理：会产生冲突，只能串行
- 规格审查必须在代码质量审查之前：顺序不能颠倒
- 审查发现问题不等于"标记问题然后继续"：必须修复后重新审查，不留尾巴
- 实现代理的自我审查不能替代双阶段审查：两者都要
- 不在主分支直接开工：需要隔离的 git worktree
FAQ
Q: 为什么不直接让 AI 一次性把所有任务都做完？
A: 越往后上下文越混乱，实现质量越难保证。子代理隔离上下文解决了这个问题，每个任务都是干净起点。
Q: 两道审查感觉很费时间，值得吗？
A: 错误发现得越晚，修复成本越高。在单任务完成后立刻审查，比全部做完后再来一锅端问题要便宜得多。而且审查代理本身速度很快。
Q: 实现代理说 BLOCKED 了怎么办？
A: 先判断原因。是上下文不够就补充上下文重新派发；是任务太复杂就拆分；是模型能力不足就换更强的模型；如果是计划本身有问题，就升级给人工处理，不要强行让同一个代理重试。
Q: 和 executing-plans 有什么区别？
A: executing-plans 适合在独立平行会话里执行、需要人工检查点的场景，且不依赖子代理功能。subagent-driven-development 在同一会话内运行，自动完成双阶段审查，不需要人工介入每个任务，更适合支持子代理的平台（如 Claude Code）。
Q: 计划要写到什么程度才适合用这个工作流？
A: 每个任务的描述要足够完整，实现代理拿到后不需要猜测意图。如果你的计划只写了"实现登录功能"，那先去把计划细化，再来用这个工作流。