在 AI 辅助编程领域，Obra/superpowers 库与 Fission-AI/OpenSpec 库代表了两种截然不同的技术路径。前者致力于构建可复用的 AI 编程技能库，后者则倡导以规范（Spec）为核心的驱动开发模式。本文将深入对比两者在核心理念、工作流程及适用场景上的核心差异，探讨它们如何分别解决 AI 开发中的效率与一致性难题。
前几天在咖啡店，我无意中听到邻桌两位程序员在激烈争论。一位坚持说："AI 编程助手最大的价值就是帮我快速写出新代码，我需要的是更多'技能'。'另一位则反驳："不对，AI 最该解决的是代码一致性，我们团队现在最缺的是'规范'。'这让我立刻想到了最近在 GitHub 上观察到的两个项目：Obra 的 superpowers 技能库和 Fission-AI 的 OpenSpec 规范驱动框架。它们恰好代表了这两种截然不同的思路。
打开 superpowers 的仓库，第一印象是它像一个为 AI 助手精心打造的'瑞士军刀'工具箱。它的核心理念非常直接：将常见的、复杂的编程任务封装成一个个可复用的'技能'（Skill）。这就像给 AI 安装了一个插件商店，当需要实现一个'用户登录'功能时，我不再需要费力地描述数据库字段、JWT 令牌生成和密码加密逻辑，而是直接调用一个预定义的 implementUserAuth 技能。这个技能里已经封装了最佳实践、安全考量和我偏好的代码结构。它的本质是知识的封装与复用，极大地降低了 AI 生成代码的随机性和不稳定性。
深入思考后发现，superpowers 的深层价值在于 '赋能个体'。它假设开发者是使用 AI 的主力，目标是最大化单兵作战效率。开发者可以根据自己的技术栈（比如 Vue、Gin、SpringBoot）和常用场景，组合和定制技能库。这种模式特别适合 快速原型开发、个人项目或者技术探索，因为它的灵活度极高，能快速响应多变的、创造性的需求。效率的提升是指数级的，因为我调教好的技能，可以一劳永逸地解决一类问题。
然而，这种高度自由也是一把双刃剑。当我把视角从个人切换到团队时，问题就浮现了：如果团队里每个人都有一套自己组合的'技能包'，或者对同一个技能的理解有细微差别，那么生成的代码风格、架构选择可能会千差万别。superpowers 解决了'会不会做'的问题，但没有强约束'怎么做才一致'。在需要高度协作和长期维护的项目中，这可能成为新的混乱源头。更关键的是，技能库的质量完全依赖创建者的水平，如果技能设计得不好，AI 只会'完美地'重复错误。
而 OpenSpec 走的是另一条路。它的出发点不是给 AI 更多'武器'，而是给 AI 设定清晰的'交战规则'。规范驱动开发（Spec-driven Development） 是它的核心。我试用 OpenSpec 时，印象最深的是它的第一步：起草提案（Proposal）。当我想添加一个'自定义专注时长'功能时，它没有立即写代码，而是反问我五个关键问题：时长范围是多少？UI 放在哪里？如何影响统计？……它强迫我在动手之前，先把需求想清楚、写明白。
这个流程的精髓在于，开发者首先需要编写一份机器可读的'规范'（Spec），这份规范会详细定义 API 接口、数据结构、业务逻辑约束。然后，AI 编码助手的角色，就从一个自由发挥的'创作者'，转变为一个严格的'执行者'。它的任务是根据这份不可撼动的规范，去生成或补全代码。代码不再是创作的起点，而是满足规范后的必然产出。
这让我意识到，OpenSpec 瞄准的痛点是 团队协作与项目治理。它通过将'规范'前置并中心化，强制保证了代码的一致性。无论是新加入的成员，还是不同的 AI 模型，只要遵循同一份 Spec，产出的代码在接口、数据流和关键逻辑上就是可预期的。这对于 来说，价值巨大。它把知识沉淀在了规范里，而非分散在个人的提示词中，彻底解决了 AI 编程中最棘手的'上下文丢失'和'需求漂移'问题。
