这个 GitHub 爆火的子智能体驱动开发 Skill 到底能干嘛?实测来了
前言
如果你用过 Claude Code、Cursor 或其他 AI 编码工具,大概率遇到过这个问题:让 AI 一次性完成太多任务,质量就开始下滑。代码混乱、漏掉需求、过度设计……这些问题在长任务中几乎是必然的。
今天搬运的这个 Skill——子智能体驱动开发(Subagent-Driven Development)——来自 GitHub 16.3 万星的 obra/superpowers 项目,提供了一套系统性的解决方案:把大任务拆成独立小任务,每个任务分派一个全新子智能体,完成后做两轮审查。听起来简单?背后的方法论值得深挖。
原始项目简介
obra/superpowers 是一个「agentic skills 框架 + 软件开发方法论」,由 obra 创建。核心理念是:AI 编码不应该「一口气干完」,而应该像管理一个小型团队一样——分任务、做审查、保质量。
- ⭐ GitHub Stars:163,220+
- 📅 最近更新:2026-04-16
- 📄 License:MIT
- 🔗 项目地址:https://github.com/obra/superpowers
该项目包含 8 个核心 Skill,涵盖头脑风暴、计划执行、TDD、系统调试、代码审查等场景。本次搬运的是其中最核心也最实用的 subagent-driven-development。
这个 Skill 解决什么问题?
问题场景: 你有一个包含 5 个任务的实现计划。传统做法是让 AI 在当前会话中依次执行所有任务。但这样做有几个致命问题:
- 上下文污染:做完任务 1 后,AI 的上下文中残留了大量任务 1 的信息,干扰任务 2
- 质量下降:没有系统性的审查环节,问题要到最终测试才被发现
- 过度/不足构建:AI 容易”自作聪明”添加没被要求的功能,或者漏掉关键需求
解决方案: 子智能体驱动开发的核心思想:
- 每个任务分派一个全新的子智能体(干净上下文)
- 每个任务完成后进行两阶段审查:
- 阶段一:规格合规审查——是否实现了被要求的内容?有没有多做或少做?
- 阶段二:代码质量审查——代码是否干净、可测试、可维护?
- 协调者(你)保留上下文用于整体调度和问题解答
核心流程
读取计划 → 提取所有任务 → 创建任务清单 ↓┌─ 任务 1 ───────────────────────────────┐│ 分派实现者子智能体 ││ ↓ ││ 实现者提问?→ 回答并提供上下文 ││ ↓ ││ 实现、测试、提交、自查 ││ ↓ ││ 阶段一:规格合规审查 ││ ↓ 不通过?→ 修复 → 复审 ││ 阶段二:代码质量审查 ││ ↓ 不通过?→ 修复 → 复审 ││ ↓ 通过! ││ 标记任务完成 │└────────────────────────────────────────┘ ↓┌─ 任务 2、3、4...(同样流程) │└────────────────────────────────────────┘ ↓最终代码审查 → 合并分支 → 完成核心功能与亮点
1. 四个实现者状态,精准处理异常
实现者子智能体会报告四种状态之一:
| 状态 | 含义 | 处理方式 |
|---|---|---|
| DONE | 任务完成 | 进入规格审查 |
| DONE_WITH_CONCERNS | 完成但有疑虑 | 先读疑虑,再审查 |
| NEEDS_CONTEXT | 需要更多上下文 | 补充信息后重新分派 |
| BLOCKED | 无法完成 | 评估阻塞原因:补充上下文 / 升级模型 / 拆分任务 / 上报人类 |
这种状态机设计**避免了 AI「硬着头皮乱做」**的常见问题。
2. 智能模型选择,省钱提速
不是所有任务都需要最强模型:
- 1-2 个文件 + 完整规格 → 用廉价快速模型
- 多文件 + 集成关注 → 用标准模型
- 需要设计判断或架构理解 → 用最强模型
这个分级策略可以显著降低 API 成本。
3. 规格审查的「不信报告」原则
规格审查者被明确告知:不要相信实现者的报告。实现者可能报告得太快、不准确或过于乐观。审查者必须直接阅读代码,逐行对比需求。这条规则直接杜绝了”AI 自说自话”的质量隐患。
4. 两阶段审查顺序不可颠倒
必须先做规格合规审查,再做代码质量审查。 如果规格都不合规,代码写得再漂亮也是白搭。这个看似简单的顺序要求,实际上防止了大量”方向正确但跑偏”的情况。
安装与使用方法
这个 Skill 是 obra/superpowers 项目的一部分,使用方式如下:
前置条件
- 需要一个支持子智能体的 AI 编码工具(Claude Code、Cursor 等)
- 安装了 superpowers 框架
- 有一个写好的实现计划文件
使用步骤
- 读取计划文件:一次性读取完整计划,提取所有任务的完整文本
- 创建任务清单:使用 TodoWrite 跟踪所有任务
- 逐个执行任务:
- 分派实现者子智能体(使用
implementer-prompt.md模板) - 回答实现者的问题
- 实现完成后分派规格审查者(
spec-reviewer-prompt.md) - 规格通过后分派代码质量审查者(
code-quality-reviewer-prompt.md) - 两个审查都通过后标记任务完成
- 分派实现者子智能体(使用
- 最终审查:所有任务完成后,分派最终代码审查者
- 合并分支:使用
finishing-a-development-branch完成开发
提示词模板
项目提供了三个现成的提示词模板:
- implementer-prompt.md:包含完整的任务描述模板、自查清单、状态回报格式
- spec-reviewer-prompt.md:强调「不信报告」,逐行对比代码与需求
- code-quality-reviewer-prompt.md:检查代码质量、文件职责划分、测试覆盖
适用场景
✅ 适合使用:
- 有一个明确的实现计划,包含多个相对独立的任务
- 需要在当前会话中完成(不想切换到并行会话)
- 对代码质量有要求,不能接受”差不多就行”
- 任务是可并行化的(不紧密耦合)
❌ 不适合使用:
- 没有实现计划,需要先头脑风暴或手动探索
- 任务之间紧密耦合,无法独立实现
- 需要跨会话并行执行(此时应使用
executing-plans)
与其他同类 Skill 对比
| 维度 | 子智能体驱动开发 | 执行计划(executing-plans) | 手动执行 |
|---|---|---|---|
| 会话模式 | 同一会话 | 并行会话 | 同一会话 |
| 上下文隔离 | ✅ 每个任务全新上下文 | ✅ 并行隔离 | ❌ 共享上下文 |
| 审查机制 | ✅ 两阶段自动审查 | ⚠️ 可选 | ❌ 无 |
| 人工介入 | 仅回答问题 | 任务间需要 | 全程 |
| 迭代速度 | 快 | 中 | 慢 |
| 适用场景 | 独立任务批量执行 | 并行会话 | 简单/探索性任务 |
与其他 superpowers Skill 的配合
这个 Skill 不是孤立使用的,它与其他 Skill 形成了一个完整的工作流:
writing-plans(写计划) ↓subagent-driven-development(执行) ├── 使用 test-driven-development(TDD) ├── 使用 using-git-worktrees(隔离工作区) └── 使用 requesting-code-review(代码审查) ↓finishing-a-development-branch(合并完成)个人评价
推荐指数:⭐⭐⭐⭐⭐(5/5)
这是我搬运过的最实用的 Skill 之一。它解决的不是「能不能做」的问题,而是「怎么做更好」的问题——这正是很多 AI 编码用户从「玩具阶段」走向「生产阶段」必须跨越的鸿沟。
亮点:
- 方法论成熟,不是简单的”让 AI 帮你写代码”
- 状态机设计优雅,处理异常情况清晰
- 两阶段审查 + 「不信报告」原则,质量把控严格
- 模型选择策略务实,兼顾质量和成本
不足:
- 学习曲线略陡,需要理解整个流程
- 依赖 superpowers 框架的其他 Skill
- 对于简单任务来说可能”杀鸡用牛刀”
总结: 如果你正在认真使用 AI 编码工具做实际项目,这个 Skill 值得你花时间学习和集成。它提供的不是一套快捷键,而是一套工程化思维。
参考链接
文章分享
如果这篇文章对你有帮助,欢迎分享给更多人!