半年之后，规格驱动开发（SDD）框架格局重排：从 +863% 到 +18% 的分化

文章目录

• [一、先说清楚：SDD 到底解决什么问题](#一、先说清楚：SDD 到底解决什么问题)
• • [1.1 从 vibe coding 到规格](#1.1 从 vibe coding 到规格)
  • [1.2 为什么框架会大量涌现](#1.2 为什么框架会大量涌现)
• 二、OpenSpec：这半年的最大赢家
• • [2.1 数据与判断](#2.1 数据与判断)
  • [2.2 真正的设计亮点：spec delta](#2.2 真正的设计亮点：spec delta)
  • [2.3 一个绕不开的转折](#2.3 一个绕不开的转折)
• 三、BMAD：最重的那个，也活得最好
• • [3.1 生态而非框架](#3.1 生态而非框架)
  • [3.2 代价](#3.2 代价)
• [四、Spec Kit：营销声量与工程体感的落差](#四、Spec Kit：营销声量与工程体感的落差)
• • [4.1 它做对了什么](#4.1 它做对了什么)
  • [4.2 它被批评什么](#4.2 它被批评什么)
  • [4.3 最值得读的那份批评](#4.3 最值得读的那份批评)
• [五、失速的两个：Task Master 与 Agent OS](#五、失速的两个：Task Master 与 Agent OS)
• • [5.1 Task Master：商业化时机的教科书案例](#5.1 Task Master：商业化时机的教科书案例)
  • [5.2 Agent OS：主动收窄，未必是坏事](#5.2 Agent OS：主动收窄，未必是坏事)
• 六、名单外的三个选手
• • [6.1 Superpowers：不是 SDD，但解决了同一个问题](#6.1 Superpowers：不是 SDD，但解决了同一个问题)
  • [6.2 GSD：执行优先的另一极](#6.2 GSD：执行优先的另一极)
  • [6.3 Beads：给 agent 换一套记忆](#6.3 Beads：给 agent 换一套记忆)
• 七、最大的变量：编码工具自己长出了这些能力
• • [7.1 被吸收的功能清单](#7.1 被吸收的功能清单)
  • [7.2 这是不是意味着框架没意义了](#7.2 这是不是意味着框架没意义了)
• 八、怎么选：一份不打太极的建议
• • [8.1 按场景对号入座](#8.1 按场景对号入座)
  • [8.2 无论选哪个都建议做的四件事](#8.2 无论选哪个都建议做的四件事)
  • [8.3 一个最小可用的落地路径](#8.3 一个最小可用的落地路径)
• 九、结论：会过时，正是重点

同一个赛道，同样的六个月。一个框架的 star 数涨了 863%，另一个只涨了 18%。平均值是 +131%，看上去所有人都在增长；可平均值恰好掩盖了这轮竞赛里最重要的事实------分化。有人重写了自己，有人主动收窄了边界，有人在最热的时候选择商业化然后失速，还有一个玩家根本不在名单上：编码工具自己。

这篇文章是对规格驱动开发（Spec-Driven Development，以下简称 SDD）生态半年演进的一次完整复盘。参照对象是最初被放在一起比较的五个框架：BMAD、GitHub Spec Kit、OpenSpec、Task Master、Agent OS ，再加上这半年冒出来的三个边缘选手：Superpowers、GSD、Beads。文中的判断混合了公开仓库数据、社区讨论、以及真实工程团队的落地反馈，也包含足够多的反面意见------因为这个领域最不缺的就是「我们这套才是正确做法」的自信。

---

一、先说清楚：SDD 到底解决什么问题

1.1 从 vibe coding 到规格

2024 到 2025 年，AI 编码的主流形态是「对话式即兴编程」：你描述一个需求，模型给一段代码，不满意就再说一遍。这套玩法在单文件脚本、原型页面上效率惊人，但在有历史包袱的真实代码库里迅速崩塌，原因很朴素：

• 意图不持久。需求只存在于对话历史里，会话一关就蒸发。
• 上下文不可复现。同一个需求换个会话、换个人、换个模型，产出完全不同。
• 审查对象错位。人类 reviewer 面对的是几百行 diff，而真正需要确认的是「这个改动改变了系统的哪条行为约束」。
• 返工成本被低估。模型跑得快，跑错方向也快。

SDD 的核心主张是把「意图」从易失的对话搬进仓库里的持久化文件：先写规格，再由规格派生计划、任务，最后才生成代码。整条链路可以抽象成：

意图 → 显式规格 → 实现计划 → 任务分解 → 代码 → 验证证据

这条链路上每一环都是可 review、可 diff、可进 CI 的文本产物。规格不再是写完就扔的脚手架，而是与代码同源、同生命周期的资产。

1.2 为什么框架会大量涌现

一旦承认「规格是核心资产」，随之而来的问题就全是工程问题：规格放哪个目录、用什么模板、如何拆任务、任务状态存在哪里、多个 agent 并行时怎么避免互相踩、上下文窗口爆掉时如何续接。这些问题没有标准答案，于是每个人都写了一套自己的约定，加上 CLI 和 slash 命令包装一下，就成了一个「框架」。

本质上，这些框架都是同一类东西：给编码 agent 套的外壳（harness）。它们不训练模型，不改推理，只做三件事------注入约定、编排流程、管理上下文。理解这一点非常关键，因为它直接解释了后文最重要的那个趋势：当编码工具自己开始内置这三件事时，外壳的存在价值就会被压缩。

---

二、OpenSpec：这半年的最大赢家

2.1 数据与判断

+863%，五个框架里唯一「跑掉」的那个。仓库当前处于 6.6 万 star 量级，是这轮增长曲线最陡的一条。更有意思的是它拿下增长的方式：不是靠功能堆叠，而是靠减法。

v1 版本是一次显著的重写，方向完全一致地指向轻量化：

• 输出更小------生成的 markdown 体量明显下降；
• 结构更清晰------目录层级收敛，减少「文档丛林」；
• 不依赖 MCP，不需要 API key，安装即用。

# 安装
npm install -g @fission-ai/openspec@latest

# 在项目里初始化
openspec init

初始化后，仓库里会出现一个 openspec/ 目录，把「已生效的规格」和「进行中的变更」分开存放：

openspec/
├── specs/                # 系统当前的行为约束（真相）
│   └── auth-session/
│       └── spec.md
└── changes/              # 进行中的变更提案（增量）
    └── add-refresh-token/
        ├── proposal.md
        ├── tasks.md
        └── specs/
            └── auth-session/spec.md   # 只写 delta

2.2 真正的设计亮点：spec delta

OpenSpec 最值得抄的设计是变更以规格增量（spec delta）的形式表达，而不是直接改主规格。一个变更提案里，规格文件只描述这次改动对系统行为约束的增删改：

## Requirement: Session expiration
- The system SHALL expire sessions after a configured duration.

## Requirement: Token refresh (ADDED)
- The system SHALL issue a refresh token valid for 30 days.
- The system SHALL revoke all refresh tokens on password change.

这个设计的价值在 review 环节被放大到极致。传统 code review 里，reviewer 要从 diff 反推意图；有了 spec delta，reviewer 先读「系统的哪条规则变了」，再决定要不要下钻到代码。审查意图，而不只是审查代码------这句话是 OpenSpec 的口号，也确实是它增长的主因。

变更被实现并验证之后，delta 合并回 specs/，提案归档：

openspec list          # 看进行中的变更
openspec show <id>     # 看某个变更的完整上下文
openspec archive <id>  # 变更落地后归档，delta 合并进主规格

2.3 一个绕不开的转折

最初的推荐名单上，排第一的是 Spec Kit。改变结论的不是任何一个版本发布，而是使用过程中的一个体感差异：在同等产出质量下，OpenSpec 的规划阶段快得多，Spec Kit 慢到影响节奏。规划本来是为了省下返工时间，如果规划自身耗时膨胀，收益就被吃掉了。于是 Spec Kit 被放弃，OpenSpec 成为默认。

更诚实的部分是后面：连 OpenSpec 最终也被放下了。原因不在 OpenSpec，而在编码工具本身长出了替代能力（第六节展开）。这不构成对 OpenSpec 的否定------它依然是给新团队的第一推荐：够快、够轻、心智负担最低，二十多个工具有原生集成，学一次到处能用。

需要说明一句偏差来源：这类结论的样本往往来自单个工程组织的实践，而不是横跨行业的统计。「一个团队的长期体感」和「所有团队的最优选择」不是一回事。

---

三、BMAD：最重的那个，也活得最好

3.1 生态而非框架

BMAD 的增长同样健康，但真正的看点不是 star 数，而是这半年交付了什么：

• v6 稳定版本质上是一次自底向上的重写；
• 12 个以上的专业化 agent 人格（产品经理、架构师、开发、QA、测试架构师等），配合 30 多个结构化工作流，覆盖分析、规划、方案、实现四个阶段；
• BMad Builder 独立成一个项目，用于构建自定义 agent、工作流和模块，本身已迭代到 1.4 量级；
• Dev Loop 自动化、社区技能小市场，共同构成一个可扩展的模块生态。

这已经不是「一个框架」，而是一套方法论加上一个插件生态。BMAD 的核心机制叫规模自适应规划（scale-adaptive planning）：小改动直接进 Build，复杂需求才走完整的 Clarify → Plan → Solution → Build → Learn 循环。

            ┌──────────────────────────────┐
模糊想法 →  │ Clarify                      │
清晰大需求 →│ Plan                         │
小改动 →    │ Build & Verify               │
            └──────────┬───────────────────┘
                       ↓
                  Learn & Adjust ──┐
                       ↑           │
                       └───────────┘

还有一个被低估的设计：Party Mode，把多个 agent 人格拉进同一个会话里做协同讨论。在架构评审这类需要多视角碰撞的场景，效果比单 agent 自问自答明显。

3.2 代价

表面积大是双刃剑：

• 上手成本高。v6 对环境有要求（Node、Python、uv 等），比「只放几个 markdown 技能文件」的框架重得多。
• 人格过剩。单人开发或五人以下小团队，12 个 agent 人格更多是负担；Quick Flow 路径缓解了这个问题，但没有消除。
• 产物目录共享。默认落在共享目录，多条并行工作流会互相干扰，不如「每个 feature 一个隔离目录」的方案干净。

这就是 BMAD 一贯的取舍：它不为周末项目设计。作者本人对定位的表述很直接------BMAD 是 vibe coding 的对立面，因为你确实要动脑子做计划。也正因为这套东西在复杂项目里省下的是真金白银，它的社区极其护主：上一轮比较里 BMAD 拿不到第一，评论区立刻涌来一批用户论证，而且他们的论据站得住。

适用判断：如果你的项目跨多个季度、有多人协作、需要可审计的规划痕迹，BMAD 的重量是投资而非成本。如果你要在周五晚上做完一个小工具，它就是纯粹的开销。

---

四、Spec Kit：营销声量与工程体感的落差

4.1 它做对了什么

GitHub 官方出品，是这个概念破圈的主要推手。工作流定义得非常清楚，六个核心命令构成完整闭环：

/speckit.constitution   # 项目治理原则与开发准则
/speckit.specify        # 定义要建什么（需求与用户故事）
/speckit.plan           # 技术实现计划（技术栈、架构选择）
/speckit.tasks          # 拆成可执行任务清单
/speckit.implement      # 按计划执行
/speckit.converge       # 对照 spec/plan 评估代码库，补齐剩余工作

constitution 这个概念很有价值：把「团队不可妥协的原则」单独提取成一份长期文件，所有后续阶段都受它约束。它还配了脚本层，保证每次操作都在同一个 feature 分支上、后续 prompt 都能正确引用先前产物。近期还补上了 specify workflow 编排层，支持 fan-out / fan-in、gate、暂停恢复，工作流本身就是你能改的 YAML。

4.2 它被批评什么

这半年 Spec Kit 收到的批评是整个赛道里最尖锐的，集中在三点：

1. 文档膨胀。一个中等规模的 feature 能生成一堆互相引用的 markdown，读完这些文档的时间接近自己写代码的时间。社区里有一句流传很广的评价：它制造了「工作正在进行」的错觉，实际产出是一堆文本。
2. 过度工程。生成的项目结构和测试往往远超需求，几百个无用测试是常见抱怨。反驳意见也成立------这更像上下文管理不当的症状，只把相关文档喂给模型、把任务切小，问题会明显缓解。
3. 规划慢。这是前文换框架的直接原因。慢本身不是罪，但在同等质量下慢，就没有理由不换。

还有一层结构性质疑：官方光环带来的关注度，和框架实际的工程成熟度之间存在落差。仓库活跃度与 issue 处理节奏时常被拿出来讨论「这个项目到底有多少投入」。

4.3 最值得读的那份批评

Martin Fowler 一侧对 SDD 工具的分析是这个领域最有分量的批评，核心担忧不是某个工具做得不好，而是整个范式让人想起模型驱动开发（MDD）：

用一种更高层的、人类可读的中间表示去驱动实现，历史上一再失败------不是因为工具不够好，而是因为自然语言的歧义无法被消除，而消歧的成本最终会超过直接写代码。

配套的批评来自另一条线索：SDD 是瀑布的回归。这篇观点在社区引起大规模讨论。逻辑很直白：先冻结规格再实现，本质上是「设计-实现」两段式，而软件工程过去三十年的经验是需求在实现过程中才被真正理解。

更资深的从业者给出了折中判断：一次性「规格到产品」的路线注定失败，就像当年的 CASE 工具和模型驱动架构------好卖，难用；真正有效的是紧凑的迭代反馈回路，AI 负责确定性强、结构化的部分，人类保留领域知识、语义正确性和架构判断。还有一条极其实用的建议：不要指望 markdown 文件能约束 agent，把规则写成 CI 里真正会跑的自动化检查（lint、schema 校验、契约测试），对人和 agent 一视同仁，并给出可操作的报错信息。

这条建议值得单独强调，因为它指向 SDD 当前最大的工程缺口：规格与代码之间缺少强制性的一致性验证机制。没有这层验证，规格就是善意的注释。

---

五、失速的两个：Task Master 与 Agent OS

5.1 Task Master：商业化时机的教科书案例

Task Master 的定位一度极具吸引力：把 PRD 解析成带依赖关系的编号任务，存在仓库的 .taskmaster/ 目录里，再一次只喂给编码 agent 一个界定清晰的任务。

# 作为 MCP 接入 Claude Code
claude mcp add taskmaster-ai -- npx -y task-master-ai

它是这批工具里最「顺手」的：依赖感知的任务图、跨编辑器可用（Claude Code、Cursor、Windsurf、VS Code）、任务状态持久在仓库里。

然后增长曲线拐平了，+18%。原因是几件事叠加：

• 仓库迁移。项目从原仓库搬到了独立仓库，star 数与社区注意力被切断了一次。
• 商业化转向。许可从纯 MIT 变成 MIT + Commons Clause：允许自用、修改、分发、用它做商业产品，但不允许售卖它本身或做成托管服务。条款不算激进，但信号很强------项目从「社区公共品」变成「有商业主体的产品」。
• 发布节奏放缓。从接近每周变成接近每月。
• 额外门槛。它自己要调用模型，因此至少需要一个 provider 的 API key，比纯文件型框架多一道配置。

技术上没什么硬伤：引擎依然可靠，核心工具照常工作，被吐槽的点大多可修复，都不是致命缺陷。问题出在时机------增长最快的时候做商业化转向，等于在社区信任的最高点收税。从数据看，「失速」这一侧的论证目前占上风。

这里有一个对所有开源基础设施作者都成立的教训：开发者工具的采纳曲线极度依赖「零摩擦」和「零疑虑」。任何需要停下来读一遍许可证的动作，都会在漏斗上打一个洞。

5.2 Agent OS：主动收窄，未必是坏事

Agent OS 走了一条相反的路：放弃全流程，专注做一件事------把代码库的标准注入 agent。

它的工作流现在只有四步：

1. Discover Standards  从现有代码库里提取模式与约定，沉淀成标准文档
2. Inject Standards    根据当前在做什么，智能注入相关标准
3. Product Planning    产品级规划
4. Shape Spec          把规划收敛成可执行的 spec

对比 v2 时期六步完整流程（Plan Product → Shape Spec → Write Spec → Create Tasks → Implement Tasks → Orchestrate Tasks），v3 明显砍掉了实现与编排环节。

这个变化在社区语境里被读成「变安静了」，但从工程角度看更像是清醒的定位收缩：实现与编排这两块正被编码工具原生能力快速吞掉，而**「把团队约定可靠地喂给 agent」这件事仍然没有好的默认解法**。

所以结论要分两句说：它已经不是大家会拿来横向比较的 SDD 框架了；但如果你的痛点非常具体------一个有大量历史约定的代码库，agent 总是写出「能跑但不像我们写的」代码------那它的价值主张依然真实且难以替代。

---

六、名单外的三个选手

讨论这半年的 SDD 生态，绕不开三个不在原始名单上、但影响力可能更大的项目。

6.1 Superpowers：不是 SDD，但解决了同一个问题

Jesse Vincent 的 Superpowers 严格来说不是规格驱动框架，它是一套可组合技能库，把 TDD、系统化调试、结构化规划、代码评审、技能编写这些方法论编码成 skill 文件，让 agent 自动触发。

核心工作流是 brainstorm → plan → execute：

/superpowers:brainstorm     # 苏格拉底式追问，逼你说清真正想要什么
/superpowers:write-plan     # 写出「零上下文、品味可疑的junior也能照做」的计划
/superpowers:execute-plan   # 启动 subagent 驱动开发，逐任务实现+评审

三个设计细节值得学：

1. brainstorm 阶段不写代码，只做消歧。它的假设是「用户说的需求」和「用户真正要的东西」不是一回事，所以用对话把差距逼出来。有案例是在写第一行代码前花了四个半小时做 brainstorm。
2. 计划的写作对象被明确定义：假设执行者「零项目上下文、判断力可疑、抗拒写测试」。这个假设直接决定了计划的详细程度，比「写清楚一点」这种模糊要求有效得多。
3. subagent 驱动执行 + 内置代码评审。每个任务由独立 subagent 完成，主 agent 负责检查和推进，因此能连续自主工作数小时不偏离计划。

它的 skill 体系还有一个工程巧思：核心 bootstrap 保持在两千 token 以内，技能按需加载。这是上下文预算意识的直接体现------外壳自身不能吃掉太多注意力预算。

有一个不太舒服但值得记录的观察：这些 skill 大量使用了权威、承诺、社会认同这类说服学手法（「技能存在时必须使用」「先声明你正在使用哪个技能」），目的不是越狱，而是让模型更守纪律。用说服技巧提升 agent 可靠性，这是 prompt 工程的一个真实前沿。

6.2 GSD：执行优先的另一极

GSD（Get Shit Done）是这半年增速最惊人的项目之一，仓库处于 6 万 star 量级，创建时间还不到一年。它的自我定位是「元提示 + 上下文工程 + 规格驱动」三合一，气质上执行优先，明确站在「企业流程剧场」的对立面。

架构上是标准的编排器 → agent 模式：

Orchestrator（工作流 .md）
  ├── 加载上下文：项目信息、配置、状态、阶段详情（JSON）
  ├── 解析模型：opus | sonnet | haiku | inherit
  ├── 派发 Agent（独立上下文窗口、独立工具权限）
  ├── 收集结果
  └── 更新状态

13 个专职 agent（debugger、planner、reviewer、researcher、scout、worker 等），每个跑在隔离上下文里、有自己的工具集和模型绑定。它还做了两件很「产品」的事：用 hook 在每次 Edit/Write 后自动跑格式化；用 statusLine 常驻显示当前模型、活动任务和上下文占用进度条，接近满的时候变红。

社区评价两极：有团队用它三个月做完并上线了一个 SaaS，说复杂任务能到 95%，剩下 5% 是手工测试；也有人讽刺它适合「一夜之间做一个 Potemkin SaaS 拍短视频」。有一个细节值得所有人注意------它的官网挂了代币和市值信息。开发者工具引入代币经济学，会实质性改变社区对它的信任评估，无论技术质量如何。

最有价值的技术观察反而来自一位深度读过它源码的工程师：预期中会看到大量脚本，实际上整套复杂工作流几乎完全由标准工具和 markdown 文件构成。指令用人类语言写，抽象层被大幅消解------这正是当下 agent 外壳的普遍形态。

6.3 Beads：给 agent 换一套记忆

Steve Yegge 的 Beads 解决的是一个被所有 SDD 框架共同忽略的问题：任务状态存在 markdown 里，天然不可靠。

Beads 是一个 git 原生的分布式图式 issue tracker，底层用 Dolt，专门为 agent 设计：

# 常见用法（作为 agent 的持久工作记忆）
bd create "修复 refresh token 撤销逻辑" --type bug --priority 1
bd dep add <child> --blocked-by <parent>
bd ready          # 列出当前没有阻塞、可以立刻做的任务

它把「一堆凌乱的 markdown 计划」替换成依赖感知的任务图 ，使 agent 能处理长周期任务而不丢上下文。issue 数据以 JSONL 存在仓库里，人和 agent 都能读写，跨会话共享。项目自己用自己管理 issue，.beads/issues.jsonl 直接可查------这种自举是很强的可信度信号。

作者的比喻贴切：不用这类工具就是穿着袜子跑步，灵活、有点保护，但脚会疼。Beads 是鞋，很主观、不适合所有场景，合脚时非常好用。

他给出的目标状态也是这个赛道的公共愿景：早上打开终端问一句「接下来做什么」，agent 自己知道答案------不是因为你交代过，而是因为它能看见依赖图、优先级、什么被阻塞、什么刚上线。

---

七、最大的变量：编码工具自己长出了这些能力

这是这半年变化最安静、影响最深远的一条线。

7.1 被吸收的功能清单

对照一下这些框架的核心卖点和编码工具现在的原生能力：

框架提供的能力	现在的原生对应物
结构化规划阶段	Plan Mode（只读研究 + 计划确认 + 检查点）
方法论注入	Skills（SKILL.md，相关时自动触发）
多 agent 编排	Subagents（独立上下文、独立工具权限、可后台运行）
任务并行拆分	批量编排能力：把改动拆成若干独立单元，每个单元一个隔离 worktree 里的后台 subagent，各自实现、跑测试、开 PR
项目约定持久化	AGENTS.md / 项目级配置
上下文压缩与续接	自动 compact、上下文占用可视化

这张表基本解释了为什么会出现「连 OpenSpec 也放下了」这种结论。当规划、技能、子 agent、并行编排全部变成工具内置能力时，外部框架剩下的差异化空间就只有两类：更强的领域方法论 （BMAD、Superpowers 走这条路）和更硬的状态基础设施（Beads 走这条路）。纯粹做流程包装的那一层，正在被挤压。

7.2 这是不是意味着框架没意义了

不是。但价值定位必须重新校准：

• 框架的长期价值在方法论，不在命令 。slash 命令会被内置，/plan 会变成按钮；但「先消歧再规划」「计划要写给零上下文的执行者」「用 spec delta 审查意图」这些认知不会过时。
• 框架是方法论的分发渠道。一个团队要从零总结出这些约定需要很久，装一个框架只要一分钟。这个价值不因原生能力增强而消失。
• 原生能力的边界是通用性。工具内置的东西必须对所有人都成立，因此不会包含「你们团队的架构原则」。这正是 Agent OS 收缩到「标准注入」后仍然成立的原因。

---

八、怎么选：一份不打太极的建议

8.1 按场景对号入座

你的情况	建议
第一次接触 SDD，想低成本验证有没有用	OpenSpec。最快，心智负担最低，spec delta 的收益立刻能感知
长周期、多人协作、需要可审计的规划痕迹	BMAD。重量是投资，Party Mode 和规模自适应规划确实解决真问题
想要官方生态、和 GitHub 工作流深度绑定	Spec Kit。接受它的文档体量，把 constitution 用起来，任务切小
代码库有大量隐式约定，agent 老写「不像我们」的代码	Agent OS。专精标准发现与注入
痛点是 agent 跨会话丢状态、长任务跑偏	Beads。它和上面任何一个框架都不冲突，是补位而非替代
想提升 agent 的工程纪律（TDD、调试、评审）	Superpowers。方法论密度最高
只想快，能接受粗糙	GSD。注意评估它的治理与代币相关设计

8.2 无论选哪个都建议做的四件事

1. 规格要小、要增量。整份重写的大规格必然过期，delta 形式的小规格才活得下来。
2. 把约束写成能跑的检查。markdown 里的规则是建议，CI 里的 lint 和契约测试才是约束。对人和 agent 一视同仁，报错信息写清楚怎么修。
3. 给上下文做预算。外壳自身的 token 开销要压到最低，按需加载技能，用 subagent 隔离重活。规划阶段吃掉的上下文，实现阶段就没有了。
4. 保留人类的判断环节。领域知识、语义正确性、架构取舍这三件事目前没有任何框架能代管。所有可用的方案都是「紧凑迭代 + 人类在关键点确认」，不是「一次性生成」。

8.3 一个最小可用的落地路径

如果不想一上来就装框架，可以先用最小组合验证 SDD 是否适合你的团队：

repo/
├── AGENTS.md                # 项目级约定：架构原则、命令、禁止事项
├── specs/
│   └── <domain>/spec.md     # 用 SHALL 句式写行为约束
└── changes/
    └── <change-id>/
        ├── proposal.md      # 为什么改、影响面、验证方式
        ├── tasks.md         # 可勾选的任务清单，每项可独立验证
        └── delta.md         # 这次变更对 spec 的增删改

流程只有四步：写 delta → 人类 review delta（不看代码）→ agent 按 tasks 实现 → 验证通过后合并 delta 并归档。跑三五个真实变更之后，你会非常清楚自己缺的是 OpenSpec 那种轻量约定、BMAD 那种流程深度，还是 Beads 那种状态基础设施。

---

九、结论：会过时，正是重点

把六个月的变化压缩成几句话：

• OpenSpec 以 +863% 跑掉，靠的是减法和 spec delta 这个正确的抽象；
• BMAD 用一次自底向上的重写换来了生态，重，但重得有理由；
• Spec Kit 声量最大，也承受了最尖锐的批评，文档膨胀与规划耗时是真实短板；
• Task Master 在最好的时候做了商业化转向，+18% 是市场给的回执；
• Agent OS 主动收窄到「标准注入」这一件还没被解决好的事上；
• 边缘地带，Superpowers、GSD、Beads 各自补上了纪律、速度和记忆；
• 而最大的变量是编码工具本身------它安静地吸收了这些框架过去承担的大部分工作。

所以真正的结论不是「该用哪个框架」，而是这一层的工具正在被你已经在用的工具内置吸收，同时新玩家还在持续出现。任何一份这样的横评都会迅速过期，而这恰恰是它值得写的原因：它记录的是一个范式从「靠外挂实现」向「成为默认能力」迁移的中间态。

最后留一句怀疑主义的提醒。这里提到的每一个框架，都把自己包装成「用 AI 规划软件的正确方式」。它们不可能全都对。真正稳定的资产不是某个仓库，而是那几条被反复验证的工程直觉：意图要持久化、规格要增量、约束要可执行、上下文要有预算、判断要留给人。框架换掉三轮之后，这些东西还在。