AILLM

BMAD：AI 驱动敏捷开发的突破性方法论与框架全解析

在讨论 BMAD 之前，需要先理解一个根本性问题：AI 到底是"怎么工作"的。这个问题的答案直接影响我们如何正确使用 AI 进行开发。

一、AI 的本质：预测下一个 token

理解 AI 的能力边界，先要理解 AI 的工作原理。

大语言模型的核心机制非常简单：根据已有的文本序列，预测下一个最可能出现的 token（词/子词）。

flowchart LR A[输入序列 今天天气] --> B[Transformer 神经网络] B --> |计算概率分布| C[预测下一个token] C --> |好| D[输出 今天天气好] D --> |作为下一轮输入| A

这个过程可以形式化为：

flowchart LR subgraph Input I1(token1) I2(token2) I3(...) In(tokenN) end subgraph Model M{计算下一个token的概率} end subgraph Output O1(token1) O2(token2) O3(token3) end Input --> Model --> Output

AI 本身并不"理解"代码，它只是在模仿训练数据中见过的模式。这带来两个关键结论：

AI 擅长AI 不擅长
按已有模式生成内容真正理解业务目标
处理大量信息处理模糊、歧义的需求
执行明确指令做全新的推理

AI 见过海量代码，所以能写出看起来正确的代码，但它不知道这段代码为什么要这样写。

各 AI 大模型为什么不一样

虽然所有大语言模型都基于"预测下一个 token"的工作机制，但不同模型之间存在差异：

差异维度说明
训练数据代码占比、质量不同
上下文窗口影响长项目处理能力
对齐技术RLHF/DPO1影响指令遵循能力

二、AI 编程的三大崩溃

当用 AI 进行软件开发时，会遇到三个核心问题，统称为"三大崩溃"。

2.1 上下文崩溃（Context Collapse）

AI 的上下文窗口（Context Window）有上限。即使模型支持 100K token，真实项目可能涉及数百万 token 的代码和文档。

flowchart TD subgraph Problem [上下文崩溃] P1[项目规模] --> |50+ 文件| P2[代码量爆炸] P2 --> P3[AI 无法全部理解] P3 --> R1[AI 忘记之前代码] P3 --> R2[AI 重复实现功能] P3 --> R3[AI 破坏已有逻辑] end style P1 fill:#ffcccc style P3 fill:#ffcccc style R1 fill:#ffeeaa style R2 fill:#ffeeaa style R3 fill:#ffeeaa

典型表现：

  • 让 AI 修改一个函数，它忘记了同文件中另一个相关函数
  • 让 AI 实现登录功能，它重新写了一个已有的用户模块
  • 让 AI 添加新功能，它改动了不相关的代码导致 bug

2.2 任务崩溃（Task Collapse）

如果不给 AI 明确的任务边界，它会"放飞自我"。

flowchart LR subgraph Problem [任务崩溃] Input[需求： 做一个商城系统] --> AI[AI 自主发挥] AI --> A[写一点登录] AI --> B[写一点购物车] AI --> C[写一点支付] A & B & C --> Chaos((代码混乱)) end style Input fill:#e1f5fe style Chaos fill:#ffcccc

你说"做个商城"，AI 可能：

  • 每个功能都写一点
  • 没有统一的架构
  • 代码风格不一致
  • 最后变成无法维护的"屎山"

2.3 质量崩溃（Quality Collapse）

AI 生成的代码 bug 率远高于人类程序员。

flowchart TD subgraph Problem [质量崩溃] Code[AI 生成代码] --> Check{检查结果} Check -->|有bug| Fix[AI 修复] Fix --> Check Check -->|修复中引入新bug| Worse[更差的代码] end style Code fill:#e1f5fe style Worse fill:#ffcccc

常见问题：

问题类型典型表现
幻觉调用不存在的 API、使用不存在的库
安全风险硬编码密码、SQL 注入漏洞
逻辑错误边界条件未处理、异常未捕获
风格问题命名不一致、格式混乱

2.4 判断力退化（容易被忽视的问题）

除了技术问题，Vibe Coding 还有一个容易被忽视的危害：人的判断力在退化。

当你习惯了"出错 → 贴报错 → 让AI再改"这个循环，你会逐渐失去对代码的深度理解。你可能说不清某个模块到底是怎么工作的，只是知道"让AI改改能跑"。

以前Vibe Coding 后
理解代码为什么这样写只知道"能跑"
能定位 bug 在哪只会贴报错给 AI
知道技术选型的理由依赖 AI 做决定

AI 时代，最稀缺的不是能写代码的人，而是能判断代码好坏的人。

三、AI 编程的演进

3.1 进化历程

timeline title AI 编程进化史 section 2013-2018 语法补全 : Tabnine、Kite section 2018-2021 智能补全 : GitHub Copilot section 2021-2023 对话编程 : ChatGPT、Claude section 2023-2024 IDE 集成 : Cursor、Windsurf section 2024-2025 Vibe Coding : Andrej Karpathy 提出 section 2025-未来 Agent 主导 : Claude Code、BMAD
阶段时间特点程序员角色
语法补全2013-2018预测下一个词代码工人
智能补全2018-2021代码片段建议副驾驶
对话编程2021-2023自然语言生成代码需求描述者
IDE 集成2023-2024多文件操作协作者
Vibe Coding2024-2025AI 主导实现审核者
Agent 主导2025-未来全流程自主执行架构师

3.2 Vibe Coding 的困境

Vibe Coding（凭感觉编程）由 Andrej Karpathy 提出，核心理念是"用自然语言描述需求，AI 直接生成整个应用"。

flowchart LR subgraph Old [Vibe Coding 模式] U[你：描述需求] --> AI[AI：生成代码] AI --> R[你：运行测试] R --> |报错| AI end style U fill:#e8f5e9 style AI fill:#fff3e0 style R fill:#ffebee

问题在于：这种模式缺乏系统化的工程管理，代码质量完全不可控。

3.3 Agentic Engineering 的提出

Andrej Karpathy 进一步提出了 Agentic Engineering（智能体工程化）的概念：

AI 时代的软件开发是一门需要学习的专业技术。

flowchart LR subgraph Change [角色转变] Old1[程序员 = 代码工人] --> New1[程序员 = AI 架构师] Old2[写代码] --> New2[指挥 AI] Old3[Debug] --> New3[Review] end

核心变化：

  • 以前：人写代码，AI 辅助
  • 现在：人定义目标和架构，AI 执行具体任务

SDD：给AI立规矩

面对 Vibe Coding 的问题，社区提出了 Spec-Driven Development (SDD) 思路：先写规格，再让 AI 干活。

主流三个框架对比：

框架核心理念适用场景
Spec Kit宪法+七阶段门禁0→1 新项目
OpenSpec增量 Delta日常迭代改功能
BMAD多 Agent 模拟团队复杂项目 / 学习
  • Spec Kit：GitHub 官方出品，适合需要严格流程管控的场景
  • OpenSpec：轻量级，适合在已有项目上做增量开发
  • BMAD：覆盖最全面，适合想系统学习 AI 开发全流程的团队

四、BMAD 是什么

BMAD 全称 Breakthrough Method of Agile AI Driven Development（敏捷 AI 驱动开发的突破性方法），是一个 AI 驱动的敏捷开发框架。

官方定义：帮助完成从构思规划到智能体实现的完整软件开发过程。

4.1 核心思路

BMAD 让 AI 模拟一个完整的软件团队：

flowchart TD subgraph Team [BMAD AI 团队] BA[Business Analyst] --> PM[Product Manager] PM --> Arch[Architect] Arch --> SM[Scrum Master] SM --> Dev[Developer] SM --> QA[QA] end Human[人类] --> |定义目标| Team style Human fill:#e8f5e9 style Team fill:#e3f2fd

内置 12+ 领域专家智能体，覆盖产品、设计、开发、测试全流程。

4.2 解决三大崩溃

flowchart TD subgraph Solution [BMAD 解决方案] C1[上下文崩溃] --> S1[文档分片 Epic Sharding] C2[任务崩溃] --> S2[任务分层 Epic→Story→Task] C3[质量崩溃] --> S3[三模式循环 Create→Validate→Edit] end style C1 fill:#ffebee style C2 fill:#ffebee style C3 fill:#ffebee style S1 fill:#e8f5e9 style S2 fill:#e8f5e9 style S3 fill:#e8f5e9
崩溃BMAD 方案
上下文崩溃文档分片 + Epic Sharding
任务崩溃Epic → Story → Task 层级
质量崩溃Create → Validate → Edit 循环

五、BMAD 核心机制

5.1 步骤文件架构

每个步骤都重新加载上下文，避免 AI “中间迷失”：

flowchart TD subgraph Steps [BMAD 步骤文件] S1[Step 1 需求分析] --> S2[Step 2 PRD 输出] S2 --> S3[Step 3 架构设计] S3 --> S4[Step 4 Epic 拆分] S4 --> S5[Step 5 Story 开发] end S1 --> |加载上下文| C1[Context1] S2 --> |加载上下文| C2[Context2] S3 --> |加载上下文| C3[Context3] S4 --> |加载上下文| C4[Context4] S5 --> |加载上下文| C5[Context5]

5.2 任务分层

flowchart TD Epic[Epic 大功能] --> Story[Story 用户故事] Story --> Task[Task 具体任务] Task --> Code[Code 代码实现] Epic --> |拆分| Epic1[Epic1] Epic --> |拆分| Epic2[Epic2] Epic --> |拆分| Epic3[Epic3] style Epic fill:#e3f2fd style Story fill:#e8f5e9 style Task fill:#fff3e0 style Code fill:#f3e5f5

5.3 三模式循环

每个工作流都具备三种能力：

flowchart LR Create[Create 创建] --> Validate[Validate 验证] Validate -->|不通过| Edit[Edit 编辑] Edit --> Validate Validate -->|通过| Done[完成] style Create fill:#e8f5e9 style Validate fill:#fff3e0 style Edit fill:#e3f2fd style Done fill:#f3e5f5

5.4 完整工作流

flowchart TD Start[需求] --> PRD[PRD 文档] PRD --> Arch[架构设计] Arch --> Epic[Epic 拆分] Epic --> Story1[Story1] Epic --> Story2[Story2] Epic --> Story3[StoryN] Story1 --> Task1[Task1] Story2 --> Task2[Task2] Story3 --> Task3[TaskN] Task1 --> Code1[代码] Task2 --> Code2[代码] Task3 --> Code3[代码] Code1 & Code2 & Code3 --> Test[测试] Test --> Review[Review] style Start fill:#e8f5e9 style PRD fill:#e3f2fd style Arch fill:#fff3e0 style Epic fill:#f3e5f5 style Review fill:#ffcdd2

BMAD 背后的原理：Context Engineering

BMAD 的"步骤文件架构"本质上是在解决一个问题：如何管理 AI 的认知。

AI 就像一个"失忆的强同事"——每次坐下来都需要准备好它需要的材料。材料不全，它干不好活；材料太多，它会迷失在信息海洋里。

Context Engineering（上下文工程）是 Anthropic 提出的概念，核心思路是系统性地管理 AI 在每次交互中能"看到"的信息：

层级内容
System ContextAI 规则、角色定义
Project Context项目背景、架构、技术栈
Task Context当前任务的需求和约束
Local Context当前代码的具体实现

BMAD 通过每步重新加载上下文，让 AI 始终"记得"该记得的事——这正是 Context Engineering 的实践。

六、BMGD 模块：游戏开发工作室

BMGD（Game Dev Studio）是 BMAD 的游戏开发模块，专注于游戏开发场景。

6.1 功能特性

  • 多引擎支持：Unity、Unreal、Godot、自定义引擎
  • GDD 生成：游戏设计文档自动生成
  • Quick Dev 模式：快速原型制作
  • 叙事设计支持：角色、对话、世界构建
  • 21+ 种游戏类型：包含特定引擎的架构指导

6.2 安装方式

1
2

npx bmad-method install
# 选择 gds 模块

或直接安装：

1

npm install -g bmad-game-dev-studio

6.3 开发模式

flowchart TD A[开始] --> B[选择引擎] B --> C[选择模式] C -->|快速原型| QuickDev[Quick Dev] C -->|完整生产| EpicFlow[Epic 驱动冲刺] QuickDev --> GDD1[GDD 生成] EpicFlow --> GDD2[GDD 生成] GDD1 & GDD2 --> Dev[开发] Dev --> Test[测试] Test --> Deploy[部署] style QuickDev fill:#e8f5e9 style EpicFlow fill:#e3f2fd
模式适用场景
Quick Dev快速原型验证、概念验证
Epic 冲刺完整生产开发周期

进阶：让AI开发具有复利

传统 SDD 有一个局限：每次任务都要从头组装上下文。上次做类似功能积累的经验、踩过的坑、选的方案——下次做相似的事，AI 不记得。你得重新告诉它一遍。

Compound Engineering（复利工程）想要解决的是这个问题：让 AI 开发系统具有"学习能力"。

flowchart LR Task1[第1次：45分钟] -->|沉淀经验| Index[经验索引] Index -->|自动加载| Task2[第2次：15分钟] Task2 --> Index Index -->|持续优化| TaskN[第N次：5分钟] style Index fill:#e8f5e9

核心思路：每次完成任务后，把方案、踩过的坑、决策理由抽取出来，写入经验索引。下次遇到类似场景，这些经验会被自动加载到 AI 的上下文里。

这就是从"人指挥 AI"到"AI 为人工作"的转变。

七、未来程序员的核心能力

AI 时代，程序员的核心能力发生转变：

flowchart LR subgraph Old [以前] O1[语法熟练] O2[编码速度] O3[框架掌握] end subgraph New [未来] N1[架构设计] N2[需求表达] N3[代码审查] end Old -->|时代变化| New
能力作用
架构能力告诉 AI 怎么拆分模块、选什么方案
Prompt 能力把需求清晰、无歧义地表达给 AI
Review 能力一眼看出 AI 生成代码的问题
产品思维知道该做什么，比知道怎么做更重要

AI 时代，最稀缺的不是能写代码的人，而是能定义好问题的人。

八、总结

BMAD 本质上是在回答一个问题：如何让 AI 开发变得可控。

从 Vibe Coding 的"快速但混乱"，到 Agentic Engineering 的"工程化"，再到 BMAD 的"系统框架"，AI 编程正在从粗放走向精细。

关键认知：

  1. AI 的本质是"预测下一个 token"，是模仿而非思考
  2. 三大崩溃（上下文、任务、质量）是 AI 开发的根本挑战
  3. BMAD 通过步骤文件、任务分层、三模式循环来解决这些问题
  4. BMGD 模块为游戏开发提供了专业的工作流

未来，不会淘汰程序员，但会淘汰"只会在键盘上打字的人"。

参考资料：

  1. RLHF (Reinforcement Learning from Human Feedback) 和 DPO (Direct Preference Optimization) 是训练时让模型更好地理解人类意图的技术 ↩︎

Licensed under CC BY-NC-SA 4.0
© 2025 - 2026 ZhuangZewei
使用 Hugo 构建
主题 Stack 由 Jimmy 设计