BMAD Story Automator 上手实录：把 5 个待办 Story 交给 AI 自主推进

文章BMAD Story Automator 上手实录：把 5 个待办 Story 交给 AI 自主推进分享给大家，欢迎收藏极客资料网，专注分享技术知识

如果你已经习惯通过 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
  → 在失败或冲突时升级给人类

从设计上说，它是在自动化“协调工作”，而不是直接替代某一个具体开发步骤。

---

升级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 分 / Medium
• Story 6.1 “通过 SDK AgentMCPServer 暴露 Axion” → 2 分 / Low
• Story 6.2 “axion mcp 命令与外部 Agent 集成验证” → 2 分 / Low
• Story 7.1 “基于 SDK Pause Protocol 的用户接管机制” → 2 分 / Low
• Story 7.2 “--fast 模式” → 5 分 / Medium

更关键的是，它不只给分，还给出原因：

• authorization / permissions
• 实时通信
• 验收标准数量高
• Story 文本较大

这意味着复杂度评估不是黑盒。你看到的不只是“结论”，而是“为什么它觉得这个 Story 更难”。这会直接影响后续的 Agent 选择策略。

换句话说，Story Automator 在做的事其实是：

先把 Story 变成“可调度对象”，再决定谁来执行。

---

第三步：你可以塞入自定义指令，但默认不强迫你多想

接下来它会问你有没有自定义指令。

比如：

• 每次修改后都运行测试
• 优先处理某个 Story
• 注意数据库迁移

这个设计我很喜欢，因为它在“全自动”和“可控”之间找到了一个不错的平衡：

• 如果你没有特殊要求，直接选 none
• 如果你有本轮迭代的偏好，可以临时注入

也就是说，它把“人类经验”当成一种可选输入，而不是每次都强迫你从头配置一大堆参数。

---

第四步：执行设置决定它跑得多激进

再往下，就是执行策略层面的配置。截图中可以看到两个核心问题：

1. 是否跳过 automate 步骤（测试自动化）
2. 最大并行会话数是多少

默认值是：

• 不跳过 automate
• 最多 1 个并行会话

对大多数真实项目来说，测试自动化是交付闭环里最不该轻易跳过的一环；而并行度默认设为 1，也避免了多个会话同时改动同一代码库时互相干扰。也就是说：

默认先追求“可控完成”，而不是“并行冲刺到极限”。

---

第五步：不同复杂度，自动映射到不同 Agent

有了复杂度矩阵之后，Story Automator 就能推荐 Agent 配置。

推荐配置如下：

• Low：create / dev / auto / review 都用 Claude
• Medium：create / dev / auto / review 都用 Codex，Claude 作为备选
• 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 里。

所以我现在对它的看法很简单：

白天手工跑，目前还是自己手工跑会更快。
但睡前把一批 Story 交给它过夜跑，这个场景它真的挺合适。

如果你正在使用 BMAD 来开发项目，你一定要试一下 Story Automator，它可能是你将重复协调时间从小时级降到分钟级的工具。

文章来源:https://www.cnblogs.com/NickYao/p/20040989
本文来自互联网用户投稿，该文观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若内容造成侵权/违法违规/事实不符，请联系邮箱：jacktools123@163.com进行投诉反馈，一经查实，立即删除！