深度拆解 Superpowers 和 gstack
我差点被AI编程骗走一整年，后来才想明白一件事
你信不信，我去年年初的时候，简直就是个傻子。
满世界都在喊“AI要取代程序员了”，我急得跟热锅上的蚂蚁一样。Claude 4出来？买！GPT-5更新？冲！每个新版本我都是第一批掏钱的人。那三个月里，我脑子里就只有一件事：哪个模型更强？
后来呢？你猜怎么着？
代码确实能跑。项目稍微复杂一点，崩得比谁都干脆。
最离谱的一次——我让Claude给我写个支付模块。你想象一下，它生成了2000行看起来完美无缺的代码，我开心得不行，上线第一天，啪，测试环境的数据库直接崩了。为什么？因为这家伙自己定义了一套“更高效”的事务处理逻辑，压根没按套路出牌。
那会儿我才开始琢磨一件事：AI编程的问题，可能根本不在模型上。你看，这个念头本身，就够反直觉的了。
说到这儿，我得跟你聊聊第一个打破我认知的东西——Superpowers。
今年2月，我在GitHub上一个小众讨论串里瞄到了它。名字我第一眼就烦：“Superpowers”？又是个蹭超级英雄热度的破烂货吧。结果点进去一看，不对劲。
它跟别的AI工具完全不一样。别的工具都说“你说吧，你要啥”，它倒好，硬性规定了一整套流程：先写设计文档，再写计划，然后写测试，最后才能写代码。每一步都有输出规范，你跳一步，它直接罢工。
我当时心想：你特么有病吧？我找AI就是为了省事儿，你让我先写文档？
但测试了两次之后，我服了，真的服了。
有一个例子我记得特别清楚。我用原生Claude写一个用户权限系统，折腾了两个小时，写了改改了写，最后得到一个勉强能跑的东西。同样一个需求，换成Superpowers走流程——脑暴、写spec、定计划、TDD、代码审查——整整花了我四个小时。
结果呢？太离谱了。第一个版本就是可交付的。测试覆盖率92%，API文档齐全，连那些我根本没想到的边缘情况都给你处理好了。
你看，这就是纪律的力量。Superpowers内置了11个核心skills，从brainstorming到finishing-a-development-branch，每一个背后都是实战沉淀出来的流程。它的创始人之一之前在医疗系统公司干了八年——你想想，医疗系统出bug会出人命，他们愣是把那种“必须测、必须审、不能跳步”的变态文化直接写进了AI工作流里。
3月的时候，gstack突然炸了。
Garry Tan——就是YC那个CEO——发了一条推，演示他团队用这套东西做的产品，配了一句“810倍生产力提升”。评论区直接炸成一锅粥。
我的第一反应跟你一样：注水。810倍？你信吗？
但好奇心这东西，你拦不住。我翻到它的代码仓库，看了十几分钟，发现gstack和Superpowers完全是两条路子。
Superpowers像一个项目经理在盯着你：“按流程走，别偷懒，先测再写。”
gstack像一个全明星团队在围着你：“我是CEO，我来判断这个需求值不值得做；我是工程总监，我来审查你的架构设计；我是QA，我来找漏洞。”
它的命令从/ceo-review到/eng-review到/design-review，每一条背后都是真实的角色扮演。最骚的操作是/codex——让两个AI互相审查对方的输出，人类只管做最终决策。
说实话，看到这里我已经有点懵了。不是模型不行吗？怎么突然冒出来一堆“工作流工具”？
接下来两个月，事情越来越有意思。
先是OpenSpec来了。它不玩人格化角色，而是把需求、规格、设计、任务、归档全部变成可追踪的“工件”。你每干一件事，都得更新spec文件、变更记录、归档状态。它更像一个版本控制系统，只不过控制的是AI开发流程。
然后Compound Engineering Plugin也出现了。这个项目最核心的理念是“做完事要留下可复用的资产”。每一轮plan、review、done之后，它把所有经验写进durable docs。下次遇到相似问题，不用从头再来。你想想，如果你做了一个支付系统，三个月后要做类似的会员系统，Compound已经帮你把架构决策、常见坑、测试策略都沉淀好了——这事儿挺要命的。
到这时候，我已经彻底放弃了“哪个模型最强”的问题。为什么？因为事实摆在那里：
同样用Claude 3.5或4，不同工具跑出来的代码质量天差地别。
我专门做了一个测试：拿一个简单的CRUD接口，分别用原生Claude、Superpowers、gstack、OpenSpec各跑三次。原生Claude三次生成了三种不同的代码风格，有一次甚至自己发明了一个不存在的数据库函数。Superpowers和gstack生成的代码虽然风格统一，但gstack更灵活，允许我快速跳过多余步骤。
最让我意外的是OpenSpec：它的输出是最慢的，但变更追溯能力是真的强。两周后我回头看一个旧的spec文件，还能清清楚楚地知道当时为什么做那个设计决策。
Lucas Fernandes在8月份发了一篇对比文章，说了一段我到现在还记着的话：“Superpowers的第一控制原语是skill和纪律，gstack的第一控制原语是角色命令与sprint流程，OpenSpec的第一控制原语是spec/change/archive工件。”这句话我后来琢磨了好几天，才意识到它其实点破了所有问题的核心。
7月份，一个叫“Harness Engineering”的概念突然冒了出来。
当时有一篇讲AI Agent底层基础设施的文章在小圈子里传。它提出了一个三层框架：
- Prompt Engineering：教AI说什么
- Skill Engineering：教AI做什么
- Harness Engineering：给AI提供安全的运行环境
我正被工作流工具搞得焦头烂额——不是它们不好，是我不知道怎么组合最合适。看到这个框架之后，脑袋里啪的一声，亮堂了。问题在哪？我们之前的思路全是“找最好的工具”，但真正需要的是“搭最适合自己项目的工作流”。
Garry Tan在一次访谈中说了一段我深以为然的话：未来的程序员只会剩下三种职能——架构师、产品经理和质量把关者。代码不是不写了，而是更多时候在做决策和审查，而不是亲自敲键盘。
这个视角下，810倍生产力提升就合理了：如果一个人变成了“管理者+审查者”的角色，他当然能同时管理好几个AI干活。
到了8月，有人终于把Superpowers、gstack、OpenSpec、Compound放在一起做了完整的横向对比。我翻那篇文章翻到凌晨三点，因为每个项目都被拆到了底层逻辑。
那篇文章列了一个表，我觉得值得抄下来给你看：
- Superpowers：强约束的开发纪律系统，重点是“必须先设计、再计划、再执行、再评审、必须测、必须审”
- OpenSpec：规格与变更工件系统，重点是“把需求、规格、设计、任务和归档变成可追踪工件”
- gstack：虚拟工程团队操作系统，重点是“多角色协作+多模型交叉审查”
- Compound：工程知识复利系统，重点是“不仅做事，还要把结果写回durable docs”
四个项目解决的是同一个问题——让AI在受控的流程里干活——但切入的角度完全不同。
11月的时候，我终于忍不住了，决定自己动手测组合。
我先在一个人项目上单独跑了Superpowers。项目是个小型SaaS的后端，大概20个API接口。我严格按照流程走：brainstorming写了设计文档，writing-plans拆了任务，executing-plans用TDD方式写代码。每一步都卡得很死——甚至不让我直接修改代码。
体验怎么说呢……像带了一个超级严格的老师傅。慢是真的慢，但稳也是真的稳。代码一次通过率比我自己写高太多了。我以前至少得改两三轮才能稳定下来，这次第一版就基本能用。
然后我换gstack跑了一个新功能。用户要加一个多租户隔离，我直接用/eng-review让gstack审查了我的架构设计。它从CEO、工程、QA三个角度提了六个问题，其中两个直接点出了我设计的漏洞。一个是数据隔离方案在极端并发下可能有性能瓶颈，另一个是租户级的缓存策略没考虑清楚。要是我直接上手写，这两个问题至少要到提测阶段才发现。
后来我试了一下组合：用gstack做架构决策和角色审查，用Superpowers做具体的编码执行。效果比我预期的还要好。
我为啥说“好”？因为数据不会骗人。纯gstack写的一个模块，架构上很合理，但测试覆盖率只有65%（gstack的流程比较灵活，它不强制你写测试）；纯Superpowers写的一个类似模块，测试覆盖率92%，但架构层面的创新不够（因为它让你按既定模板走）。两个组合起来之后，gstack审查过的架构没有任何大问题，Superpowers又用TDD保证了代码质量，最终版本测试覆盖率接近90%，而且架构决策在review阶段就被确认过，不用事后返工。
这个过程让我终于理解了为什么有人说“Superpowers让AI更像工程师，gstack让AI更像团队”。一个偏“能力系统”，一个偏“组织系统”。一个擅长把执行做扎实，一个擅长把流程做清晰。
说到这儿，咱们回到开头那个问题：AI编程真正的差距到底在哪？
如果你问我现在的答案——不在模型，在工作流。
这个认知是我花了一整年踩坑踩出来的。想想看：同一个Claude 4，在不同的工作流工具里跑出来的结果可以天差地别。有人用它三天写出一套能部署的应用，有人用同样的模型写出代码全是坑。区别在哪？不在于模型的能力在变化，在于你怎么用这个模型。
过去我们说prompt engineering，后来我们说agent。现在更准确的说法，其实是workflow engineering、agent orchestration、decision scaffolding、AI-native software process——说白了，就是怎么让AI知道自己该在什么时候干什么事，而不是“你看着办，帮我写个XX”。
我知道有些读者可能会觉得我站队Superpowers或者gstack。坦白说，我目前更倾向于混合使用：
- 复杂Web产品：核心逻辑用Superpowers的强约束流程保证质量，辅助功能用gstack的灵活流程快速迭代
- 小团队/个人项目：gstack更适合，因为你没有那么多角色可以分配，gstack的虚拟团队模式恰好补充了这个缺口
- 长期维护的项目：强烈建议引入OpenSpec的工件管理或Compound的durable docs，因为半年后你回头改代码，当初的设计决策上下文早就忘了
- 一次性项目：我反而不推荐Superpowers，流程太重，gstack的轻量模式就够用了
你写的项目类型不同，适合的工作流结构也不同。没有银弹。
但我可以给你一个我自己的判断标准：如果你的项目有超过5个核心模块、预计维护周期超过6个月、或者需要多人协作，那工作流工具不是“选了更好”，而是“不选会踩坑”。
最后，给你三条实操建议，我踩过的坑你就别踩了。
第一，别贪多，从一条命令开始。
我见过太多人下载了Superpowers就把11个skills全部激活，结果第一个小时就被各种约束搞崩溃。我的建议是：刚开始只用brainstorming和writing-plans这两个基础skills，跑完两个feature之后再加executing-plans和TDD。让团队适应“AI也要写设计文档”这件事需要一个过程，强推必定反弹。
第二，CLAUDE.md是核心，别跳过。
配置CLAUDE.md是最关键的一步，因为它决定了Claude Code遇到模糊指令时该调哪个skill。我之前踩过一个坑：某个团队把gstack和Superpowers的配置文件放在一起，但没有写清楚默认路由，结果AI在“做个计划”这个指令下随机匹配了Superpowers的writing-plans和gstack的/plan-eng-review，两个工作流互相干扰，最后项目进度整整延后了一周。
第三，不要迷信任何一套流程。
Superpowers虽然好，但有些场景下它的“必须先测”会拖慢原型验证速度。gstack虽然灵活，但过度使用/codex会让决策时间拉长。最好的方法是：自己跑三到五个项目周期，记录每次的选择和原因，三个月后回头看，你会发现自己的模式偏好。
最后说一句，真的，别听那些“AI要取代所有人”的鬼话了。
真正该做的事，是趁这个机会重新想清楚一件事：你到底是写代码的，还是做决策的？你的价值到底在哪？当AI能把代码写得更快更好的时候，你还能提供什么它不能替代的东西？
这事儿想清楚了，你就不会焦虑了。
AI写代码的时代，真正值钱的不是你的手，是你的脑子。
读者评论 4