问题：你的AI代理在实施过程中频繁停滞
你花了几个小时精心制定详细的实施计划。你将一个复杂功能分解成十个独立任务，每个都有清晰的规范。你把它交给AI编码代理并说：“执行这个计划。”
接下来发生的事情令人沮丧。代理完成任务1，然后暂停。“我应该继续执行任务2吗？”它问。你说是。它完成任务2，然后再次暂停。“我已经完成了前两个任务。在继续之前您需要总结吗？”每次中断都让你付出上下文切换的时间成本，打断你的工作流程。
或者更糟：代理试图在一个长会话中执行所有任务。到任务5时，它的上下文窗口已经被任务1-4的实现细节污染。它开始做出不一致的决策，忘记原始计划中的约束，或者产生与早期工作冲突的代码。随着会话进行，质量明显下降。
这是使用AI代理进行多步骤开发工作时的常见工作流程问题。代理要么：
- 过于频繁地停止，将每个任务视为需要人工批准
- 随着会话变得更长更复杂而失去上下文质量
- 未能维持任务之间的隔离，导致一个任务的实现细节渗透到另一个任务
- 不执行系统化审查，导致规范合规性和代码质量问题悄然积累
根本原因是架构性的。大多数AI代理会话将所有工作视为单一对话。没有内置机制来隔离任务上下文、强制执行审查门或防止代理提出不必要的确认问题。
好的解决方案应该改变什么
执行多任务实施计划的有效方法应该：
- 维持任务隔离 — 每个任务应该从干净的上下文开始，只包含该任务所需的内容
- 强制执行质量门 — 每个完成的任务都应该在继续之前接受规范合规性和代码质量的审查
- 消除不必要的中断 — 除非真正受阻，否则代理应该连续执行
- 保留协调器的上下文 — 主会话应该专注于编排，而不是实现细节
- 适当地扩展模型使用 — 简单任务不应该消耗昂贵的模型容量
如果你当前的工作流程存在任何这些问题，你可能想检查一个叫做子代理驱动开发的技能。
介绍子代理驱动开发
这个技能为AI代理执行实施计划实现了一种特定的执行模式。它不是在单个会话上下文中执行所有任务，而是为每个任务分派一个新的子代理，执行结构化审查，并从中央协调器协调结果。
核心原则很简单：每个任务一个新子代理 + 任务审查（规范合规性 + 代码质量）+ 广泛的最终审查 = 高质量、快速迭代。
工作原理
该过程遵循结构化循环：
- 阅读实施计划并创建带有上下文和全局约束的任务列表
- 对于每个任务：
- 分派一个新的实现者子代理，带有精确制定的指令
- 子代理实现、测试、提交并自我审查
- 一个单独的任务审查者子代理检查规范合规性和代码质量
- 如果发现关键问题，修复子代理会解决它们
- 标记任务完成并继续下一个
- 所有任务完成后： 分派最终代码审查者进行整个分支审查
- 完成开发分支并进行标准清理
关键见解是每个子代理只接收它需要的上下文——不多也不少。任务3的实现者不知道也不关心任务1的实现细节。这种隔离防止了上下文污染，并保持每个代理的专注。
何时适用此技能
此技能适用于特定情况。在以下情况下使用：
- 你有一个包含大部分独立任务的实施计划
- 你想留在当前会话中（不需要并行会话）
- 任务足够明确，新代理可以执行它们
- 你希望在任务之间设置自动审查门
它不适合以下情况：
- 任务紧密耦合，需要共享上下文才能实现
- 你需要先进行头脑风暴或创建计划（单独进行）
- 你想跨多个会话并行运行任务
评估此技能是否适合你的工作流程
在采用此方法之前，请考虑以下因素：
优势
- 上下文隔离防止长会话中的质量下降
- 结构化审查及早发现规范合规性和代码质量问题
- 连续执行消除不必要的人机交互中断
- 模型成本优化 — 你可以对机械任务使用更便宜的模型，对复杂工作保留能力强的模型
局限性和考虑因素
- 需要结构良好的计划 — 此技能执行计划，不创建计划
- 任务独立性假设 — 如果任务紧密耦合，隔离模型就会失效
- 每个任务的开销 — 分派单独的子代理比单会话执行增加了延迟
- 审查复杂性 — 审查过程增加了步骤，对于简单更改可能感觉过于繁重
模型选择策略
该技能包含具体的模型选择指导以控制成本：
- 机械任务（隔离的函数、清晰的规范、1-2个文件）：使用快速、便宜的模型
- 集成任务（多文件协调、调试）：使用标准模型
- 架构任务：使用能力最强的可用模型
- 审查任务：根据差异的复杂性和风险匹配模型能力
这种分层方法防止了对简单转录工作使用昂贵模型的常见错误。
使用此技能前需要检查什么
如果你正在考虑这种方法，请检查以下方面：
仓库信号
该技能来自obra/superpowers仓库，该仓库具有显著的社区吸引力（233K+星）。这表明该方法已在许多用例中经过测试。但是，请务必验证：
- 许可证兼容性 — 检查LICENSE文件是否适合你的用例
- 近期活动 — 确保仓库正在积极维护
- 问题跟踪器 — 寻找与你的用例类似的问题报告
安全考虑
该技能被标记为低安全级别，这意味着它不会引入超出你的AI代理已有的安全风险。但是：
- 代码执行 — 子代理将执行代码，因此请确保你的环境具有适当的沙盒化
- Git操作 — 该过程涉及提交和分支操作；了解将进行哪些更改
- 审查彻底性 — 自动审查有帮助，但不应替代关键系统的人工代码审查
设置上下文
该技能引用了特定的提示文件（implementer-prompt.md、task-reviewer-prompt.md）和审查包脚本。在使用之前：
- 验证这些文件存在于你的环境中
- 了解审查包生成的工作原理
- 首先用小型、非关键的计划进行测试
与工作流程的集成
考虑此方法如何适应你现有的实践：
- 版本控制 — 该技能假设基于Git的工作流程，每个任务都有提交
- 测试 — 实现者应该测试他们的工作；确保你的测试基础设施支持这一点
- 代码审查 — 自动审查补充但不替代人工审查流程
实际示例：此技能何时有帮助
想象你正在实现一个需要以下步骤的功能：
- 添加新的数据库表
- 创建API端点
- 构建前端组件
- 编写集成测试
- 更新文档
这些任务大部分是独立的。使用子代理驱动开发：
- 任务1获得仅包含数据库模式上下文的子代理
- 任务2获得API设计上下文，而不知道任务1的实现细节
- 每个任务在继续之前都会被审查
- 最终审查确保一切协同工作
如果没有这种方法，单个代理可能会在任务2中记住任务1的特定列名，做出不在规范中的假设，或者失去对API设计要求的关注。
何时不使用此技能
此方法会增加开销。在以下情况下跳过它：
- 单个任务 — 直接执行
- 探索性工作 — 你在弄清楚要构建什么，而不是执行计划
- 紧密耦合的更改 — 需要理解彼此实现的任务
- 时间关键的热修复 — 审查循环增加了你无法承受的延迟
开始使用
如果此方法解决了你的工作流程问题，你可以：
- 查看完整的技能文档
- 检查仓库结构和提示文件
- 用小型、定义良好的实施计划进行测试
- 根据你的成本和质量要求调整模型选择策略
该技能提供了一个结构化框架，但你需要根据你的具体开发环境和团队实践进行调整。