如果你已经习惯通过 BAMD 写代码，接下来真正耗时间的，往往不是“写”，而是“协调”。
一个 Epic 里有 5 个、10 个、20 个 Story。每个 Story 都要经历创建规格、开发实现、自动化测试、代码审查、回顾总结。真正让人疲惫的，不是某一步本身，而是你要不断盯着流程、切换会话、处理失败、决定下一步。
Story Automator 想解决的，就是这层“人肉编排”。
昨晚我实际跑了一遍 /bmad-story-automator 的完整流程。下面就是这次使用过程的记录，以及一些当时截下来的图。
先用一句话概括 Story Automator：
你告诉它要处理哪些 Story、用什么执行策略，它就自动完成「创建规格 → 开发实现 → 测试自动化 → 代码审查 → 回顾」这条流水线，只在真的需要人类决策时才打断你。
这和普通“单命令跑一个 Skill”不一样。它更像一个构建周期编排器：
初始化
→ 读取 Epic / Sprint 状态
→ 选择 Story 范围
→ 评估复杂度
→ 选择 Agent 策略
→ 执行 create / dev / automate / review / retro
→ 在失败或冲突时升级给人类
从设计上说，它是在自动化“协调工作”，而不是直接替代某一个具体开发步骤。
如果你想体验 Story Automator，需要先把 BMAD 升到 6.6。安装时记得把 BMad Automator (Experimental) 这个模块勾上。
不然装完 BMAD，后面是用不起来的。
第一次执行 /bmad-story-automator 时，它不会急着开跑，而是先做初始化检查。
从下面这张图可以看到，它先加载配置，然后尝试读取当前编排状态；如果发现状态目录还不存在，这是正常的首次运行场景。接着它会自动安装 Stop Hook 到 .claude/settings.json 中。
真正进入编排前，Story Automator 会先读取 Epic 和 sprint 状态，然后让你决定处理范围。
下面这张图展示了一个很典型的场景：Epic 5、6、7 中一部分 Story 已完成，一部分仍然待办。工具会把这些状态直接展示出来，然后询问你要处理哪些 Story。
这是我觉得 Story Automator 最有意思的部分之一。
它不是把所有 Story 一股脑丢给同一个 Agent，而是先生成一个Story 复杂度矩阵。截图里可以看到：
更关键的是，它不只给分，还给出原因：
这意味着复杂度评估不是黑盒。你看到的不只是“结论”，而是“为什么它觉得这个 Story 更难”。这会直接影响后续的 Agent 选择策略。
换句话说，Story Automator 在做的事其实是：
先把 Story 变成“可调度对象”，再决定谁来执行。
接下来它会问你有没有自定义指令。
比如：
这个设计我很喜欢，因为它在“全自动”和“可控”之间找到了一个不错的平衡：
none也就是说，它把“人类经验”当成一种可选输入，而不是每次都强迫你从头配置一大堆参数。
再往下，就是执行策略层面的配置。截图中可以看到两个核心问题：
automate 步骤（测试自动化）
默认值是：
对大多数真实项目来说，测试自动化是交付闭环里最不该轻易跳过的一环；而并行度默认设为 1，也避免了多个会话同时改动同一代码库时互相干扰。也就是说：
默认先追求“可控完成”，而不是“并行冲刺到极限”。
有了复杂度矩阵之后，Story Automator 就能推荐 Agent 配置。
推荐配置如下：
从这个配置可以看出，它已经不是“调用一个模型”的层面了，而是在做模型编排。
而且它还提供了策略选项：
不同团队可以这样用：
而从后面的配置摘要截图也能看出来，这次实际演示最后保存成了 all-claude。这恰好说明：推荐是推荐，不是强制。 你既可以让系统按复杂度智能分配，也可以为了稳定性或一致性，手动统一到同一类 Agent。
这一步让整个系统更像一个“调度器”，而不是一个简单的命令包装器。
当你确认后，Story Automator 会把这次运行配置保存下来。截图里展示的是一个名为 all-claude 的配置摘要：
摘要里写了几件事：
这类“摘要页”看起来很普通，但它是编排器可恢复、可审计、可复盘的基础。
因为自动化一旦跨越多个 Story、多次会话、多个阶段，就一定会面对这些问题：
有了显式保存的配置，后续无论是恢复执行还是事后分析，都不会变成猜谜游戏。
昨晚睡觉前，我直接把这 5 个 Story 交给 Story Automator 去跑。早上起来看结果，它总共跑了 5 个半小时。
坦白说，速度是比我自己手工盯着跑要慢的。按我平时的节奏，这 5 个 Story 如果自己来，估计 3 个小时内能收完。至于为什么会慢这么多, 具体原因还不太清楚, 还没有仔细的去分析它的实现原理，不过目前还只是试验版，能跑通比较重要。
目前比较适合：睡觉前梭一把。
另外一个我觉得做得不错的点，是每个 Epic 跑完之后，它会顺手做一次复盘，把有用的信息补到 project-context.md 里。
所以我现在对它的看法很简单：
白天手工跑，目前还是自己手工跑会更快。
但睡前把一批 Story 交给它过夜跑，这个场景它真的挺合适。
如果你正在使用 BMAD 来开发项目，你一定要试一下 Story Automator，它可能是你将重复协调时间从小时级降到分钟级的工具。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。