BMad Agentic Engineering 深度解析

核心哲学：为什么我们需要工程化？

"Vibe Coding" 的陷阱

传统的 AI 编程（即兴对话、Vibe Coding）依赖直觉和短时记忆。随着项目复杂度增加，上下文窗口溢出，导致：

架构漂移 (Architectural Drift)：Agent 忘记了之前的技术决策。
幻觉 (Hallucination)：在缺乏明确约束时编造 API。
循环重构：新代码破坏了旧逻辑，陷入死循环。

BMad 的工程化解法

BMad 引入了“单一事实来源 (Single Source of Truth)”链条。每个阶段的产出物都是下一个阶段的硬性约束。

Brief → PRD → Architecture → Story → Code

* Code 从不凭空生成，它永远是 Story File 的实现。

关键工程机制

上下文工程

BMad 通过文档分片 (Sharding) 和故事文件，为每个任务构建“最小完备上下文”。开发 Agent 不读取整个代码库，只读取包含 PRD 引用和 AC 的 Story 文件。

对抗性审查

利用“红蓝对抗”思维。一个 Agent 生成，另一个 Agent 被指令“必须找到问题” (Assume problems exist)。这消除了 AI 常见的“盲目赞同”倾向。

领域自适应

BMad 识别项目类型自动调整规划深度。对于医疗软件，强制注入合规性检查；对于 MVP，则跳过繁琐的非功能性需求。

PRACTICE

实战演示：Trae 产品化工作流

BMad 不仅是工程师的工具，也是产品经理（PM）和非技术创业者的**“AI 研发团队”**。以下案例展示了如何在 **Trae** 编辑器中，通过自然语言指挥 Agent 团队完成一个 **宠物社交 App (PawConnect)** 的从 0 到 1。

Phase 1: 创意立项

Agent: Analyst (Mary)

协助头脑风暴，挖掘核心价值，生成《产品简报》。

$ /bmad-brainstorming
Output: product-brief.md

Phase 2: 需求定义

Agent: PM (John)

将简报转化为 PRD，定义功能边界（如：实名认证、LBS 匹配）。

$ /bmad-bmm-create-prd
Output: PRD.md (FRs & NFRs)

Phase 3: 蓝图设计

Agent: Architect & UX

Winston 制定技术栈（WebSocket vs Firebase），Sally 规划交互流程。

$ /bmad-bmm-create-architecture
Output: architecture.md, ux-spec.md

Trae Chat: Party Mode

-- 开启派对模式评审 "附近匹配" 功能 --

YOU

请评审当前的“附近匹配”功能，是否存在风险？

PM (John)

功能很棒，能增加活跃度。但我担心隐私问题，如果不模糊处理位置，用户会被骚扰。建议增加“隐身模式”。

Architect (Winston)

同意 John。技术上我们必须对坐标进行“加盐”偏移（Offset），不仅是前端展示模糊，后端 API 返回的数据也必须是模糊的，防止抓包泄露。

UX (Sally)

那我在界面上增加一个显眼的盾牌图标，提示用户：“出于安全，仅显示模糊位置”。

结果：生成了无需编码的完整产品方案，可直接移交开发。

工程化落地路径

1. 结构化规划 (Structured Planning)

不直接写代码。首先运行 /create-prd 和 /create-architecture。这不仅是文档，更是为后续 Agent 生成了“记忆锚点”。

2. 任务原子化 (Atomization)

利用 /create-epics-and-stories 将系统拆解为原子化的 Story 文件。每个 Story 文件包含了该任务所需的全部上下文（从数据库 Schema 到 API 定义），确保 Dev Agent 不需要“猜”。

File: epic-1.story-2.login-api.md
> Context: Requires User Table (see architecture.md)
> Constraint: Must use JWT (see security-policy.md)
> AC: Pass integration test scenario #4

3. 隔离执行 (Isolated Execution)

每个 Story 在一个新的 Chat Session 中执行（Fresh Chat）。由于所有必要信息都在 Story 文件中，我们不再依赖 LLM 长窗口记忆，从而彻底解决了上下文衰减问题。