从 Vibe Coding 到 BMAD：AI 全栈开发方法论全景图

一年前我写过一篇《AI编程助手全面横评：七大工具功能与架构对比》，逐一拆解了 Copilot、Cursor、Claude、Devin 们的功能差异。一年后回头看，工具层的差距正在急速收窄——Cursor 有的 Agent Mode，VS Code Copilot 也有了；Windsurf 有的 Memories，Claude Code 的 CLAUDE.md 也做到了。

真正拉开项目交付质量的，不再是你用哪个 IDE，而是你用什么方法论驱动 AI。

这篇文章尝试画一张完整的地图：从最松散的 Vibe Coding 到最结构化的 BMAD Method，从一个 .cursorrules 文件到 36 个 MCP tools 的任务管理系统——AI 全栈开发的方法论，在 2026 年中已经形成了清晰的光谱。

一、Vibe Coding：一切的起点

2025 年 2 月，Andrej Karpathy 在一条推文里造了个词：Vibe Coding。

"You just see stuff, say stuff, run stuff, and copy paste stuff, and it mostly works."

不写代码，只描述意图；不调试，只让 AI 重来；不读源码，只看效果。这种"氛围编程"解放了大量非专业开发者，也让很多专业开发者在原型阶段的效率翻了几倍。

但 Vibe Coding 有一个天然的天花板：它没有记忆。

每次新开对话，AI 忘了你的项目结构、忘了你的编码规范、忘了你上次踩过的坑。项目一旦超过几百行，Vibe Coding 就开始"振动式崩溃"——AI 改 A 文件的同时破坏了 B 文件，你贴回错误，它改 B 的时候又把 A 改回去。

后续所有方法论的演化，本质上都在解决同一个问题：怎样给 AI 持久的上下文。

二、从 Prompt Engineering 到 Context Engineering

.cursorrules：最早的项目级指令

Cursor 在 2024 年底引入 .cursorrules——一个放在项目根目录的文本文件，告诉 AI"这个项目的规矩"。内容可以是编码规范、技术栈偏好、甚至"不要用 class 组件"这样的禁令。

这看起来只是一个配置文件，但它代表了一个范式转变：指令从对话框搬到了仓库里。

几乎同时，不同生态各自发展出了自己的版本：

Memory Bank：跨会话的持久记忆

Cline/Roo Code 社区走得更远。他们提出了 Memory Bank 模式：在项目中维护一组 Markdown 文件（projectbrief.md、techContext.md、progress.md、activeContext.md），要求 AI 在每次会话开始时先读取、在会话结束时回写。

这解决了 Vibe Coding 最致命的问题——遗忘。但 Memory Bank 是被动的：你得记得让 AI 去读、去写。

Context Engineering：2026 年的新共识

到 2026 年，业界逐渐形成一个共识：Prompt Engineering 正在被 Context Engineering 取代。

区别在哪里？Prompt Engineering 优化的是"这一次对话怎么问"；Context Engineering 优化的是"AI 在开始工作之前，已经知道了什么"。

一个好的 Context Engineering 体系包含三层：

1. 静态上下文 — 项目结构、编码规范、技术栈（.cursorrules / CLAUDE.md）
2. 动态上下文 — 当前任务状态、进度、依赖关系（Memory Bank / Taskmaster）
3. 工具上下文 — AI 能调用哪些外部能力（MCP servers / 浏览器 / 数据库）

方法论之间的差异，本质上就是在这三层上做了不同深度的投入。

三、Spec-Driven Development：PRD 先行的全链路

如果 Context Engineering 是"给 AI 读什么"，Spec-Driven Development 就是"让 AI 按什么流程做事"。

这一层的框架把软件工程的经典流程——需求 → 架构 → 任务拆解 → 编码 → 测试——用 AI 重新实现了一遍。

BMAD Method（⭐ 47.9k Stars）

Build More Architect Dreams，目前社区最大的 AI 敏捷开发框架。

核心设计：12+ 个专业化 Agent（产品经理、架构师、开发者、UX 设计师、测试工程师……），通过 34+ 个预定义 Workflow 协作。你不是直接让 AI 写代码，而是先让 PM Agent 写 PRD，再让 Architect Agent 做技术方案，然后 Developer Agent 才开始编码。

关键特性：

• 规模自适应 — 自动判断项目复杂度，小修小补走轻量流程，大型系统走完整架构评审
• Party Mode — 在一个会话里同时召唤多个 Agent 角色讨论方案
• bmad-help Skill — 随时问"我下一步该做什么"，框架自动导航

BMAD 的理念是：AI 不应该替你思考，而应该引导你思考得更好。它不是一个自动生成器，而是一个结构化的协作框架。

Taskmaster / Hamster（⭐ 27.2k Stars）

更侧重"任务管理"而非"角色扮演"。

工作流：写一份 PRD（.taskmaster/docs/prd.txt）→ AI 解析生成任务树 → 按依赖关系逐个执行 → 每完成一个自动更新状态。

它的杀手特性是 MCP 集成——36 个 MCP tools 直接暴露给 AI IDE，让你在 Cursor/Claude Code 里说一句"解析我的 PRD"就能自动生成全部任务。配合 research 命令，AI 还能在实现前先搜索最佳实践。

Taskmaster 的定位更务实：不搞角色扮演，就是一个让 AI 照着计划干活的任务调度器。

Plandex（⭐ 15.4k Stars）

终端派的选择。2M token 有效上下文窗口，用 tree-sitter 做项目索引，支持 30+ 语言。

最大亮点是沙箱式 diff 审查——AI 生成的改动不直接写入文件，而是暂存在 Plandex 自己的版本控制里，你可以逐步审查、分支对比、回滚到任意状态。

这三个框架的共同点：它们都认为"先规划再编码"比"边聊边写"产出更高质量的代码。差异在于规划的粒度和执行的自动化程度。

四、Rules 生态与多 Agent 协调

当项目大到一定规模——多个模块、多个团队、甚至多个 AI Agent 同时工作——就需要更细粒度的规则管理。

cursor.directory / Open Plugins

Cursor 官方推出的插件市场，社区共享 rules / skills / agents / MCP servers。它定义了一个标准目录结构：

rules/*.mdc          # 行为规则
skills/*/SKILL.md    # 专业技能
agents/*.md          # Agent 角色
hooks/hooks.json     # 钩子脚本
.mcp.json            # MCP 服务器配置

这个 Open Plugins 规范正在成为 AI IDE 生态的事实标准。

agentic-cursorrules

解决一个特定问题：大仓库里多个 Agent 互相踩脚。

它把代码库按目录分区，为每个区域生成独立的 Markdown 规则文件（如 @agent_backend_api.md）。每个 Agent 只能看到自己负责的文件树。像给赛马戴上眼罩——只往前跑，不左顾右盼。

devin.cursorrules（⭐ 6k Stars）

一个巧妙的 hack：用 .cursorrules + scratchpad.md + Python 脚本，让 Cursor 模拟 Devin 的行为——先写计划、按计划执行、遇到错误自动回溯、积累"教训"到规则文件里。

它的核心概念是自我进化：每次你纠正 AI，它会把教训写回 .cursorrules，下次不再犯同样的错误。这让 AI 从"每次都是新手"变成了"越用越懂你"。

五、MCP：连接方法论与工具的胶水层

Model Context Protocol（MCP），Anthropic 在 2024 年底提出的工具调用协议，到 2026 年已经成为 AI IDE 的通用标准。

如果把前面的方法论比作"战略"，MCP 就是"后勤"——它决定了 AI 能调用什么外部能力。数据库查询、浏览器操作、文件系统、API 调用、甚至控制另一个 AI，都可以封装成 MCP server 暴露给 Agent。

MCP 之所以重要，是因为它把方法论从"只能聊天"升级到了"能做事"。BMAD 的 Architect Agent 可以通过 MCP 读取数据库 schema 再做架构决策；Taskmaster 可以通过 MCP 直接在 IDE 里创建和管理任务。方法论 + MCP = 有执行力的方法论。

目前主流 AI IDE 的 MCP 支持情况：

六、工具层 vs 方法论层：一张关系图

到这里，我们可以画一张清晰的分层图了：

┌─────────────────────────────────────────────────────┐
│  第五层：理念（Vibe Coding / Context Engineering）     │
├─────────────────────────────────────────────────────┤
│  第四层：全链路框架（BMAD / Taskmaster / Plandex）     │
├─────────────────────────────────────────────────────┤
│  第三层：规则与协调（.cursorrules / Memory Bank /       │
│          Open Plugins / agentic-cursorrules）         │
├─────────────────────────────────────────────────────┤
│  第二层：工具协议（MCP / CodeAct）                      │
├─────────────────────────────────────────────────────┤
│  第一层：AI IDE（Cursor / Claude Code / VS Code /      │
│          Windsurf / trae / 通义灵码 / Qoder）          │
└─────────────────────────────────────────────────────┘

企业培训常说的"用 trae/Qoder/Lingma 做 AI 全栈开发"，实际上只覆盖了第一层。而真正决定开发效率的，是你在第三到第五层做了多少投入。

一个用 Cursor + BMAD + Taskmaster 的团队，和一个只用 Cursor 写 Vibe Coding 的团队，用的是同一个 IDE，但产出可能差几倍。

七、全景对照表

选型建议

• 刚入门 AI 编程 → 从 Vibe Coding 开始，写几个小项目找感觉，同时给项目加一个 .cursorrules 或 CLAUDE.md
• 个人开发者做中型项目 → Taskmaster 管理任务 + CLAUDE.md/cursorrules 管理规范，够用
• 团队协作 → BMAD Method 全流程，配合 agentic-cursorrules 做域隔离
• 重度终端用户 → Plandex 的沙箱 diff 审查是独有优势
• 想要"越用越聪明"的 AI → devin.cursorrules 的自我进化机制

这些框架之间不互斥。BMAD 可以和 Taskmaster 搭配使用（BMAD 管方法论，Taskmaster 管执行）；MCP 是底层协议，跟上面每一个都兼容；.cursorrules 和 CLAUDE.md 是最低成本的起点，5 分钟就能给项目加上。

八、收束

回到开头的那个观察：工具在趋同。

2025 年初，选 Cursor 还是 Copilot 是一个重大决策；2026 年中，它们的功能差异已经小到可以忽略。Agent Mode、MCP 支持、多文件编辑、上下文窗口——你有的我都有了。

但方法论不会趋同。BMAD 的 12 Agent 全链路和 Taskmaster 的 PRD → Task 单链路，服务的是截然不同的团队和场景。.cursorrules 的轻量约束和 Memory Bank 的持久记忆，解决的是不同阶段的问题。

工具是交通工具，方法论是路线图。同样一辆车，有人在城市里乱转，有人沿着导航到达目的地。区别不在车，在图。

如果你现在还停留在"打开 IDE，开始聊天"的阶段，不妨从最简单的一步开始：在项目根目录创建一个 CLAUDE.md（或 .cursorrules），写下你的项目结构、技术栈、编码规范。就这一个文件，就能让 AI 的输出质量产生可感知的提升。

然后你会自然地想要更多：任务管理、角色分工、持久记忆、工具集成……

方法论的路，是一步一步走出来的。