| 编辑推荐: |
本文主要介绍了AI
Coding实践｜从OpenSpec、SuperPower、Gstack到RalphLoop：四大框架如何让AI编程起飞相关内容
。希望对你的学习有帮助。
本文来自于微信公众号ThinkingAgent，由火龙果软件Alice编辑，推荐。 |
|
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 的不同层面，它们不是竞争关系，而是可以堆叠的互补层。
| 维度 |
OpenSpec |
Superpowers |
Gstack |
RalphLoop |
| 核心层 |
Spec 层 |
流程层 |
工作流层 |
架构层 |
| 核心隐喻 |
Git for specs |
方法论即代码 |
认知换挡 |
Bash 循环 |
| 解决的痛点 |
意图漂移、上下文衰减 |
纪律缺失 |
认知混叠 |
上下文退化 |
| GitHub Stars |
59.4k |
247k |
121k |
技术形态20.9k(主实现) |
| 20.9k(主实现) |
CLI+Markdown |
14 个 SKILL.md |
23 个技能+8 工具 |
Bash 循环模式 |
| 自动化程度 |
半自动 |
技能触发 |
人工驱动 |
全自动 |
| 适用阶段 |
需求定义 |
开发执行 |
全生命周期 |
无人值守 |
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 管理代码一样管理。目录结构如下：
project_root/
└── openspec/
├── project.md
# 全局上下文
├── specs/
# 真理来源——当前系统行为
│
├── auth-login/spec.md
│
└── checkout-cart/spec.md
└── changes/
#
进行中的proposals
├── add-oauth-login/
│ ├── proposal.md # 为什么和做什么
│ ├── design.md # 技术方案
│ ├── tasks.md # 实现清单
│ └── specs/ # spec增量:
ADDED/MODIFIED/REMOVED
└── archive/ # 已完成的变更（不可变）
|
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 示例：
###
Requirement: Session expiration
- The system SHALL expire
sessions after a configured duration.
+ The system SHALL support
configurable session expiration periods.
#### Scenario: Extended
session with remember me
+ - GIVEN user checks "Remember
me" at login
+ - WHEN 30 days have passed
+ - THEN invalidate the
session token |
这种设计使 OpenSpec 在 brownfield（存量代码库）场景中表现突出。Hashrocket
的 Vinicius Negrisolo 在生产 Rails 应用上实测：OpenSpec 每个功能的
spec 约 250 行，而 Spec Kit 约 800 行，减少的冗长使 review 更容易。
四阶段工作流
| 阶段 |
命令 |
做什么 |
| Propose |
/opsx:propose |
创建隔离工作区，生成 proposal/design/tasks/spec delta |
| Define |
openspec validate |
静态分析 spec 语法和场景错误 |
| Implement |
/opsx:apply |
AI 严格按 spec 执行 tasks.md |
| Archive |
/opsx:archive |
delta 合并回 specs/，proposal 移入 archive |
一个完整的 Dark Mode 工作流只需要四行对话：
You:
/opsx:propose add-dark-mode
AI: Created openspec/changes/add-dark-mode/
proposal.md,
specs/, design.md, tasks.md ready!
You: /opsx:apply
AI: ✓ Add theme context
provider ✓ Create toggle ✓ CSS variables ✓ localStorage
You: /opsx:archive
AI: Archived. Specs
updated. Ready for next feature.
|
实测数据
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.
|
（先写了代码？删掉。重来。没有例外。）
红旗清单列出了代理最可能用来跳过规则的合理化借口：
| 借口 |
现实 |
| 「太简单不用测试」 |
简单代码也会坏。测试只需 30 秒 |
| 「我之后再测」 |
后写的测试立即通过，证明不了什么 |
| 「删除 X 小时工作是浪费」 |
沉没成本谬误。无法信任的代码才是技术债 |
阶段工作流
Superpowers 的工作流就是技能按顺序执行：
① Brainstorm → ② Git Worktree
→ ③ Written Plan → ④ Subagent-Driven Implementation
→ ⑤ TDD → ⑥ Code Review → ⑦ Finish
每个阶段都有硬性门禁：设计未批准不写代码、计划未完成不实现、测试未先失败就删除重来、审查未通过就修复重审。
子代理驱动开发
这是 Superpowers 最独特的机制。每个任务分派一个全新的子代理（隔离上下文），实现后由另一个子代理审查，审查通过后再分派下一个任务。
模型选择策略也值得注意：
| 任务类型 |
模型层级 |
| 机械实现（隔离函数、清晰 spec） |
最便宜/最快 |
| 集成与判断（多文件协调） |
标准 |
| 架构与设计 |
最强可用 |
| 最终全分支审查 |
最强可用 |
核心原则：Turn count beats token
price.（轮次数比 token 价格更重要。）最便宜模型在多步骤工作上经常需要
2-3 倍的轮次。
真实案例：chardet 7.0.0
chardet 是 Python 的自动字符编码检测库，月下载量
1.3 亿次。Jesse Vincent 用 Superpowers 方法论驱动了 chardet
的从零重写：
| 指标 |
chardet
6.x |
chardet
7.0.0 |
| 速度 |
基线 |
41x 更快 |
| 准确率 |
94.5% |
96.8%（2179 测试文件） |
| 支持编码 |
— |
99 种 |
| 运行时依赖 |
— |
零 |
后续版本 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：
while
:; do cat PROMPT.md | claude-code ; done
|
Huntley 说：这就是 Ralph 的美妙之处——这个技术在一个不确定的世界中是确定性差的。
四大核心原则
| 原则 |
含义 |
| Iteration > Perfection |
不追求首次完美，让循环来精炼 |
| Failures Are Data |
失败是可预测的、有信息量的 |
| Operator Skill Matters |
成功取决于写好提示词 |
| Persistence Wins |
持续尝试直到成功 |
关键创新：每次迭代使用全新上下文窗口。
这直接解决了 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 阶段：知识积累飞轮
| 维度 |
回答的问题 |
| 计划有效性 |
什么成功了？什么需要调整？ |
| 测试发现 |
开发期间遗漏了什么问题？ |
| 常见错误 |
出现了什么 Agent 错误模式？ |
| 可复用模式 |
什么最佳实践值得固化？ |
学习成果的嵌入路径：系统提示词(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 官方插件的用法：
/ralph-loop
"Build a REST API for todos. Requirements: CRUD,
validation, tests. Output
<promise>COMPLETE</promise> when
done."
--completion-promise "COMPLETE"
--max-iterations 50 |
机制：Stop hook 拦截 Claude 的退出尝试 → 将相同提示词重新喂回
→ 循环直到完成。
真实案例
| 案例 |
详情 |
| CURSED 编程语言 |
Huntley 用 Ralph 构建了全新 esoteric 语言，历时 3 个月 |
| $50k 合同→$297 |
价值 5 万美元的 MVP 合同（含测试+审查）仅花费 297 美元 API 费用 |
| 浏览器 Excel 克隆 |
Matt James 用 Ralph 约 1 小时构建了功能性 Excel 克隆 |
| YC Hackathon |
一夜之间发布 6 个仓库 |
| .NET 10 应用 |
Ben Abt 用 Ralph+Copilot CLI 自主创建完整.NET 10
控制台应用 |
七、组合使用：从 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）：
#
Phase 1: OpenSpec定义spec
openspec init &&
/opsx:propose add-user-auth
# Phase 2: 生成任务列表（Superpowers
writing-plans）
# Plan中每个任务2-5分钟，含测试代码和验证步骤
# Phase 3: RalphLoop循环执行
while read task; do
echo "$task" | claude
--skill superpowers:tdd
npm test &&
git commit -am "feat: $task" || git checkout
.
done < tasks.md
# Phase 4: Gstack /review
+ /ship
claude --skill gstack:review
&& claude --skill gstack:ship
|
组合策略矩阵
| 场景 |
推荐组合 |
原因 |
| 个人项目快速原型 |
RalphLoop 单用 |
循环即一切，走开就回来审查 commits |
| 团队产品开发 |
OpenSpec+Gstack |
Spec review + 多角色审查 + 跨模型验证 |
| 严格 TDD 项目 |
OpenSpec+Superpowers |
Spec 先行 + TDD 铁律 + 子代理隔离 |
| 无人值守夜间开发 |
OpenSpec+Superpowers |
Spec 先行 + TDD 铁律 + 子代理隔离 |
关键注意事项
不要同时运行多个主框架。 Superpowers
和 Gstack 的技能系统可能冲突。选择一个主框架，另一个做补充。
RalphLoop 的安全性。 每次迭代都给
Agent 完全权限，务必在 Docker 沙箱中运行，或使用--dangerously-skip-permissions时配合文件系统隔离。
Spec 质量是上游瓶颈。 mejba.me
的评测总结得最好：「Spec 质量是上游瓶颈。其他一切都在放大那里的决定——无论好坏。」
如果 spec 写不好，RalphLoop 只会让你更快地生产出错误的产品。
八、数据对比与选型指南
增长数据
| 框架 |
2026.3 |
2026.5 |
2026.7 |
月均增长 |
| Superpowers |
89k |
174k |
247k |
~40k/月 |
| Gstack |
— |
— |
121k |
48h 内破 10k |
| OpenSpec |
~25k(npm) |
~110k(npm) |
~207k(npm) |
~45k/月 |
| RalphLoop |
— |
— |
189k 安装 |
— |
选型决策树
你的项目是什么阶段？
- 全新项目（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，已经不是「能不能用」的问题，而是「怎么用好」的问题。这四个框架，就是目前最好的答案。 | 
订阅
