Superpowers × OpenSpec：给 AI 编程同时配上"图纸"和"手艺"

上周有个朋友跟我吐槽："我用 Claude Code 写了三天功能，最后发现它做的根本不是我要的东西。"

我问他："那你一开始跟它说清楚要做什么了吗？"

他愣了两秒："我就在聊天框里说了句'帮我加个用户积分系统'，然后它就开干了。"

我又问："那它写的代码有测试吗？逻辑你审过吗？"

他更心虚了："没有……它说写完了我就 merge 了，结果上线第二天积分算错了，回滚到现在。"

这两个问题，其实是 AI 编程的两种典型死法。一种是做错了东西——它压根没搞懂你要什么；另一种是东西做烂了——它搞懂了，但写得稀烂，没测试、瞎改、留一堆坑。

有意思的是，社区里恰好有两个最近很火的开源工具，一个专治第一种病，一个专治第二种病。前者叫 OpenSpec，后者叫 Superpowers。今天就来聊聊，把这俩组合起来用，是一种什么样的体验。

AI 编程的两种死法

先别急着装工具。你得先想明白一件事：为什么 AI 写代码这么容易翻车？

因为它太"听话"了。

你给它一句模糊的指令，它不会停下来问"你确定吗"，而是立刻脑补一个版本，吭哧吭哧写出来。它的脑补水平很高，但脑补终究是脑补——你想要的是按订单金额给积分，它给你按登录次数算，逻辑自洽，方向全错。

这是第一种死法：需求活在聊天记录里。聊天记录是会蒸发的。今天聊的需求，明天换个会话窗口，AI 就失忆了；你自己过一周也忘了当初到底是怎么定的。需求没有一个"权威版本"沉淀下来，每次都是重新脑补。

第二种死法更隐蔽：它写得太快，快到没人来得及把关。AI 是个手速惊人的实习生，你说一句它写一百行。没有测试,没有红绿重构,遇到 bug 就东改一下西补一下,改完一个冒出三个。你看着进度条飞涨,心里却越来越没底。

你看,这俩问题根本不在一个层面上。一个是"做什么"出了问题——方向错了;一个是"怎么做"出了问题——手艺糙了。

AI 编程的两种死法：一种是方向错，一种是手艺糙

想治病，得对症下药。治"做什么"的药,是把需求从聊天框里捞出来,变成仓库里一份白纸黑字、人人能审的文档——这是 OpenSpec 干的事。治"怎么做"的药,是给 AI 套上一套工程师的纪律,逼它先想后写、写完必测——这是 Superpowers 干的事。

一句话:方向和手艺,是两件完全不同的事,得用两味不同的药。

OpenSpec：把"做什么"钉进仓库

OpenSpec 是 Fission-AI 团队做的一个开源框架,定位特别清晰:在写任何一行代码之前,先让人和 AI 就"要做什么"达成白纸黑字的一致。

它的核心动作就三个,官方叫 Propose-Apply-Archive(提案-实施-归档):

Propose(提案):你说一句"我想加个用户积分系统",它不直接写代码,而是先生成四份文档——proposal.md(为什么做、范围多大)、specs/(需求和验收场景)、design.md(技术方案)、tasks.md(任务清单)。
Apply(实施):照着 tasks.md 这份清单,一项一项打勾实现。
Archive(归档):做完了,把这次变更归档,同时更新仓库里那份"主规格",作为下一次迭代的基准。

装起来也简单,一行命令:

# 全局安装 OpenSpec（需要 Node.js 20.19+）
npm install -g @fission-ai/openspec@latest

# 在你现有的项目里初始化（不会重写你的代码）
cd your-project
openspec init

关键在最后一句注释:不会重写你的代码。这正是 OpenSpec 跟很多"规格驱动"工具最大的区别——它是给老项目用的。

关键区别

市面上的规格驱动工具,很多是给"从零开始的新项目"准备的。OpenSpec 反着来:它专门解决老项目的增量迭代。它用 ADDED / MODIFIED / REMOVED 这样的"增量标记",清清楚楚标出这次改动相对于现有功能加了什么、改了什么、删了什么。你不用为了用它就把祖传代码推倒重来。

那它到底解决了什么?还记得第一种死法吗——需求活在聊天记录里。OpenSpec 干的事,本质上就是把那段会蒸发的对话,固化成仓库里一份能 git diff、能 code review、能传给下一个会话的文档。

打个比方。没有 OpenSpec 的时候,你跟 AI 的协作像是口头点菜:"来份宫保鸡丁,不要太辣。"厨师(AI)凭印象做,做出来咸了你也只能认。有了 OpenSpec,变成了先写一张订单小票:菜名、辣度、忌口,白纸黑字。厨师照单做,做错了对照小票一目了然,而且这张小票永远在那儿,换个厨师也能接着做。

更妙的是它的"规格增量审查"(spec delta review):你 review 的时候,不用一行行啃几百行代码 diff,只看这份规格变更——加了哪条需求、改了哪个场景——就能在高层面上判断这次改动对不对。从审代码,变成审意图。

所以 OpenSpec 给 AI 编程补上的,是那块最容易丢的拼图:一个不会蒸发、能被审阅的"做什么"。

Superpowers：把"怎么做"变成肌肉记忆

如果说 OpenSpec 管的是"做什么",那 Superpowers 管的就是"怎么做才不丢人"。

Superpowers 是 Jesse Vincent(GitHub 上叫 obra)做的。这人来头不小:90 年代写了 Request Tracker,管过 Perl 6,做过 K-9 Mail(后来被 Mozilla 收了变成安卓版 Thunderbird)。一个干了三十年工程的老兵,把自己脑子里那套工程纪律,打包成了一堆 Markdown 文件,塞给 AI。

对,你没看错,Superpowers 的本质就是一堆 Markdown。它不是什么黑科技,而是一套"行为规范",告诉 AI:别一上来就写代码,给我按规矩来。它现在是 Claude Code 生态里最火的插件之一,GitHub 上九万多颗星。

它最核心的几个"技能"(skill),你一看就懂为什么有用:

技能	它逼 AI 做什么	治的是哪种糙
brainstorming(头脑风暴)	写代码前必须先问清楚、提设计方案,问明白之前不准动手	上来就瞎写
writing-plans(写计划)	把功能拆成 2-5 分钟一个的小任务,带明确文件路径和验证步骤	大干快上、无章法
test-driven-development(TDD)	严格红→绿→重构:先写失败的测试,再写最少的代码让它通过	没测试就 merge
systematic-debugging(系统化调试)	四阶段流程,没搞懂根因之前禁止动手改	东改西补、越改越乱

你品品这几条。每一条,都精准打在第二种死法的痛点上。

我最喜欢的是 brainstorming 那条规矩:问明白之前,不准写代码。这一条就把"AI 太听话所以瞎脑补"的毛病按住了。它会反过来问你:积分按金额还是按次数?有没有上限?过期吗?——这些问题,本来就该在写代码前问清楚。

insider 视角

Simon Willison 专门写文章夸过 Jesse 是"最有创造力的 coding agent 用户之一"。一个反直觉的细节:这套插件极其省 token——核心文档加载进来不到 2k token,需要更细的流程时才用 shell 脚本临时拉取。重活脏活全都甩给子 agent(subagent)去干,主对话窗口始终保持清爽。换句话说,纪律没有以"撑爆上下文"为代价。

还有个有意思的花絮:Jesse 甚至给 Claude 设计了一本"情绪日记",让它记录自己干活时的投入程度;还试过用 Graphviz 的 DOT 图当工作流指令,发现 Claude 居然能看懂流程图照着执行。这人是真把 AI 当一个需要培养的工程师在带,而不是当个搜索框在用。

所以 Superpowers 给 AI 补的,是另一块拼图:一套不会偷懒、写完必测、改前先懂的"怎么做"。它不让 AI 变得更聪明,而是让 AI 变得更靠谱。这是两件完全不同的事。

组合实战:图纸 + 手艺,一条龙跑通

现在,把这两味药合在一起吃,会发生什么?

先说结论:它俩不打架,反而严丝合缝。因为它们管的根本是两个不同的层面——OpenSpec 管"图纸",Superpowers 管"手艺"。一个建筑工地,既要有人人认可的设计蓝图,也要有遵守规范的施工队,缺一个都出事。

它们的接口在哪?就在 OpenSpec 生成的那份 tasks.md。这份任务清单,正好是 Superpowers 那套执行纪律的输入。OpenSpec 负责把"做什么"拆成一条条任务,Superpower 负责用 TDD、调试纪律,一条条把它们高质量地实现掉。

组合工作流:OpenSpec 定方向 → tasks.md 交棒 → Superpowers 高质量落地 → 归档回写规格

一个完整的回合,大概长这样:

OpenSpec 起头:你跑 /opsx:propose "用户积分系统",它跟你来回确认需求,生成 spec、design、tasks。你在这一步审"意图",方向定死。
Superpowers 接棒:进入实现阶段,Superpowers 的 brainstorming 会对着 spec 再抠一遍设计细节,然后用 TDD 一个任务一个任务地写——每个任务先写一个失败的测试,再写代码让它变绿。
遇到 bug,systematic-debugging 接管:先定位根因,再动手,绝不瞎补。
实现脏活甩给子 agent,主窗口保持清醒,随时能看到整体进度。
全部绿灯,跑 /opsx:archive 归档,把这次变更回写进主规格。下次迭代,这份规格就是新的起点。

你发现没有?这套组合最妙的地方,是形成了一个闭环:意图被固化成规格(OpenSpec)→ 规格被高质量实现(Superpowers)→ 实现回写进规格(OpenSpec)。每转一圈,你的仓库里就多沉淀一份"既是文档、又是事实"的资产。

这就是为什么 1+1 在这里能大于 2:OpenSpec 让 AI 做对的事,Superpowers 让 AI 把事做对。前者管方向不跑偏,后者管手艺不缩水。

踩坑记录:1+1 不会自动等于 2

但我得泼盆冷水。装上这俩工具,不等于第二天你就能躺着收高质量代码。我自己踩过几个坑,说给你听。

第一个坑:职责重叠,谁说了算。OpenSpec 有自己的提案流程,Superpowers 也有 brainstorming 和 writing-plans。两个都想在"动手前规划"这件事上插一脚。如果你不理清楚,会出现 AI 在 OpenSpec 里规划一遍,进了 Superpowers 又规划一遍的尴尬。

踩坑记录

我的解法是给它俩划清地界:OpenSpec 负责"是什么"层面的规划(需求、验收标准、技术方案),产出仓库里的持久化文档;Superpowers 负责"怎么实现"层面的规划(任务怎么拆、测试怎么写、子 agent 怎么派)。一个对外定契约,一个对内排施工。别让它俩抢同一块活,否则你会看到两份打架的计划。

第二个坑:规格也会过期。OpenSpec 最大的卖点是"规格即事实",但前提是你真的去归档。我见过有人 propose 完爽快,实现完就跑了,从来不 archive。结果仓库里躺着一堆"提案中"的变更,主规格还停在三个月前。这时候规格不但没用,反而误导——它说的是过去,代码跑的是现在。

第三个坑:纪律是有成本的。Superpowers 那套红绿重构、问清再写,确实让代码更靠谱,但也确实更慢。改个文案、调个样式这种五分钟的小活,你非要走一遍 propose-spec-TDD 全流程,纯属自我折磨。工具是给硬骨头准备的,不是给软柿子准备的。

所以我的判断很明确:这套组合,是给那些"做错了代价很高、做烂了很难收场"的功能准备的——支付、权限、核心业务逻辑这类。小修小补,直接聊天框搞定,别上重型武器。

记住一句话:方法论是放大器,放大对的东西,也放大错的折腾。用在刀刃上,它是神器;用在牙签上,它是负担。

写在最后:你今晚就能试的一件事

聊了这么多,把核心几点拎出来,方便你截图收藏:

两种死法,两味药:AI 编程要么做错东西(方向),要么做烂东西(手艺)。OpenSpec 治方向,Superpowers 治手艺。
OpenSpec 管"做什么":把需求从会蒸发的聊天框,固化成仓库里能 diff、能 review 的规格文档,专为老项目增量迭代设计。
Superpowers 管"怎么做":一套打包成 Markdown 的工程纪律——问清再写、先测后码、懂了再改,让 AI 从手快变靠谱。
组合是个闭环:意图→规格→高质量实现→回写规格,接口就在那份 tasks.md。
别滥用:重型方法论留给硬骨头,小修小补走聊天框。

说到底,这两个工具背后是同一个朴素的道理:AI 不是越自由越好,而是越有章法越好。真正释放 AI 生产力的,从来不是更花哨的 prompt,而是给它一个"先想清楚做什么、再认真做对"的框架。

所以,今晚回去试一件事——

挑一个你之前用 AI 写崩过、或者改到一半放弃的功能。先用 OpenSpec 给它写一份 proposal,逼自己(和 AI)把"到底要做什么"说清楚;再用 Superpowers 的 TDD 模式,让它先写一个失败的测试,再写代码。

就跑通这一个最小回合。然后对比一下:这次的代码,你敢不敢直接 merge?

如果答案从"不敢"变成了"敢"——恭喜你,你已经摸到了 AI 编程下一个阶段的门槛:不是让 AI 写更多代码,而是让 AI 写你敢负责的代码。