顾总结。真正让人疲惫的不是某一步本身而是你要不断盯着流程、切换会话、处理失败、决定下一步。Story Automator 想解决的就是这层“人肉编排”。昨晚我实际跑了一遍/bmad-story-automator的完整流程。下面就是这次使用过程的记录以及一些当时截下来的图。它解决的不是“写代码”而是“盯流程”先用一句话概括 Story Automator你告诉它要处理哪些 Story、用什么执行策略它就自动完成「创建规格 → 开发实现 → 测试自动化 → 代码审查 → 回顾」这条流水线只在真的需要人类决策时才打断你。这和普通“单命令跑一个 Skill”不一样。它更像一个构建周期编排器初始化 → 读取 Epic / Sprint 状态 → 选择 Story 范围 → 评估复杂度 → 选择 Agent 策略 → 执行 create / dev / automate / review / retro → 在失败或冲突时升级给人类从设计上说它是在自动化“协调工作”而不是直接替代某一个具体开发步骤。升级BMAD到最新版(v6.6)如果你想体验 Story Automator需要先把 BMAD 升到6.6。安装时记得把BMad Automator (Experimental)这个模块勾上。不然装完 BMAD后面是用不起来的。第一次运行先补齐 Stop Hook防止工作流半路被打断第一次执行/bmad-story-automator时它不会急着开跑而是先做初始化检查。从下面这张图可以看到它先加载配置然后尝试读取当前编排状态如果发现状态目录还不存在这是正常的首次运行场景。接着它会自动安装Stop Hook到.claude/settings.json中。第一步先选 Story不是盲跑所有待办项真正进入编排前Story Automator 会先读取 Epic 和 sprint 状态然后让你决定处理范围。下面这张图展示了一个很典型的场景Epic 5、6、7 中一部分 Story 已完成一部分仍然待办。工具会把这些状态直接展示出来然后询问你要处理哪些 Story。第二步复杂度不是拍脑袋而是先打分再分配 Agent这是我觉得 Story Automator 最有意思的部分之一。它不是把所有 Story 一股脑丢给同一个 Agent而是先生成一个Story 复杂度矩阵。截图里可以看到Story 5.3 “Server 命令与 API 认证” →4 分 / MediumStory 6.1 “通过 SDK AgentMCPServer 暴露 Axion” →2 分 / LowStory 6.2 “axion mcp 命令与外部 Agent 集成验证” →2 分 / LowStory 7.1 “基于 SDK Pause Protocol 的用户接管机制” →2 分 / LowStory 7.2 “--fast 模式” →5 分 / Medium更关键的是它不只给分还给出原因authorization / permissions实时通信验收标准数量高Story 文本较大这意味着复杂度评估不是黑盒。你看到的不只是“结论”而是“为什么它觉得这个 Story 更难”。这会直接影响后续的 Agent 选择策略。换句话说Story Automator 在做的事其实是先把 Story 变成“可调度对象”再决定谁来执行。第三步你可以塞入自定义指令但默认不强迫你多想接下来它会问你有没有自定义指令。比如每次修改后都运行测试优先处理某个 Story注意数据库迁移这个设计我很喜欢因为它在“全自动”和“可控”之间找到了一个不错的平衡如果你没有特殊要求直接选none如果你有本轮迭代的偏好可以临时注入也就是说它把“人类经验”当成一种可选输入而不是每次都强迫你从头配置一大堆参数。第四步执行设置决定它跑得多激进再往下就是执行策略层面的配置。截图中可以看到两个核心问题是否跳过automate步骤测试自动化最大并行会话数是多少默认值是不跳过 automate最多 1 个并行会话对大多数真实项目来说测试自动化是交付闭环里最不该轻易跳过的一环而并行度默认设为 1也避免了多个会话同时改动同一代码库时互相干扰。也就是说默认先追求“可控完成”而不是“并行冲刺到极限”。第五步不同复杂度自动映射到不同 Agent有了复杂度矩阵之后Story Automator 就能推荐 Agent 配置。推荐配置如下Lowcreate / dev / auto / review 都用 ClaudeMediumcreate / dev / auto / review 都用 CodexClaude 作为备选High同样以 Codex 为主Retro回顾阶段使用 Claude从这个配置可以看出它已经不是“调用一个模型”的层面了而是在做模型编排。而且它还提供了策略选项Suggested采用按复杂度分层的推荐配置Uniform所有 Story 都使用同一个 Agent不同团队可以这样用想稳一点按推荐走想保持行为一致就统一 Agent而从后面的配置摘要截图也能看出来这次实际演示最后保存成了all-claude。这恰好说明推荐是推荐不是强制。你既可以让系统按复杂度智能分配也可以为了稳定性或一致性手动统一到同一类 Agent。这一步让整个系统更像一个“调度器”而不是一个简单的命令包装器。第六步配置会被显式保存方便恢复和复盘当你确认后Story Automator 会把这次运行配置保存下来。截图里展示的是一个名为all-claude的配置摘要摘要里写了几件事Epic 是哪个Story 范围是什么自定义指令有没有create / dev / auto / review / retro 分别用什么 Agent是否跳过自动化这类“摘要页”看起来很普通但它是编排器可恢复、可审计、可复盘的基础。因为自动化一旦跨越多个 Story、多次会话、多个阶段就一定会面对这些问题中途停了怎么办我这次到底选了什么配置为什么这批 Story 用的是这个 Agent 组合有了显式保存的配置后续无论是恢复执行还是事后分析都不会变成猜谜游戏。实际体验结论昨晚睡觉前我直接把这 5 个 Story 交给 Story Automator 去跑。早上起来看结果它总共跑了5 个半小时。坦白说速度是比我自己手工盯着跑要慢的。按我平时的节奏这 5 个 Story 如果自己来估计3 个小时内能收完。至于为什么会慢这么多, 具体原因还不太清楚, 还没有仔细的去分析它的实现原理不过目前还只是试验版能跑通比较重要。目前比较适合睡觉前梭一把。另外一个我觉得做得不错的点是每个 Epic 跑完之后它会顺手做一次复盘把有用的信息补到project-context.md里。