如果你这半年在认真用 AI 写代码，大概率已经过了那个"哇它能自己写一整个文件"的兴奋期了。新鲜劲儿过去之后，真正的问题开始冒出来：AI 生成的代码风格飘忽不定，同一个项目里今天写的和昨天写的像两个人干的；需求稍微复杂一点，Agent 就开始在上下文里迷路，改着改着把之前修好的 bug 又改回去了；更别提那种看起来能跑、一上生产就炸的"幻觉代码"——AI 不会告诉你它不知道，它会硬编。
说白了，vibecoding 的时代过去了。那个靠几句 prompt 就能"感觉对了就行"的阶段，只适用于 Demo 和 side project。一旦你面对的是一个真实的、有历史的、多人协作的代码库，光靠 vibe 是不够的，你得有纪律。而"纪律"这个东西，正是目前这波 Agentic coding 框架试图解决的核心问题。
目前市面上能称得上"框架"而非"工具"的方案，大致有五家：Superpowers（Nous Research）、BMAD Method、SpecKit（GitHub）、OpenSpec、GSD。它们加起来 GitHub Star 超过 17 万，但各自的思路差异之大，大到选错一个可能会让你白忙活好几周——不是学不会，而是它压根就不是为你这种场景设计的。
这篇文章是我作为一个日常在用 AI 写代码的开发者，对这五个框架的一次横向梳理。不是什么权威评测，更像是一个同行的使用笔记。
共同的基因：Agent、Workflow、Skill
先把共同点说清楚。这五个框架虽然长得完全不一样，但底层都建立在一个三元结构上：Agent（执行者）、Workflow（流程控制）、Skill/Knowledge（知识和能力）。
Agent 是干活的那个——不管是 Claude Code、Codex 还是你自己搭的 LLM 管线，最终总有一个东西在读写文件、执行命令。Workflow 是管流程的那个——什么时候该写 spec、什么时候该写代码、什么时候该跑测试、什么时候该停下来等人审查，这些决策不是 Agent 自己做的，而是框架在控制。Skill 或者说 Knowledge 是"怎么干"的那部分——项目规范、编码风格、技术栈约定、之前踩过的坑，这些上下文如果不被系统化管理，Agent 每次都得从零开始猜。
这三个东西任何一家都绕不开，区别只在于谁主谁次、谁严谁松。
BMAD 把重心压在 Workflow 上，而且是非常重的那种——它试图模拟一整个开发团队。SpecKit 和 OpenSpec 把重心压在 Workflow 的"前置环节"，也就是写规格说明这件事上。GSD 的重心在 Knowledge 或者说上下文管理上，Workflow 相对轻量。Superpowers 是我觉得三块分配最均匀的一个，但它的核心卖点是把 TDD 变成了强制纪律。
下面一个一个说。
BMAD Method：模拟一个团队的重量级方案
BMAD 是这几个里面最"重"的，重到什么程度呢——它不只是帮你写代码，它试图模拟一整个软件开发团队。
它的核心理念是角色扮演。你在 BMAD 里不是跟"一个 AI"对话，而是跟一个 Product Manager、一个 Architect、一个 Developer、一个 QA 分别对话。每个角色有自己的人格、知识域和决策权限。PM 负责拆需求，Architect 负责做技术决策，Developer 负责实现，QA 负责验证。而且这些角色之间会互相 challenge——Architect 可以驳回 PM 的不合理需求，QA 可以打回 Developer 的不合规代码。
这个设计的出发点我很理解：真实的软件工程本来就不是一个人说了算的，质量是靠多方博弈出来的。BMAD 试图把这个博弈过程也自动化，让你一个人坐在电脑前就能体验到"被 PM 催进度、被 QA 挑毛病"的完整开发生态。
但它的问题也很明显。首先，太重了。你要配置角色、定义权限、设置交互规则，光初始化就得花不少时间。对于一个小团队或者独立开发者来说，这种重量是劝退级的。其次，多角色之间的 context 传递是个大坑——PM 说的东西 Architect 理解偏了，Architect 的决策 Developer 没完全执行，QA 测的东西跟 PM 想要的不是一回事。这些人在类团队里是真实存在的问题，BMAD 没有消除它们，只是把它们数字化了。
BMAD 适合的场景是那种已经有一套成熟开发流程的大团队，你想把这套流程固化到 AI 工作流里，让它自动运转。对于"我一个人想快点把东西做出来"的需求，BMAD 大概率会让你觉得它在耽误你时间。
SpecKit 和 OpenSpec：把"先写文档"这件事制度化
这两个放在一起说，因为它们解决的是同一个问题：在不写规格说明的情况下让 AI 写代码，等于在沙漠里不带地图开车。
SpecKit 是 GitHub 官方的方案，它的思路非常 GitHub 风格——gate everything。你必须先写 spec（规格说明），spec 通过审查之后，才能进入实现阶段。实现必须严格对应 spec 里的每一项，不能多做也不能少做。整个过程是门控式的：spec → review → plan → implement → verify，每一步都有明确的准入和准出条件。
这套流程的好处是确定性极强。你很清楚每一步在干什么，中间出了什么问题也能快速定位到是哪个阶段出的错。而且因为有 spec 的存在，即使你换了一个 AI 模型甚至换了一个开发者，只要 spec 没变，产出就不会差太多。
但 SpecKit 的问题也很 GitHub——它更适合新项目。如果是一个从零开始的项目，先写 spec 再写代码这个流程非常顺。但如果你面对的是一个已经跑了好几年的老代码库，有几千个文件和几十万行代码，你不可能给整个项目补一份 spec。你只能给这次要改的那一小块写，但这一小块跟其他部分的耦合关系怎么办？SpecKit 在这方面没什么好办法。
这就是 OpenSpec 切入的角度。OpenSpec 提出的是 delta spec 的概念——你不需要描述整个系统，你只需要描述这次要改什么。它的 spec 是增量的、跟 diff 绑定的、针对现有代码的变化而写的。这个思路对 brownfield 项目（也就是大部分真实项目）友好得多。
SpecKit 和 OpenSpec 的对比，本质上是一个老问题的新版本：先设计再实现 vs 在现有基础上迭代。没有谁绝对好，但如果你面对的是一个真实的老项目，OpenSpec 的实用性明显更高。反过来，如果你在做一个全新的东西，SpecKit 的严谨性能帮你少走很多弯路。
GSD（Get Stuff Done）：上下文管理才是真正的瓶颈
GSD 的全名叫 Get “Stuff” Done，名字起得很随意，但它解决的问题一点都不随意。它关注的是一个在 AI 编程里被严重低估的问题：上下文腐烂（context rot）。
什么叫上下文腐烂？你让 AI 帮你改一个功能，它一开始做得很好，理解你的需求、找到了相关的文件、甚至写的代码风格都对。但当你继续跟它对话，让它再改第二个、第三个功能时，它的表现越来越差。因为它脑子里的上下文已经被前面的对话污染了——旧的假设没清除、新的信息跟旧的冲突、文件状态在它认知里和实际已经不一致了。
GSD 解决这个问题的方式叫 wave parallelism（波次并行）。它把一个大任务拆成多个独立的 wave，每个 wave 有自己隔离的上下文窗口，互不干扰。Wave A 改用户模块，Wave B 改支付模块，两个 wave 并行跑，不会互相污染对方的上下文。等所有 wave 都跑完了，再合并结果。
这个思路的巧妙之处在于，它不试图让 AI 变得更聪明，而是改变我们使用 AI 的方式。上下文腐烂不是 AI 的 bug，是大语言模型在长对话中的固有特性。GSD 接受了这个限制，然后用架构手段绕开了它。
GSD 还有一个值得说的点是它的多 Agent 编排。它的 Agent 之间不是 BMAD 那种角色扮演关系，而是更像一个任务分发系统——主控 Agent 负责拆分任务，Worker Agent 负责执行，最后汇总。这种模式更接近 MapReduce 的思路，在处理大型代码库的批量修改时效率很高。
GSD 的弱点是它的学习曲线和生态。它的概念体系（wave、context isolation、orchestration）需要一定的理解成本，而且它不像 SpecKit 那样有 GitHub 官方背书，社区和文档的成熟度还在早期阶段。如果你愿意花时间啃，它的回报是真实的；如果你想要开箱即用，它可能会让你有些挫败。
Superpowers：用 TDD 当锚，把纪律写进流程
终于说到 Superpowers 了——我得坦白，我对它的了解比其他几个更深，因为我自己就在用它。
Superpowers 的核心洞察很简单也很深刻：AI 最大的问题不是不够聪明，是不够可靠。而软件工程里对付"不可靠"最成熟的武器，是测试驱动开发（TDD）。
Superpowers 把 TDD 从一种"推荐实践"变成了强制流程。它的 pipeline 是：brainstorming → design → plan → implement，而 implement 阶段的每一步都必须先写测试、测试失败（RED）、再写实现、测试通过（GREEN）、然后重构（REFACTOR）。这个 RED-GREEN-REFACTOR 的循环不是建议，是框架级别的硬约束。
这样做的好处是什么？你不会被 AI 的幻觉骗到。AI 写的代码能不能用，不是靠你肉眼看出来的，是靠测试跑出来的。测试不过，这块工作就没完。这种确定性在一个长期项目里是巨大的心理安慰——你知道不管 AI 怎么折腾，只要所有测试还是绿的，系统就没崩。
除了 TDD 这个杀手锏，Superpowers 的其他设计也很有意思。它的 Skills 系统是一个可复用的知识库——你可以把项目规范、技术约定、踩过的坑封装成 skill，之后每次新会话都会自动加载。它的 Memory 系统把跨会话的重要信息持久化，解决了"每次开新对话都要重新解释一遍项目背景"的痛点。它的 brainstorming → design → plan → implement 四阶段流程，在"想清楚了再动手"和"别想太多赶紧干活"之间找了一个还不错的平衡点。
Superpowers 的 Trade-off 也很清楚：它要求你接受一套相对固定的工作流。如果你习惯了自己随手写 prompt、边写边改、想到哪做到哪的自由风格，Superpowers 会让你觉得束手束脚。它更适合那些已经认同 TDD 价值、愿意花时间写测试的开发者。如果你本身就觉得写测试是浪费时间，那 Superpowers 的整个价值主张对你来说就不成立。
另外，Superpowers 目前绑定在它的 CLI 和会话管理上，跟 IDE 的集成不算特别深。如果你习惯了在 VS Code 里一站式操作，Superpowers 需要你切换到终端环境，这个切换成本不算小。
横向对比：一张决策表
把这些框架放在一起看，各自的定位其实很清晰：
如果你是一个人开发者，想要可靠的产出：Superpowers 的 TDD 流程是最直接的保障。你不需要模拟团队，你需要的是代码别出幺蛾子。
如果你在一个大团队，流程已经很成熟：BMAD 能把你们已有的流程自动化，前提是你愿意承受它的重量。
如果你在做全新项目，且重视文档：SpecKit 的 gated spec 流程能保证需求和实现的一致性，新人接手也容易。
如果你在维护老项目，每次只改一小块：OpenSpec 的 delta spec 比全量 spec 务实得多。
如果你的瓶颈是上下文管理，项目很大很复杂：GSD 的 wave parallelism 是目前我看到的最优雅的上下文隔离方案。
而且，这些框架不是互斥的。
混合使用的可能性
说实话，纯用一种框架可能不是最优解。我自己的实践中，Superpowers 的 brainstorming → design → plan 流程在前期非常好用，但 spec 的写法上我更倾向于 OpenSpec 那种 delta 风格——不是因为全量 spec 不好，而是真实项目里你改的东西永远是局部的，写全量 spec 的性价比太低。
如果你用的是 GSD 做上下文管理，完全可以在每个 wave 内部用 Superpowers 的 TDD 流程保证质量。BMAD 的角色扮演也可以在 Superpowers 的 design 阶段引入，让 AI 用不同角色的视角审视同一个设计。
这不是二选一的问题，更像是搭乐高——每个框架解决一个特定层面的问题，你可以按自己的场景组合。
最后说两句
这波 AI 编程框架的出现，本质上是对 vibecoding 的一次集体反思。大家都意识到，让 AI 写出能用的代码不难，难的是让 AI 持续地、可靠地、可预期地写出能用的代码。而"持续可靠可预期"这三个词，恰恰是软件工程这门学科花了几十年试图解决的问题。
这些框架各自从不同的角度给出了答案：BMAD 说你要有团队流程，SpecKit 说你要有规格文档，GSD 说你要管理好上下文，Superpowers 说你要有测试。
没有哪个答案是完美的，但每一个都比"凭感觉写 prompt"往前走了一大步。
对我自己来说，我目前的选择是 Superpowers + OpenSpec 风格 spec + 适度引入 GSD 的上下文隔离思路。这个组合还在磨合，但大体上让我觉得——终于不再是自己在跟一个不可靠的 AI 较劲了，而是有一套系统在帮我管着它。
就够了。