把开发循环的控制权,交还给确定性代码合集 - BMAD(3)1.BMAD开发效率翻倍: 一条命令交付整个Epic02-242.BMADStory Automator 上手实录:把 5

把开发循环的控制权,交还给确定性代码合集 - BMAD(3)1.BMAD开发效率翻倍: 一条命令交付整个Epic02-242.BMADStory Automator 上手实录:把 5
那篇文章里我留了个没回答的问题——为什么它跑得比人手工还慢我当时说还没仔细分析它的实现原理。现在 BMAD 6.10 把这套东西重写了一遍改名BMAD Loop也顺手把那个问题接上了。答案只有一句话但它是理解整个设计的钥匙控制环里不应该放 LLM。先纠正一个最容易踩的误解很多人第一次接触 BMAD Loop会以为它是几个新 skillbmad-loop-setup、bmad-loop-sweep、bmad-loop-resolve、bmad-dev-auto。不是。这几个 skill 本身什么也不做。真正驱动循环的是一个用uv从 Git 装进来的Python 工具——bmad-loop包仓库在 bmad-code-org/bmad-loop。那几个 skill 只是编排器在循环的不同阶段会去调用的基本操作官方文档里叫 primitive说白了就是最基础的、可以单独派活的小单元bmad-dev-auto开发——把意图变成经得起 review 的产物bmad-loop-sweep巡检——清理延后工作台账bmad-loop-resolve交互——和人一起消除歧义换句话说skill 是肌肉Python 编排器才是中枢神经。这一点想通了后面所有设计都顺理成章。灵魂信条No LLM in the control loop官方 README 的副标题一句话就给它定了性A deterministic ralph-loop orchestratorfor the BMAD-METHOD implementation phase.翻译过来一个确定性的循环编排器。确定性deterministic这三个字是全文最重要的一组词。它把整个开发循环切成两种完全不同的工作工作谁来做为什么控制逻辑选哪个 story、重试几次、什么算完成、能不能提交纯 Python 代码要确定、可调试、可复现、不花钱创意工作写代码、写测试、做对抗式 reviewLLM在一次性会话里这才是 LLM 擅长、且只有 LLM 能做的事回过头看 Story Automator 为什么慢——它的控制环里塞满了用提示词去问 LLM 现在该干嘛的环节。每问一次都要花 token、等推理还可能跑偏跑偏了就再问一次。把调度交给 LLM等于让一个容易走神、按字计费的新人在流水线上当调度员。BMAD Loop 的做法是调度员换成一段不会走神、不收钱的 Python 代码LLM 只在每个工位上干它该干的创意活干完就走。这样做换来四个好处是后续所有机制的出发点确定性同样的 sprint 跑两次调度路径一致可调试流程是代码出问题能打断点、看日志而不是猜提示词哪里没说清可复现每次运行的决策都有磁盘上的状态机记录省钱控制逻辑零 token 消耗四个让它敢放手的关键机制控制环不放 LLM说起来轻松但它带来一个尖锐的问题编排器怎么知道一个 LLM 会话干完了、干对了旧做法是让编排器自己也是个 LLM去看会话的输出——这正是 Story Automator 的包袱。BMAD Loop 用四个机制绕开了这个包袱。机制一每个步骤都是全新上下文的一次性会话Dev 和 review 是两个独立会话review 会话绝不继承dev 会话的上下文。这一点反直觉但极其关键。如果 review 会话带着 dev 写代码时的记忆它天然会护短——人对自己刚写的代码容易先入为主、下不去狠手心理学叫锚定效应anchoring biasLLM 也一样。把 review 放进一个对 dev 一无所知的全新会话里它才会真的去挑刺而不是附和。类比你不能让写代码的人和 code review 的人是同一个脑子。上下文隔离就是给 review 配一双没见过这份代码的眼睛。机制二靠 hook 事件文件通信绝不抓屏编排器怎么知道会话结束了答案是给 coding CLIClaude Code / Codex / Gemini注册 hook——Stop、SessionStart、SessionEnd、PreCompact。这些 hook 在关键节点往磁盘写结构化事件文件编排器只管 watch 这些文件。而每个 skill 在自动化模式下跑完会写一个机器可读的result.json声明自己这一轮的产物和状态。旧做法Story Automator BMAD Loop 的做法 ┌─────────────┐ ┌─────────────┐ │ 编排器(LLM) │ │ 编排器(Python)│ │ 去看屏幕 │ ←脆弱、贵、易错 │ watch 文件 │ ←稳、免费、结构化 └─────────────┘ └─────────────┘ ↑ ↑ 抓 pane / 读对话 读 Stop hook 写的事件 读 skill 写的 result.json抓屏pane-scraping是上一个时代的痛终端输出格式一变、模型多说了一句废话编排器就懵了。换成hook 写文件、编排器读文件接口就从自然语言降维成了结构化数据鲁棒性立刻上一个台阶。机制三Trust nothing, verify everything这是整个系统最硬核的地方。每个 LLM 会话结束后编排器不信任会话自己说的我搞定了而是去磁盘上独立校验spec frontmatter文件开头的元信息状态story 的规格文件状态字段是否真的变成了 donebaseline-commit 匹配会话声称改了哪些文件和 git 里实际的 diff 对不对得上——这是一个便宜的LLM 撒谎检测器非空 diff到底有没有真的改东西sprint-status 同步状态文件是否和实际进度一致你的测试 / lint 命令最后提交前跑一遍你自己定义的测试和 lint校验全过才允许 commit。任何一项不过要么重试要么升级。这条哲学值得单独记住LLM 会幻觉但 git 不会。把是否真的完成这个判断从问 LLM挪到看磁盘证据整个系统就稳了。机制四deferred-work 台账 sweep终于有人读它了循环里总会遇到现在干不了的活——某个 edge case 要等另一个 story 先落地、某个决策该人来拍板。这些不能硬干也不能丢于是写进一份台账deferred-work.md。有意思的是这份台账的身世。在更早的 BMAD 版本里这是个有名的半成品——bmad-code-review会往deferred-work.md里写延后项但没有任何 skill 会回头读它社区甚至专门提了 issue 报这个 bug。写进去的债永远没人还。BMAD Loop 的bmad-loop-sweep终于补上了这一环。它做的事是只读巡检把台账里每条 open 的项对着真实代码库逐条验证grep 症状、查 git log、读相关文件然后分成五类分区含义编排器怎么办already_resolved后来的工作顺手解决了但没标记拿证据file:line / commit自动关掉bundles现在就能一起干的按相同文件/子系统打包成一个 dev 会话执行blocked得等某个未来的 story/epic 落地标记阻塞方挂着skip已过时、无关、或项目明确排除跳过decisions必须人来拍板改冻结 spec、改 API 形状等升级给人写进去的债有人还了——而且是带着证据还不是凭台账里的旧状态拍脑袋。这条机制让循环可以长时间无人值守地跑下去而不至于债台高筑。一张图看清整个循环把上面四个机制拼起来一个 story 在 BMAD Loop 里的完整生命周期是这样的整条链路的控制流是 Python只有②③④这几个创意工位是 LLM 在一次性会话里干活。这就是确定性编排器的完整含义。多模型编排三个 CLI按角色混搭BMAD Loop 通过一个通用的 tmux 适配器驱动三种 coding CLIclaude默认、codex、gemini。而且可以按阶段混搭——配置在项目的.bmad-loop/policy.toml里[adapter] name claude # 默认所有阶段都用 claude [adapter.review] name codex # 但 review 阶段换成 codex为什么要混搭因为不同模型擅长的事不一样。一个很实用的组合是让一个模型写代码、让另一个模型做对抗式 review——两个不同家族的模型互相挑刺比同一个模型自审要狠得多。这正好和机制一review 用全新上下文叠加双重消除偏置。这已经不是调一个模型了是模型编排。什么时候它会停下来叫你CRITICAL 升级无人值守不等于无人干预。有一种情况编排器会主动暂停整个 run等人——CRITICAL 升级。触发条件通常是dev 或 review 会话发现冻结的 specfrozen-after-approval块自相矛盾或者对某个关键场景保持沉默没法安全地继续。这时候它不猜、不硬干而是把 run 挂起等你用bmad-loop resolve --story story-key起一个交互式会话。这个会话里有人你所以它会问你问题、给出 2-4 个具体选项和推荐。你拍板之后它去改 spec 本身——不是改代码——把歧义消掉然后编排器重新驱动这个 story对着一份修正过的、没有矛盾的 spec 重跑。这个设计很克制有几条硬规矩值得点赞resolve 会话只改 spec 内容不写一行功能代码、不跑测试、不提交它不动 sprint-status.yaml也不设 spec 的 status 字段——这些由编排器在恢复时确定性地产出如果信息不够、或者正确的修复超出了 spec 编辑的范围比如需要改 PRD/架构它会直接说我解决不了不写完成标记run 继续挂着——这是安全的默认行为一句话遇到拿不准的宁可停下来等你也不编一个答案往下冲。这是对无人值守最负责的理解。