本文适合：有一定编程经验、对 AI 辅助开发感兴趣的开发者
如果你现在打开编辑器，随手写一半函数，剩下的代码会自动补全出来。
这件事放在五年前，是科幻小说。
AI 辅助编程走到今天，经历了六个截然不同的阶段。每一次范式跃迁，都不只是工具变了——是我们和代码的关系变了。
这篇文章，我想把这段历史梳理清楚，因为只有理解"我们从哪里来"，才能判断接下来该怎么走。
阶段零：静态补全时代（2010 年前）
最早的代码补全，本质是字典查找。
IDE 维护一张关键字列表：if、for、while、class……你打出前两个字母，它在列表里匹配，把候选项弹出来。没有理解，没有推断，只有字符串前缀匹配。
后来进化出了 IntelliSense（微软，1996 年）。它能分析当前文件的 AST，知道你声明了哪些变量、对象有哪些方法。你打出 user.，它能列出 user.name、user.email。
这是静态分析，不是智能。它不理解你想做什么，只知道"语法上哪些是合法的"。
这个阶段持续了将近二十年，直到 2021 年，一个东西改变了一切。
阶段一：语义补全的诞生（2021 年）
2021 年 6 月 29 日，GitHub CEO Nat Friedman 发了一篇博客：
"Today, we're launching a technical preview of GitHub Copilot, a new AI pair programmer that helps you write better code."
▲ 2021 年 6 月，GitHub Copilot 技术预览版发布。由 GitHub 与 OpenAI 合作开发，底层是 OpenAI Codex 模型。
Copilot 和之前所有补全工具的本质区别：它理解意图，而不只是语法。
你写一个注释：// 计算两个日期之间的工作日数量，它能补全出完整的实现——包括跳过周末、处理节假日边界。它不是在查字典，是在"猜测你的意图，并给出实现"。
我第一次用 Copilot 时的感受是：这东西在读心术。
你只要写出函数名，或者写半行代码，它就知道你接下来要写什么。那种感觉，是把你脑子里模糊的意图，直接翻译成代码。
但这个阶段有个明显的天花板：Copilot 只能补全，不能对话。你不能问它"为什么这样写"，也不能让它帮你重构整个模块。它是一个非常聪明的"续写工具"，而不是一个协作者。
阶段二：对话驱动编程（2023 年）
2023 年，ChatGPT 引爆了一轮新范式。
不是因为 ChatGPT 的代码能力比 Copilot 强多少，而是它带来了一种全新的交互方式：对话。
你不再需要在代码里写半行等补全，你可以直接说：
"帮我写一个 Express 中间件，对所有
/api/路径的请求做 JWT 验证，验证失败返回 401"
然后你得到的是一段完整的、可直接运行的代码，外加一段解释。
这一阶段的特征是：开发者变成了需求描述者。写代码的比重下降了，而描述需求、审查输出、调整方向的工作量上升了。
很多开发者发现，自己的工作流从"写代码"变成了：
- 用自然语言描述需求
- 粘贴 AI 输出到编辑器
- 跑测试，看哪里挂了
- 把报错贴回去，让 AI 修
- 重复
这很高效，但也开始暴露问题：AI 不记得上下文，不了解你的项目，每次对话都从零开始。
阶段三：Vibe Coding（2025 年）
2025 年 2 月，前特斯拉 AI 总监、前 OpenAI 联合创始人 Andrej Karpathy 在 X 上发了一条推文，造出了一个新词：
"There's a new kind of coding I call 'vibe coding', where you fully give in to the vibes, embrace exponentials, and forget that the code even exists."
中文直译："我把它叫做 Vibe Coding——你完全顺着感觉来，拥抱指数级增长，甚至忘记代码本身的存在。"
这条推文后来被柯林斯词典评为 2025 年度词汇。
▲ Karpathy 在 AI Ascent 2026 峰会上从 Vibe Coding 讲到 Agentic Engineering。（图源：tonybai.com）
Vibe Coding 描述的是一种极端化的工作方式：
- 你不写代码，你描述你想要什么
- AI 生成整个实现
- 报错了，你把报错贴给 AI，不看报错内容
- AI 修好了，你继续下一个需求
- 你甚至可以不理解这段代码是怎么工作的
听起来很爽，对吧？
Karpathy 自己承认他沉迷过这种方式：
"我只是不停地要求更多，而它（AI）输出的总是对的。我记不清我上一次纠正它是什么时候了。"
这种顺滑感的背后，有一个隐患：你在渐渐失去对系统的理解。
Vibe Coding 对某些场景确实非常适用——快速验证一个想法、搭建 demo、写一次性脚本。但如果你用同样的方式去做生产系统，迟早会遇到一个 AI 根本无法帮你解决的问题，而你自己也看不懂代码。
阶段四：Agent 编程（2025—2026 年）
Vibe Coding 火了，但真正让开发者生产力发生质变的，是 Coding Agent 的成熟。
Cursor Agent、Claude Code、Devin 这一批工具，把 AI 的能力从"生成代码片段"，推进到了"自主完成多步任务"。
区别是什么？
| Chat-driven（阶段二） | Agent 编程（阶段四） | |
|---|---|---|
| 交互粒度 | 一问一答 | 多步骤自主执行 |
| 代码感知 | 无，每次从零开始 | 读整个代码库，理解项目结构 |
| 工具使用 | 无 | 可以运行终端命令、跑测试、查文件 |
| 错误处理 | 靠你粘贴报错 | 自动看报错、自动修、自动验证 |
一个典型的 Claude Code 使用场景是这样的：
$ claude "帮我把 UserService 里的所有数据库操作抽取成 Repository 层，
参考项目里现有的 OrderRepository 的写法，
写完之后跑 npm test 确认没有测试挂掉"
你不需要告诉它文件在哪里，不需要解释什么是 Repository 模式，不需要手动跑测试。它会自己读代码库、自己写、自己验证。
这一阶段的核心变化是：AI 从"代码生成器"变成了"任务执行者"。
但这也带来了新的复杂度——你现在面对的不是一个等你喂输入的工具，而是一个会自主行动的 Agent。你需要想清楚：它应该被允许做什么，不应该做什么。
阶段五：Harness Engineering（2026 年至今）
Agent 能跑了，但跑得稳吗？
早期用 Coding Agent 的开发者，都踩过类似的坑：Agent 陷入死循环、改了不该改的文件、一个 Bug 导致它反复调用 API 花了几十美元、在测试环境运行正常但生产环境行为完全不同……
问题的根源在于：大家都在关注 Agent 能做什么，但没有人认真设计 Agent 运行的"框架"。
这就是 Harness Engineering 要解决的问题。
Harness，直译是"马具"——套在马身上控制方向的那套装备。在 AI 工程语境里，Harness 指的是围绕 LLM 搭建的所有非模型代码：调度逻辑、工具注册、重试机制、状态管理、成本控制、可观测性……
一个完整的 Agent Harness 通常包含四个核心模块：
┌─────────────────────────────────────────┐
│ Agent Harness │
│ │
│ ┌─────────────┐ ┌─────────────────┐ │
│ │ Tool │ │ State Machine │ │
│ │ Registry │ │ （步骤调度） │ │
│ └─────────────┘ └─────────────────┘ │
│ │
│ ┌─────────────┐ ┌─────────────────┐ │
│ │ Retry & │ │ Observability │ │
│ │ Fallback │ │ （日志/成本） │ │
│ └─────────────┘ └─────────────────┘ │
│ │
│ ↕ LLM API │
└─────────────────────────────────────────┘
Tool Registry：明确告诉 Agent 它能用哪些工具、每个工具的参数格式，以及什么情况下调用哪个。少一个约束，Agent 就多一种"乱来"的可能。
State Machine：控制 Agent 的执行流程。每一步做什么、下一步是什么、失败了走哪条路——必须显式定义，不能靠 Agent 自己"想"。
Retry & Fallback：模型输出不符合预期（格式错误、内容离题、工具参数缺失）时，有明确的重试策略和降级逻辑，而不是直接崩溃或无限重试。
Observability：每次 LLM 调用的 input、output、耗时、token 用量、cost，全部留存可查。没有这层，Agent 出了问题你根本不知道发生了什么。
Harness Engineering 的核心洞察是：模型智能是不稳定的，工程设计是可控的。 你不能指望模型每次都完美，但你可以设计一个足够健壮的框架，让它在出错时能优雅降级，而不是整个系统崩掉。
这也是 AI 编程范式演进的终点逻辑：从"怎么让 AI 写代码"，到"怎么让 AI Agent 在生产环境稳定可靠地运行"。
当下的困境：工具越来越强，但「如何用好」反而更难了
五个阶段走下来，有一个规律越来越明显：
模型能力的提升，并没有线性地转化为开发者效率的提升。
原因在于，制约效率的瓶颈在变。
- 早期（阶段零），瓶颈是工具能力，IDE 太笨
- 中期（阶段二），瓶颈是上下文管理，AI 不了解你的项目
- 现在（阶段四），瓶颈是如何有效地驾驭 AI——怎么把你的项目上下文传递给它，怎么设计 Agent 的工具权限，怎么让它稳定输出你想要的质量
换句话说，越到后面，对"用 AI 的人"的要求越高。
Karpathy 在 2026 年的 AI Ascent 峰会上，把这一现象总结得很到位：
"Vibe Coding 是在提升所有人的下限。而 Agentic Engineering，是在探索质量与效率的上限。"
▲ Karpathy 在峰会上区分了「Vibe Coder」和「Agentic Engineer」两种开发者画像。（图源：tonybai.com）
会 Vibe Coding，是这个时代开发者的入场门票。
但能做好 Agentic Engineering，才是真正的竞争壁垒。
小结
回顾五个阶段：
| 阶段 | 时间 | 标志事件 | 核心变化 |
|---|---|---|---|
| 零：静态补全 | 2010 年前 | IntelliSense | 关键字匹配 |
| 一：语义补全 | 2021 年 | GitHub Copilot | AI 理解意图 |
| 二：对话驱动 | 2023 年 | ChatGPT 爆火 | 需求描述代替手写 |
| 三：Vibe Coding | 2025 年 | Karpathy 提出 | 顺着感觉，忘记代码 |
| 四：Agent 编程 | 2025—2026 年 | Claude Code / Cursor Agent | AI 自主执行多步任务 |
| 五：Harness Engineering | 2026 年至今 | Agent 大规模落地 | 设计可靠的 Agent 运行框架 |
我们正处于第四和第五阶段的交界处——Agent 能跑起来已经不是难题，难题是如何让它在生产环境稳定运行、成本可控、出错可查。
下一篇，我会聊聊 Vibe Coding 为什么经常翻车——不是在否定它，而是帮你理解它的边界在哪里，以及翻车背后真正的技术原因。
作者：与 AI 结对编程
关注公众号「与 AI 结对编程」，持续更新 AI 工程实践。
