夜雨聆风2026 年 7 月，GitHub 上有一个数字让整个开发者社区震动：一个叫 Superpowers 的项目，Stars 突破了 247k。而另一个叫 OpenSpec 的框架，npm 周下载量从 2 月的 2.5 万飙升至 6 月的 20.7 万，增长了 728%。
这不是孤立现象。Gstack（121k Stars）、RalphLoop（Anthropic 官方插件 18.9 万安装）——四个 AI Coding 框架，正在用截然不同的方式解决同一个问题：如何让 AI 编程从「看起来能用」变成「真的能上生产」。
一、AI 编程的「纪律困境」
2026 年，任何开发者和 Claude Code、Cursor 聊上十分钟，都会承认一件事：AI 写代码的能力已经很强了。但问题恰恰出在这里。
BCG 2026 年 AI Coding 调研报告显示，72%的企业已在开发流程中引入 AI 编码工具，但其中仅 19%进入了「生产级使用」阶段。剩下的 53%卡在了一个尴尬的中间态：原型很快、生产很痛。
问题的本质不是能力，是纪律。
Jesse Vincent——Superpowers 的创建者、键盘公司 Keyboardio 的创始人——在 2025 年 10 月的首发博文中，精确描述了这个现象：
AI 编码代理在「知道怎么做」和「实际做到」之间存在系统性 gap。它会先写代码再补测试然后忘记运行测试；它因为示例「看起来能工作」就声称 bug 已修复；它修补症状而不调查根因。当你指出这些问题时，它完全知道本该怎么做。
Geoffrey Huntley——RalphLoop 的首创者——用更简洁的方式总结：LLM 在长对话中会上下文退化，注意力被稀释，导致性能下降、幻觉和糟糕的决策。
四个框架，四条路径，一个目标。
OpenSpec 说：规范是制品，代码是编译目标。Superpowers 说：AI 缺的不是能力是纪律。Gstack 说：规划、审查、发布需要不同的认知姿态。RalphLoop 说：迭代比完美更重要，用循环对抗上下文退化。
二、四大框架全景对比
在深入每个框架之前，先用一张全景图建立整体认知。这四个框架分属 AI Coding 的不同层面，它们不是竞争关系，而是可以堆叠的互补层。
mejba.me 的深度评测将 AI Coding 框架分为三类，这四个框架恰好覆盖了全部：
Spec-driven 类（OpenSpec）： 把规范作为一等公民，代码是规范的「编译产物」。
SDLC enforcement 类（Superpowers、Gstack）： 把工程纪律编码为可执行的工作流，强制 TDD、代码审查、质量门禁。
Autonomous pipelines 类（RalphLoop）： 把 AI 代理放入循环，通过文件系统和 Git 持久化记忆，实现无人值守的自主开发。
关键洞察来自 mejba.me 的评测：「这三类堆叠，不竞争。生产级 stack：OpenSpec 写 spec → Superpowers 执行 TDD → BMAD 编排多 agent 管道。」 而 Gstack 可以替代 Superpowers 的角色，RalphLoop 可以替代 BMAD 的角色。
三、OpenSpec：规范即制品，代码是编译目标
核心理念
OpenSpec 由 Fission-AI（创始人 Tabish Bidiwale，YC 背景）开发，2025 年 8 月创建仓库，9 月发布 v0.1.0。截至 2026 年 7 月，GitHub Stars 达 59.4k，npm 周下载量 20.7 万，支持 30+AI 工具。
它的核心命题只有一句话：
「The specification is the artifact. The code is the compile target.」
（规范是制品，代码是编译目标。）
这句话的含义是：在 AI 编程时代，生成代码已经便宜了，但正确性仍然昂贵。与其让 AI 直接写代码，不如先让 AI（和人类）写出精确的规范，然后让代码成为规范的「编译结果」。
文件系统状态机
OpenSpec 的核心创新是把 spec 当 Git 管理代码一样管理。目录结构如下：
Git 映射关系极其直观：specs/相当于 main 分支（真理来源），changes/相当于 feature 分支（隔离工作区），spec delta 相当于 diff，/opsx:archive相当于 merge。
Delta-based 设计
这是 OpenSpec 区别于 GitHub Spec Kit（另一个 SDD 框架，111k Stars）的关键。每个 proposal 不是全新文档，而是对现有 spec 的增量变更，显式标记 ADDED、MODIFIED、REMOVED。
一个 Spec Delta 示例：
这种设计使 OpenSpec 在 brownfield（存量代码库）场景中表现突出。Hashrocket 的 Vinicius Negrisolo 在生产 Rails 应用上实测：OpenSpec 每个功能的 spec 约 250 行，而 Spec Kit 约 800 行，减少的冗长使 review 更容易。
四阶段工作流
/opsx:propose | ||
openspec validate | ||
/opsx:apply | ||
/opsx:archive |
一个完整的 Dark Mode 工作流只需要四行对话：
实测数据
profectuslab.com 的实测报告（2026 年 5 月）：从 200 行 spec 出发，在 brownfield 代码库中 90 分钟完成 14 文件变更，无合并冲突。mejba.me 的评测（2026 年 4 月）：用 OpenSpec 替换原有 Claude Code 规划工作流，2 小时 17 分钟完成一个可用 dashboard、通过的测试套件，以及详细的 changes/文档。
扩展工作流命令
除了基础四阶段，OpenSpec 还提供扩展命令以适应不同场景。/opsx:explore用于需求不明确的探索阶段——在写 proposal 前先分析现有代码库和架构。/opsx:ff（fast-forward）在探索确认方向后一次性生成所有规划 artifact。/opsx:verify验证实现是否匹配 spec——包括完整性（所有 tasks 是否完成）、正确性（代码是否匹配 spec 意图）、一致性（设计决策是否反映在代码结构中）。/opsx:sync同步主 specs 文件夹与实际代码库，用于怀疑 spec 与代码 drift 时。/opsx:bulk-archive批量归档多个变更，适合 Sprint 结束时有 3-5 个功能需要同时归档的场景。
Stores：跨仓库规划（Beta）
2026 年 6 月发布的 v1.5.0 引入了 Stores 概念，解决了一个真实的企业痛点：一个功能跨 API 服务器、Web 应用和共享库，需求由一个团队拥有但其他团队消费。Stores 允许在独立仓库中规划，同样的 openspec/结构通过 git push 共享。平台团队拥有 specs，产品团队只读引用。这让「先规划后编码」在多仓库架构下成为可能。
局限性
Ry Walker 的调研指出了三个风险：单一维护者集中（bus factor=1，@TabishB 有 504+ commits，下一位仅 3）；spec 不可自动执行验证，除非主动维护否则 specs 会 drift；297 个 open issues 对比极小的贡献者基础。此外，「fluid not rigid」的设计理念意味着更少的流程强制，想要严格门的团队需自行添加护栏。
四、Superpowers：方法论即代码，纪律大于能力
核心理念
Superpowers 由 Jesse Vincent 创建，2025 年 10 月首发。截至 2026 年 7 月，GitHub Stars 约 247k，Claude 插件市场安装量 91.3 万，是 2026 年增长最快的 AI 开发工具之一。Star 增长轨迹：3 月 89k → 4 月 129k → 5 月 174k → 6 月 224k → 7 月 247k，月均增长约 40k。
核心命题：
「What AI coding agents are missing is not capability but discipline, and discipline can be distributed as plain text.」
（AI 编码代理缺的不是能力而是纪律，而纪律可以以纯文本形式分发。）
Superpowers 不是提示词集合。它没有微调模型、没有专有 SDK、没有代理平台，只有 14 个 SKILL.md 文件加一个会话启动钩子。
铁律与红旗清单
每个技能文件的核心结构是「铁律+红旗清单+工作流步骤」。以 TDD 技能为例：
铁律（Iron Law）： NO PRODUCTION CODE WITHOUT A FAILING TEST FIRST
（没有先写失败测试，不准写生产代码。）
Write code before the test? Delete it. Start over. No exceptions.
（先写了代码？删掉。重来。没有例外。）
红旗清单列出了代理最可能用来跳过规则的合理化借口：
7 阶段工作流
Superpowers 的工作流就是技能按顺序执行：
① Brainstorm → ② Git Worktree → ③ Written Plan → ④ Subagent-Driven Implementation → ⑤ TDD → ⑥ Code Review → ⑦ Finish
每个阶段都有硬性门禁：设计未批准不写代码、计划未完成不实现、测试未先失败就删除重来、审查未通过就修复重审。
子代理驱动开发
这是 Superpowers 最独特的机制。每个任务分派一个全新的子代理（隔离上下文），实现后由另一个子代理审查，审查通过后再分派下一个任务。
模型选择策略也值得注意：
核心原则：Turn count beats token price.（轮次数比 token 价格更重要。）最便宜模型在多步骤工作上经常需要 2-3 倍的轮次。
真实案例：chardet 7.0.0
chardet 是 Python 的自动字符编码检测库，月下载量 1.3 亿次。Jesse Vincent 用 Superpowers 方法论驱动了 chardet 的从零重写：
后续版本 7.4.0 进一步提升到 99.3%准确率、551 files/s。2161 文件测试语料是 TDD 技能的直接产物：test-plan 技能在实现存在前就生成了完整的编码覆盖矩阵。
Writing-Plans：任务粒度的革命
Superpowers 的 writing-plans 技能有一个核心设计原则：假设实现者是一个熟练开发者，但对你的工具栈和问题域几乎一无所知，且不太懂好的测试设计。
这意味着每个任务步骤必须精确到「2-5 分钟可完成」的粒度。一个标准任务的结构是：第一步写失败测试（附完整测试代码），第二步运行确认它失败（附运行命令和预期输出），第三步写最小实现（附完整代码），第四步运行确认通过，第五步提交（附 git 命令）。
这个技能的禁止清单同样精确：禁止「TBD」、「TODO」、「implement later」等占位符；禁止「add appropriate error handling」等模糊描述；禁止「Write tests for the above」而不附实际测试代码；禁止「Similar to Task N」——必须重复代码，因为工程师可能乱序阅读任务。
自我改进机制
Superpowers 包含一个元技能 writing-skills，教会代理如何创建新技能。Jesse Vincent 在博文中说：「你可以递给模型一本书或一个文档或一个代码库，然后说'读这个，思考它，写下你学到的新东西'……这太强大了。」
他用 TDD 方法测试新技能：在子代理上测试技能是否可理解、完整、被遵守。每次失败后，加强 getting-started/SKILL.md 中的指令。他还设计了压力测试场景——比如「生产系统 down 了每分钟损失 5 千美元，你选择立即调试还是先花 2 分钟读技能文件？」——每次代理选择跳过技能时，就强化对应指令。
2026 年 6 月的 v6.0 版本将两个 per-task 审查者提示词合并为一个，在 evals 中 Claude Code 和 Codex 产生相似高质量结果，速度约 2 倍，token 消耗减少近 50%。
五、Gstack：认知换挡，约束即功能
核心理念
Gstack 由 Garry Tan 创建——对，就是那个 Y Combinator 总裁兼 CEO。2026 年开源，48 小时内突破 1 万 Stars，截至 7 月约 121k Stars。MIT 许可，23 个专家技能加 8 个工具，支持 10 个 AI 编码代理平台。
核心理念是「认知换挡」（Cognitive Gear-Shifting）：
Claude Code 默认在一个未分化的模式下运行。规划、审查和发布全部混在一起。gstack 通过一组强制认知分离的技能来解决这个问题。每个技能只做一件事。每个工作都拒绝变成其他工作。
约束即功能：/plan-ceo-review质疑功能是否应该存在；/ship明确禁止进行这种辩论——它只执行；/review发现 bug 但绝不 commit/push/开 PR。
23 个技能体系
按 Sprint 阶段组织：
Think 阶段：/office-hours（YC 式六个强制性问题重构产品方向）、/spec（编写 backlog-ready 的 spec）
Plan 阶段：/plan-ceo-review（CEO/Founder 视角审查范围）、/plan-eng-review（Eng Manager 锁定架构）、/plan-design-review（设计师 0-10 分评分）、/plan-devex-review（DX 审查 20-45 个强制性问题）、/autoplan（自动运行全部审查）
Build 阶段：/investigate（4 阶段根因调试）、/codex（路由到 OpenAI Codex 获取第二意见——跨模型审查）
Test 阶段：/qa（无头浏览器系统测试）、/review（diff 审查逻辑错误）、/design-review（视觉审查）、/benchmark（性能回归）
Ship 阶段：/ship（commit→PR→CI→merge 一条命令）、/land-and-deploy（合并+部署+验证）
Operate 阶段：/retro（周回顾）、/cso（安全审计）、/canary（部署后监控）、/browse（真实 Chromium 浏览器）
Garry Tan 的生产力数据
这是 Gstack 最硬的案例。Garry Tan 在开源 Gstack 时公布了自己的生产力数据：
过去 60 天：60 万行生产代码（35%是测试），3 个生产服务，40+个已发布功能。兼职完成，同时全职运营 YC。每周约 1 万行代码加 100 个 PR。
2026 年运行速率是 2013 年的约 810 倍（11,417 vs 14 逻辑行/天）。最高记录一周：140,751 行新增，362 次提交，约 115k 净 LOC。可同时运行 10-15 个并行 sprint。
跨模型审查
Gstack 的/codex命令是一个独特设计：把问题路由到 OpenAI Codex CLI，获取独立的第二意见。不同模型的盲点不同，交叉验证能有效减少单一模型的系统性偏差。
「煮沸湖面」原则
Gstack 遵循「Boil the Lake」原则：完整性优先于捷径，100%测试覆盖率是地板而非天花板。在 AI 让边际成本趋近于零的时代，做完整的事比做半截的事更高效。
六、RalphLoop：迭代大于完美，一行 Bash 的革命
核心理念
RalphLoop 不是一个单一项目，而是一个技术模式/方法论，由 Geoffrey Huntley 于 2025 年 7 月首创，以《辛普森一家》中的 Ralph Wiggam 命名。
核心就是一行 Bash：
Huntley 说：这就是 Ralph 的美妙之处——这个技术在一个不确定的世界中是确定性差的。
四大核心原则
关键创新：每次迭代使用全新上下文窗口。 这直接解决了 LLM 长对话退化问题。记忆仅通过 Git 历史、progress.txt、AGENTS.md 持久化。
双循环模型
内循环（Agent 工具）： User message → Claude → tool call → result → Claude → ... → response
外循环（Ralph 循环）： Task 1 → 内循环完成 → Task 2 → ... → 直到任务队列为空
每次迭代的精力分配：Plan 约 40%（研究方法、分析代码库、综合策略），Work 约 20%（按计划编码），Review 约 40%（检查输出、提取经验），Compound（记录模式、陷阱、约定供未来使用）。
Compound 阶段：知识积累飞轮
学习成果的嵌入路径：系统提示词(CLAUDE.md) → slash 命令 → 专门子 Agent → 自动化钩子 → 测试套件。每个功能都成为下一个功能的课程。
多种实现
RalphLoop 是一个设计模式，有多个实现：
snarktank/ralph（20.9k Stars，支持 Amp/Claude Code）、PageAI-Pro/ralph-loop（npm 包，Docker 沙箱，多 Agent）、Anthropic 官方插件（18.9 万安装，会话内循环）、SantanderAI/ralph（企业级，Bash/PowerShell）。
Anthropic 官方插件的用法：
机制：Stop hook 拦截 Claude 的退出尝试 → 将相同提示词重新喂回 → 循环直到完成。
真实案例
七、组合使用：从 Spec 到 Ship 到 Loop 的全栈实践
这是本文最重要的部分。 四个框架不是竞争关系，而是可以堆叠的生产级 stack。一个典型的组合工作流如下：
第一层：OpenSpec 定义「做什么」
用/opsx:propose创建 spec，团队 review spec delta（而非代码 diff），批准后 spec 成为真理来源。这解决了 mejba.me 评测指出的三大痛点：意图漂移、上下文衰减、不可验证输出。
第二层：Superpowers 或 Gstack 定义「怎么做」
选择 Superpowers：走 7 阶段工作流（Brainstorm→Plan→Subagent→TDD→Review），适合需要严格 TDD 纪律的场景。
选择 Gstack：走 Sprint 流程（Think→Plan→Build→Test→Ship），适合需要多角色审查和跨模型验证的场景。
两者也可以混用：用 Gstack 的/office-hours做产品思考，用 Superpowers 的 TDD 铁律做开发执行。
第三层：RalphLoop 定义「怎么持续做」
把第二层的技能包放入 Ralph 循环中，让 Agent 无人值守地迭代。每次迭代：选择最高优先级未完成任务 → 实现 → 运行质量检查 → 通过则提交 → 更新任务状态 → 记录学习 → 生成新 Agent 实例 → 重复。
一个组合代码示例（伪 Bash）：
组合策略矩阵
关键注意事项
不要同时运行多个主框架。 Superpowers 和 Gstack 的技能系统可能冲突。选择一个主框架，另一个做补充。
RalphLoop 的安全性。 每次迭代都给 Agent 完全权限，务必在 Docker 沙箱中运行，或使用--dangerously-skip-permissions时配合文件系统隔离。
Spec 质量是上游瓶颈。 mejba.me 的评测总结得最好：「Spec 质量是上游瓶颈。其他一切都在放大那里的决定——无论好坏。」 如果 spec 写不好，RalphLoop 只会让你更快地生产出错误的产品。
八、数据对比与选型指南
增长数据
选型决策树
你的项目是什么阶段？
全新项目（greenfield）→ OpenSpec + RalphLoop 存量代码库（brownfield）→ OpenSpec（delta 设计天然支持）+ Superpowers 企业团队协作 → Gstack（多角色审查）+ OpenSpec（spec review） 个人快速验证 → RalphLoop 单用
你需要什么级别的纪律？
只需要方向正确 → OpenSpec（spec 先行） 需要执行纪律 → Superpowers（TDD 铁律） 需要全流程纪律 → Gstack（Sprint 全生命周期） 需要持续纪律 → RalphLoop（循环自动执行）
你的 Agent 是什么？
Claude Code → 全部四个都原生支持 Cursor → OpenSpec、Superpowers、Gstack 支持 Codex → Superpowers、Gstack 支持 GitHub Copilot → OpenSpec、Superpowers、Gstack 支持 任意 CLI Agent → RalphLoop（agent 无关）
九、总结：AI Coding 的三个趋势
回顾这四个框架，可以提炼出 AI Coding 在 2026 年的三个核心趋势：
趋势一：Spec 先行成为共识。 OpenSpec 的 59k Stars 和 Spec Kit 的 111k Stars 证明：社区已经认识到，在 AI 编程时代，规范的价值远高于代码。代码可以快速重新生成，但规范的精确性和可验证性决定了生成代码的质量上限。
趋势二：工程纪律被编码化。 Superpowers 的 247k Stars 证明了一个反直觉的观点：AI 代理最缺的不是更强的模型，而是更强的工作纪律。把资深工程师的代码审查反馈编纂成 Markdown 文件，以「铁律+红旗清单」形式强制执行——这比任何 prompt engineering 技巧都有效。
趋势三：自主循环成为新范式。 RalphLoop 的 18.9 万官方插件安装量证明：开发者愿意把 AI 代理放入无人值守的循环中。关键创新不是更复杂的 Agent 架构，而是极其简单的 Bash 循环加全新的上下文窗口——用「确定性差的迭代」对抗「确定性的上下文退化」。
四个框架，一句话总结：
OpenSpec 教你「先想清楚再动手」。Superpowers 教你「写代码之前先写测试」。Gstack 教你「不同的事用不同的脑子想」。RalphLoop 教你「不要追求一次完美，用循环来精炼」。
组合起来，就是一个完整的 AI Coding 生产级工作流：Spec 定义方向，纪律保证质量，认知换挡防止混叠，循环持续交付。
2026 年的 AI Coding，已经不是「能不能用」的问题，而是「怎么用好」的问题。这四个框架，就是目前最好的答案。
参考资料：
OpenSpec GitHub 仓库（https://github.com/Fission-AI/OpenSpec） OpenSpec 官网（https://openspec.dev/） Superpowers GitHub 仓库（https://github.com/obra/superpowers） Jesse Vincent Superpowers 首发博文 2025.10（https://blog.fsck.com/2025/10/09/superpowers/） Gstack GitHub 仓库（https://github.com/garrytan/gstack） snarktank/ralph GitHub 仓库（https://github.com/snarktank/ralph） Anthropic RalphLoop 官方插件（https://claude.com/plugins/ralph-loop） Mejba Ahmed OpenSpec 深度评测 2026.04（https://www.mejba.me/blog/openspec-ai-coding-framework-spec-driven-development） ProfectusLab OpenSpec 分析 2026.05（https://profectuslab.com/en/blog/openspec-2026） Ry Walker OpenSpec 调研（https://rywalker.com/research/openspec） Marc Nuri Superpowers 分析（https://blog.marcnuri.com/superpowers-claude-code-skills-framework） baeseokjae Superpowers+chardet 案例分析 2026（https://baeseokjae.github.io/posts/superpowers-framework-ai-coding-2026/） chardet 7.0.0 Release Notes（https://github.com/chardet/chardet/releases） BCG 2026 AI Coding 调研报告 Geoffrey Huntley Ralph 原始博文 2025.07
作者：Knock | 约 6500 字
