一、Superpowers 是什么Superpowers 是 obraJesse Vincent开源的一套「软件开发方法论 可组合技能库」专为编码 agent 设计。它的核心机制不是让你手动敲/命令而是会话一开始就生效靠技能自身的 description 元数据自动匹配触发。agent 一察觉你在「构建 / 改 bug / 评审」对应的技能就自己加载把流程强制走一遍而不是给出建议。一句话概括它的定位不是固定阶段而是一组会话开始即生效、自动触发的技能是强制性工作流而非建议。1.1 三条哲学哲学含义TDD先写失败测试再写代码真·红绿重构YAGNI、DRYProcess over ad-hoc用强制流程而非临时发挥Evidence over claims拿证据证明做完了而不是口头声称「应该能跑了」1.2 自动触发是怎么做到的引导注入using-superpowers会话启动时以及上下文被压缩 compaction 之后自动注入「如何使用 Superpowers」的说明教会 agent 在动手前先查「有没有技能适合当前任务」。描述匹配每个技能自带触发描述descriptionharness 根据对话内容自动匹配并加载对应技能。结果你不需要做任何特殊操作agent 就「自带 Superpowers」。官方验证方式新会话里发一句Lets make a react todo list安装正确的话brainstorming会在写任何代码前自动触发。二、主工作流Happy Path从「你开始构建」到「分支收尾」的主链路如下每一步都自动衔接最彻底更省钱brainstorming问清真实意图 → 设计文档using-git-worktrees新分支隔离 绿基线writing-plans拆成 2-5 分钟小任务执行模式subagent-driven-development每任务一个全新子代理 评审executing-plans会话内联执行 整枝评审test-driven-development红-绿-重构贯穿实现verification-before-completion拿证据验收finishing-a-development-branch合并 / 清理 / 收尾另有若干按需 / 元技能不在主链路上而是满足条件时才触发见下文第 ⑦⑧⑩ 组。三、15 个技能逐个详解每个技能按功能作用 / 触发场景 / 解决的问题三维度讲解。① 元·引导层using-superpowers元技能 / 引导功能作用整套框架的入口。会话启动时以及上下文被压缩 compaction 之后自动注入「如何使用 Superpowers」的引导说明教会 agent 在动手前先查「有没有技能适合当前任务」。触发场景每个会话开始自动注入压缩后再次注入。无需手动触发。解决的问题技能只是躺在目录里的文件没有引导 agent 根本不知道要去读。它解决「技能为什么没触发」和「长会话压缩后忘了用」的问题保证整套技能始终在线。这就是「会话开始即生效」的真正来源。② 发现层brainstorming需求挖掘功能作用在写任何代码之前激活。agent 不直接开建而是先反问「你到底想做什么」探索多种方案把设计分节给你确认最后落盘成一份设计文档。触发场景agent 一察觉你「要构建某样东西」就自动触发——这正是「一看到你开始构建就先追问你真正想做什么」。解决的问题模糊想法被直接开写 → 做错了方向、白干返工。强制「先对齐意图与设计再动手」从源头砍掉无效工作。③ 规划层writing-plans写实现计划功能作用设计获批后把工作拆成2–5 分钟一个的小任务每个任务都写清精确文件路径、完整代码、验证步骤——精细到「一个热情但没判断力、没项目上下文、不爱写测试的初级工程师」都能照着做。触发场景设计文档被批准后自动激活。解决的问题计划太粗、被 agent 自由发挥 → 执行跑偏、偷工减料。强制「计划可执行 信息完整」这是它能自主连续跑几小时不跑偏的前提。④ 隔离层using-git-worktreesGit 工作树隔离功能作用设计批准后在新分支上建一个独立工作区跑项目初始化并确认测试基线是绿的动手前基线必须干净。触发场景设计批准之后、正式执行之前自动激活。解决的问题直接在主分支上改 → 污染基线、难回滚、难验证对错。强制「独立分支 先确认绿基线」让工作可回滚、改动可对照。⑤ 执行层subagent-driven-development子代理驱动开发 · 最彻底功能作用对每个工程任务派一个全新子代理去实现做完后评审其产出通过再进入下一个。每个任务都用干净上下文不累积污染。触发场景计划完成后自动激活是默认的推荐执行模式。解决的问题单个 agent 长时间连做 → 上下文污染、判断退化、错误滚雪球。「一任务一新代理 独立评审」让长自主运行保持高质量agent 常常能自主连续工作数小时而不偏离计划。executing-plans执行计划 · 省钱版功能作用轻量执行模式——不在每个任务开子代理而是在当前会话内联逐任务实现最后对整个分支做一次全新评审。触发场景当任务较小、风险较低、你想要更快更省时地执行时自动激活与上一个二选一。解决的问题子代理模式成本高一任务一代理。提供一个「够用、更省」的替代按任务规模 / 风险匹配执行力度。dispatching-parallel-agents并行派发代理功能作用把多个相互独立的任务同时派给多个子代理并行处理。触发场景出现一批可并行、互不冲突的工作时触发。解决的问题串行执行太慢。用并行压缩墙钟时间。关键前提任务必须真正独立否则会互相冲突。⑥ 纪律层哲学的落地test-driven-developmentTDD功能作用强制红-绿-重构先写一个会失败的测试→ 看它失败 → 写最小代码 → 看它通过 → 提交。强调真·红绿、YAGNI、DRY甚至会删掉「没先写测试就写的代码」。触发场景实现阶段自动激活。解决的问题agent「先写码、后补测试」→ 测试沦为摆设、覆盖率虚高。强制「测试先行」让每行代码都有对应测试正确性和重构信心都有保障。verification-before-completion完成前验证功能作用在宣称「做完了」之前先收集证据证明它确实可用——跑测试、跑程序、检查真实输出而不是凭感觉。触发场景任何「完成 / 成功」的声明之前自动触发。解决的问题agent 说「应该能跑了」但没验证 → 带着 bug 报喜。落地「evidence over claims」——证据不摆出来就不算完成。⑦ 调试层systematic-debugging系统化调试功能作用四阶段根因分析复现问题 → 收集数据 → 分析原因 → 验证修复。核心是「先找根因再动手修」绝不靠猜、不靠打补丁。触发场景一旦出现 bug、报错或你问「为什么 X 失败了」就自动触发。解决的问题agent 盲目试错打补丁 → 治标不治本还引入新 bug。强制「先定位根因」让修复一次到位。⑧ 评审层requesting-code-review发起代码评审功能作用代码完成后主动发起评审把改动、上下文、关注点整理好交给评审方。触发场景实现完成、进入评审阶段时触发。解决的问题代码写完就默认 OK、从没人看 → 质量 / 安全问题漏网。把「主动求评审」变成制度性动作。receiving-code-review接收代码评审功能作用一套应对评审反馈的纪律先READ完整读完、不急着反驳→UNDERSTAND用自己的话复述需求有疑问就问→ 然后再行动。触发场景收到评审意见 / 反馈时触发。解决的问题agent 面对反馈要么防御性反驳、要么盲从全收→ 真问题被忽略或好心办坏事。强制「先理解、再回应」。⑨ 收尾层finishing-a-development-branch收尾开发分支功能作用开发完成后做收尾合并分支、清理工作树、按规范处理PR / squash 等。触发场景分支上所有任务完成并通过验证后触发。解决的问题做完了但没清理 → 分支 / 工作树堆积、主分支迟迟不合并。把「收尾」闭环不留烂尾。⑩ 元·扩展层writing-skills写技能功能作用指导创作新技能标准文件组织SKILL.md 参考文件 脚本、如何写触发描述、怎么让技能既会被触发又可复用。触发场景你想往 Superpowers 里新增一个技能时触发。解决的问题技能写得不规范 → 不被触发、没法复用。提供一套「可复用技能」的写作方法论Superpowers 自己也是用这套方法写出来的。diagnosing-superpowers诊断框架本身功能作用元诊断技能。当 Superpowers自身表现异常——技能该触发没触发、会话启动钩子没生效、行为不符合预期时帮你定位问题在哪一层。触发场景你发现「技能没起来」「行为不对」时触发。解决的问题框架自己出问题却没人知道为什么。提供一条自我诊断路径让这套强制流程本身也能被排查。四、它们如何咬合成一条流水线这套东西的价值不在单个技能多聪明而在于它们互相咬合成一条强制流水线——任何一步想「跳过」都会被下一个技能拦住。这正是「强制性工作流而非建议」的工程纪律所在。被锁住可并行加速扩展 / 自检using-superpowers让系统在线brainstorming问清意图writing-plans写死计划using-git-worktrees隔离战场执行subagent / 内联test-driven-development verificationsystematic-debugging出问题走这里code-review请求 / 接收finishing-a-development-branch收尾dispatching-parallel-agentswriting-skills / diagnosing-superpowers层技能一句话元·引导using-superpowers让整套技能始终在线发现brainstorming写码前问清「你真正想做什么」规划writing-plans拆成 2–5 分钟、信息完整的小任务隔离using-git-worktrees新分支 绿基线可回滚执行subagent-driven-development / executing-plans一任务一新代理彻底或内联省钱执行dispatching-parallel-agents独立任务并行加速纪律test-driven-development红-绿-重构测试先行纪律verification-before-completion拿证据验收不口头声称调试systematic-debugging先复现、找根因再修评审requesting / receiving-code-review主动求评审先理解再回应收尾finishing-a-development-branch合并、清理、闭环元·扩展writing-skills / diagnosing-superpowers造新技能 / 自检框架五、Superpowers × OpenSpec互补搭配Superpowers 解决了「怎么写」但它回答不了「写什么」。这正是OpenSpec补上的那一半一个管规格what / why一个管纪律how两者天然互补。5.1 OpenSpec 一句话定位OpenSpecFission-AI是面向 AI 编码助手的Spec-Driven DevelopmentSDD工具核心是写代码之前先写一份可验证的规格说明。四个规划工件构成完整规划链proposal提案为什么/做什么→specs规格行为如何变化→design设计技术决策→tasks任务拆解实现清单。目录结构openspec/specs/主规格 系统当前「事实来源」openspec/changes/变更名/每个变更一个独立文件夹装四件套changes/archive/已完成的变更。六个命令/openspec-propose生成四件套·/openspec-explore思考伙伴、只读澄清需求、绝不写码·/openspec-apply逐任务实现·/openspec-update修订已有规划工件·/openspec-sync把 delta spec 合并进主规格·/openspec-archive归档变更。关键特性规格**「活在代码里」**spec-anchored不是一次性对话产物Delta Spec既人类可读又机器可解析无刚性阶段门禁——任何工件随时可改流程流动。5.2 分工各自侧重解决什么问题维度OpenSpecSuperpowers核心问题写什么、为什么写what / why怎么写how性质规格 / 工件驱动流程 / 技能驱动产出物持久化文件specs / changes过程实时执行中的强制面向谁供人审阅需求与变更供agent严谨执行主要解决需求漂移、范围蔓延、无规格、规格腐烂、难评审agent 跑偏、无测试代码、虚假完成、盲目调试时间维度长期活的规格、可追溯记录实时构建过程中的强制比喻火车头制定路线图/ 猛虎铁轨保证列车按规范行驶/ 双翼一句话OpenSpec 是「脑」决定并记录要造什么Superpowers 是「肌肉」带纪律地执行。5.3 搭配的关键补上「规划—执行断层」把两个插件一起装上并不等于它们会自动配合——两者之间缺一个衔接层。最常见的坑是代码写完了规划文档还躺在仓库里吃灰。你在规划阶段花了 30% 的精力但这些产出物对后续 70% 的执行阶段毫无约束力——执行阶段的 AI 不知道那些约束存在知道也不会主动去读。所以搭配的关键是在「规划」和「执行」之间建一座桥把规划压缩成一份执行阶段真正可强制的执行契约。一份设计良好的桥契约通常包含意图锁Intent Lock用一句话锁定本次变更的核心意图。执行阶段任何决策都必须对齐这个意图对不上就拒绝执行。它是给范围蔓延上的紧箍咒——拦住那种「顺手重构一下」最后引爆 7 个文件回归的冲动。约束清单Constraint Checklist从四个规划文档里抽出所有硬约束性能指标、兼容性要求、安全规范变成可验证的检查项执行时逐条守住。验收标准Acceptance Criteria每个 task 的完成标准 「代码写完 且 通过这些验证」而不是「代码写完了」。进阶内容级校验签约时对规划文档记一份哈希如 SHA256执行前重算比对——防止「规划文档在签约后被悄悄改过」一旦不一致契约即作废、需重新签。需要说明上面三要素是**「好的桥应当长成的样子」设计原则并不是某个工具一条命令就能吐出文件的东西。在原生 OpenSpec Superpowers** 里这三要素本就分散在四件套中——意图锁 ≈design.md的 Goals / Non-Goals约束清单 ≈specs/的 SHALL / MUST 需求验收标准 ≈tasks.md里每个任务自带的验证步骤官方要求每个 task 必须写明如何验证完成并没有一份单独的「执行契约」文件也没有哈希校验。只有走整合框架方式 C才有专门的contract-builder命令把它们压缩成一份execution-contract.md见 5.4、5.5。此外工作流会在若干关键节点设决策点DP需求确认 / 提案确认 / 规格确认 / 设计确认 / 任务确认 / 契约确认 / 批次确认 / 收尾确认强制 AI 停下来征求人确认。设计哲学是把人的判断力用在刀刃上而不是让 AI 在无关紧要处反复问「要不要继续」。5.4 一个完整的搭配工作流[OpenSpec 主导] [桥接层] [Superpowers 主导] /openspec-explore 澄清需求 /openspec-propose → proposal specs design tasks ↓ 原生方式 A无专门命令三要素本就分散在四件套 意图 design.md 的 Goals/Non-Goals · 约束 specs 的 SHALL/MUST 验收 tasks.md 逐任务验证步骤writing-plans 可再拆细粒度计划 整合框架方式 Ccontract-builder → execution-contract.md 意图锁 约束清单 验收标准 SHA256 ↓ using-git-worktrees 新分支 绿基线 /openspec-apply 逐任务实现 ← Superpowers 纪律全程在场 TDD 红-绿-重构 subagent-driven-development / executing-plans verification-before-completion拿证据验收 遇到 bug → systematic-debugging ↓ requesting / receiving-code-review 评审 ↓ /openspec-sync delta spec 合并进主规格 /openspec-archive 归档变更 finishing-a-development-branch 合并 / 清理阶段级映射阶段OpenSpecwhatSuperpowershow需求澄清/openspec-explore思考伙伴只读brainstorming 纪律问清真实意图产出规划/openspec-propose四件套writing-plans拆成 2–5 分钟可执行子任务隔离—using-git-worktrees新分支 绿基线建契约桥三要素本就分散在四件套design Goals/Non-Goals · specs SHALL/MUST · tasks 逐任务验证原生无专门命令writing-plans 再拆细粒度整合框架contract-builder → execution-contract.md执行/openspec-apply逐任务、勾选TDD subagent-driven-development / executing-plans verification-before-completion调试—systematic-debugging评审—requesting / receiving-code-review收尾/openspec-sync/openspec-archivefinishing-a-development-branch搭配的精髓OpenSpec 告诉你「做哪些任务」Superpowers 告诉你「每个任务怎么严谨地做」。OpenSpec 的tasks.md就是 Superpowers 的计划输入OpenSpec 的apply就是 Superpowers 的纪律化执行OpenSpec 的archive就是 Superpowers 的分支收尾。5.5 社区的三种落地方式方式做法优点缺点A. 双插件 手动桥接两个插件都装规划产物由你手动搬运进执行零额外依赖、最灵活你成了「翻译官」状态不对齐时易掉链子B. 外部编排用 YAML 状态机如 Comet编排对两个工具的外部调用配置灵活、平台覆盖广两个工具互不知晓对方内部状态只能做「表面」状态检查C. 源码级融合框架把两者引擎吸收进一套自洽的 skill / 状态机如 spec-superflow紧致自洽、内容级状态检测、无需手动桥接要学一套全新概念9 skill / 8 状态 / 8 DP说明B、C 是社区的具体项目示例仅作路线对照用哪种不关键。无论走哪条路本质都一样在「规划」和「执行」之间建立一份契约让执行阶段的约束真正来自规划阶段的产出而不是靠人临场记性。5.6 小结OpenSpec回答「写什么、为什么写、怎么记录下来」what / why 持久规格解决需求漂移、范围蔓延、规格腐烂。Superpowers回答「怎么写得稳」how 执行纪律解决 agent 跑偏、无测试、虚假完成、盲目调试。两者之间的桥是「执行契约」意图锁 约束清单 验收标准把规划压缩成执行阶段可强制的形式「规划—执行断层」被补上从需求澄清到变更归档形成自洽闭环。六、小结定位给编码 agent 的完整软件开发方法论靠自动触发把最佳实践变成强制流程。核心TDD · Process over ad-hoc · Evidence over claims 三条哲学由 15 个技能落地。精髓单技能不稀奇互相咬合、谁也跳不过才是工程纪律的来源——agent 能长时间自主运行而不跑偏靠的就是这条流水线。搭配与 OpenSpec规格管「写什么」配合Superpowers纪律管「怎么写」——用「执行契约」补上规划与执行的断层从需求到归档形成自洽闭环详见第五章。参考资料obra/superpowersGitHubskills 目录15 个技能Fission-AI/OpenSpecGitHub · openspec.devAI 编程工作流选型Spec-Kit、OpenSpec、Superpowers 深度对比腾讯云
