企业官网建设流程全解析

前置条件就一条：你得有一个BMAD v6 项目，而且bmad-sprint-planning已经跑过、生成了sprint-status.yaml。换句话说，PRD / 架构 / epics&stories / 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那本"永远没人还的债账"终于有人管，也值。