我在个人项目中使用 BMAD 框架的经验（需要耐心）

I’m happy to translate the article for you, but I don’t have the ability to retrieve the full text from the link you provided. Could you please paste the content you’d like translated (excluding any code blocks or URLs you want to keep unchanged)? Once I have the text, I’ll translate it into Simplified Chinese while preserving the original formatting and markdown.

入门指南：“我只用 BMAD 来加速”

在过去的几周里，我一直在个人项目中使用 BMAD 框架，并且想趁记忆犹新时把它写下来。

起初，我的期待相当简单：把我的想法套进去，让工作流指引我，这样我就能快速编写代码，方向更明确，死路更少。

这……部分属实。但有一个很大的前提。

BMAD 并不是“20 分钟内开始编码”的套件。 更接近于“先把前期工作做好，这样编码就不再是最难的部分”。
如果你习惯先随意拼凑原型再去弄清产品，这会让你感觉进展缓慢，甚至痛苦地慢。

第一次现实检验：在写代码之前需要花费大量时间

你在使用 BMAD 时首先会注意到，它会在让你感受到工程师通常所定义的生产力（交付代码）之前，迫使你经历一套完整的工作流程。

它会带你完成一系列步骤，例如：

• 定义问题（不仅仅是“我想构建 X”，而是“存在哪些痛点，针对谁？”）

  • 定义用户角色
  • 头脑风暴方案
  • 调研相关领域

• 明确约束条件（时间、预算、基础设施、团队、目标平台）

  • 将这些转化为 史诗（epics）、用户故事（stories） 和执行计划

所有这些都是有价值的。但它们并非免费。

对我而言，在写下第一行代码之前，大约花了 12 到 16 小时。

如果你以“周末项目”的心态来想，这个数字听起来很荒唐。但我越是沉下去，越能理解：BMAD 强迫你去思考那些通常会等到项目已经混乱时才去处理的内容。

公平地说，我也曾多次走相反的路线：

1. 快速构建某个东西
2. 发现自己构建了错误的东西
3. 重写它
4. 失去动力
5. 放弃它

所以，是的，这种前期投入是真实存在的。这也正是它的意义所在。

Source: …

框架其实很好（尤其是对商业思维）

我真的很喜欢的一点是，BMAD 中提出的框架能让你从不同的角度看问题，尤其是围绕业务层面你正在构建的东西。

如果你是一个工程师在做个人项目，通常会从以下开始：

• “我想用什么技术栈？”
• “哪种架构看起来更干净？”
• “哪些云服务最便宜？”

BMAD 会把你拉回到这样的问题：

• 这到底是为谁准备的？
• 他们想要实现什么目标？
• 他们现在是怎么做的？
• 为什么他们会换用你的方案？
• 能证明价值的最小可行产品是什么？

即使你觉得自己已经知道这些答案，把它们写下来也会迫使你更清晰。

这里的价值不在于它告诉你什么神奇的东西，而是让你对决策负责。

不过，你需要用时间来换取这种清晰度。你不是在写代码，而是在思考和记录。

“Party Mode”以及我如何耗尽上下文和积分

然后我进入了有趣（也是痛苦）的部分：party mode。

如果你还没有使用过，party mode 基本上就是“快速获取多种视角并生成大量材料”的模式。当你需要广度时，它会非常有用：

• 不同的解决方案
• 不同的权衡
• 不同的产品角度
• 风险清单
• 架构选项

我犯了一个错误，让它在 LangSearch 上运行 party mode，同时在 Gemini 上也运行 party mode，这个组合彻底耗尽了我的上下文窗口和使用积分。

事后看来，这一切都是可以预见的：party mode 想要读取、拉取来源、综合，然后生成。这意味着：

• 大量的 输入 令牌
• 大量的 输出 令牌
• 并且，根据使用的工具，还会产生大量付费调用

我尝试聪明地告诉它类似“不要读取所有内容，只把东西放进文件并做摘要”的指令。实际上，这并没有像我预期的那样工作。一旦你指示工作流进行深度研究，它就会坚持下去。它想收集材料，以便为结论提供依据。这对质量有好处，但如果不小心，成本控制就会变差。

不过，我还是要说：它非常有用。当它拥有多个角度进行比较时，输出的质量真的更好。只不过这要付出代价。

如果你打算使用 party mode，我的建议很简单：

• 有目的地使用
• 设定边界（范围、来源、最大深度）
• 假设如果让它自由发挥，成本会很高

12–16 小时后：第一行代码……随后我撞上了架构墙

在完成所有设置和工作流后，我终于到了开始编写代码的阶段。

几乎立刻，我意识到自己犯了一个架构错误。

这部分很重要，因为这类错误在让助手主导、自己只“监督”而不是主动构建时很容易出现。

我让架构师关注低成本，于是它倾向于使用无服务器（serverless）方案，具体是 AWS Lambda 风格的计算。随后我又让它使用NestJS。

纸面上听起来没问题，实际操作却相当棘手。

NestJS 可以在无服务器环境中运行，但除非正确配置，否则并不是“直接把 NestJS 丢进去就能部署到 Lambda”。通常需要一个适配层（例如使用 @vendia/serverless-express 或类似模式），或者使用更直接面向无服务器请求处理的框架。

如果没有这些适配，你会得到一堆不匹配的假设：

• 长生命周期的服务器模式 vs. 冷启动
• 框架启动时间 vs. 延迟期望
• 请求生命周期差异
• 部署打包和处理程序绑定

于是接下来发生的正是你可以预料的：错误遍布各处，系统不断尝试在循环中自我修复，却没有取得实质性进展。

6 小时调试螺旋（以及为何如此令人困惑）

我花了大量时间尝试修复它，约 六小时。

令人沮丧的是，当时的感受…

症状修复循环

我并没有立刻知道哪里出了问题。它并不是那种“一眼就能看出错误，比如用了错误的 import”的干净错误。

更像是：

1. 某些东西失败。
2. 你修复了症状。
3. 另一些东西又失败。
4. 修复引入了另一个问题。
5. 于是陷入循环。

如果你曾在项目早期遇到过不匹配的架构决策，你就会明白这种感觉。代码在单独看时是 正确 的，但环境和假设却是错误的。

这也是 AI 辅助工作流会变得怪异的地方。如果系统试图提供帮助，它可能会不断提出在局部看起来合理、却未能解决根本不匹配的更改。你会花大量时间批准那些“合理”的编辑，却始终无法收敛。

而这正是发生的情况。它一直在旋转，我一直在想，“为什么卡住了？”

转折点：我没有自己找出答案，是回顾会找到了答案

发生了什么？

我注意到流程花费了太多时间却没有收敛，于是我启动了 BMAD 工作流来进行一次 回顾会。这一步正是突破口。

与其继续向前推进（那只是表面的进展），回顾会迫使我们停下来并提出：

• 我们想要做什么？
• 什么在阻碍我们？
• 我们做了哪些假设？
• 有什么变化了吗？
• 哪个决定导致了反复失败？

于是我们发现，当前的设置并不正确。架构需要调整以匹配运行时模型。

接下来的步骤

• 调整 NestJS 的配置，使其在无服务器处理模型中正常运行，或者
• 更改计算模型（例如，在 ECS/Fargate 上使用容器化服务，或使用普通虚拟机），具体取决于目标，或者
• 选择更自然适配无服务器的框架。

关键在于 回顾会迫使系统停止临时修补，转而进行诊断。

“大多数工程师在个人项目出问题时不会进行回顾会。我们只会更努力地硬碰硬。”

我已经这样硬碰硬很多次了，效果往往不佳。

修复后：一切顺利（而且“Stories” 成了超级力量）

一旦环境正确搭建，体验就彻底改变了。

最大的收获：Stories

我拥有真实的故事，而不是模糊的任务比如“构建后端”。
通过 Stories，我可以准确地告诉系统要实现什么，且范围明确、可测试。从想法到工程任务的转换已经完成。

我的新角色

• 监督
• 审核决策
• 对代码进行合理性检查
• 偶尔对请求和更改点击是/否
• 确保工作与目标保持一致

这与“我自己动手做所有事”的感觉截然不同。

如果你曾经带领过团队，你会认同这种模式：你不需要写每一行代码；你要确保所做的工作是正确的工作。

BMAD 做对的事：以耐心换取动力

总体来看，我觉得 BMAD 非常酷，但我不想夸大它。权衡非常明确：

• 你需要耐心来进行设置
• 你需要给出好的答案
• 你需要审查所有内容
• 你需要接受早期阶段会显得缓慢

如果把它当作魔法代码生成器来使用，你会感到恼火。
如果把它当作一种前期投入思考、文档和执行结构的过程来对待，它就会变得合情合理。

一旦你跨过最初的坡度，它就会变得相当直接。

被低估的特性：因为所有内容都记录在文档中，你可以随时恢复

另一件我在深入使用后才真正体会到的好处是，你可以 随时恢复。

因为一切都有文字记录，你不必依赖记忆或脆弱的聊天上下文。你拥有的文档包括：

• 角色设定
• 问题陈述
• 架构笔记
• 史诗（Epics）
• 故事（Stories）
• 决策与权衡

所以你可以在一天或一周后回来，直接说：

• “执行这个史诗”
• “继续这个故事”
• “实现下一个任务”
• “对最近的改动进行回顾”

而不会有重新开始的感觉。

对个人项目来说，这意义重大。我们大多数人失去动力并不是因为不会编码，而是因为在休息后返回时，需要花一个小时重新构建上下文。BMAD 减少了这种负担。

在他们尝试之前，我会告诉另一位工程师的事

我不会假装这适用于所有项目。如果你只是在快速写脚本或测试一个 API 想法，BMAD 可能显得太重。但如果你在构建真正想要发布的东西——即使是作为独立开发者——也值得考虑。

我实践中的经验教训

• 为设置预留时间。 如果你期望在第一小时就开始写代码，你会与工作流抗争。
• 小心使用“派对模式”。 它很有用，但会快速消耗上下文和额度。
• 不要随意对待架构提示。 “低成本”会把你引向无服务器模式，这固然好，但会限制框架选择和部署形态。
• 卡住时使用回顾。 本能是继续前进；更聪明的做法是停下来诊断。
• 故事是收益所在。 一旦有了好的故事，执行就会变得更机械化。

结束语

BMAD 最终成为那种在最初阶段感觉充满摩擦的体验，而后来你才意识到摩擦正是其全部意义。

它迫使我放慢脚步，明确自己的所作所为，并将决策显式化。我在几个地方浪费了时间（以及积分），尤其是在 party mode 上，并且因一次架构不匹配损失了六个小时，本该更早发现。

但一旦工作流和文档就位，整个过程出奇地顺畅。能够从 epics 和 stories 继续，并在不必不断重写需求的情况下引导实现，这是真正的生产力提升。

如果你尝试 BMAD，请保持耐心。保持自律。并假设你会在编码前花更多时间思考。

如果这与你产生共鸣，你在结构化 AI‑辅助工作流方面有什么经验？我很想了解。