前言
当 OpenSpec、Superpowers、GStack、GSD、Agent Skills 同时摆在你面前……到底该选哪个？还是说，我们都被”工具焦虑”绑架了？
你是否也遇到了这些情况？当前ai工具每天都在诞生，今天学了工具A,每天又出来工具B,然后又去学习了，之后发现自己一直在学习工具X的路上，明显已经是工具学习焦虑症FOMO。
一、一场”AI Agent 框架狂欢”
2026 年的 AI 编程圈，正在经历一场前所未有的”框架大爆炸”。
如果你刷过Github、YouTube、B 站或者知乎，大概率被这些名字轰炸过：
•OpenSpec — Spec-Driven Development（规格驱动开发），Propose → Apply → Archive 三阶段工作流
•Superpowers — 14+ 可组合技能，7 阶段工程流程（头脑风暴 → 规格 → 计划 → TDD → 子代理开发 → 审查 → 清理），GitHub 11.7 万星
•GStack — YC CEO Garry Tan 出品，模拟完整软件团队（CEO、QA、工程师），6 个自定义斜杠命令切换角色
•GSD（Get Sh*t Done） — 三阶段”计划-执行-验证”框架，强调在新鲜上下文窗口中运行每个阶段
•Agent Skills — Google Gemini 团队主管 Addy Osmani 开源，20 个核心工程技能，覆盖软件开发生命周期 6 大阶段，一周狂揽 2 万星
更夸张的是，教程圈开始搞”组合拳”了：
“GStack + GSD + Superpowers 三合一工作流，让 Claude Code 无敌！”
“OpenSpec + Superpowers 强强联合，AI 编程新范式！”
YouTube上这类视频播放量动辄十几万，标题一个比一个炸裂——“Workflow Is Insane!”、“Make Claude Code Unstoppable”、“三大框架让 AI 编程起飞”。
看起来，AI 编程的终极答案就是：装得越多，写得越快。
但等等。
大家或者你自己你有没有想过——
我们真的需要这么多工具吗？
真的需要吗？
每个都需要了解？
非学不可？
需要懂得这么多吗？
二、这些工具到底在解决什么问题？
先别急着站队。让我们先搞清楚：这些框架到底在解决什么痛点？
2.1 核心痛点：AI 编程的”最短路径陷阱”
Addy Osmani 在介绍 Agent Skills 时说了一句非常精准的话：
“AI coding agents take the shortest path to done”——AI 编程助手会走最短路径来完成你给的任务，而这条最短路径，通常意味着跳过规格说明、测试和代码审查。
这就是所有框架的共同敌人。
想象一下你直接用 Claude Code 或 Cursor 写代码的体验：
1.你给了一个需求：“做一个用户登录功能”
2.AI 三下五除二写完了——看起来完美
3.但你没让它写测试、没让它做安全审查、没让它考虑边界情况
4.上线后出了问题，调试时间比写代码时间长 10 倍
这就是所谓的 “Vibe Coding”（氛围编程）——靠感觉和连续对话来驱动 AI， hoping it “gets the vibe right”。
所有上述框架，本质上都在做同一件事：给 AI 套上缰绳，让它按资深工程师的方式工作。
2.2 五大工具的”核心主张”对比
| 工具 | 核心主张 | 解决什么问题 | 类比 |
| OpenSpec | 先写规格，再写代码 | AI 不理解需求就动手 | 建筑师先画蓝图再施工 |
| Superpowers | TDD + 分阶段执行 | AI 跳过测试直接写代码 | 先写用例再编码 |
| GStack | 角色切换（CEO/QA/工程师） | AI 缺少全局视角 | 一个团队各司其职 |
| GSD | 新鲜上下文窗口 | AI 聊久了就”失智” | 每次任务开新会话 |
| Agent Skills | 工程最佳实践编码化 | AI 不懂行业规范 | 给 AI 一本工程师手册 |
看出来了没？它们的终极目标是一致的——让 AI 像资深工程师一样思考。
区别只在于路径不同：
•OpenSpec 走”规格先行”路线
•Superpowers 走”测试驱动”路线
•GStack 走”角色扮演”路线
•GSD 走”上下文管理”路线
•Agent Skills 走”技能包”路线
三、组合使用的代价：被忽略的”隐性成本”
教程告诉你”三个框架一起用更强大”，但没人告诉你代价是什么。
3.1 认知开销：你是在编程还是在学工具？
为了使用 GStack + GSD + Superpowers 组合，你需要：
•学习 GStack 的 6 个斜杠命令（/plan-ceo-review, /architecture-review, /gstack-ship…）
•学习 GSD 的 3 阶段流程（/gsd:new-project, /gsd:verify…）
•学习 Superpowers 的 14+ 技能模块和 7 阶段工作流
•理解它们之间如何衔接和配合
对于简单任务，配置和学习这些工具的时间，可能比你直接写代码还长。
就像为了切一个土豆，你先把整个厨房的刀具都磨了一遍。
3.2 Token 消耗：隐形的”吞金兽”
这些框架的工作流有一个共同特征：频繁运行”计划 → 生成 → 自检 → 重试”循环。
根据实测数据：
•GSD 这种强调完整流程的框架，token 消耗可能是 Superpowers 的 5-7 倍
•组合使用时，每个框架都会产生额外的”计划文档”和”审查报告”
•长上下文带来的不仅是费用问题，还有响应迟滞
一位开发者在 Reddit 上吐槽：
“我用 GSD 跑一个小功能，token 费用够我喝一个月咖啡了。
而且 AI 在超长上下文中越来越’笨’，前面说的话后面就忘了。”
3.3 “感觉快，实际慢”的错觉
2026 年的实证研究揭示了一个反直觉的数据：
•开发者感觉自己用 AI 编程速度提升了 20%-40%
•但实际项目完成速度的测量显示，反而降低了 19%原因？
•AI 生成代码的速度确实快，但代码审查时间增长了 91%
•”看起来正确”的代码往往逻辑有误，调试复杂度成倍增加
•代码流失率（Code Churn）翻倍——写了改，改了删
这就是所谓的 Perception Gap（感知鸿沟）：AI 让你感觉自己在飞速前进，但实际上你可能在原地打转。
3.4 技术债务海啸
AI 工具容易产生”盲目信任”危机。当你用一套复杂框架让 AI “自主编程”时：
•如果 AI 误解了业务逻辑，它会以极高速度生成整套错误的架构
•AI 擅长写函数片段，但在处理大型系统时引入”重复抽象”和”混乱的所有权”
•技术债务增加 30%-41%
一位台湾开发者在 Threads 上的吐槽很真实：
“如果你还在用 GSD、Superpowers、gstack，项目烂掉是迟早的。GSD 慢了一大堆，但 Bug 也是一大堆。
Superpowers 在大 feature 上很有价值，但在小 task 上就会变阻碍。”
四、拆解”框架神话”：什么在起作用，什么是噪音
让我们冷静下来，剥离营销话术，看看这些框架的真正价值和过度设计分别是什么。
4.1 真正有价值的核心理念（通用！）
无论哪个框架，以下理念是真正被验证有效的：
① 先想清楚再动手（Spec-First）
在写代码之前，先明确需求、设计和边界条件。这不是 AI 时代的发明——这是软件工程 50 年来的铁律。AI 只是让这个步骤更加必要，因为 AI 不会主动问你”你确定要这样吗？”
② 测试先行（TDD）
先写测试用例，再写实现代码。Superpowers 把这个作为核心强制要求。这不是 AI 专属——这是 XP（极限编程）20 年前的实践。
③ 上下文管理
不要让 AI 在一个超长对话里干完所有事。GSD 的”每个阶段开新会话”思路是对的——AI 的注意力是有限的。
④ 审查关卡（Review Gates）
在关键节点停下来检查。GStack 的”CEO Review”、”Security Review”本质就是这个。这是 CI/CD 的思想迁移到 AI 编程。
⑤ 文档与代码同步
OpenSpec 的”活文档”理念——规格文档不是写完就扔的，而是和代码一起演进的。
4.2 可能是”过度设计”的部分
① 角色扮演（Persona）
GStack 让你切换 CEO、QA、工程师角色。听起来很酷，但实际上——你就是那个 CEO，你只需要在关键节点停下来思考”这个架构合理吗？”就行，不需要 AI 扮演另一个 CEO 来告诉你。
② 过度流程化
Superpowers 的 7 阶段流程对大型项目有价值，但对一个”给按钮加个动画”的小任务来说，走完 7 个阶段比直接写代码还慢。工具应该适配任务规模，而不是反过来。
③ 框架组合迷信
“三个框架一起用更强大”——这个逻辑的潜台词是”每个框架都不完整”。但如果每个框架都在解决同一个核心问题的不同侧面，选一个最契合你思维方式的就够了。
五、我的建议：精简到本质
基于对市面上主要框架的调研和批判性分析，我给出以下建议：
5.1 一个核心认知
你要掌握的是”理念”，不是”工具”。
所有框架的核心理念可以浓缩为一句话：
“在让 AI 写代码之前，先让它想清楚；在让它交付之前，先让它验证。”
这就够了。你不需要装任何框架就能做到这一点——你只需要在 prompt 里加上这两句话：
这其实就是 OpenSpec + Superpowers + GSD 的核心思想，但只需要 4 行 prompt。不需要哪些乱七八糟的ai agent 工具的。
一次不行，那么多轮对话其实也可以解决问题的。
5.2 按任务规模选择策略
| 任务规模 | 推荐策略 | 是否需要框架 |
| 小任务
（改 bug、加个小功能、写脚本） |
直接对话，加上”先想后写”的 prompt | ❌ 不需要 |
| 中等任务
（新模块、API 开发、页面重构） |
选一个框架（推荐 OpenSpec 或 Agent Skills） | ✅ 选一个 |
| 大项目
（全新应用、架构重构） |
一个主框架 + 手动补充关键环节 | ✅ 一个主框架 |
| 团队协作 | 统一框架 + CI/CD 集成 | ✅ 统一选一个 |
5.3 如果一定要选，怎么选？
选框架就像选 IDE——没有绝对最好的，只有最适合你的。
•如果你是一个喜欢先规划再动手的人 → OpenSpec（规格先行，最符合传统工程师思维）
•如果你是一个测试驱动信仰者 → Superpowers（TDD 强制执行，质量最高但最慢）
•如果你经常和 AI 聊着聊着就乱了 → GSD（上下文管理最强）
•如果你想要最轻量、最灵活 → Agent Skills（技能包模式，按需加载）
不要全选。 选一个，用熟，比什么都强。
5.4 最高级的”框架”是你自己的工程判断
说到底，这些框架都是在试图编码资深工程师的判断力。但框架再完善，也无法替代你作为开发者的：
•对业务逻辑的理解——AI 不知道你的用户是谁
•对技术选型的权衡——AI 不知道你的团队擅长什么
•对优先级的判断——AI 不知道这个功能是否真的值得做
框架是拐杖，不是腿。 当你理解了核心理念，你完全可以扔掉框架，用自己的方式实践同样的原则。
六、结语：回归本质
AI 编程工具圈正在经历一个典型的”技术成熟度曲线”：
1.技术触发（OpenSpec、Superpowers 等框架出现）
2.期望膨胀期（“三合一工作流无敌了！”）
3.泡沫破裂低谷期（“太复杂了，Bug 一堆，token 烧钱”）← 我们可能在这里
4.稳步爬升复苏期（人们回归本质，找到适合自己的方式）
5.生产成熟期（AI 编程成为像 Git 一样的基础设施）
在期望膨胀期，人们容易陷入”工具焦虑”——总觉得”我是不是漏了什么神器？”
但真相是：最好的 AI 编程工作流，是你能够持续执行的那一个。
不是最复杂的那一个，不是最”工程化”的那一个，不是 YouTube 播放量最高的那一个。
是你用起来顺手、能坚持、能产出结果的那一个。
所以，放下”全都要”的执念。理解核心理念，选一个顺手的工具（甚至不用工具），开始写代码。
毕竟，代码是写出来的，不是配出来的。
附录：五大工具速查表
| 工具 | GitHub Stars | 定位 | 最佳场景 | 学习成本 | Token 消耗 |
| OpenSpec | ~30k | 规格驱动开发 | 中大型项目、已有代码库 | 中 | 低 |
| Superpowers | ~117k | TDD + 分阶段执行 | 对质量要求高的大型功能 | 高 | 中 |
| GStack | ~50k | 角色切换 + 治理 | 需要多视角审查的项目 | 高 | 高 |
| GSD | ~35k | 计划-执行-验证 | 独立功能开发 | 中 | 极高 |
| Agent Skills | ~19k | 工程技能包 | 灵活按需使用 | 低 | 低 |
⚠️ 注：Stars 数据为 2026 年 5 月近似值，仅供参考。
文章来自：51CTO
