【敏捷FAQ 今日实验室】BMAD 能否消除对“唯AI是从开发”的不安？（前篇）

 感谢您阅读本文。我是隶属于敏捷组的藤井智弘。
 在上一篇番外篇《日本式アジャイル撲滅》中，我写到 AI 驱动开发有可能成为日本式敏捷的新招牌。这次是接续上一篇的“实验室”（……话说，究竟什么时候才能回到正篇……）。
 我长期专注于使用用例和故事进行需求管理等“上游工程”。“要做什么”（What）是如何决定并被语言化的，始终是我工作的核心。对这样的我而言，近来的 AI 驱动开发似乎蕴含着一种“稍不留神就会变成唯命是从”的危险，因此让我感到不太踏实。
 不过，随着 AI 在开发中的应用领域以惊人的速度扩大，当它进入我的专业领域时，我不可能不在意。

 因此，在这间实验室里，我将实际试用最近一段时间（真的）沉迷其中的 BMAD Method（以下简称 BMAD）。我想既有想快速了解的人，也有想亲自试试的人，因此前篇将展示实际对话的示例及评价，后篇则作为面向想试用者的操作指南（没什么深度可言）。
 评价的视角有以下三个。

1. 如果唯 AI 是从，会怎样
2. 能否与 AI 建立对话
3. 这种对话是否不仅仅是简单的问答，而是有助于打磨人的想法

• 视角1：即使人在不回答任何问题的情况下继续推进，工具也会给推测打上标记，并保留需要确认的问题。不过，它仍然基于这些推测生成了一份长达 586 行的需求规格；而当人实际作答后，发现许多前提都与现实不同
• 视角2：对话可以成立。AI 会复述听到的内容以进行确认，根据回答改变接下来的问题，也能接受“我不知道”这一回答
• 视角3：它有助于打磨想法。题目从“新建一个网站”被改写为“探寻现有网站未被使用的原因”，我的判断也被重新定位为“需要验证的假设”。不过，打磨并非单向进行，人修正 AI 提议的场景同样重要

 即使工具能提出问题，回答的人依然是人。如果在不回答的情况下继续推进，最终仍会趋近于“唯 AI 是从”。

 BMAD 是 Breakthrough Method for Agile AI-Driven Development 的缩写，是一种开源的 AI 驱动开发方法。它可集成到 Claude Code 这样的编码 AI 工具中使用。
 其特点是，将 AI 智能体分别设定为开发团队中的不同角色，各自创建本阶段的文档并交给下一阶段。

 也可以根据规模省略规划阶段；在任何阶段，谁以何种方式做出了什么决定，都会逐行保留在记录文件（.memlog.md）中。
 本文关注的只是表中分析和规划阶段，也就是 BMAD 能在规格确定“之前”提供多大程度的支持。不讨论设计、实施、代码质量及与其他方法的比较。

 题目是某虚构软件供应商提出的以下需求。

为本公司产品的用户建立支持网站，最大化客户的便利性。

 起点只有这一句话。
 我以两种方式进行了推进。实验 1 验证视角 1，实验 2 验证视角 2 和 3。

 表中的“决策记录”是前述记录文件中留下的行数。“推测标记”将在视角 1 中详细说明。

 BMAD 会输出相当多的文档，因此本文介绍的输出均为关键部分的摘录。完整内容，请务必按照后篇的步骤亲自尝试并确认。
 首先是实验 1 的产品概要开头部分。

为本公司产品的用户建立一个支持网站，使其遇到困难时能够自行找到答案；若找不到，也能毫不迷茫地联系到人工支持。需求中所说的“最大化便利性”在当前形式下无法衡量。因此，本概要将其重新表述为：能够快速、可靠地解决问题。
据调查，问题并不在于“没有支持网站”，而在于“即使有也找不到”。通过自助服务完全解决的咨询仅占 14%，失败的最大原因是“找不到相关信息”（超过 43%）（Gartner，2024 年）。

 坦白说，做得很好。AI 在没有询问任何人的情况下，甚至进行了 Web 调研，并将不可衡量的“最大化便利性”改写为了可衡量的表述。对于推测的部分，也都恰当地加上了标记。
 先在这里说明一下“推测标记”。BMAD 的 AI 在根据推测写下未经人确认的内容时，会在该处加上 [ASSUMPTION]（英文意为“假设”）标记。它表示“这里是 AI 的推测，尚未经过任何人确认”。在不向人提问的实验 1 中，所有未知事项只能用推测填补，因此这样的标记会很多。此外，无法用推测填补、只能由人回答的问题，会汇总在文档末尾，作为“未经确认的问题”保留下来。
 实际的课题章节如下。标题旁的 [ASSUMPTION] 就是这一标记。

本公司方面 [ASSUMPTION]

• 同样的问题反复出现，占用了支持人员的时间。
• 因为回答没有留存在任何地方，无法交接给下一位负责人。

 在文末的“未经确认的问题”中，也确实保留了需要验证的问题。

3. 现有的 FAQ、手册和咨询窗口有哪些，由谁管理？
4. 目标是客户满意度，还是降低支持成本？如果两者兼顾，发生冲突时优先哪一方？

 随后生成的 PRD 有 586 行。27 条功能需求被编了号。PRD 中有一个名为“使用场景（用户旅程，UJ）”的章节，以具名人物的故事描述用户如何使用产品；其中第一个是这样开始的。

UJ-1. 财务负责人佐藤先生，在月末结账作业过程中自行解决出现的错误。
佐藤先生是一名在每月结账时使用本公司产品的财务负责人。他不熟悉产品。截止期限迫在眉睫。

 “佐藤先生”并未出现在产品概要中。在 PRD 该章节的开头，AI 自己这样注释道。

产品概要中没有关于用户实际使用场景的描述。以下内容是根据产品概要中的“为谁而做”“要做什么”构建的设想。

 也就是说，佐藤先生是 AI 在 PRD 阶段新设想出来的人物，推测之上又叠加了推测（当然，这个场景也带有推测标记）。那么，实际情况是怎样的？下面与实验 2 中我所作的回答并列比较。

 公平地说，工具完成了它该做的事情。不过，推测标记只有在人阅读并确认时才有意义。 如果不确认标记就将内容传递到下一阶段，27 条功能需求就可能建立在实际上并不存在的“支持人员”或“财务负责人佐藤先生”这一前提之上。
 在唯 AI 是从的情况下，需要警惕的并不只是会生成错误的文档，而是看似合理的文档很容易在未被验证的情况下，成为下一工程的前提。

 在实验 2 中提供同样的需求后，分析师没有立即生成文档，而是先要求我把脑中的内容全部写出来。当我想到什么就写下关于产品、当前咨询流程、契机及优先事项的内容后，它将听到的内容重新整理成表格并反馈给我。

 复述听到的内容以进行确认，并指出关键卡点所在。这和优秀倾听者所做的事情是一样的。选择“快速路径”后，剩余的不明事项被归纳为 6 个问题；对于我回答“不明”的地方，它要么以带有推测标记的形式补全，要么作为“尚未了解的事项”保留下来。之后补充发送的回答，也得到了准确反映。
 对话可以成立。 不过，在“快速路径”中，问题会集中到来，因此互动更接近于问答。顺带一提，还有一种“细致路径（Coaching path）”，它会逐题追问并推进。请大家务必亲自试试看。

 这是我最想了解的地方。

题目被改写，手段的选项也扩大了

 当我回答“已经有一个简单的网站”时，分析师便将题目改写为“探寻现有网站未被使用的原因”，并补充道：

如果操作相关的问题很多，而且用户是在工作过程中遇到问题，那么之后或许还需要重新审视“网站”这一形式本身是否正确。

 实际上，之后它结合同行业其他公司的调研结果问我：“范围是否仅限于网站，还是也包括从产品界面中调用的帮助功能？”我回答：“因为优先考虑快速上线，所以首先只做网站。”扩展选项的是 AI，做出选择的是我。

判断被重新定位为假设

 针对“为什么现有网站不起作用”，我回答：“我认为是文章不够，且难以查找。”产品概要中这样写道：

“操作相关的问题很多”“文章不够且难以查找”，二者都只是判断，而非经验证的结果。

 既不否定，也不当作事实，而是重新定位为“首先需要验证的事项”。我在第 3 回到第 5 回中谈过先确认“现有功能”的事情，同样的动作也发生在需求阶段。

衡量标准变得可用

 当我回答满意度是“综合问卷、解约情况和续约时的反馈来判断”时，分析师表示：“由于这是需要花时间才能看到结果的指标，因此我补充了可以在前面更快产生反应的指标”，并加入了解决所需时间等指标。在它指出之前，我没有意识到自己缺少在过程中确认重建的网站是否有效的手段。

无法回答的问题被保留了下来

 在草稿完成后，分析师针对最薄弱的点追问了我：

谁来撰写文章，并持续更新？
如果在没有支持人员的情况下让开发人员负责制作文章，“回答问题的负担”只会变成“撰写文章的负担”。

 我无法回答，只回复了“现在无法决定”。它被保留在产品概要“尚未了解的事项”的首位。将尚未得到答案的问题放在最显眼的位置，我认为也是打磨的一部分。

打磨并非单向进行

 也有反向的场景。分析师在草稿开头将题目改写为：“让操作相关的问题无需询问他人，便能在短时间内解决。剩余问题由非开发人员的窗口接收。”而在最终完成阶段，它声明这仍然是尚未获得我同意的提议。重新阅读后，我发现开发人员从流程中被遗漏了。实际上，一级窗口无法处理的咨询会升级给开发人员，而且我也希望利用 AI。这样告诉它之后，改写内容被修正为：

让用户能够通过网站（并借助 AI 的帮助）在短时间内自行解决大多数操作相关的问题。无法自行解决的问题由一级窗口接收，只有一级窗口也无法解决的问题才升级给开发人员。

 分析师自身此前提出的“首个版本不包括 AI 自动回复”这一推测，也在此时被撤回，并记录在记录文件中。
 它有助于打磨想法。 不过，并不是 AI 单方面完成了打磨。AI 的问题动摇了人的判断，人的回答修正了 AI 的提议。回顾来看，就像实验 1 原样接受了“建立网站”一样，我也差点在不怀疑“网站”这一手段及自身判断的情况下作答。区别仅在于，是否有一个能够提出问题的对象。

• 不会代替人思考：产品概要技能的说明中写着“不要代替对方思考”“如果回答过于浅薄就追问”（原文为英文，引用为笔者译文。下同）。实际行为也正如视角 2、3 所示
• 对推测进行标记，并保留未决定的事项：PRD 的说明规定，即便在不询问人的情况下推进，“也不得编造成功指标或范围判断，必须予以记录”。实际上，目标值仍保留为空，PRD 也将自身状态报告为“部分完成（需要人工确认）”，而非“完成”
• 区分 AI 的提议与人的决定：如视角 3 所见，它将尚未获同意的改写声明为“提议”。这可能是防止“唯 AI 是从”最重要的性质
• 设置制衡指标：PRD 中设置了这样一项指标：“咨询数量——不应将减少本身作为目标。因为只要隐藏入口，就能轻易减少。”这正是我在第 9 回、第 10 回中所写的“不把指标当作成绩单”的理念
• 未决定的 What 不会流入下一阶段：拆分为史诗和故事的技能中，没有不询问人就推进的路径。说明中写着“不要在没有人类输入的情况下生成内容”；在实施前的判定中，也会问“是否能在不编造未被记录的判断的情况下实施”。这与所谓的“就绪定义（Definition of Ready）”是同一个问题
• 保留决策记录：连推测的撤回也会逐行保留。这与第 5 回的“神秘行为判断清单”以及架构决策记录（ADR）有着相同的思路

• 推测也会融入结构完整的文档中：要逐一确认 586 行中的 31 处标记并不容易。文档越完整，就越容易想跳过确认直接往下走，因此需要有意识地注意
• 调研只是一般论：调研本身是准确的。产品概要引用的 Gartner 调研（2024 年 8 月）确实存在，数据也与来源一致。不过，Web 调研所能了解的是世间的一般情况，无法反映这家公司“没有支持人员”的具体情况。正因为调研可靠，推测部分也会显得很可靠，这一点或许需要注意
• 只有在人作答时，才会重新审视手段：实验 1 从头到尾都将“建立网站”作为前提
• 流程安排可能看起来像瀑布式敏捷：如果针对整个系统一次性执行这一流程，并以合同冻结文档，就可能变成我在“撲滅”一文中写的“用 AI 更快敲键盘的瀑布模型”。它也准备了在中途修正方针的机制（Correct Course），希望能善加利用
• 文档会增加：从一句需求开始，13 分钟就生成了 586 行。越是用 AI 撰写，越需要具备判断“这是谁在何时阅读的文档”的纪律
• 回答所需的时间只能由人投入：BMAD 大幅代劳了“创建方案”的一侧，但无法代劳“做决定”的时间

1. 由人消除所有推测标记和未经确认的问题后，再进入下一阶段。可以将标记数量直接理解为“人需要确认的事项数量”
2. 将最初的工作设为“验证判断”。不要将需求或判断当作事实
3. 不要整体推进，而是按史诗单位循环。不要将文档视为合同附件，而应视为一旦学到新东西就要修改的文件
4. 不要混淆 AI 的提议与人的决定。改写、成功衡量标准、哪些内容不做，只有在获得人认可后才作为决定对待

 我在第 1 回中写过，每当 CASE、RAD、低代码等新工具出现，人们都会问“基础是否不再需要”。每次的结论都是一样的：工具改变的是“如何做”，而“做什么”“学习什么”仍然留在人这一侧。BMAD 已经进入到了“做什么”的前一步，但实际使用后我发现，留在人这一侧的工作并没有消失，而是变得清晰可见了。
 还有一点发现。我的回答大多只是简短的词语，但 AI 会将其复述，并整理成结构完整的产品概要。语言化这项工作本身，AI 能够提供相当大的帮助。
 另一方面，实验 1 猜错的不是措辞，而是事实。留给人的，是语言化的内容。了解现场事实的能力。能够区分判断与已验证事实的能力。能够说出“现在无法决定”的能力。能够指出 AI 提议哪里不对的能力。相比于“编写”需求的技能，“引出、验证、决定”需求的技能在 AI 时代会变得更加重要。作为长期从事上游工程的人，这是一项令我有些欣慰的发现。
 无论工具变得多么智能，掌握 What 内容的依然是人。因此，人很重要。

 写完之后，我还意识到了“作业”和“工作”的区别。机械地完成既定步骤是作业，带来有意义结果的是工作。我想，“唯 AI 是从”与“和 AI 对话”的差异就在这里。与 AI 对话时，我会思考那些此前未曾想到过的条件，也会思考这些究竟有什么用。
 我经常被问到：“如果 AI 成长起来，Scrum Master 和开发者会不会不再需要？”但在完成这次实验后，我觉得还有一个比这更重要的问题。AI 能否成为帮助 PO 成熟的伙伴？它能在决定做什么的 PO 身边提出问题、动摇判断，并将尚未得到答案的事情摆在眼前。作为 AI 的定位，这一角色要重要得多。
 前者是减少人的话题，后者是发挥人的价值的话题。
 如果是我，我希望站在后者的立场，向客户推荐 AI。

 那么，我想问问读到这里的各位。
 如果有像 BMAD 这样的工具，是否感觉可以避免“唯 AI 是从”了呢？

 ……虽然这样问，但笔者自己也还是 BMAD 的新手，还必须继续精进。

后篇（操作篇）：“实际运行 BMAD——从搭建环境到比较‘仅 AI’与‘人作答’的方法”／下次：“PO 很忙，无法来到团队中”（12/1）／正篇连载列表请参阅第 1 回。