AI Coding 路线图：从 Vibe Coding 到 Context Coding

文章目录

• 0.引言
• [1.阶段一：提示工程师 （Prompt Coder）](#1.阶段一：提示工程师 （Prompt Coder）)
• • [1.1 特征](#1.1 特征)
  • [1.2 为什么很多人停在这里？](#1.2 为什么很多人停在这里？)
  • [1.3 怎么跳到阶段二？](#1.3 怎么跳到阶段二？)
• [2.阶段二：规划师（Plan Coder）](#2.阶段二：规划师（Plan Coder）)
• • [2.1 特征](#2.1 特征)
  • [2.2 Plan Mode 的陷阱](#2.2 Plan Mode 的陷阱)
• [3.阶段三：上下文工程师（Context Engineer）](#3.阶段三：上下文工程师（Context Engineer）)
• • [3.1 特征](#3.1 特征)
  • [3.2 Token 是 AI 的硬通货](#3.2 Token 是 AI 的硬通货)
  • [3.3 Context Rot：你一直在和它过招](#3.3 Context Rot：你一直在和它过招)
  • [3.4 如何应对？](#3.4 如何应对？)
  • [3.5 做减法比做加法更难](#3.5 做减法比做加法更难)
  • [3.6 阶段四是啥？](#3.6 阶段四是啥？)
• [4.阶段四：系统编排者（System Orchestrator）](#4.阶段四：系统编排者（System Orchestrator）)
• • [4.1 特征](#4.1 特征)
  • [4.2 能力 1：触碰现实（MCP）](#4.2 能力 1：触碰现实（MCP）)
  • [4.2 能力 2：消灭重复（Skills / 自定义命令）](#4.2 能力 2：消灭重复（Skills / 自定义命令）)
  • [4.3 能力 3：分身协作（Multi-Agent）](#4.3 能力 3：分身协作（Multi-Agent）)
• 推荐阅读

0.引言

近期 AI 编程发展地如火如荼，各种概念层出不穷：

• Vibe Coding
• Prompt Engineering
• Context Engineering
• MCP
• Agentic Coding...

每个都号称是下一个编程范式，但你既不清楚它们之间的关系，也不知道自己该如何下手，目前处于哪个阶？

面对层出不穷的 AI 编程概念，你是否感到迷茫？

本文将为你梳理一条清晰的进阶路径，揭示这些概念如何层层递进，解决上一阶段的遗留问题。

本文尝试将 AI Coding 过程总结为四个阶段：

• 阶段一：提示工程师 （Prompt Coder）
• 阶段二：规划师（Plan Coder）
• 阶段三：上下文工程师（Context Engineer）
• 阶段四：系统编排者（System Orchestrator）

每个阶段都有各自的问题，AI Coding 也确实不是万能的。但我们恰恰是在面对这些问题、解决这些问题的过程中成长的。悲观者可能正确，但乐观者永远前行。

1.阶段一：提示工程师 （Prompt Coder）

1.1 特征

核心特征：单向指令 | 陷阱：AI 垃圾。

这是所有人的起点，也是大多数人停留的地方。

2025 年 2 月，Andrej Karpathy（OpenAI 联合创始人、前特斯拉 AI 总监）在 X 上创造了 Vibe Coding（氛围编程） 这个词：

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

--- Andrej Karpathy, Feb 2025

MIT Technology Review 后来为此专门写了篇文章------Vibe Coding 不是泛指所有 AI 辅助编程，而是特指那种放弃控制、凭直觉推进的编码方式。Karpathy 本人也承认，这种方式适合原型和个人项目，但不适合生产系统。

Vibe Coding 虽然方便，但是产生的代码表面可用，内部混乱。

这是Vibe Coding最普遍的问题。AI生成的代码往往能跑通，但不一定能跑好。

• 缺乏设计模式：代码通常是过程式的堆砌，缺乏面向对象设计、模块化或清晰的抽象。多个功能可能被塞进一个巨大的函数里，导致代码难以阅读和维护。

• 命名混乱：变量、函数、类的命名可能不一致、无意义或与功能不符（如 data1、temp2、process_data）。

• 冗余代码：经常出现重复的逻辑、未使用的导入、多余的变量赋值。

• 糟糕的错误处理：通常只处理了"快乐路径"（Happy Path），对异常情况、边界条件、网络中断、用户误操作等缺乏健壮的考虑。

后果：这种代码被称为"一次性代码"或"拼凑品"，也就是 AI 垃圾。它能跑，但不属于你的项目。你得花大量时间修剪它，最后发现还不如自己写来得快。
否
是
开始
定义: 拆解任务
生成: AI写代码
验证: 代码正确?
反馈: 报错/修改意见
优化: 重构/加注释
交付代码

1.2 为什么很多人停在这里？

1. 即时满足感太强。

30 秒出代码，编译通过，测试绿灯------这个正反馈回路太短了。你很容易产生"AI 已经帮了大忙"的错觉，而忽略后面花两小时修剪代码的隐性成本。就像点外卖很快，但你不会因此觉得自己会做菜。

2. 搜索引擎惯性。

我们用了十几年 Google/Stack Overflow，思维模式早已固化为"输入问题 → 拿答案"。AI 聊天框长得跟搜索框一模一样，于是大脑自动切换到搜索模式：一句话甩过去，等结果。但 AI 不是搜索引擎，它是一个可以和你协作的实体------只是你没给它协作的机会。

3. 缺少质量基线。

如果你不清楚"好代码"长什么样------不清楚自己项目的分层架构、错误处理规范、命名约定------那 AI 吐出什么你都觉得"还行"。阶段一的本质问题不是 Prompt 写得不好，而是你对输出的标准太低。

4. 门槛最低的蜜罐。

不需要学任何新概念、不需要配置任何东西、不需要改变任何习惯。打开 Cursor，打字，回车。这个"零成本上手"恰恰是最大的陷阱------因为太容易，所以没有动力改变。如果大家都会的，又怎么体现 coder 的核心能力呢？

1.3 怎么跳到阶段二？

当你第三次发现"修剪 AI 代码的时间超过了手写的时间"，就该停下来了。

"Most AI failures in production are context failures, not model failures."

--- Anthropic, Effective Context Engineering for AI Agents

AI 给的"平均答案"，不是因为它笨，是因为你没给约束。

具体行动：下次开 Cursor 的时候，做一个简单的改变------不要说"写个 XXX"，改成说"帮我规划一下怎么实现 XXX"。就这一个词的区别（"写" → "规划"），会把你从单向命令模式拉进双向对话模式。

或者更直接：打开 Plan Mode。

2.阶段二：规划师（Plan Coder）

2.1 特征

核心特征：双向对话 | 关键工具：Plan Mode

当 Cursor 和 Claude Code 进入 Plan Mode（规划模式） 时，游戏规则变了。

核心原则：别让 AI 直接写代码，先让它出方案。

这个阶段我们要做的是在编码前先和 AI"吵架"。

比如"做一个订单状态流转系统。"

AI 不再直接生成代码，而是反问："状态流转规则是什么？有终态吗？不同证券市场的订单的流转逻辑一样吗？"

当AI从"代码生成器"转变为"专家顾问"，并通过反问来澄清需求，这种做法带来了本质上的好处。它标志着AI从工具向协作者的跃迁。

这种双向交流，不仅让 AI 能更清楚的了解需求，也让开发者对需求有更全面的了解。

与 AI 的交互流程变成了下面这个样子：

1. 触发规划：人类提出模糊需求，AI进入Plan Mode，不直接写代码。

2. 反问澄清：AI通过一系列问题（状态规则？终态？区域差异？）逼迫人类思考。

3. 人类反思：人类发现自己思维盲区，不同证券市场的订单的流转逻辑不一样。

4. 梳理反馈：人类想清楚后，向AI详细描述各区域的差异逻辑。

5. AI理解：AI吸收信息，按区域分别建模。

6. 达成共识：通过多轮"吵架"直到双方对方案理解一致。

7. 输出方案：AI 输出设计方案（状态图、伪代码等），供人类审查。

8. 进入编码：方案通过后，才进入真正的代码生成阶段。

这个流程的核心是：先聊透，再动手。
代码 AI规划师 人类开发者 代码 AI规划师 人类开发者 人类反思 loop [多轮对话] 达成共识 触发规划 反问澄清 梳理反馈 AI理解 追问细节 补充说明 输出方案 进入编码 生成代码

Plan Mode 的价值不在于让 AI 帮你干活，而在于通过一来一回的博弈，把你脑子里那些"理所当然"的隐性知识逼出来。

研究也印证了这一点。MIT Technology Review 指出，即便是 Vibe Coding，也需要编程专业能力，只是能力重新分配了------从写代码转向了上下文管理、快速评估、以及判断何时接管 AI。

2.2 Plan Mode 的陷阱

Plan Mode（规划模式）虽然能极大提升需求清晰度和代码质量，但它并非银弹。在实际使用中，也要警惕 Plan Mode 的陷阱。

1. Plan Mode 的成功体验反而成了舒适区。

你学会了和 AI 对话，代码质量确实比阶段一好了。你觉得"够用了"。这种进步带来的满足感，恰恰是通往下一阶段最大的阻力------因为你已经觉得自己"会用 AI 了"。

2. 每次对话都在重复同样的背景介绍。

"我们项目用 DDD 分层"、"错误要用 xerror"、"状态变更要走 FSM"------你发现自己每次新开对话都要说一遍同样的话。这个重复劳动很烦，但你已经习惯了，觉得这是"用 AI 的正常成本"。实际上这是一个信号：你的知识应该持久化，而不是每次口头传达。

3. 对话越长，AI 越糊涂。

你和 AI 聊了 20 轮，前面说好的约束它开始忘了，开始自相矛盾。你以为是 AI"变蠢了"，其实是 Context Rot（上下文腐烂） ------ 对话太长，早期信息被淹没。但大多数人不知道这个概念，只是每次遇到就新开一个对话，从头再来。

4. 没有意识到"知识可以代码化"。

很多人不知道 Cursor Rules、CLAUDE.md 这些机制的存在。或者知道但觉得"花时间写文档不值得"。这里有一个认知盲区：你以为写 Rules 是"额外工作"，实际上它是一次投入、永久复利。

3.阶段三：上下文工程师（Context Engineer）

3.1 特征

核心特征：管理上下文窗口 | 核心对手：Context Rot

阶段二你学会了和 AI 对话，代码质量上去了。但你很快会遇到一个诡异的现象：同一个 AI，有时候表现惊艳，有时候蠢得离谱。

为什么？

因为你一直忽略了一个东西------上下文窗口（Context Window）。

3.2 Token 是 AI 的硬通货

所有 AI 模型都有一个上下文窗口，你可以理解为它的"工作记忆"。你发给 AI 的每一个字、AI 回复的每一个字、加载的每一个文件、每一条规则------全部以 Token 的形式填充这个窗口。

Token 就是 AI 世界的硬通货。Claude Opus 4.6 在你手上有几层功力，不取决于模型本身的能力上限，而取决于你怎么管理这个窗口。窗口干净、信息精准，它就是顶级架构师；窗口臃肿、垃圾堆积，它就是一个糊涂的实习生。

在 Claude Code 里，你可以随时输入 /context 查看上下文窗口的占用情况。这个命令应该变成你的习惯------就像开车看油表一样。

3.3 Context Rot：你一直在和它过招

Context Rot（上下文腐烂）是这个阶段你要面对的核心对手。简单说就是：上下文内容越多，AI 的表现越糟糕。

这不是理论，是实测结果。

有人做过系统测试：上下文占用 20-30% 时，AI 输出精准、结构一致；50% 时，小问题开始出现------命名风格漂移、导入路径混乱；70% 以上，AI 开始"自信地犯错"------语法正确但架构决策完全跑偏。

https://research.trychroma.com/context-rot

Anthropic 在其工程博客中也正式确认了这一点，并总结了四种上下文失败模式：

失败模式	表现
Poisoning（中毒）	AI 的幻觉输出被当作"事实"反复引用，错误滚雪球
Distraction（分散）	过多历史对话淹没了当前任务重点
Confusion（混淆）	无关信息干扰判断，AI 开始张冠李戴
Clash（冲突）	上下文中存在矛盾指令，AI 左右为难

这个问题至今没有根本解决。2026 年了，Context Rot 依然在。

3.4 如何应对？

核心操作：留意上下文窗口的状态，到一定阶段主动 clear（重置）。

操作	说明	我的建议
/context	查看当前窗口占用	养成习惯，像看油表一样频繁
/clear	清空上下文，全新开始	每完成一个独立子任务就 clear，宁可重新铺垫
/compact	压缩上下文，保留摘要	不太推荐------效果一般，压缩本身也消耗 token，反而加速腐烂

大部分人不愿意 clear。心理上总觉得"前面聊了这么多，清掉可惜"。但事实是：一个干净的 50% 窗口，远比一个臃肿的 90% 窗口有价值。被腐烂的上下文拖累的 AI，还不如一个重新开始但方向明确的 AI。

3.5 做减法比做加法更难

这个阶段最违反直觉的认知转变是------不是给 AI 越多信息越好，而是要判断哪些信息帮助它、哪些信息伤害它。

举个例子。CLAUDE.md 曾经一度风靡------项目根目录放一个文件，写满编码规范和架构约定，AI 每次启动自动加载。听起来很美。但后来的研究发现，CLAUDE.md 在某些场景下反而会拉低成功率。为什么？因为那些规范并不是每个任务都需要，但它们每次都会占用上下文窗口。你以为在"教 AI"，实际上是在"分散 AI 的注意力"。

同样的道理：

• 把整个仓库加载进来？伤害。AI 的注意力被稀释。
• 一次加载十个配置文件"以防万一"？伤害。不相关的信息就是噪音。
• 在一个长对话里做完五个不相关的任务？伤害。前面的任务残留是后面任务的毒药。

Anthropic 把这个核心思想总结成一句话：

"Finding the smallest possible set of high-signal tokens that maximize the likelihood of some desired outcome."

--- Anthropic, Effective Context Engineering for AI Agents

翻译成大白话：用最少的、最精准的信息，换取最好的结果。

上下文工程师的核心技能，不是"怎么给 AI 更多信息"，而是"判断哪些信息该给、哪些信息不该给"。这是做减法的艺术。

3.6 阶段四是啥？

某天你统计了一下自己的工作时间分配，发现只有 30% 的时间在真正写代码，剩下 70% 都在查日志、查数据库、发通知、手动测试、等部署。你突然意识到：AI 只帮你优化了那 30%。

具体行动：

1. 列出你每天做得最多的 3 个"非编码任务"；
2. 挑最高频的那个（大概率是查数据库），花一个下午接入一个 MCP Server；
3. 把你最常重复的操作流程封装成一个 Skill；
4. 体验到"动嘴比动手快"的那一刻，你就回不去了。

4.阶段四：系统编排者（System Orchestrator）

4.1 特征

核心特征：工具链 + 多 Agent | 核心能力：一人成军

前三个阶段都在优化"我和 AI 的单次沟通"。到了阶段四，游戏规则彻底变了：我不只在写代码，我在设计一套 AI 工作的系统。

这一阶段融合三个关键能力：

4.2 能力 1：触碰现实（MCP）

MCP（Model Context Protocol）是 Anthropic 创建的开放标准，2025 年 12 月捐赠给 Linux Foundation。业界称它为 "AI 的 USB-C" ------ 一套统一的协议，让 AI 连接任意外部工具和数据源。

截至 2026 年 2 月的生态数据：

• 9700 万 月 SDK 下载量
• 13,000+ GitHub 上的 MCP Server 实现
• 所有主流厂商接入：Anthropic、OpenAI、Google、Microsoft、Amazon

你的 IDE
MCP
MCP
MCP
MCP
MCP
AI Agent
数据库
飞书
浏览器
Notion
...

实操场景：

场景	以前 (纯手动模式)	现在 (MCP 模式)
查订单状态	打开 DBeaver → 手动执行多条 SQL 语句 → 人肉拼接状态，拼凑出业务全貌。	一句话完成："查一下订单 xxx 的全链路状态"。AI 通过 MCP 自动查询数据库并分析返回结果。
回归测试	手动打开后台管理系统 → 一步步点击导航菜单 → 输入查询条件 → 手动截图并粘贴到文档。	AI 直接操作浏览器，自动执行回归测试步骤，并自动截图生成报告。

MCP 的三个核心概念：Resources（只读数据，类似 GET）、Tools（执行操作，类似 POST）、Prompts（预定义模板，类似 Swagger）。

另一个常见问题：MCP 和 Google 主导的 A2A（Agent-to-Agent） 协议是什么关系？答案是互补------MCP 解决 agent 连接工具，A2A 解决 agent 之间协调。

4.2 能力 2：消灭重复（Skills / 自定义命令）

如果你发现自己总在重复同一套 Prompt，就该把它固化成 Skill。

这不仅仅是省时间，而是把最佳实践代码化、可复用化。

4.3 能力 3：分身协作（Multi-Agent）

SWE-bench（AI 编程能力基准测试）有一个反直觉的发现：同一个底层模型，在不同 Agent 框架下的得分差了 17 题。这说明 Scaffolding（编排框架）比 Model（模型）更重要------选对工具、配好上下文，比追逐最新模型效果更大。

2026 年的 AI 编程工具已经分化成三大品类：

品类	代表工具	特点
终端 Agent	Claude Code / Aider / Gemini CLI	最省 token，适合大规模重构
IDE Agent	Cursor / Windsurf / GitHub Copilot	最佳 IDE 集成，日常开发首选
自主 Agent	Devin / OpenAI Codex	端到端自主执行，云端并行

也有的形态是利用 Git Worktrees 实现多 Agent 并行：
指挥官（你）

定义接口契约 & 分发任务
Agent A

feature/api

后端接口
Agent B

feature/ui

前端组件
Agent C

feature/test

测试用例
合并 & 冲突解决
交付

多 Agent 并行效率惊人，但最大挑战不是写代码，是 Merge。如果三个 Agent 对接口定义的理解不一致，合并时就是灾难。前提条件：你必须先把接口契约定义清楚，然后才分发任务。

推荐阅读

资源	链接	一句话推荐
Anthropic: Context Engineering	anthropic.com	上下文工程的理论根基
MIT: What is Vibe Coding?	technologyreview.com	Vibe Coding 的定义与边界
Cursor Docs: Rules	cursor.com/docs/rules	官方 Rules 配置指南
awesome-cursorrules	github.com	38k+ stars 的社区 Rules 模板集
MCP 官方文档	modelcontextprotocol.info	从零搭建 MCP Server
AI Coding Agents 对比	lushbinary.com	2026 主流工具功能 & 价格横评