1. 先别急着写代码：为什么 AI 编程越写越乱
如果你最近用过 Claude Code、OpenCode 这类 AI 编程工具，大概率经历过这种场景：第一个需求丢进去，AI 三下五除二把骨架搭出来了，看起来很惊艳；第二个需求加进去，它在前一个文件里东改西改，还能勉强跑通；第三个需求再叠加，它开始自作聪明地猜你的意图，甚至把之前已经验证过的逻辑悄悄改坏。等到第四次、第五次迭代，你发现自己已经不敢轻易让它改代码了，因为改动哪里、为什么改、改完会不会影响别的地方，完全不可控。
我之前的做法是不断在对话里补充提示词，比如“记住不要动 XXX 模块”“上次已经确认过这个逻辑”，但效果并不好。模型虽然有很长的上下文窗口，但对话一长，早期约定的规则很容易被稀释。真正的问题不是模型不够聪明，而是“它并不知道你为什么让它写这段代码”。它只能基于你当下这句话去推测需求，而项目级别的约束、边界和业务规则，随着对话轮次增加会逐渐失真。
这也是“规格驱动”这套打法出现的根本原因。OpenSpec 和 Superpowers 这两个工具组合在一起，本质上是把传统软件工程里的需求规格、任务拆分、验收标准这些概念，重新用 AI 编程时代的语法官表达出来。换句话说，不是让 AI 更聪明，而是让 AI 在动手之前，先拿到一份它自己参与确认过的、结构化的需求说明书。这套思路解决的问题非常具体：让 AI 写出来的代码，从“看起来对”变成“确实对”。
这篇文章我会从实际使用角度，把这套组合打法的完整链路讲清楚。包括为什么需要用规格驱动代替自由对话、OpenSpec 和 Superpowers 各自承担什么角色、怎么装怎么配、一套可复用的工作流长什么样，以及我实测下来无规格和有规格体验上最明显的差别在哪里。
2. OpenSpec 和 Superpowers 到底分别扮演什么角色
很多人在热词里看到“OpenSpec 搭配 Superpowers 一起使用”这个说法，但不太清楚这两个东西各自的职责边界。我一开始也踩过这个坑，以为它们是同类工具，装完发现根本不是一回事。
2.1 OpenSpec：项目级的需求规格管理框架
OpenSpec 是一个面向 AI 编程场景的规格驱动开发框架。它的核心思路是：在 AI 动手改代码之前，先把需求变更写成一堆结构化的 markdown 文件，让 AI 自己基于这些文件去理解全貌，再决定改哪些文件、怎么改、怎么验证。
OpenSpec 定义了一套项目内的目录结构，通常包含specs/目录，里面按变更单元组织规格文件。每个规格文件会明确描述当前变更的动机、涉及的行为变化、需要调整的代码区域以及验收标准。它不是给人看的文档，而是给 AI 看的需求上下文。
这个工具的典型用法是：开发者把需求用自然语言描述出来，然后让 AI 基于现有代码库生成一份规格提案（proposal）。开发者审核这份提案，确认或修改里面的内容，之后 AI 再按这份提案去执行代码修改。这个过程中，规格提案扮演了两个关键角色：一是把需求从“对话里的一句话”变成“项目里的一份文件”，不随对话上下文漂移；二是给后续的每一次代码修改提供一个可追溯的依据，AI 不会因为用户中途换了话题而丢掉之前确认过的规则。
2.2 Superpowers：AI 的技能包，相当于给编程助手开外挂
Superpowers 和 OpenSpec 完全不是一个层面的东西。Superpowers 是 GitHub 上一个开放的 skills 集合，专门给 Claude Code 这类操作型 AI 增强能力用的。
Skill 的概念可以理解成 AI 的“操作手册”。默认状态下，Claude Code 只是一个能读文件、写代码、跑命令的通用工具，你让它干什么它就干什么。但如果你给它是配了某个 skill，它就知道在特定场景下应该按某套流程、某种格式标准去做事。例如一个 code review skill 会约定它拿到代码之后先检查哪些方面、按什么顺序输出结果、哪些问题需要直接修改哪些只需要提醒。Superpowers 将来就是一堆这样预置好的、按场景分类的 skill 集合。
在 OpenAI 生态里有 GPTs，在 Claude 生态里这件事就是靠 skill 来完成的。Superpowers 这类项目做的，就是把社区里沉淀下来的高质量 skill 统一打包，让你免去自己写提示词的功夫，直接以插件形式挂载到 Claude Code 上，让它自动在合适的时候调用对应技能。
2.3 两者的关系：一个管“方向”，一个管“能力”
我用一个比较直白的比喻来解释。OpenSpec 相当于给 AI 装了一个“产品经理”，负责把模糊的需求整理成清晰的、有验收标准的任务说明；Superpowers 相当于给 AI 装了一批“资深工程师”，负责在执行具体任务时遵循最佳实践而不是自由发挥。
单独使用 OpenSpec，AI 了解需求的方向，但具体怎么执行还是依赖默认的代码能力；单独使用 Superpowers，AI 有很强的执行技巧，但缺少一份结构化的规格文件去约束它的工作边界。把两者合在一起，就形成了比较完整的闭环：先通过 OpenSpec 把需求和标准固定下来，再让 Superpowers 里预置的技能驱动 AI 高质量地完成编码动作。
3. 环境准备：Claude Code、OpenSpec 与 Superpowers 的安装与联通
先说清楚，这套方案最基础的前提是一个能跑的 AI 编程终端工具。我目前的主力是 Claude Code，下文所有操作默认它已经安装好并且能正常使用（Node.js 环境这些就不展开说了）。OpenSpec 本身也是一套命令行工具，需要 Node.js 环境，这一点在安装前先确认好。
3.1 安装 OpenSpec：一条命令的事
OpenSpec 的安装非常简单，它是一个 npm 包，全局安装即可：
npm install -g openspec安装完之后，进入你的项目目录，执行初始化命令：
openspec init这一步会在项目根目录下创建openspec/目录，里面默认有一份project.md文件，用来描述整个项目的技术栈、模块结构、编码规范等基本信息。这份文件相当于给 AI 看的项目总纲，建议认真填写，越详细越好。
要注意的是，openspec init只在项目根目录执行一次就可以了。它会生成固定的目录骨架，之后新增需求变更不需要再重复初始化。
3.2 安装 Superpowers：从 GitHub 拉取 skills
Superpowers 的安装方式稍微灵活一点，因为它本质上是把技能文件放置到 Claude Code 能识别的位置。以我使用的 Claude Code 为例，它有一个用户级配置目录，skills 一般放在~/.claude/skills/下。
从 GitHub 仓库拉取：
git clone https://github.com/xxx/superpowers.git ~/.claude/skills/superpowers（仓库的具体地址以最新版本为准，建议去 GitHub 搜索 superpowers 找到官方仓库。）
拉取完成后，确认一下目录结构是否正确。每个 skill 通常是一个子目录，里面包含一份SKILL.md文件，这个文件就是技能的核心定义。Claude Code 会通过扫描这个目录来识别可用的技能。
如果你用的是 OpenCode 或其他兼容 skill 机制的 AI 编程工具，安装路径可能不同，但原理一样——只要让工具能找到SKILL.md文件即可。
3.3 验证两个组件是否被正确识别
装完之后怎么确认它们真的生效了？我自己是这样验证的：
先验证 Superpowers，直接在 Claude Code 的对话里问一句“你现在有哪些可用的 skills，分别介绍一下”。如果它开始列举具体的技能名称和作用，说明已经成功加载。如果它一脸茫然，大概率是目录放错了位置，或者需要重启会话。
再验证 OpenSpec，在项目目录下直接执行：
openspec list如果能看到当前项目下的提案列表（刚开始应该是空的），说明框架已经正常工作了。
这里有一个小建议：如果你在 Windows 环境下使用，路径处理方面会有些小坑，优先推荐用 WSL 或者在 Git Bash 里跑，会省去很多路径兼容的麻烦。
4. 从需求到规格：一套可执行的规格驱动工作流
工具装好之后，真正关键的其实是工作流怎么设计。我在实际项目中摸索下来，比较顺手的流程是：描述需求生成提案，审查规格提案，让 AI 按规格执行，最后做一致性验证。
4.1 把需求变成 spec 提案：让 AI 先“想清楚”再动手
以一个实际例子来说明。假设我的项目是一个待办事项管理应用，现在新需求是“给每个待办事项增加截止日期，并且在过期后高亮显示”。
传统做法是直接告诉 Claude Code：“帮我给待办事项增加截止日期和过期高亮。”它可能直接就开干了，改模型、改接口、改前端、改样式，一气呵成。看起来效率很高，但问题也很明显：它没问清楚截止日期存什么格式、过期高亮的样式标准、时间比较用本地时区还是服务器时区，就凭自己的“常识”开始设计了。
用 OpenSpec 的流程，第一步不是让它写代码，而是让它生成一份规格提案：
openspec proposal create add-todo-deadline --description "给每个待办事项增加截止日期，并在过期后高亮显示"执行完之后，OpenSpec 会在提案目录里生成一组 markdown 文件，并调用 AI 基于当前项目代码库分析需求影响。AI 会读项目里现有的数据模型、接口定义、前端页面结构，然后自动补全规格内容。
这个环节你可以观察到一个明显差异：AI 不再急着输出代码，而是在“思考”需求本身的合理性以及落地方案。它会在提案里写清楚需要改动哪些文件、数据模型应该怎么调整、涉及哪些前端组件变更。
4.2 审查提案：开发者的核心工作在这里
提案生成之后，你需要像做 Code Review 一样审一遍这份规格说明。这一步是整个流程中开发者最有价值的部分，因为你在用人类的判断力去校正 AI 对需求的理解，而不是去和它争论代码实现细节。
比如说 AI 生成的提案里写了“截止日期类型为 string 类型”，你发现项目里其他时间字段都已经用了 ISO 标准字符串存储，那这个提案就符合项目惯例，直接放行；但如果它写的是 “用 UNIX 时间戳”，那就不对，你得改掉。再比如它可能没有考虑到过期高亮在移动端的展示差异，你得把这个边界条件补进提案的验收标准里。
有些版本的 OpenSpec 支持通过对话方式直接修改提案，也就是你把它生成的规格文件和修改意见一起丢回对话里，让它自己修订一遍。如果当前版本只能手动编辑 markdown 文件，那直接改文件也一样，提案本身就是给人审核用的。
4.3 按规格执行：AI 从“自由发挥”变成“按图施工”
提案审核通过后，接下来才是真正写代码的阶段。把规格文件明确的路径传给 AI，让它严格按里面的变更范围和验收标准来执行。
这时的体验和直接对话式编程完全不同。AI 不再是“猜你想改哪”，而是“按规格来改”。它能先定位到规格里提到的关键代码区域，再逐个文件执行变更。过程中遇到规格里没覆盖的情况，它更倾向于停下来问，而不是擅自做决定。
你也无须担心 AI 在实现过程中对需求的记忆逐渐模糊。规格文件就放在项目里，每轮对话它都能去重新确认，不需要靠对话历史来记住“当初是怎么约定的”。
4.4 验收：用规格里的标准来判断是否完成
最后一个环节是验证。以前判断 AI 代码写没写对，主要靠跑测试、肉眼检查功能是否正常。有规格驱动的流程之后，判断标准更明确了：直接对照提案里的验收标准逐条过。
还拿上面的例子来说，验收标准可能包括：
- 新建待办事项时能正确设置截止日期，格式与项目现有时间字段一致
- 待办列表中对已过期但未完成的事项有高亮标识
- 高亮样式符合设计规范中定义的警示色值
- 已完成事项即使过期也不再显示高亮
- 修改截止日期后高亮状态实时更新
让 AI 逐条跑一遍这些场景，把结果反馈给你。通过的标准非常明确，没有任何模糊地带。整个开发闭环到这里才算走完。
5. 实测对比：没有 OpenSpec 和有 OpenSpec 的体验差异
这部分我想聊点更直观的，就是我在一个中小型全栈项目里分别用“纯粹对话式编程”和“规格驱动编程”的对比体验。虽然没法给你一个精确到小数点后面的量化数据，但那种体感上的差异，比数字更真实。
5.1 在复杂需求变更场景下的差异最明显
我先让 Claude Code 直接实现一个涉及数据模型变更加前端联动的新功能。前二十分钟看起来很顺利，AI 自己改了后端的数据模型、迁移脚本和前端表单，代码风格也和项目保持一致。但当我提出一个边界情况时，比如“如果用户没有设置截止日期会怎样”，它开始犹豫了，一会儿说加默认值，一会儿说允许为空，最后写出来的逻辑和原有校验逻辑互相冲突。
换到 OpenSpec 流程，同样一个需求，AI 先花几分钟读了代码库，在提案里写清楚了截止日期是可选还是必选、为空时怎么处理、底层校验逻辑放在哪里。我审完提案只需要回答一个问题：“这个行为是否符合产品预期？”回答是，后面整个实现过程就顺畅得多，因为边界已经在动手前被定义过了。
5.2 上下文保持能力不是一个量级
纯对话式编程的场景下，上下文保持能力完全取决于对话窗口的余量。当你和 AI 聊了几十轮之后，早期确认过的“使用 UTC 时间存储”这种决定，它慢慢就不记得了。你不得不过几分钟重申一次，甚至因为它没遵守约定而返工。
有规格文件的加持后，这类问题基本消失。时间存什么格式、字段叫什么名字、接口返回什么结构，全都在那份规格文件里躺着。AI 每次动手前读一遍，它不需要“记得”，只需要“去看”。
5.3 返工率从“随缘”变成“可控”
说实话，没有任何流程能保证一次就把代码写对。但关键区别在于：对话式编程的返工，是 AI 因为误解需求而把代码改错了方向，这种返工经常牵一发动全身；而规格驱动的返工，是在验收阶段发现某些细化标准没达到，改动范围通常局限在局部函数或样式层面。
这两种返工的成本完全不在一个量级。前者可能让你想重写整个模块，后者基本就是改个判断条件或者换个样式类名的事。
6. Superpowers 的实战技能拆解：它到底给了 AI 哪些超能力
Superpowers 的价值不像 OpenSpec 那样体现在流程框架层面，它更接地气——直接改变了 AI 在具体任务里的行为模式。下面这几个技能方向是我实际用得最多、觉得最值回票价的。
6.1 Code Review 技能：把 AI 从“偏袒自己”的评审中解救出来
编程 AI 有个比较隐蔽的问题，自己写代码自己审查，往往很难发现自己的思维盲区。它可能会继续用一种错误的模式写下去，因为整个上下文里这种错误的出现是连续且自洽的。
Superpowers 的 Code Review 技能通过预先定义一套审查规范来解决这个问题。它会要求 AI 在审查时不考虑“这段代码是谁写的”，而是按一套固定清单逐项考察：安全性、边界条件、性能、可维护性、命名规范等。审查结果也按统一格式输出，必要的时候直接给出修复代码。
我最常用的是在完成一个开发任务后，让 AI 以另一个身份重新审视所有改动文件。技能加持下它经常会发现一些我之前完全没想到的问题，比如某个公共函数被不再需要的 import 残留污染了命名空间，或者某处异步操作漏掉了异常捕获。
6.2 数据库 Schema 变更技能：改表结构不再心惊胆战
全栈项目开发中，改数据库表结构永远是最让人揪心的环节之一，改的时候感觉很爽，跑迁移脚本的时候就开始流汗，等数据一真是丢失，那就要哭了。
Superpowers 里有一个专门处理数据库 Schema 变更的技能。它规定了 AI 在执行数据库迁移时的行为标准：生成迁移脚本之前先检查现有数据库模型、对破坏性变更提出警告、给出可回滚的方案。更贴心的是，它会规范迁移文件命名，并保留向下兼容。
如果没有这些技能约束，AI 很可能会直接生成一个DROP COLUMN脚本，毫不在意地删掉一列数据。而有了技能指导，它至少会提示你“这是一个破坏性操作，是否确实要执行？”这一句提示，有时候就能避免一个无法挽回的事故。
6.3 调试排错技能：不再“东一榔头西一棒槌”
默认状态下，AI 面对一个 bug，会立刻开始推测性修复：怀疑是这里的问题，改一行；怀疑是那里的问题，又改一行。虽然有时候确实能修好，但整个过程非常混乱，而且经常修好一个 bug 又引入新的问题。
Superpowers 的调试技能会强制 AI 按照“复现问题→定位根因→提出假设→验证假设→修复确认”的顺序来工作。它不允许 AI 在还没确认问题来源之前就动手改代码。
实测中这个技能在遇到复杂 bug 时效果非常明显。有一次我的应用出现偶发性内存溢出，正常情况下 AI 可能会在内存缓存和数据库连接池之间反复横跳，但调试技能引导它先复现问题、记录日志，一步步缩小范围，最后定位到是某个定时任务没有释放数据库连接。如果没有流程上的约束，这个过程大概率会变成一场猜谜。
7. 实战中的坑与经验：把这些工具用顺的关键细节
工具链本身不太复杂，动手跑一遍就能掌握基本用法。但想要真正把这套规格驱动打法用顺，有几处细节值得单独说一下，都是我自己踩过之后才领悟的。
7.1 不要跳过提案审查步骤
很多开发者初用 OpenSpec 的时候，看到 AI 生成的提案文件已经写得有模有样，就直接让它去实现。这样做虽然比纯对话式编程好一些，但错过了这个流程最大的价值——人才是需求的第一责任人，AI 只是在模仿你对需求的理解。
我自己的经验是，提案审查环节至少要过三遍：第一遍看业务逻辑是否正确理解；第二遍看字段和命名是否符合项目现有风格；第三遍看验收标准是否充实到可以指导编码。这三遍下来可能只需要几分钟，但能省掉后面大量的来回修改。
7.2 skill 不是越多越好
我第一次用 Superpowers 的时候，本着“多多益善”的心态把仓库里的 skill 全都挂着，结果发现 AI 的行为反而变得有点怪：有时候它在多个 skill 之间来回横跳，执行任务的思路不够专注，本来一步能完成的事它会套一套复杂的流程。
后来我把默认启用的 skill 减少到和当前项目相关的几个核心项，比如 Code Review、数据库 Schema 管理、调试排错等，整体效率反而提升了。AI 更像一个有明确职责划分的工程师，而不是一个什么都懂一点但什么都不精的万金油。
7.3 规格文件也需要维护
很多人以为规格文件写完就完事了，等项目迭代几轮之后再来看，发现里面的技术方案描述已经和实际代码对不上了。规格驱动的优势在于它给你提供了“当前变更的决策依据”，但也要意识到它本质上是一份活的文档。
我的做法是每次新需求走完一轮规格流程后，顺手更新项目总纲文件project.md，把新模块的边界、新增的技术决策补充进去。这样 AI 在下一轮需求生成提案时，能读到的是最新的项目全局约束，产出的提案质量会明显更高。
7.4 先小项目验证，再大项目铺开
如果你是第一次尝试这套组合打法，我不建议直接拿它去处理一个大型存量项目。规格驱动最有可能暴露问题的时候，恰恰是当它需要理解已有代码库时，如果代码库本身非常庞大且结构不清晰，AI 生成的提案质量就会下降，导致你审查起来很费劲。
更好的路径是在一个中小型的新项目里先完整跑几轮，熟悉流程，感受规格驱动的工作方式，再逐步把它应用到更大的项目中去。跟我一样从小项目验证起步，踩坑成本低很多，也更容易体会到这套打法的真正优势。
说到底，OpenSpec 和 Superpowers 的组合没有高深的技术壁垒，它们提供的是一种更符合人脑工作方式的 AI 编程工作流。它可能不会让 AI 一次性写出完美代码，但可以让你在 AI 编程的过程中重新掌握主导权——从被动接受 AI 的产出，变成定义标准并检查产出。这套“规格驱动”的打法，对任何一个想认真用好 AI 编程工具的人来说，都值得花一个下午部署一次，体验一下。
