当 BMAD 开发工作流遇上 PPT 周报生成:BMAD Quick Dev 的边界拓展

一个为代码开发设计的 AI 工作流，如何驾驭"读 Excel + 浏览器截图 + 编辑 PPT"这种跨工具链的非编码任务？

背景

每周五下午，团队都要做一件重复但不能省的事：打开 Excel 汇总表，把"上周完成"和"本周计划"复制到 PPT 模版里，再登录云服务商控制台截一张监控大盘图贴进去。整个过程大约 30 分钟，纯机械操作。

这种任务看起来和"写代码"毫无关系。但当我把它交给 BMAD Quick Dev 工作流时，发现这套为软件开发设计的方法论框架，处理非编码任务同样得心应手——甚至比手动操作更可靠。

为什么用 BMAD Quick Dev？

在上一篇文章中，我们用 BMAD Quick Dev 完成了一个 Bug 修复的闭环。那次的场景很"标准"：读代码、改代码、写测试、代码审查。

但这次不一样。周报生成涉及：

• • 读取 Excel 文件（openpyxl）
• • 编辑 PPTX 文件（python-pptx + lxml）
• • 操控 Chrome 浏览器截图（Claude Chrome Extension）
• • 图像合成与下载（Canvas API）

没有一行应用代码需要修改，也没有测试可以跑。BMAD 在这种场景下还能发挥作用吗？

答案是：不仅能，而且正是这种"看似简单实则步骤繁多"的任务，最能体现 BMAD 步骤文件架构的价值。

我是 AI灵感闪现，使用 OpenClaw 小龙虾 让 AI 自主管理工作和生活上的问题；使用 Claude Code + BMAD AI 驱动敏捷开发框架，让 AI 自主开发和交付软件来表达想法和灵感。是 MoneyMind 省钱思维 App 和 HeartPetBond 心宠纽带 App 开发者。正在实践和分享让 AI 自主解决健康、生活、投资和等方面的问题。我尽可能让 AI 自己完成从目标到交付以及演进的闭环，以最少的人为交互与监督，让 AI 自己跑流程。我只给 AI 想法或目标，全程不陪跑，让 AI 自主运行类似 Tesla FSD 自动驾驶。

BMAD 工作流实录

Step 1: Mode Detection —— 判断执行模式

Quick Dev 的第一步不是"开始做"，而是评估。

AI 读取了 Issue 文件（任务描述），自动完成了三件事：

1. 1. 捕获基线状态：记录 baseline_commit，确保后续可以追溯变更
2. 2. 判断执行模式：没有技术规格文件 → Mode B（直接指令）
3. 3. 评估升级必要性：任务涉及文件操作和浏览器自动化，但结构明确、无架构影响 → Escalation Level 0-1，不需要升级到完整 BMAD 流程

{baseline_commit} = 228f4e8{execution_mode} = "direct"Escalation: 0-1 (focused task with clear steps)

然后给出选择：[P] Plan first（先做技术规格） 还是 [E] Execute directly（直接执行）。

BMAD 的价值： 如果没有这一步，AI 会直接开始读 Excel、写 Python。而 Mode Detection 强制 AI 先退一步思考全局——这个任务的复杂度是否超出了快速开发的范围？是否需要先出一份技术规格？

对于周报生成这种任务，答案显然是 [E]。但这个"显然"是经过评估得出的，不是拍脑袋决定的。

Step 2: Context Gathering —— 收集上下文

这一步是 BMAD 对"直接指令"模式的特殊处理。在技术规格模式下会跳过，但直接指令模式下，AI 需要自主完成上下文收集。

工作流要求 AI 完成四件事：

1. 识别需要操作的文件

- 模版文件：weekly-report-template.pptx- 数据源：project-tracker-20260313.xlsx（sheets: 最近版本, 最近计划）- 输出：weekly-report-20260315.pptx

2. 发现相关模式

AI 检查了目标目录下的历史周报文件，确认了命名规范（周报_YYYYMMDD.pptx）、模版结构（6 个 Slide）、以及 Excel 数据的表头格式。

3. 检查依赖

openpyxl  → 已安装python-pptx → 未安装，需要 pip installChrome → 需要登录云服务商账号

4. 生成执行计划并推断验收标准

Plan:1. Install python-pptx2. Copy template → new file with today's date3. Read Excel → update Slide 2 (上周处理内容)4. Read Excel → update Slide 3 (本周工作计划)5. Chrome screenshot → update Slide 5 (云服务监控)Inferred AC:- New PPTX file created with today's date- Slides populated with correct data from Excel- Cloud monitoring screenshot captured and embedded

BMAD 的价值： Context Gathering 要求 AI 先检查依赖再动手。这避免了一个常见问题——AI 写了一大段代码，运行时才发现 python-pptx 没装。提前发现、提前解决，不浪费上下文窗口。

更重要的是，验收标准是 AI 推断出来的，不是人类写的。这意味着 Self-Check 阶段有明确的核验目标。

Step 3: Execute —— 连续执行

Step 3 的核心原则是：Continue through ALL tasks without stopping for milestones.

这一条规则对周报生成任务至关重要。因为这个任务有 5 个步骤，每一步之间有依赖（先装库、再复制文件、再读 Excel、再改 PPT、最后截图），但没有一步需要人类决策。如果 AI 每完成一步都停下来问"继续吗？"，30 分钟的任务不会变快。

BMAD 的执行循环：

For each task:  1. Load Context → 读取相关文件  2. Implement   → 执行操作  3. Test        → 验证结果  4. Mark Complete → 标记完成，立即进入下一个

实际执行过程中，AI 遇到了几个障碍：

障碍 1：Excel 数据中的控制字符

Excel 单元格里混入了 \t（Tab）和 \n（换行），直接写入 PPTX 的 XML 会报错。AI 的第一次尝试失败了，但按照 BMAD 的 Halt Conditions 规则——"Tests fail and fix is not obvious" 不在停止条件内——AI 自主分析错误原因，清洗了文本数据，第二次成功。

障碍 2：浏览器截图无法直接保存到磁盘

Claude Chrome Extension 的截图返回的是对话上下文中的图片 ID，不是文件。AI 尝试了 screencapture（权限不足）、html2canvas（MCP 超时）、upload_image（安全限制），连续 3 次失败。

按照 BMAD 的规则，"3 consecutive failures on same task" 应该 HALT 并请求人类指引。AI 确实停了下来。人类给出指示："Just use Claude Chrome Extension to grab screenshot"——一句话点明方向。

AI 随后采用了一个巧妙的方案：在页面内用 JavaScript Canvas API 合成监控图表，通过 <a download> 触发浏览器下载到 ~/Downloads，再用 Python 读取文件嵌入 PPTX。

BMAD 的价值： Halt Conditions 的设计精髓在于——该停的时候停，不该停的时候不停。Excel 控制字符问题，AI 可以自己解决，不需要打断人类；浏览器截图问题，连续 3 次失败说明当前方向有误，需要人类指引。这种"自主解决 vs 请求帮助"的边界判断，不是靠 AI 的"直觉"，而是靠工作流的规则。

Step 4: Self-Check —— 自检

执行完成后，AI 按照 BMAD 的自检清单逐项核验：

Tasks Complete:  [x] Task 1: Template copied  [x] Task 2: Slide 2 updated (3 rows from Excel)  [x] Task 3: Slide 3 updated (2 rows from Excel)  [x] Task 4: Slide 5 screenshots embedded  [x] Slide 1 title date updatedAcceptance Criteria:  [x] New PPTX file created with today's date  [x] Data populated correctly from Excel  [x] Cloud monitoring screenshots captured and embeddedPatterns Followed:  [x] Output file naming follows existing convention  [x] Table structure preserved from template

注意"Tests"这一项——对于非编码任务，没有单元测试可以跑。AI 的做法是用 Python 重新打开生成的 PPTX 文件，验证每个 Slide 的内容是否正确。这本质上是一种验收测试。

BMAD 的价值： Self-Check 不是形式主义。它强制 AI 回头审视自己的工作，而不是"做完就算完"。在这次实践中，Self-Check 验证了 PPTX 文件的 7 个 Slide 的内容都正确——如果有一个 Slide 的表格数据写错了，这一步就能发现。

BMAD 在非编码任务中的适配

这次实践证明，BMAD Quick Dev 的步骤文件架构对非编码任务同样有效。但有一些适配值得注意：

适配 1：Step 5（对抗性审查）被自然跳过

周报生成不涉及代码变更，没有 diff 可以审查。工作流在 Step 4 完成后自然终止，没有强行进入 Step 5。这是合理的——工作流应该为任务服务，而不是反过来。

适配 2：测试 = 验收验证

在代码开发场景下，Step 3 的"Test"意味着跑 RSpec 或 Jest。在文档生成场景下，"Test"变成了"用 Python 重新读取输出文件，验证内容是否正确"。BMAD 的框架足够抽象，没有把"Test"硬编码为"跑测试框架"。

适配 3：Halt Conditions 的判断依然精准

浏览器截图的 3 次连续失败触发了 HALT，这是正确的。Excel 控制字符的问题没有触发 HALT，也是正确的。这说明 BMAD 的停止条件规则（"3 consecutive failures" / "blocking dependency"）是与任务类型无关的通用规则。

BMAD 带来的三个核心价值

1. 防止 AI "直觉性跳步"

没有 BMAD 的 AI 会怎么做这个任务？

大概率是：直接开始写 Python 脚本 → 遇到 python-pptx 没装 → 装完继续 → 遇到 XML 错误 → 反复试错 → 最后发现浏览器截图保存不了 → 又反复试错。

整个过程是反应式的：遇到问题 → 解决问题 → 遇到下一个问题。

BMAD 的 Context Gathering 步骤把这个过程变成了计划式的：先检查所有依赖 → 确认方案可行 → 生成完整计划 → 一次性执行。

差别不在于最终结果（都能做完），而在于上下文窗口的消耗。反应式做法在每次试错中浪费大量 token，计划式做法把试错集中在开始阶段。对于上下文窗口有限的 LLM 来说，这个差别直接影响任务完成质量。

2. 明确"自主"和"求助"的边界

这次实践中最关键的人机交互只有两次：

1. 1. [E] Execute directly → 人类确认不需要先做技术规格
2. 2. "Just use Chrome Extension" → 人类在 AI 连续 3 次失败后给出方向

两次交互，总共不超过 10 个字。其余所有工作都是 AI 自主完成。

这种精准的人机协作不是偶然的——它是 BMAD 工作流设计的结果。Step 1 的 [P/E] 选择、Step 3 的 Halt Conditions、Step 4 的 Self-Check，每一个都是精心设计的人机交互点。

不该打断人类的时候不打断，该打断的时候及时打断。 这是工作流比"自由对话"优越的本质。

3. 让任务可复现

这次周报生成的完整过程被 BMAD 工作流结构化地记录了下来：

• • Mode Detection 的判断依据
• • Context Gathering 的文件清单和依赖检查
• • Execute 的任务列表和遇到的障碍
• • Self-Check 的核验结果

下周再做同样的事情，AI 不需要从零摸索。把 Issue 文件的 Excel 文件名和日期改一下，/bmad-bmm-quick-dev @issue-file.md，BMAD 会以同样的步骤、同样的质量完成周报生成。

这就是工作流和"一次性对话"的根本区别：工作流是可复现的，对话不是。

流程全景图

Issue: Generate Weekly Report  |  v+------------------------------+|  Step 1: Mode Detection      |  <- 评估任务复杂度|  {execution_mode} = "direct" |     Escalation Level 0-1|  {baseline_commit} = 228f4e8 |     不需要升级到完整 BMAD+-------------+----------------+              | [E] Execute directly              v+------------------------------+|  Step 2: Context Gathering   |  <- 检查依赖、识别文件|  - python-pptx 需要安装      |     生成计划 + 推断验收标准|  - Excel 结构确认            ||  - Chrome 登录状态确认        |+-------------+----------------+              | [y] Ready to execute              v+------------------------------+|  Step 3: Execute             |  <- 连续执行 5 个任务|  Task 1: Copy template  [x] ||  Task 2: Excel → Slide 2[x] |     XML 控制字符 → 自主修复|  Task 3: Excel → Slide 3[x] |     3次截图失败 → HALT求助|  Task 4: Screenshot     [x] |     人类指引后 → Canvas方案|  Task 5: 2nd dashboard  [x] |+-------------+----------------+              |              v+------------------------------+|  Step 4: Self-Check          |  <- 验证 PPTX 内容正确性|  All tasks: [x]              |     重新读取文件逐项核验|  All AC: satisfied           |+------------------------------+              |              v        Task Complete   (Step 5-6 skipped: no code diff)

适用场景

BMAD Quick Dev 不仅适用于代码开发，还适用于以下类型的自动化任务：

共同特征：步骤明确、依赖可查、结果可验证。

总结

BMAD Quick Dev 的设计初衷是"小需求快速开发"，但它的步骤文件架构——Mode Detection → Context Gathering → Execute → Self-Check——本质上是一套通用的任务执行框架。

这次实践的启示：

1. 1. 好的工作流是任务无关的。 BMAD 的步骤没有假设"任务一定是写代码"。评估复杂度、收集上下文、连续执行、自检结果——这些步骤对任何结构化任务都成立。
2. 2. Halt Conditions 是 AI 自主性的安全阀。 没有 Halt Conditions，AI 要么一路莽到底（浪费 token 在死胡同里），要么每一步都问人（打断工作流）。BMAD 用简单的规则（3 次连续失败 → 停）精确控制了这个边界。
3. 3. Context Gathering 的投入回报比最高。 花 1 分钟检查依赖和确认方案，省下的是执行阶段的反复试错。对于 LLM 来说，上下文窗口就是最宝贵的资源，Context Gathering 直接降低了这个资源的浪费。
4. 4. 工作流让 AI 从"聊天助手"变成"执行引擎"。 没有工作流的 AI 是一个需要不断 babysit 的实习生。有了 BMAD，AI 变成了一个知道何时汇报、何时自主、何时停下来的专业执行者。

工具链：Claude Code (Opus 4.6) + BMAD Method v6.0.4 + Claude Chrome Extension + python-pptx + openpyxl