BMAD 和 OpenSpec 都想解决同一件事AI 写代码时需求只活在聊天记录里。BMAD 用一套可伸缩的规划、构建与审查流程把产品、架构、开发等视角请到桌边OpenSpec 用一层轻量规格把每一次变更讲清楚、记下来。本文结合我用 BMAD 从零做 ec-calc、日常用 OpenSpec 改代码的经历补上两者到 BMAD v6.12 / v7 预览、OpenSpec v1.14 的最新变化顺带看看 GitHub 的 Spec Kit讲清它们的区别、成本以及什么场景该选哪一个。本文资料 · 接着动手开源https://zhcmqtt.top/article/bmad-vs-openspec鸿尘客 Honchic · AI 编程 · 2026-04-05我用 AI 写代码前后试过两套办法。它们在项目里留下的痕迹很好认一个是_bmad-output/一个是openspec/。两个文件夹里装的都是 Markdown都是写给 AI 看的。打开一看气质却完全不一样。_bmad-output/里有 PRD、架构文档、UX 规范、Epic 列表还有一沓 Story 文件像一家小公司的共享盘。openspec/里只有两个目录一个写系统现在什么样一个写这次打算改什么像一本随手记的施工日志。我之前分开写过这两个工具。这一篇不再把每条命令重新讲一遍只想把它们摆在一张桌子上聊聊它们到底差在哪什么时候该用哪一个。顺便把这两个项目最近的变化补上它们都变了不少。同一个病根先说它们为什么会长得这么像。和 AI 结对写代码最磨人的往往不是写代码本身。你花两段话描述一个功能AI 听起来像懂了写出来却跑偏。纠偏几轮上下文窗口已经用掉大半。好不容易做完一个功能第二天开个新对话昨天定下的技术栈、约束和取舍全没了又得从头交代。需求只活在聊天记录里对话一关一切归零。BMAD 和 OpenSpec 开出的药方方向是一致的把重要的东西写成文件放进仓库。AI 每次开工从文件出发不从你的口头描述出发。分歧在下一步。写什么文件写多少谁来写写完怎么用。BMAD把一支团队的思考搬进流程BMAD 的全称是 Breakthrough Method for Agile AI Driven Development。它的思路是借敏捷开发的那一套让 AI 轮流扮演分析师、产品经理、架构师、UX 设计师和开发者从一个模糊的想法一路走到能跑的代码。我当时拿它从零做了一个前端小工具叫ec-calc一个讲纠删码原理的可交互计算器。完整流程走下来是这样的。从一份 16 行的产品想法出发分析师 Agent 陪我做头脑风暴和调研。产品经理 Agent 写 PRD架构师 Agent 定技术栈、分层和关键决策每份文档我都审一遍。产品经理 Agent 把 PRD 拆成 Epic 和 StoryScrum Master Agent 做 Sprint 规划逐个生成 Story 文件。开发 Agent 按 Story 一个个写测试、写代码、跑测试再做代码审查。头脑风暴是最让我惊喜的一段。它一问一答地引导每出 10 个想法就强制换一个维度从技术换到商业再换到边缘情况为的是冲过前 20 个平庸想法。在这一步舍得用推理强的大模型回报很高LLM 的领域知识实在太广了。代价也很具体。ec-calc的核心逻辑不超过 500 行BMAD 给它生成了 6 个 Epic、23 个 Story 文件外加 PRD、架构文档、UX 设计、实现就绪报告。仪式性产出物的总量远远超过了实际代码量。每个对话都要重新读取状态和规则token 用量跟着往上蹿。当时我还吐槽过几处。Scrum Master、Retrospective 这些角色原样搬给 LLM 有点生硬LLM 不需要被「协调」也不会疲劳。所谓的多 Agent其实是我在不同对话里手动加载不同的 Prompt 文件。还有自审的问题同一个模型既写代码又审代码可信度要打折扣。有意思的是这几处后来 BMAD 自己动刀了。角色合并了。v6.3 把快速开发的 Barry、QA 的 Quinn 和 Scrum Master Bob 并进了开发 Agent Amelia。v6.1 起工作流、Agent 和任务都改成了统一的 Skill核心工作流从 YAML、XML 换成了 Markdown。实现阶段收成了一条线。v6.11 把 Quick Dev 改名为bmad-build定为官方唯一的写代码方式第四阶段收成bmad-sprint-planning → bmad-build → bmad-code-review。原来的create-story、dev-story那一对被标记为弃用Core 模块的技能从十四个砍到八个。流程开始量体裁衣。v6.12 的说法很直白Build 先调查一遍改动再决定要走多重的流程。简单的改动只配一份两节的 spec一个会话就能做完。审查开始讲证据。几种审查方式合进了一个bmad-review用对抗式、边界情况、验证缺口等不同视角去看。v6.12 起每一条审查发现都要记下结论和证据不能悄悄丢掉。回顾也要求每一条发现都标出处。真的能自己跑了。新的 BMad Loop 模块可以无人值守地把一整个 Epic 构建、验证、回顾完。现在的稳定版是 v6.12v7 正在预览 alpha可以通过 Skills CLI 或 Claude Code、Codex 的插件市场安装。稳定版的安装方式没变。npx bmad-methodinstall注意它现在需要uv来跑 BMad 的配置和 Python 脚本装之前先把这个准备好。所以我对它的印象得更新一下。BMAD 不再是「只适合大项目的重流程」它正在变成一套能伸缩的方法。小改动直接 build大项目再一层层往上加规划。但它的底子没变它关心的是从想法到交付的整个过程产品、架构、UX、测试这些视角它都想替你请到桌边来。BMAD 的 README 里有一张交付循环图把这层意思画得很直白。想法还模糊从澄清开始。想法清晰又大进规划。改动很小直接构建和验证。做完以后学到的东西再绕回去调整计划。图出自 BMAD 官方仓库MIT 许可。OpenSpec只管把这一次改动讲清楚OpenSpec 的野心小得多小得很克制。它不打算模拟一支团队只想在你和 AI 之间加一层轻量的规格。官方给自己写的原则只有几条灵活而非死板迭代而非瀑布简单而非复杂为存量项目而生从个人项目到企业都能用。整个体系建立在一个二分法上。openspec/ ├── specs/ ← 系统现在是什么样的 └── changes/ ← 我们打算改什么specs/是系统当前行为的权威描述。changes/里每个功能、每个 Bug 修复独立一个文件夹各放一份proposal.md、specs/、design.md和tasks.md分别回答为什么做、行为怎么变、技术上怎么做、具体干哪几件事。最妙的是 Delta Specs。改一个功能不用把整个系统的规格重写一遍只写这次的 ADDED、MODIFIED、REMOVED。归档时这些增量自动合进主规格变更目录移进openspec/changes/archive/下带日期的文件夹。规格写出来大概是这样纯 Markdown没有要额外学的语法。## ADDED Requirements ### Requirement: Theme selection The app SHALL let users switch between light and dark themes, defaulting to the system preference. #### Scenario: User toggles dark mode - **WHEN** the user clicks the theme toggle - **THEN** the app switches to dark mode and persists the choice日常用起来就是几个斜杠命令。想不清楚先/opsx:explore它只读代码、帮你权衡不落文件。想清楚了/opsx:propose一口气生成整套工件扫一遍没问题就/opsx:apply按清单干活做完/opsx:archive。中途被打断下次开个新对话再/opsx:apply它读tasks.md看哪些打了勾从断点接着来。这种体验很像在工地上贴施工单。它不问你这个产品该不该做只问你这次到底要改什么。OpenSpec 这段时间更新得很勤大多数改动都在往同一个方向使劲让规格更不容易悄悄出错。/opsx:sync进了默认安装新增了/opsx:update可以只修订规划工件不碰实现。openspec show change --diff只把真正变化的行拎出来审查 MODIFIED 的时候不用在大段相同文字里找不同。openspec status最后会多一行Next:直接告诉你下一步该敲哪条命令断点续做不再需要背流程。纯重构、纯文档的改动可以声明skip_specs: true不用硬编一份规格。propose 和 ff 在起草工件前会先看相关代码、测试和文档。apply 遇到一份规格都没有的变更也会提醒归档和 delta 解析不再悄悄改动或丢掉你写的内容。面向团队的 Stores 进入 beta把规划放进一个单独的仓库一个变更可以横跨好几个代码仓库。在终端里敲openspec view能看到一块仪表盘主规格有几份、需求有多少条、哪些变更还在做、任务完成了几成一屏看完。v1.14 起它还会单独列出已归档的变更标出每个活跃变更的工件哪些已完成、哪些还卡着。截图出自 OpenSpec 官方仓库MIT 许可。截至 v1.14它已经支持三十多种 AI 编程工具。安装一如既往地简单要求 Node.js 20.19.0 以上。npminstall-gfission-ai/openspeclatestcdyour-project openspec initmacOS 上也可以直接brew install openspec。桌边还坐着一个 Spec Kit聊规格驱动绕不开 GitHub 官方的 Spec Kit。OpenSpec 的 README 里专门拿它做过对比说它周全但偏重阶段门禁严格Markdown 很多还要装 Python 环境。这是 OpenSpec 自己的说法听一半就好。Spec Kit 现在到了 v1.2需要 Python 3.11 和uv。它的主线是每个项目先定一份 constitution然后每个功能走 specify、plan、tasks、implement、converge。修 Bug 和评估一个想法值不值得做则作为可选扩展单独安装。放在这里一比它的位置大概在 BMAD 和 OpenSpec 中间。比 OpenSpec 更讲究阶段又不像 BMAD 那样请来一整支团队。三家最近还有一个共同的动向都在往 Agent Skills 靠。BMAD 从 v6.1 起把一切改成 Skillv6.5 起在支持的平台上统一写进跨工具的.agents/skills/目录。OpenSpec v1.8 加了一个中立的agents目标同样写进.agents/skills/。Spec Kit 的流程也是在 Agent 对话里一个个调用的/speckit-*Skill。工具本身越来越像流程变成了可以装、可以卸的技能包。剩下要选的主要是你想给 AI 配多重的流程。放在一张桌子上看两个工具的差别拆开来看大概是这样。维度BMADOpenSpec关心什么从想法到交付的整个过程每一次变更讲没讲清楚核心产物简报、PRD、架构、UX、Epic 与 Storyspecs/主规格、changes/变更与 Delta Specs流程重量可伸缩小改动直接 build大项目层层规划轻没有阶段门禁工件随时可改进度记在哪状态文件和 spec frontmattertasks.md的复选框知识怎么沉淀前期规划文档定方向每次归档主规格长一点擅长的起点想法还模糊、从零开始的新项目已经有代码、需求零碎的存量项目上手成本角色和技能多需要 Node.js 和 uv一个 npm 包几个斜杠命令多视角产品、架构、UX、开发、测试分别出场没有角色专注规格本身一句话收一下BMAD 管的是想清楚OpenSpec 管的是记下来。当然这句话有点偷懒。BMAD 也在记它的 Story 文件和状态文件一样能接住断点。OpenSpec 也在想/opsx:explore就是专门用来想的。只是两个工具把力气花在了不同的地方。什么时候用哪一个我自己的判断按场景分。一句话就能说清的小改动。修个样式、改个文案、加一个字段两个都可以不用直接改、直接测。真要留痕OpenSpec 的 propose 或 BMAD 的 build 都够轻。从零开始想法还很模糊。这是 BMAD 的主场。头脑风暴、调研、PRD、架构一层层把模糊的东西逼成具体的东西。项目越大越需要产品、架构、UX 这些视角在动手前就把冲突摊开BMAD 的那些规划文档就越值回 token。BMAD 官方文档按规模给了四条路径。琐碎的改动改完验证就行。一个会话能做完的从意图直接进 Build。Epic 大小的先写 spec、拆 Story每个 Story 跑一次 Build最后整合和回顾。项目级的先立产品、UX、技术的共享约定再把 Epic 那条路重复几遍。图出自 BMAD 官方文档仓库MIT 许可。已经有一摊代码要长期迭代。这是 OpenSpec 的主场。你不需要先给整个系统补一份完整规格从第一个变更开始用就行。几次归档之后openspec/specs/会自然长成一份可用的系统行为手册这一切都是在正常开发里顺手攒出来的。手上同时推进好几个功能。OpenSpec 的变更天然隔离各自一个文件夹切换时只要换个变更名最后统一归档。BMAD 按 Epic 和 Story 组织适合有先后依赖的一整串工作。想让 AI 一口气跑完一整段。BMAD 的 BMad Loop 是冲着无人值守去的。OpenSpec 不打算替你编排整段流程它更愿意你在每个工件节点上看一眼。两个能不能一起用我的看法是可以分段用但别叠在一起用。比如新项目前期用 BMAD 把产品和架构想清楚主体落地以后零碎的改动交给一套更轻的规格流程。最怕的是同一件事在_bmad-output/和openspec/里各写一份两边一对不上AI 也不知道该信谁。真源只能有一个。还有一个判断标准是从 OpenSpec 的文档里学来的我觉得对两个工具都适用。这个改动搞砸了返工成本高不高。高就多花点时间写规格、走规划。改错了五分钟就能修好写个大概就够了。两个都替你做不了的事最后说点泼冷水的。不管是 BMAD 的审查视角还是 OpenSpec 的/opsx:verify都是 AI 拿着文件去检查 AI 写的代码。两家都在补这块短板BMAD 要求每条审查发现都带证据OpenSpec 的 verify 改成如实报告自己查了什么。这些都让检查更可信但做不到让它独立。我做ec-calc的时候体会很深。前端项目必须人在环里亲手点一遍体验有问题再反馈回去修。测试是 AI 写的代码也是 AI 写的它们可能犯同一个错。所以这两套东西与其说是让 AI 更聪明不如说是让「对不对」有处可查。规划文档也好Delta Specs 也好都是给人回头对照用的。对照这件事还是得有人真去做。另外两个工具对模型的推理能力都很敏感。规划、拆解、写规格这几步尽量用推理强的模型。真正照着清单写代码的阶段要求可以低一点。开始实现之前最好开一个干净的新对话让 AI 从文件出发别被前面讨论阶段的噪音带偏。回到那两个文件夹现在再看项目根目录里那两个文件夹我的理解是这样的。_bmad-output/像一间会议室适合在动手之前把该吵的架吵完。openspec/像一本施工日志适合在动手的过程中把每一刀切在哪记清楚。你缺的是想清楚就先进会议室。你缺的是记下来就翻开那本日志。脑洞先落地细节慢慢打磨两个文件夹都是为后半句准备的。鸿尘客 Honchic · 把脑洞焊到电路板上本文资料 · 接着动手开源https://zhcmqtt.top/article/bmad-vs-openspec