Claude Code三件套：OpenSpec与Superpowers的分工、安装与选型

摘要：Claude Code负责写代码，OpenSpec负责在写之前把需求和方案定下来，Superpowers负责让写代码的过程守工程纪律。三者分别对应三个问题：需求跑偏、跳过测试、决策没有归档。工具并非越多越好，30分钟的小脚本套全套就是过度工程。本文说明三者各自解决什么、如何安装并跑通一条完整流水线，以及按任务工时该用几件，既避免毫无约束地开发，也避免过度流程化。

用Claude Code写代码效率很高，但长期使用后，三类问题会反复出现：你想要的功能和它交付的不一致；它为了快直接写实现，跳过了测试；最隐蔽的一类是，本次会话里讨论出的技术决策，关掉窗口就丢失了，下次会话读不到，同样的弯路又走一遍。

OpenSpec和Superpowers这两个开源框架针对的正是这三个问题。加上Claude Code，业内有人把这套组合称为“三件套”。带客户做独立站后端时实测下来，结论很明确：它确实能明显提升AI编程的稳定性，但不适合无差别全上。场景用错时，三件套带来的流程开销比它节省的还多。先把每件工具的职责讲透，再谈什么时候该上。

Claude Code三件套分别解决AI编程的哪类问题？

三个工具对应三个具体问题，逐一对照如下：

• 问题一：AI交付的不是你要的。根源是需求理解有偏差，你一句话带过的地方，它会自行补全假设。OpenSpec用一层规格文档先把需求对齐，解决的是这个问题。
• 问题二：跳过测试直接写代码。根源是缺少工程纪律，赶进度时测试最先被砍掉。Superpowers通过强制的TDD和代码审查纪律解决这个问题。
• 问题三：决策依据随聊天窗口关闭而丢失。根源是没有版本化归档：这次为什么这样设计、否决了哪些方案，下次无处可查。OpenSpec的归档机制解决这个问题。

这三个问题在真实项目里都会反复出现。问题一最常见的形态是：你说“做个登录”，它交付的登录只有用户名和密码，没有任何限流和锁定，因为你没提，它也没问。问题二的形态是：功能跑通后你问“测试呢”，它才回头补几个走过场的断言。问题三最麻烦：上周刚讨论清楚“为什么不用第三方登录”，这周它又自行接入了OAuth，因为那段对话的上下文已经不在了。三个问题单独看都不致命，叠加起来就是AI编程“看起来很快、实际在原地打转”的根本原因。

从分工看，Claude Code是执行者，速度快但没有约束；OpenSpec在它之前加了一层规划，Superpowers在执行过程中加了一层纪律。三层叠加，才形成“先想清楚、再按规矩写、最后把决策存档”的完整流程。这套组合并非单纯堆工具，它把人类团队里“产品对齐需求、架构确定方案、测试把关质量、文档记录决策”的协作分工，搬到了一个人带AI开发的场景里。

OpenSpec与Superpowers的定位和机制是什么？

OpenSpec是Fission AI团队开发的开源框架，核心方法是规格驱动开发（Spec-Driven Development）。它把你的需求转化为几份结构化文档：提案（proposal.md）、规格（specs/）、设计（design.md）和任务清单（tasks.md），让人和AI在动手前就把“做什么、做成什么样”明确写下来。它不绑定Claude，官方宣称支持二十多种编程助手。

Superpowers是Jesse Vincent（隶属Prime Radiant）开发的开源技能框架，2025年10月发布后增长很快。很多教程里写的“14万星”是旧数据，截至2026年中它已超过21万星，是当年最受关注的开源项目之一。它为Claude Code提供一套工程纪律技能，包括测试驱动开发、代码审查、系统化调试、头脑风暴、并行子代理等，采用宽松的MIT许可证，商用没有负担。

OpenSpec四份文档的分工值得单独说明，这套分工是OpenSpec全部价值的地基。proposal.md是提案，说明为什么做、做什么；specs/目录存放行为规格，定义“做成什么样才算对”，写法接近“在什么条件下、发生什么、得到什么结果”，刻意不涉及实现细节；design.md记录技术方案和关键决策，比如为什么选这个库、否决了哪种架构；tasks.md是拆分好、可逐项勾选的任务清单。

四份文档各有分工，把一个模糊的需求逐层落实为可执行、可验收、可追溯的内容。OpenSpec还有意把单份规格控制在两三百行以内，避免内容过长导致AI读到后面丢失上下文。

两者的区别可以这样划分：OpenSpec管规格和归档，是流程的骨架；Superpowers管写代码时的工程规范，是执行的肌肉。两者职能有重叠（都关注质量），但侧重点不同，后文会说明为什么缺一个流程就会断开。另外，这两个工具都不是Anthropic官方出品，而是社区里发展起来的开源框架。Superpowers能在半年里增长到二十多万星，说明“给AI编程加一层工程纪律”是普遍存在的需求，并非少数人的偏好。

从机制上看，Superpowers是一大包经过精细调校的Skill。它没有发明新方法，而是把TDD、代码审查、系统化调试这些工程实践封装成Claude Code原生支持的技能包，按描述自动匹配、按需加载。所以如果你已经熟悉Claude Code的扩展机制，理解它会很快。

如果还分不清Skill、MCP、Hook这几种机制，建议先看MCP、Skills、Hooks的区别，再来看三件套会顺畅很多。你会发现：OpenSpec多半通过MCP接入，Superpowers运行在Skills上，而“强制TDD”这类硬约束最终还要靠Hook兜底。三件套实际上是建立在这三种扩展机制之上的一层应用。

三件套怎么安装才能跑通？

安装本身不复杂，关键是命令不要抄错。分三步进行：

第一步，安装Claude Code（前提是有Claude的付费订阅）：

# macOS / Linux / WSL
curl -fsSL https://claude.ai/install.sh | bash

# Windows PowerShell
irm https://claude.ai/install.ps1 | iex

# 验证
claude --version

第二步，全局安装OpenSpec并在项目中初始化（需要Node.js 20.19或更高版本）：

npm install -g @fission-ai/openspec@latest

cd your-project
openspec init

第三步，在Claude Code中安装Superpowers插件：

claude
> /plugin install superpowers@claude-plugins-official

openspec init会在项目中生成规格目录骨架，并注册一组以/opsx:开头的斜杠命令。常用命令只有几条，对应规格生命周期的四个阶段：/opsx:explore用于调研和发散问题，/opsx:propose把想法生成为那四份规格文档，/opsx:apply按规格逐个任务实施，/opsx:archive把完成的变更合并归档；过程中还可以用/opsx:verify核对完成情况。按“探索、提案、实施、验证、归档”这条主线记忆，整套流程的命令就齐了，其余的continue、bulk-archive等都属于辅助命令。

如果希望Claude直接调用OpenSpec的能力，还可以把OpenSpec作为一个MCP服务器接入，并在权限配置里放行openspec、npm、git相关命令。需要提醒的是：安装完成后，三者如何协同、谁在什么阶段介入，要在CLAUDE.md里写清路由规则，否则职能重叠的部分会互相冲突。CLAUDE.md的作用域和写法，保哥在CLAUDE.md记忆配置指南里讲过，这一步不能省。

一个认证API从需求到归档怎么走完三件套流程？

光看命令没感觉，跑一遍才知道这套流程到底改变了什么。拿最常见的任务“做个用户认证API”走一遍全流程：

第一步，把需求规格化。先不让它写代码，而是先提交提案：

> /opsx:propose 用户认证 API，Express + MongoDB + JWT。
  功能：注册、登录、获取用户信息。
  安全要求：bcrypt 加密，JWT 鉴权。

OpenSpec会据此生成那四份文档。这一步的主要价值是逼出你没想清楚的细节，文档只是载体：令牌过期如何处理？密码强度校验放在哪一层？这些平时写到一半才发现的问题，会被提前摆出来。

第二步，复核计划。打开tasks.md，花五分钟通读任务顺序，检查有无遗漏项、验收标准是否合理。这五分钟通常能省下后面一两个小时的返工，是整套流程里投入产出比最高的一步。

第三步，启动执行。确认计划后开始实施。如果在CLAUDE.md里要求了TDD，此时Superpowers的纪律会接管，进入“红→绿→审查”循环：先写一个会失败的测试（红），再写实现让测试通过（绿），最后做一轮代码审查。有一个细节常让人意外：为了保证真正的测试驱动，Superpowers的TDD技能会删除你在写测试之前抢先写好的实现代码，强制测试先行。刚开始会不习惯，但这样能保证测试反映需求，避免测试沦为给已写好的代码补盖一张橡皮图章。

第四步，验证与归档。运行/opsx:verify检查任务完成情况，确认无误后用/opsx:archive把本次变更的规格合并并版本化存档。这一步针对的是问题三：下次会话中，AI能读到“认证模块当初如何设计、为什么选JWT而非session”，不会推倒重来。

全流程跑下来，时间分配会明显前移：需求对齐和设计规划占两三成，编码反而成了顺势完成的部分。这和“一上来就让AI一次性写完”的体验完全不同：前期慢，后期快，返工大幅减少。

这里有一个反直觉的地方：很多人认为“需求对齐占两三成时间”是浪费，因为这段时间没有产出一行代码。但项目的真实成本主要不在编码环节，而在“方向错了重来”和“上线后救火”这两个环节。

propose把模糊地带提前暴露，apply阶段的TDD把边界提前固定，archive把决策提前存档。这三步都是用前期多花的确定时间，换取后期不确定的大额返工。对一次性脚本，这笔账不划算；对需要维护的系统，基本稳赚。规格驱动开发的核心思路就是把不确定性尽量前移，移到修改成本最低的阶段。

为什么OpenSpec、Superpowers与Claude Code缺一不可？

有人会问：只用其中两个行不行？逐一拆开看，每个工具都占着其他工具替代不了的位置。

只用Claude Code：速度最快，但完全没有约束。同一团队里代码风格各不相同，安全漏洞拖到测试阶段才暴露，需求理解全凭模型当次的发挥。这种方式适合一次性脚本，撑不起正式项目。

OpenSpec + Claude Code，缺Superpowers：有了结构化蓝图，但执行阶段没有监督。规格写得再好，编码时偷工减料、跳过测试，规范和实现照样会偏离。图纸挂在墙上，施工现场却没人检查。

Superpowers + Claude Code，缺OpenSpec：TDD和代码审查保证了质量，也有设计文档（存放在docs目录里）。但它有一个关键短板：没有多轮版本化归档。下次做头脑风暴时，新的设计文档会直接覆盖旧文档，历史决策随之丢失。这正是OpenSpec的Delta / Archive机制独有的能力：每轮变更增量归档，并自动把“唯一可信规格”注入上下文。

因此三者是正交互补的关系：OpenSpec负责规划与归档，Superpowers负责纪律与质量，Claude Code负责执行。去掉任何一个，流程就缺一环。这也解释了为什么它们职能有重叠，却不会自动协调分工：你需要在CLAUDE.md里明确每个工具负责哪一段，否则两个工具同时处理设计文档时就会发生冲突。

三件套实战案例：订阅复购功能的效果如何？

空谈收益说服力有限，拿一个真实项目来看。保哥去年为一个宠物用品独立站开发“订阅复购”功能，这是典型的适合上全套的任务：要对接现有订单系统，要计算复购周期和优惠，还要发送提醒邮件，由多人维护，上线后不能随意改动。以它为样本，可以看出三件套实际改变了什么。

最出乎意料的是propose阶段。还没写一行代码，仅把需求整理成规格文档，就暴露出七八个事先没考虑到的问题：订阅中途更换地址怎么处理？优惠券和订阅价能否叠加？用户取消订阅后历史数据保留多久？在“直接开写”的模式下，这些都是写到一半甚至上线后才会暴露的问题。规格阶段提前把它们列出来，等于把返工成本最高的那批问题，移到修改成本最低的阶段解决。

执行阶段，Superpowers的TDD纪律也切实起到了兜底作用。复购周期计算逻辑有不少边界情况，比如月底下单、闰年、跨时区。按测试先行的方式开发，这些边界在写实现之前就被测试固定下来，没有出现“主流程跑通、边界全是Bug”的常见问题。

这个功能最终的时间分配大致是：需求对齐和设计占三成多，编码占一半出头，验证和修复占一成多。账面上编码的占比下降了，但总耗时和返工反而更少，因为没有出现“做完才发现方向错误、只能推倒重来”的大缺口。上线后的那一版几乎没有回滚，这在过去“一次性写完”的开发节奏下很难做到。

当然，这种回报只出现在适合上全套的任务上。换成“给后台加个导出按钮”这种半小时的小任务，同样的流程只会让人觉得处处受限。所以下一节讨论什么情况下不该用这套流程。

哪些任务不该上三件套全套？

好处讲完，得泼盆冷水：三件套不是默认配置，不加区分地使用就是过度工程。下面按任务体量给出一张决策表：

判断标准只有一条：这项任务是否值得为它写规格、留归档。一个跑完就丢的脚本，套上propose、apply、archive全流程，只会给自己增加负担。反过来，一个多人协作、需要长期维护的功能，如果省掉规格对齐这一步，后期沟通扯皮的成本会成倍增加。工具要服务于目标，不必追求流程的完整度本身。Superpowers里的并行worktree用法值得单独研究，Claude Code worktree并行开发一文专门拆解了如何让多条任务线互不干扰。

规格驱动流程最容易在哪些环节出错？

高频翻车点集中列一下，每一条都有人踩过：

• 把Spec写成伪代码。规格应描述行为（在什么条件下、发生什么、得到什么结果），不应描述实现细节。一开始就写函数如何实现，规格就失去了对齐需求的作用。
• 完成后忘记archive。这是最常见的问题。不归档，下次会话AI读到的仍是旧规格，可能把已经完成的功能重新实现一遍。执行/opsx:archive要形成固定习惯。
• 跳过头脑风暴直接开发。省掉前期对齐，等于把技术决策的时机全部推到事后，修改成本反而更高。
• 不看Plan就执行。通读tasks.md只需五分钟，却能省下一两小时返工，投入产出比很高，不要嫌麻烦。
• 30分钟的任务也跑全套。即前文反复提到的过度工程，工具应服务于目标，不能让目标反过来迁就工具。

这五条中，前两条与归档有关，中间两条与“图快跳步”有关，最后一条是总原则。三件套的价值建立在前期的细致投入上，如果每一步都想走捷径，还不如不用，免得流程开销白白浪费。

新手该按什么顺序用熟三件套？

一次性全部上手，多半会被流程劝退。建议按以下路线逐步推进：

第一周，只用Claude Code。先熟悉在终端里与AI结对编程这件事本身：如何提供上下文、如何纠偏、如何验证结果。基础不扎实，叠加再多框架也难以发挥作用。

第二周，加入Superpowers。这时你大概率已经遇到过一两次“AI跳过测试”的问题，正好能直接体会TDD和代码审查纪律的价值。先从一两个核心技能用起，感受“被强制写测试”从别扭到认可的转变。

第三周以后，按需加入OpenSpec。当你开始开发需要决策追溯或多人协作的功能时，再引入规格和归档。带着“需要把决策存下来”的实际需求去用，比一开始就背着全套流程运行要顺畅得多。

这个顺序遵循“先熟悉工具、再加纪律、最后上规格”。它与把三件套当成安装清单一次性装完的做法正好相反：工具的价值只有在你遇到对应问题时才会体现，没有需求硬上，只会觉得处处受限。想系统了解Claude Code本身如何用得更顺，可以先读保哥的Claude Code最佳实践打基础，再引入这套流程框架。

三件套属于“刚需”还是“过度工程”，没有统一答案，取决于手上的任务是否值得认真对待。一次性脚本上全套是过度工程，多人维护的核心系统不加任何约束则会埋下隐患。可以把这套工具看作一个档位可调的流程：小任务放松，大任务收紧，按任务体量自由组合，不必在全上和全不上之间二选一。合理的做法是每次把档位调到刚好够用，流程跑得最全并不是目标。

常见问题解答

OpenSpec和Superpowers能单独用吗，必须一起上？

能单独用，但各有短板。只上OpenSpec缺执行纪律，规格和实现易偏离；只上Superpowers缺多轮版本化归档，新设计会覆盖旧决策。两者互补，正经项目建议一起，小活按体量取舍即可。

Superpowers真的会删掉我写的实现代码吗？

它的TDD技能确实会在“测试先行”时，把你抢在测试之前写的实现删掉，逼你真正测试驱动。目的是让测试反映需求而非给已有代码补章。觉得太激进，可以在CLAUDE.md里调整对该技能的触发要求。

OpenSpec只能配Claude Code用吗？

不是。OpenSpec不绑定具体助手，官方称支持二十多种编程助手。它本质是一层独立的规格文档框架，Claude Code只是其中配合得最顺的执行端之一，你换别的AI助手也能用。

装了三件套，开发会不会变慢？

前期会慢——需求对齐和设计规划要占两三成时间。但写代码和返工的时间大幅下降，整体往往更快、更稳。它牺牲的是“立刻开写”的爽感，换来的是少踩坑、少推倒重来，适合要维护的正经项目。

怎么避免OpenSpec和Superpowers职能打架？

关键在CLAUDE.md里写清路由规则：谁负责设计文档、谁负责测试纪律、归档归谁管。两者都关心质量、职能有重叠，但不会自动互让，必须由你显式划清边界，否则容易在设计文档归属上冲突。

什么任务根本不值得上这套流程？

两小时内的原型和一次性脚本。它们没有长期维护和决策追溯的需求，写规格、走归档纯属增加开销。这类活直接用Claude Code一把梭最划算，把三件套留给要协作、要维护的功能。

权威参考资料