你以为自己在用 AI 编程。
实际上，AI 在用你。
这不是修辞。当你把 AI 当作代码生成器——输入需求、接收代码、提交上线——你正在把自己训练成 AI 工作流中最没价值的环节：一个人肉回车键。
2025 年 2 月，Andrej Karpathy 在 X 上发了一条帖子，给这种编程方式起了个名字：Vibe Coding（氛围编程）——“完全沉浸在感觉中，依靠 LLM 生成代码，而不需要真正理解输出”。这个词后来被柯林斯词典选为 2025 年度词汇。
一年后的今天，行业的对话已经翻篇了。问题不再是"要不要用 AI 编程"，而是"你在 AI 工作流中扮演什么角色"。
这篇文章要说的，就是这条分水岭两边的区别。
一、你用 AI 写代码很快，但你不踏实
GitHub 的一项研究给出了一个具体数字：使用 Copilot 的开发者完成任务的速度比未使用的快 55%。实验场景是用 JavaScript 写一个 HTTP 服务器——使用 Copilot 的组平均用时 1 小时 11 分钟，对照组 2 小时 41 分钟。
55% 的提速。听起来像是一个值得庆祝的数字。
这也只是故事的一半。
另一半是你在日常工作中已经感受到的：AI 产出的代码越来越多，但你对项目代码库的掌控感在下降。你不确定那段 AI 生成的逻辑是否覆盖了所有边界情况。你不确定那个自动补全的错误处理是否真的合理。你不确定三个月后回来看这段代码，还能不能读懂。
一天产出过去一周的代码量，这在 AI 辅助开发中很常见。代价是这些代码的可维护性、安全性、性能可能都成问题。
代码审查的压力也随之而来。AI 生成的代码需要更仔细的审查，因为你不是写它的人，你不知道它的隐含假设是什么。产出量上去了，审查量也跟着上去。
这种"速度提升但掌控感下降"的体验，不是你的错觉。
它有一个准确的诊断：你在做 Vibe Coding。
划重点：速度提升是真实的（55% 有研究支撑），但掌控感下降也是真实的。如果你只感受到了前者而忽略了后者，你可能正在用一种注定不可持续的方式和 AI 协作。
二、Vibe Coding 和 Agentic SE：不是工具的区别，是方法论的质变
先把两个概念说清楚。
Vibe Coding（氛围编程）——用直觉和提示词驱动的 AI 编程方式。你说一句话，AI 生成一段代码。你觉得差不多，提交。没有系统性的测试、没有架构审查、没有明确的质量门禁。核心特征是"快，但不可控"。
Agentic Software Engineering（智能体软件工程）——人定义目标、约束和质量标准，AI Agent 在结构化监督下自主完成从设计到提交的完整流程。核心特征是"人管方向，AI 管执行"。
两者的区别不在于你用了什么工具。用 Cursor 可以做 Vibe Coding，也可以做 Agentic SE。用 Claude Code 同样如此。
区别在方法论。
想象你管理一个实习生。Vibe Coding 相当于你口头说一句"帮我写个用户注册功能"，然后实习生闷头写了两天交给你，你看了一眼就合并了。Agentic SE 相当于你给实习生一份完整的需求文档、架构规范、测试标准和验收清单，实习生按照流程逐步完成，每个环节都有质量检查点。
同一个实习生，两种管理方式，产出的质量天差地别。
Agentic SE 的典型工作流分 6 步：
- 理解需求——AI 分析上下文，明确要做什么、不做什么
- 设计方案——AI 生成实现方案，人确认后再动手
- 代码实现——AI 按方案编写代码
- 自动测试——AI 编写并运行测试用例
- 质量审计——AI 检查代码规范、安全漏洞、性能问题
- 提交 PR——AI 生成变更说明，人做最终审查
每一步都有人的监督接入点。这和 Vibe Coding 的"一步到位"模式有本质区别。
你只需要知道：Vibe Coding 和 Agentic SE 的核心差异是"人在 AI 工作流中的位置"。前者中人是被动接收者（“AI 写了什么我就用什么”），后者中人是主动设计者（“我定义 AI 怎么工作”）。
三、2026 年的三个分水岭信号
“从 Vibe Coding 到 Agentic Engineering"这个判断不是我的发明，它正在被学术界、企业界和行业观察者同时验证。
信号一：学术界已经点名。
智谱 AI 和清华大学联合发布了 GLM-5（744B 参数），这篇论文的标题直接用了 “From Vibe Coding to Agentic Engineering”。当一个顶级研究团队把这个叙事写进论文标题，说明它已经从社交媒体上的流行语变成了学术界认可的范式描述。
信号二：企业级已经落地。
JPMorgan 在 AI Agent 领域的标杆技术会议 LangChain Interrupt 上展示了 “Ask David”——一个多智能体 AI 系统，用于处理复杂的投资研究分析。不是原型，不是 demo，是在生产环境中服务金融专业人士的系统。多个专业 Agent 各司其职，人类专家在关键节点做决策。
这就是 Agentic SE 在企业级的样子。
信号三：行业共识正在成型。
MIT Technology Review 在一篇深度分析中指出，2025 年软件工程领域最大的转变是从"追求速度和规模"到"管理上下文”。原文的表述是：“The fact the conversation has moved from questions of speed and scale to context puts software engineers right at the heart of things.”
一句话说：当 AI 的瓶颈从算力变成了上下文理解，工程师的价值不是降低了，而是被重新定义了。
| 信号 | 来源 | 核心信息 |
|---|---|---|
| 学术界点名 | GLM-5 论文（智谱 AI / 清华） | 论文标题直接使用 “From Vibe Coding to Agentic Engineering” |
| 企业级落地 | JPMorgan “Ask David” | 多 Agent 系统在金融生产环境中运行 |
| 行业共识成型 | MIT Technology Review | 软件工程核心转变：从追求速度到管理上下文 |
三个信号指向同一个结论。
2026 年，工程师的分水岭不是"会不会用 AI"，而是"你在 AI 工作流中扮演什么角色"。
一句话总结：这不是一家之言。学术论文、企业实践、行业媒体从不同角度验证了同一个判断——Vibe Coding 到 Agentic Engineering 的转变正在发生。
四、Agentic Engineer 的三个核心能力
认清分水岭之后，下一个问题是：从 Vibe Coding 这一侧走到 Agentic SE 那一侧，你需要什么。
答案可以压缩成三个维度的能力转型。
从"写提示词"到"设计上下文"：上下文工程
MIT Technology Review 把这个能力叫 Context Engineering（上下文工程）。
最直观的例子：在项目根目录维护一个 CLAUDE.md 文件（如果你用 Claude Code 的话），把项目的技术栈、编码规范、禁止事项、测试要求写清楚。每次 AI 开始工作时自动读取这个文件，相当于给 AI 配了一份"项目记忆"。
这和"写一个好的提示词"是不同级别的事情。提示词解决的是"这次对话让 AI 做什么"，上下文工程解决的是"AI 在这个项目中的所有行为都遵循什么规则"。
一个是单次对话的输入，一个是持久化的工作环境设计。
前者是 Vibe Coding 的天花板。后者才是 Agentic SE 的起点。
从"手动调试"到"设计质量门禁"：测试设计
有完善测试的代码库，AI 做了改动后可以立刻验证是否破坏了现有行为。没有测试的代码库，AI 的每一次改动都是一次赌博。
这个逻辑在传统开发中就成立。在 AI 辅助开发中，它被放大了十倍——因为 AI 产出的代码量远超人类手写，如果没有自动化测试作为安全网，技术债的累积速度会让你绝望。
Agentic Engineer 的测试策略不只是"写单元测试"。它包括为 AI 的输出设计验收标准，定义什么样的代码可以自动合并、什么样的必须人工审查。
这是在给 AI 设计质量门禁。
从"一问一答"到"多 Agent 协作"：Agent 编排
Simon Willison 在他的 Agentic Engineering Patterns 系列中提出了一个核心原则：Agent 系统的最大敌人不是 LLM 的能力不够，而是不可调试性——如果你不知道 Agent 为什么做了某个决定，你就无法改进它，也无法信任它。
MCP（Model Context Protocol）正在成为 Agent 工具连接的事实标准。一个被广泛引用的类比是：MCP 对 Agent 工程的意义，类似于 REST 对 Web API 的意义——不是唯一方案，但正在成为行业默认选择。
对于大多数后端工程师来说，Agent 编排不需要你从零构建框架。它需要你理解 Agent 的协作模式，能把复杂任务分解成多个 Agent 各自负责的子任务，能设计 Agent 之间的通信和监督机制。
这些技能，和你在微服务架构中做服务编排的经验是相通的。
三个转型方向：（1）上下文工程：从写提示词到设计 AI 的工作环境；（2）测试设计：从手动调试到设计 AI 的质量门禁；（3）Agent 编排：从一问一答到多 Agent 协作流水线。这不是要你学全新的东西，而是把已有的工程思维应用到 AI 协作场景中。
五、从今天开始的三件事
如果你读到这里，认同这条分水岭确实存在，下一步不是等，是动手。
三件具体的事，每件都可以在 5 分钟内起步——起步，不是完成。从 Vibe Coding 到 Agentic SE 是一个持续的过程，这三件事只是你迈出的第一步。
第一件：给你最重要的项目加一个上下文文件。
如果你用 Claude Code，创建一个 CLAUDE.md。如果你用 Cursor，创建一个 .cursorrules。写上四样东西：技术栈说明、编码规范、禁止事项、测试要求。
不需要写很长。“这个项目用 Go 1.22，数据库是 PostgreSQL，所有 API 都要有对应的单元测试，禁止使用全局变量”——30 个字，已经比没有上下文文件的项目领先了一步。
第二件：为 AI 产出的代码补一个测试。
从最危险的模块开始——支付、权限、数据处理。不需要追求 100% 覆盖率，先给最关键的路径加上安全网。
有了测试之后，AI 的每一次改动都可以被自动验证。这是从 Vibe Coding 到 Agentic SE 最小的一步，也是最关键的一步。
第三件：改变你和 AI 对话的方式。
把"帮我写一个用户注册功能"改成"按照以下规范实现用户注册功能：接口定义见 API 文档，错误处理使用项目预定义的错误类型，需要包含输入校验和单元测试"。
前者是 Vibe Coding。后者是 Agentic SE 的起手式。
区别不在字数，在意图的精确度。
分水岭的意义不在于你站在哪一侧，而在于你是否意识到这条线的存在。
2026 年，最大的风险不是"不会用 AI"，而是"以为自己在用 AI，实际上被 AI 用"。
从今天开始，做 AI 的架构师，不是 AI 的回车键。
本文是"AI 时代工程师进化"系列的第一篇。下一篇将深入实操：Agentic Engineering Patterns——从单 Agent 到多 Agent 的可复用设计模式。
从今天开始：（1）加上下文文件（5 分钟起步）；（2）补关键路径测试；（3）升级你和 AI 对话的精确度。不需要一步到位，但需要从现在开始。
参考资料
- Andrej Karpathy 关于 Vibe Coding 的原帖 — Vibe Coding 概念的起源（2025.2）
- GitHub Copilot 效率研究 — 55% 速度提升的原始研究数据
- GLM-5 论文 (arXiv:2602.15763) — 智谱 AI / 清华大学，标题呼应"From Vibe Coding to Agentic Engineering"
- MIT Technology Review: From vibe coding to context engineering — Context Engineering 概念的行业分析
- Simon Willison: Agentic Engineering Patterns — 可复用的 Agent 工程模式与实践
- The Bootstrapped Founder: How to Actually Use Claude Code — Claude Code 工程化使用的最佳实践