前置条件就一条你得有一个BMAD v6 项目而且bmad-sprint-planning已经跑过、生成了sprint-status.yaml。换句话说PRD / 架构 / epicsstories / sprint planning 这条链得先走完Loop 才有故事可转。装好之后通过bmad-loop-setup这个 skill它会从 Git 装 Python 工具 跑bmad-loop init注册 hook、铺 skill、写 policy.toml核心命令其实很少bmad-loop init # 装 bmad-loop-* skill hook policy.toml gitignore bmad-loop validate # 预检config / sprint-status / git / tmux / CLI / hook bmad-loop run --dry-run # 先打印计划不真的拉起会话 bmad-loop run # 开跑 bmad-loop tui # 或者干脆全在可视化面板里操作完整命令清单覆盖了run / sweep / resume / resolve / decisions / status / attach / stop / clean等但日常 90% 的场景就是上面这几条。bmad-loop tui那个仪表盘挺漂亮——run 选择器、sprint 树、deferred-work 台账、每个 story 的实时任务表、带颜色的日志流一屏打尽。一个必须知道的一次性设置坑如果目标项目里 coding CLI 从来没跑过比如 claude 没在这个目录启动过你要先手动启动一次接受 workspace-trust 和 hooks 审批对话框。编排器拉起的子会话没法替你点这些首次运行对话框而一个挂着的对话框会被编排器误判成会话超时。血统从 Story Automator 到 BMAD Loop把 BMAD Loop 放回时间线里它的位置就很清楚了Story Automator bmad-automator / bmad-auto BMAD Loop (2026 初, 我那篇 (中间的过渡形态, (6.10, 重写为 实测的版本) 工具名 bmad-auto) 确定性 Python 编排器) │ │ │ └──── 控制环里有 LLM ─────┴───── 重写 ────────► 控制环里没有 LLM ──┘ (慢、贵、易跑偏) (确定、可调试、省钱)README 里写得很坦诚Inspired by the original bmad-automator (a separate, legacy project)——它明确把上一代当成 legacy自己是从头来的重写。而它给自己定位是a deterministic ralph-loop orchestrator。如果你关注过 autonomous dev 这个圈子应该听说过 Ralph——那个让 Claude Code 自己跑开发循环的工具。BMAD Loop 借用了ralph-loop这个模式无人值守、反复迭代的小循环但把它确定性地实现在了 BMAD 的 story 体系上。所以它是Ralph 的精神 BMAD 的骨架 Python 的中枢。适合谁不适合谁延续我测评 Story Automator 时的坦诚基调给你一个不吹的判断。适合用的场景你已经完整走完 BMAD 的规划链PRD → 架构 → epics → sprint planning手头有一串清晰、可独立实现的 story你接受睡前梭一把这种异步交付模式——第二天起来看结果而不是盯着它实时干你的项目有可靠的测试和 lint机制三最后那道闸靠它们否则 verify 形同虚设你想做多模型互相 review又不想自己手动切来切去不适合 / 要谨慎的场景story 还很模糊、依赖关系没理清——这种跑进循环里大概率触发一堆 CRITICAL 升级反而更累没有测试的项目——编排器再聪明最后那道 verify 闸门空转等于裸奔期待它又快又好又自动——确定性编排让它更稳、更省但单 story 的绝对速度未必比一个熟手手工盯更快。它的价值在批量、异步、可恢复不在单点提速和上一代最大的区别也是我现在最看好它的一点因为控制环是确定性代码它可调试、可复现、可信任。Story Automator 时代那个为什么这么慢的黑盒这一次终于打开了——流程是 Python你看得到每一步在干嘛、为什么这么决策。光这一点就值得把它从试验品升级成可以认真用起来的工具。写在最后从 v6.8 的锁定意图让 AI 先搞懂你要什么到 6.10 的 BMAD Loop让确定性的代码当调度员、LLM 只管写代码BMAD 这两年的演进方向其实非常一致把不该让 LLM 干的活一件一件从 LLM 手里拿回来。意图理解该锁定的用 SPEC 锁定调度该确定的用 Python 确定该人拍板的挂起 run 等人。LLM 越来越被收敛到它真正擅长的那块创意工作上。这不是对 LLM 不信任恰恰是对它的尊重——别让它干它不擅长、又会幻觉、还按字收费的活。如果你也在用 BMAD 做项目强烈建议拿一个 sprint 来认真试一次 BMAD Loop。哪怕只是为了让deferred-work.md那本永远没人还的债账终于有人管也值。
怎么用：上手三步
前置条件就一条你得有一个BMAD v6 项目而且bmad-sprint-planning已经跑过、生成了sprint-status.yaml。换句话说PRD / 架构 / epicsstories / sprint planning 这条链得先走完Loop 才有故事可转。装好之后通过bmad-loop-setup这个 skill它会从 Git 装 Python 工具 跑bmad-loop init注册 hook、铺 skill、写 policy.toml核心命令其实很少bmad-loop init # 装 bmad-loop-* skill hook policy.toml gitignore bmad-loop validate # 预检config / sprint-status / git / tmux / CLI / hook bmad-loop run --dry-run # 先打印计划不真的拉起会话 bmad-loop run # 开跑 bmad-loop tui # 或者干脆全在可视化面板里操作完整命令清单覆盖了run / sweep / resume / resolve / decisions / status / attach / stop / clean等但日常 90% 的场景就是上面这几条。bmad-loop tui那个仪表盘挺漂亮——run 选择器、sprint 树、deferred-work 台账、每个 story 的实时任务表、带颜色的日志流一屏打尽。一个必须知道的一次性设置坑如果目标项目里 coding CLI 从来没跑过比如 claude 没在这个目录启动过你要先手动启动一次接受 workspace-trust 和 hooks 审批对话框。编排器拉起的子会话没法替你点这些首次运行对话框而一个挂着的对话框会被编排器误判成会话超时。血统从 Story Automator 到 BMAD Loop把 BMAD Loop 放回时间线里它的位置就很清楚了Story Automator bmad-automator / bmad-auto BMAD Loop (2026 初, 我那篇 (中间的过渡形态, (6.10, 重写为 实测的版本) 工具名 bmad-auto) 确定性 Python 编排器) │ │ │ └──── 控制环里有 LLM ─────┴───── 重写 ────────► 控制环里没有 LLM ──┘ (慢、贵、易跑偏) (确定、可调试、省钱)README 里写得很坦诚Inspired by the original bmad-automator (a separate, legacy project)——它明确把上一代当成 legacy自己是从头来的重写。而它给自己定位是a deterministic ralph-loop orchestrator。如果你关注过 autonomous dev 这个圈子应该听说过 Ralph——那个让 Claude Code 自己跑开发循环的工具。BMAD Loop 借用了ralph-loop这个模式无人值守、反复迭代的小循环但把它确定性地实现在了 BMAD 的 story 体系上。所以它是Ralph 的精神 BMAD 的骨架 Python 的中枢。适合谁不适合谁延续我测评 Story Automator 时的坦诚基调给你一个不吹的判断。适合用的场景你已经完整走完 BMAD 的规划链PRD → 架构 → epics → sprint planning手头有一串清晰、可独立实现的 story你接受睡前梭一把这种异步交付模式——第二天起来看结果而不是盯着它实时干你的项目有可靠的测试和 lint机制三最后那道闸靠它们否则 verify 形同虚设你想做多模型互相 review又不想自己手动切来切去不适合 / 要谨慎的场景story 还很模糊、依赖关系没理清——这种跑进循环里大概率触发一堆 CRITICAL 升级反而更累没有测试的项目——编排器再聪明最后那道 verify 闸门空转等于裸奔期待它又快又好又自动——确定性编排让它更稳、更省但单 story 的绝对速度未必比一个熟手手工盯更快。它的价值在批量、异步、可恢复不在单点提速和上一代最大的区别也是我现在最看好它的一点因为控制环是确定性代码它可调试、可复现、可信任。Story Automator 时代那个为什么这么慢的黑盒这一次终于打开了——流程是 Python你看得到每一步在干嘛、为什么这么决策。光这一点就值得把它从试验品升级成可以认真用起来的工具。写在最后从 v6.8 的锁定意图让 AI 先搞懂你要什么到 6.10 的 BMAD Loop让确定性的代码当调度员、LLM 只管写代码BMAD 这两年的演进方向其实非常一致把不该让 LLM 干的活一件一件从 LLM 手里拿回来。意图理解该锁定的用 SPEC 锁定调度该确定的用 Python 确定该人拍板的挂起 run 等人。LLM 越来越被收敛到它真正擅长的那块创意工作上。这不是对 LLM 不信任恰恰是对它的尊重——别让它干它不擅长、又会幻觉、还按字收费的活。如果你也在用 BMAD 做项目强烈建议拿一个 sprint 来认真试一次 BMAD Loop。哪怕只是为了让deferred-work.md那本永远没人还的债账终于有人管也值。
