在开发 video-helper 这个项目初期，我一度觉得写代码变成了一件特别爽的事。需要个什么功能，直接丢给大模型，几秒钟代码就出来了。
但这股新鲜感没维持多久。当 video-helper 从一个简单的脚本，膨胀成一个包含 Next.js 前端和 FastAPI 后端的完整开源项目时，光靠对话来驱动 AI 开发开始频频翻车。模型经常写着前端的页面，就忘了后端的数据接口长什么样；或者在修复一个小 bug 时，顺手把我之前定好的架构给重构了。
我意识到，管理 AI 就和带团队一样：对于单点任务，给个指令就行；但要交付一个完整的工程，你需要一套SOP(标准作业程序)。
这也是为什么我在 video-helper 的开发中，开始重度依赖 BMAD（Breakthrough Method of Agile AI Driven Development，敏捷 AI 驱动开发的突破性方法）。它不是一个传统的代码库框架，而是一套约束并驱动智能体协同工作的“工作流引擎”。今天就和大家聊聊，这套框架是如何来把控项目的。
用“微型文件架构”锁住 AI 的注意力
你可能会想，要让 AI 别乱跑，多写点长提示词不就行了吗？
其实不然。长提示词的边际效应递减得非常厉害，AI 在长文本中的注意力很容易涣散。BMAD 的解法是：把大块的任务切碎。
它采用了一种微型文件架构。当你请求 AI 帮你撰写产品需求文档时，后台并不是把一坨几万字的提示词直接糊给大模型。实际上，它会严格按照预设的工作流，依次读取初始指引、发现探索等各个阶段的拆解文件，并在每读取一步后立刻执行动作、停顿并产出中间态结果，确认无误后再进入下一步。
这就好比给 AI 设了一条有轨电车，它只能在这个环节拿特定的上下文做这一件事，做完才走下一步。这种极细粒度的任务拆分，是解决 AI 幻觉和需求无序蔓延的对症良药。
流水线的交接棒：工件驱动
把任务拆细了，那不同角色的 AI 之间怎么配合？
在 BMAD 中，预设了一支高度专业化的 Agent “虚拟研发团队”。当你有一个粗糙的 Idea 时，这套代码工厂的齿轮就开始转动了：
首先下场的是 Analyst（分析师）。你可以让它帮你做头脑风暴和竞品调研，把早期灵感收敛成一份清晰的产品简报。有了简报，PM（产品经理） 就会接手将其转化为详尽的产品需求文档（PRD）。而在涉及界面的项目中，UX-Designer（UX 设计师） 也会在这个阶段介入，同步敲定交互模式。
需求一旦成型，紧接着入场的就是 Architect（架构师）。它不仅负责产出技术底座方案，还把守着一道极度关键的防线——执行“实施就绪检查”。在这里，它会以极其严苛的挑剔视角，排查前期的需求与技术落地之间是否存在逻辑断层。
当架构和需求这块“硬骨头”啃完后，PM 会再次返场，把冰冷的需求结合架构上下文，拆解为细致的开发故事（Epics & Stories）。
进入开发周期后，SM（Scrum Master） 负责统领全局。它调度开发故事的派发顺序，并在每个核心周期结束后拉着全员做深度复盘。而真正干起脏活累活的绝对主力则是 Dev（开发者），它必须严格遵循极度克制的工作循环：细化步骤、编码、配齐单测，甚至互相之间还会充当“黑脸”进行双盲交叉代码审查。
如果你只是想写个微型小脚本，觉得这套全流程太重，系统还为你留了一个 Quick-Flow Solo Dev。这就相当于敏捷通道里的全流程大拿，单枪匹马就能包揽从极简规划到落地的全部活计。
这些角色协作本质，完全抛弃了传统的“靠上下文聊天传递信息”，而是一场完全被工件(Artifacts)驱动的击鼓传花。前一个角色写出的 Markdown 文档（比如 prd.md），就是下一个角色触发工作的核心约束。AI 从此不再是摸黑凑代码，而是像真人工厂的流水线工人一样，手拿确定的图纸一步一步在干活。
测试驱动开发（TDD）的底层烙印
除了让 AI 乖乖看文档写代码，BMAD 开发流程里常常带有测试驱动开发（TDD）甚至是验收测试驱动开发（ATDD）的烙印。
你可能会觉得要求大模型写测试很繁琐，但在 BMAD 的 testarch-atdd 工作流中，系统会强制要求在编写实际业务代码之前，先生成预期会失败的验收测试脚本。只有当后续 Dev 角色把功能代码写对，测试由红翻绿后，这个环节才算闭环。这种用“冷酷的测试用例”作为最终验收标准的工程倒逼法，极大程度避免了 AI 凭直觉写出一堆看似漂亮却无法运行的“幻觉代码”。
怎么让 AI 遵循你的审美和规范？
前面的测试驱动，保证的是 AI 写出的代码能跑通；但理解了流水线后，新的问题又来了：怎么保证 AI 写的代码符合你的口味和技术栈？就算有了工件流转，每个 AI 脑子里的“默认最佳实践”往往是不一样的。怎么保证它们不会今天用了 React 的 Context，明天又偷偷引个 Redux 进来呢？
这时候就得提到 project-context.md。
这就相当于公司的“开发规范手册”。你可以在里面明确告诉 AI 你的技术栈版本（比如 Next.js 16, FastAPI），还能设定关键规则。比如我在开发中就可以规定：“所有 API 调用必须使用 apiClient 单例，绝对不准直接用 fetch”。在后续所有的技术架构规划或是代码审查环节中，系统会自动加载这个上下文。专注于那些不明显的内容，AI 就能做出与你项目风格高度一致的决策。
大炮打蚊子？敏捷通道 Quick Dev
看到这里，你一定有个直接的感受：这套体系太重了。为了改个按钮颜色，难道还要先起草一份 PRD，再经过架构师评审吗？
BMAD 同样考虑到了这点，所以它提供了一个双轨制。如果说刚才说的是完整版方法论，那对于小需求，它有一个快速通道叫 quick-dev。
以开发桌面端打包功能为例，我想把现有的 Web 应用套壳成 Electron。这其实是个边界很明确的任务。所以我完全跳过了前期的繁文缛节，建立了一个极简规格书。在这个文档里，我只需要指明核心的改动范围和特定组件的依赖更新，不需要长篇大论的背景介绍。
随后触发 Quick Dev，由一个叫 quick-flow-solo-dev 的全栈型大拿直接兼顾规划与开发，一波流把代码写完。而且系统内置了范围监控，如果 AI 发现你的 Quick Dev 涉及了太多破坏性的重构，它会立刻中止并警告你：“这活太大了，你得切回正规流程去写架构文档。”
当团队产生分歧：Party Mode
其实，用 AI 辅助开发最怕的不是它写错代码，而是它为了讨好你，一口答应那些在架构上极其别扭的需求。
为此，BMAD 设计了一个非常有想象力的机制——派对模式（Party Mode）。这不是说找个更聪明的大模型，而是利用底层的多智能体对话回路来实现的——说白了，就是系统让你选定的几个 AI 在同一个群聊里连轴转着讨论。当你触发后，系统会在后台读取开发花名册并充当“会议主持人”，强制要求底层大模型在同一个对话连线中不断交替加载不同的角色设定。
当你抛出一个纠结的需求时，你可以让它们互相挑刺。PM想要极致体验，Architect不仅盯着容错率还要控制可维护性，Dev 更是会抱怨实现成本和极端用例。通过这种多视角的交叉对谈，大模型往往能主动暴露出自己思维过程里的盲区。经过这样对抗讨论后形成的“共识”，再写进 PRD 里，所有的水分就被彻底挤干了。
并行开发经验包：用契约和 Worktree 加速
如果你想在 BMAD 里玩得更飞，这里还有一个进阶的经验包：如何让多个 Dev Agent 并行干活？在项目的开发中期，为了赶进度，我起初尝试让它们并发去开发不同模块，结果迎面撞上了一个大坑——多个 Agent 各自为战，同时修改了数据结构和错误码，导致最后拼装时接口全线报错。
为了安全并行，我总结了这两步：
- 让 SM（Scrum Master）在冲刺规划时输出并行协作方案。在分配开发任务时，千万别不管三七二十一把任务铺开。首先，必须在规划阶段指派某一个 Dev（开发者）把数据契约提前做出来并完全冻结。先把 API 的增删改查规范、错误码注册表等一次性锁死，充当所有并发任务的唯一事实来源。同时，我也要求 SM 在后续的任务规划中，通过分析依赖关系，产出一份清晰的“可并行开发方案”供参考，指明哪些模块可以多线开发，哪些核心任务建议先单独完成。
- 利用物理隔离的分支技巧（如 Git Worktree）管理上下文。一旦核心契约冻结，后端 API 骨架和前端页面就可以安全进入并行状态。为了防止多线开工的 AI 读错或覆盖彼此的文件，我为每个任务分配了独立的本地工作区。每个流水线只关注自己的一亩三分地，合并代码前跑完基础检查。这种方法能让大模型的并发产能呈指数级上升。
无论是前面讲到的“微型文件架构”、严苛的 TDD 规范，还是这种为了冲刺进度而采用的契约隔离，BMAD 的这套运作逻辑其实都在向我们揭示一个深刻的切面：随着大模型基础能力的爆发，我们与 AI 协作的最大痛点，早就从“它能不能写出这段代码”，变成了“它能不能在一个庞大的工程里按部就班，不添乱”。
这套体系也在不知不觉中改变了我的开发习惯。它让我意识到，与其去四处搜刮“如何写好一行牛逼的 Prompt”之类的奇技淫巧，未来工程师更具长远价值的杠杆，其实是极高纬度的系统设计与流程掌控能力。
我们要学着像一个真正的技术总监那样去拆解工程边界、管理工件流转、甚至是制定严酷的协作契约，然后只需退后一步，看着这群不知疲倦的硅基员工按照你定好的轨道，把蓝图一行行变成坚固的代码。
BMAD官方文档:docs.bmad-method.org/zh-cn/
