这段时间在做复杂项目时，我越来越明显地感觉到：AI 已经不只是“帮我写代码”的工具了，它开始参与需求理解、任务拆解、代码生成、测试修复，甚至重构决策。
但真正的问题也来了——AI 不是不会做，而是很容易在复杂项目里做偏。
所以我开始关注两类思路：OpenSpec 和 Superpowers。在我看来，它们代表的是两条不同的 AI 工程化路线：一个偏“规格驱动”，一个偏“能力增强”。
我对 OpenSpec 的理解：先把规则讲清楚
如果让我用一句话概括 OpenSpec，我会说它像是给 AI 画施工图。
它不是急着让 AI 动手，而是先把需求、边界、约束、验收标准说清楚。这个思路对复杂项目特别重要，因为项目一大，最怕的不是写不出来，而是方向错了，返工更贵。
我比较喜欢 OpenSpec 的地方有三个：
- 它能逼着你先想清楚问题是什么
- 它适合多人协作，大家对目标理解更一致
- 它对长期维护更友好，后面回看也知道为什么这么做
但它也不是没有代价。最大的问题就是：前期会慢一点。
如果只是做一个小功能，可能会觉得有点重。你得先定义规格、拆任务、定验收，有时候会让人觉得“还没开始写代码，就先写了一堆说明”。
所以在我看来，OpenSpec 更适合那种：
- 业务比较复杂
- 需求经常变
- 项目周期长
- 团队协作多
简单说，它适合“先定规则，再开工”。
我对 Superpowers 的理解：让 AI 跑得更快
Superpowers 给我的感觉更像是“增强 AI 的执行力”。
它不一定先帮你把所有规则写死，而是更强调怎么让 AI 更高效地推进任务：拆分、执行、修复、迭代。对于一些需要快速验证、快速产出的场景，这种方式很有用。
它的优点很直接：
- 上手快，几乎可以立刻进入工作状态
- 执行效率高，适合快速试错
- 灵活，需求变了也容易跟着改
但它的问题我也踩过：
如果前面没有足够清晰的目标和约束，AI 跑得越快，偏得也越快。尤其在复杂项目里，局部看起来都对，拼起来就乱了,这种情况下适合先以demo的方式把整个需求跑一遍，自己就能知道这个项目到底该怎么做，然后直接推翻重来，不要再之前的code上做修改了，直接重新来一遍，这样质量直接拉升结果档次.
所以 Superpowers 更像是适合：
- 快速原型
- 高频迭代
- 小中型项目
- 需求变化比较快的团队
它的核心价值不是“替你定义问题”，而是“帮你更快把问题做出来”。
真正有价值的，不是二选一，而是怎么搭配
如果只站在开发者角度看，我觉得 OpenSpec 和 Superpowers 其实不是对立关系，而是分工不同。
- OpenSpec 负责把问题定义清楚
- Superpowers 负责把执行效率拉上去
我的实际经验是，复杂项目里最稳的做法往往是：
- 先用 OpenSpec 把目标、边界、验收标准定下来
- 再用 Superpowers 去推进实现、测试和修复
- 中途有变化，再回到规格层重新校准
这样做的好处是，AI 不会只会“猛干”，而是能在工程边界里稳定输出。
如果是我来选，我会这么分场景
如果是下面这种项目，我会更偏向 OpenSpec：
- 核心业务复杂
- 需求不稳定
- 团队成员多
- 代码要长期维护
如果是下面这种，我会更偏向 Superpowers：
- 想快速验证一个想法
- 功能迭代频繁
- 项目体量没那么大
- 更看重效率而不是流程完整度
从开发者的角度看，我不太愿意把它们简单理解成“谁更强”。
更准确地说：
- OpenSpec 更像方向盘和路线图
- Superpowers 更像发动机和加速器
复杂项目里，最怕的不是 AI 不够强，而是 AI 很强，但没有边界。
所以我的经验是：先用规格把方向定住，再用能力把执行拉满。
插播一句:
当然这两个最大的缺点就是特别消耗token,如果使用一些openai或者cc的plus,pro会员顶不住的，，一方面可以借鉴这些工具的思路，自己做几个小型的promot file，一些rules，例如使用vscode 的copilot或者其他编码工具，以最小的方式来约束AI，当然想要试到这些全球顶级的工程化工具还是要舍得花钱，走官方不划算，可以买一些中转站的api，当然要是靠谱的，不掺水的,我自己也是换了几个中转了: www.intelalloc.com/register?pr… 有需要的可以看看，非广，纯推荐，刚好我的邀请码进去好似送了点额度.
