雄关漫道真如铁，而今迈步从头越。——毛泽东《忆秦娥·娄山关》
题记：这是我在上周做的我在极客时间的 AI 训练营二期的开营直播的讲座语音稿。如果对这个训练营感兴趣，可以扫描文末的二维码。
过去两年，我从 Cursor 的付费用户一路走到 Claude Code 的深度使用者，又在公司内部大力推行 AI 编程工具，把它从”尝鲜玩具”变成了主力生产工具。在这条路上，我目睹了 AI 编程从一个众人嗤之以鼻的概念，演变为每个工程师、每家公司都必须严肃对待的历史洪流。
这篇文章，是我对这段历程的一次系统性总结。不讲虚的，只谈实质。
一、形势判断：星火已燎原
2025 年初，Karpathy 提出”氛围编程”（Vibe Coding）的时候，它还是一个初级的概念——大家拿它做几个酷炫网页，觉得有意思，也就到此为止了。绝大多数从业者对此不以为然：一个严肃的系统，怎么能由 AI 来写？
不到一年，天翻地覆。
今天，我们已经可以用 AI 生成整个软件系统的基础设施代码，驱动从后端到前端、从无服务器架构到传统服务架构的全流程开发。我们有一整套完全由 Claude Code 生成的基础设施代码，在生产环境中每天进行大量部署——全部由 AI 驱动。
这不再是茶余饭后的谈资，而是正在发生的现实。
在我看来，未来 6 到 18 个月，AI 编程将成为编程的主力。 人类工程师将把精力集中在定义问题、选择方案和最终验收上，而具体的编码工作，将越来越多地交给 AI 来执行。主流的工作流将变成：人定义问题 → AI 提供多个方案 → 人选择方向 → AI 执行编码 → 人审阅验收。
这个转变，不是在远方，而是在脚下。
二、试错成本的革命：从万金油到一次性
为什么氛围编程必将成为大势所趋？这要从一个根本性的经济问题说起——试错成本。
以前，想做一个新产品或验证一个新想法，成本极高。你需要一个五到十人的团队——运维、后端、前端、甚至机器学习工程师——花三到六个月把想法推进到可验证的阶段。如果产品失败了，整个投入就打了水漂。这使得软件工程在试错方面的代价极其高昂，很多好的想法因此胎死腹中。
而有了氛围编程，一切不同了。
我有一个想法，或者在市面上看到一个有意思的产品，我可以直接把想法告诉 Claude Code，让它替我生成一个从后端到前端的完整产品。我甚至不用关心它的代码质量——因为这就是一个用完即弃的软件，我只想验证我的想法。上线之后让一小群人体验、反馈，方向可行就认真做第二版；不可行就果断弃之，损失微乎其微。
快速失败，快速构建——这就是氛围编程对创新最大的贡献。
当然，事物要一分为二地看。面向用户的核心产品，你需要严谨性；基础设施的变更，需要足够的审核。但内部系统，尤其是面向开发者或小群体的工具系统，完全可以放开手脚去试错。据我观察，氛围编程已经在很多公司的内部系统里大量使用，同时在面向用户的系统中做局部尝试。内部先行、逐步外推——这是一条稳妥的路径。
三、AI 是新的编译器
今年 1 月是一个很有意思的月份。Linux 之父 Torvalds 和 Redis 之父 Antirez——这些行业里最资深的工程师——纷纷开始拥抱氛围编程，给予正向评价。Torvalds 甚至说：AI 是新的编译器。
这个类比相当精辟。
在我职业生涯早期，我写过大量汇编语言。六七十年代的工程师，唯一的编程语言就是汇编。编译器出现后，他们可以写更高级的语言，不再需要手搓汇编。当时也有很多程序员困惑：用高级语言写代码，我还算不算一个严肃的开发者？
历史总是惊人地相似。AI 现在占据了编译器的生态位——它把我们的自然语言”编译”成对应的编程语言。英语、中文，都将成为新的编码方式。
效率上，这是一个巨大的飞跃。一个人类工程师，哪怕架构思路再清晰、对事无巨细都知道下一步怎么做，一天写出几千上万行高质量代码仍然是极其费劲的事。而氛围编程，可能在一个小时之内就能替你产生几千行。
四、辩证地看待 AI 的能力
这里引出一个核心问题：代码的质量如何保证？
AI 是一个很有意思的存在。它拥有全世界的知识，脑容量超过世界上任何一个资深工程师。然而，当它做具体任务的时候，因为只激活局部的参数来完成当前任务（现在主流的混合专家架构就是如此），且极其专注于当前任务，它会陷入一种隧道视野——就像人在隧道里，只看到眼前那点光亮。
于是你经常会发现：AI 为了修一个缺陷，只盯着眼前的问题，却引入了新的问题；写出的代码质量不高，架构不合理。它坐拥全世界的知识，在处理具体问题的时候却像个新人工程师——代码写得不靠谱。
但这不是 AI 的问题，是我们没有合理地激活它的能力。
当你作为一个资深工程师，给它足够好的上下文——告诉它你想做什么，让它先不要急着动手，先跟你探讨设计方案，多给几个方案让你挑选——很多时候你不需要像带新人一样手把手教它。比如 AI 给了一个方案，你觉得不够好，告诉它”用布隆过滤器会更好”就够了。你不需要解释什么是布隆过滤器，不需要告诉它在你使用的语言下有哪些好的依赖库——AI 自己知道，它会去找。你告诉它用 SOLID 原则来设计系统，告诉它用观察者模式来处理模块间关系，它马上就能领悟，给你一个截然不同的、漂亮得多的设计。
所以要辩证地看：一方面，AI 的脑容量超过任何资深工程师；另一方面，不给它正确的指引，它就像个新人一样瞎搞。 这个时候，工程师自己的品位、修为、架构能力、设计能力，就变得比以往更加重要了。
在我过去两年不断尝试的过程中，有一个发现：能力越强的工程师，AI 给他的提效越大。 因为架构对了，代码即便写得再差也是大差不差的；而架构不对，到处引入竞态条件，每一行代码写得再精妙，也摆脱不了补丁垒补丁的困境。
五、规格驱动开发（SDD）：给 AI 一张地图
如果说 AI 是执行者，那谁来确保它不跑偏？答案是规格文档 (spec)。
当你让 AI 构建一个子系统，如果直接让它去写，它可能写得杂乱无序、没有清晰的目标。但如果你让它先为这个子系统构建一份产品需求文档，然后你去审阅每一个条目——哪些要、哪些不要——反复讨论直到定稿；再让它根据需求文档写一份技术设计文档，在设计文档中指定你的技术偏好（网络框架用什么、数据库访问层用什么、并发怎么处理），然后你去仔细审阅它的数据结构、公共接口、架构是否合理。
这整个过程，就像你跟一个同事在沟通对话。你不是直接去改它的方案，而是对方案提出意见，让它去改，改完你再审阅，最终拍板。拍板之后剩下的事情是机械而枯燥的——让它按照设计方案一个阶段一个阶段去实现，每个阶段做完之后跑构建、格式化、静态检查、测试，全部通过再进入下一个阶段。
所有阶段完成后，用另一个 AI（比如 Codex）去做代码审查——注意最好用A家的模型开发，用B家的模型审查，因为自己审查自己，跟人类工程师一样，深层问题往往发现不了。审查发现的问题再一个个排查，最后提交合并请求。
这不就是人类团队做项目的流程吗？需求文档 → 设计评审 → 分阶段实现 → 代码审查 → 测试验收。我们只是把人协作的整套逻辑，搬到了人与 AI 交互的逻辑上。
一个 AI 工具能不能成功，核心要素就是：你能不能把原本公司内部由人跑通的流程，让 AI 工具也跑通。
六、验证：最后一公里
规格文档做得好是”入口”，验证做得好是”出口”。这两个步骤，我认为是整个流程里最关键的环节。
我所说的验证，不仅仅是单元测试和集成测试，而是把产品放到真实场景下，让 AI 驱动它去验证。
如果是命令行工具，让 AI 把每个子命令、每个参数都执行一遍；如果是接口服务，让 AI 按流程把完整的工作流跑一遍；如果是带前端的产品，让 AI 驱动 Playwright 打开浏览器、导航到相应页面、执行新功能的操作，执行前后做截图对比，分析设计是否像素级还原。手机端也一样——iOS 和安卓都有模拟器，AI 应该去驱动这些模拟器做类似的验证。
唯有这样，AI 才能端到端地掌控整个开发过程，人类审阅代码的心智负担才能降到最低。 在提交合并请求的时候，附上整个验证过程的关键截图和录像，审阅者的信心就会高很多。
这一块在今年将成为一个重要的研究方向。如何给 AI 提供一个它可以随意操作的环境让它去完成这个环境下的所有工作？如何在微服务链条中做完整的端到端验证？如何隔离 AI 的预发布环境以避免互相干扰？这些问题都值得深入思考。
七、智能体时代：每个人都是管理者
目前我们正处在智能体编排的时代。各种智能体为我们做执行层面的事情，而我们更多的是把意图告诉智能体，通过技能、工具协议、命令行工具等方式让它利用这些工具，不断逼近我们给定的目标，最终生成一个完整的合并请求交给人来验收。
如果你的生态系统里，项目管理软件有命令行接口、代码仓库也有命令行接口，那就意味着智能体可以自动去项目管理软件里拉取最新的未处理工单，分析哪个用户故事它能做，生成设计文档让工程师审阅，审阅通过后开始执行，完成后通过命令行提交合并请求。所有这些交互都可以自动化。
整个工作范式正在发生变化：以前大家都是一个个独立贡献者，现在每个人都在变成管理者——只不过你管理的不是一群人，而是一群智能体。 你能不能把它们编排好，就是你的核心竞争力。
既然是管理者，你就要对这些东西兜底。基础设施方面的知识不懂？快速学习。原来是前端工程师，现在要做后端？快速补课。未来的工程师是端到端的，不会再细分谁是运维、谁是前端、谁是后端——只有一个方向：现在有一个待解决的难题，你能不能组织你的AI智能体大军去搞定它？
八、工具协议与技能：工具不在多，在精
在工具选择上，我要说一个当前被广泛误用的问题：不是什么东西都要做成模型上下文协议（MCP）。
MCP 有很大的代价——当你给 Claude Code 或其他智能体装了太多 MCP 之后，它会大量吞噬原本宝贵的上下文窗口，导致真正用于编码的上下文变得很小。这对编程智能体的工作非常不利。
我的判断标准很简单：如果一个工具只是在本地跟智能体一起使用，不依赖集中式数据库，不需要远程支持，那就做成命令行工具加技能（skill）封装，而不是 MCP。像 Playwright、模拟器这样只在终端使用的工具，完全应该用命令行加技能的方式来完成。
MCP 适用的场景是：为另一家公司提供能力，或公司内部使用者非常多且需要集中式的数据库支持。
技能同时具有工具属性和知识属性。工具属性封装命令行的调用能力，知识属性提供处理特定事情的方法和工作流程。这些东西不会随着模型的提升而消亡——恰恰相反，你给模型提供的工具越充实、环境越好，整个系统的能力就越强。模型和工具是互补关系，不是替代关系。
九、工程师的修行之道
对于资深开发者，你需要在架构层面、方向选择上有更敏锐的判断力，用你的品位来把控 AI 的产出质量，靠过去的知识积累和经验来发现各种问题。
对于刚入门的开发者，你需要快速提升在软件方面的修为——底层原理、技术术语、架构模式，都要快速掌握。同时，不要完全依赖 AI，还要保持一定量的手写核心数据结构和算法的练习。这个过程是帮助你形成对代码的品位和感知——八成的工作让 AI 做氛围编程，两成的时间保持手工练习，这个比例是健康的。
不管资深还是新手，有几件事是共通的：
第一，保持好奇心。 遇到一个有意思的东西，就去刨根问底——它底层究竟是怎么实现的？以前维持这种好奇心的代价很高，你得一行行读文档、读代码、反复尝试。现在完全可以交给智能体——让它帮你读代码、梳理架构、抽丝剥茧了解细节。好奇心的门槛降到了前所未有的低，没有理由不保持它。
第二，学会学习。 软件开发的迭代速度会越来越快，智能体随时可能抛出你不懂的概念、框架、依赖。你能不能快速用深度研究工具搞清楚它是什么、为什么要用它？这种学习能力，将来是核心竞争力。
第三，不要追逐表面，要抓住实质。 光 SDD 这件事，GitHub 上排名很高的框架就不下十种，而且还会层出不穷。与其疲于追逐，不如每次有新东西出来就拉下来，让智能体帮你分析——它底层用了什么技术、提供了什么能力、实质是什么——然后把对你有益的部分吸收到自己的工作流中。
每个人、每个团队、每家公司，都有各自的”国情”。 一个市面上大而全的框架，不一定符合你的直接需求。你要构建的是属于你自己的使用智能体的工作流。
十、结语：手工艺到工业化
编程，以前是一门手工艺，以后，它将更多地变成工业化生产——大量的智能体每天产出大量的代码，而这些代码的质量由我们来管控。
在这个转型中，有两件事不能丢：
一是对质量的敬畏。 我们对底层逻辑的掌握不能丢弃。好的工程师，遇到一个新系统时永远会问：它底层是怎么实现的？这种刨根问底的好奇心，这种对根本原理的执着追求，是 AI 时代工程师最宝贵的品质。唯有这样，你才能守住代码质量的底线。
二是人类的理性和审美。 不要在自动化的快感中迷失。我们需要把自己的品位和审美注入到我们要构建的软件之中。AI 给了我们十倍百倍的效率，但效率是手段，不是目的。软件工业活动的唯一目的是构建出真正好的软件产品，解决真正的问题，服务真正的用户。
软件开发的长久之道，在于理解实质而非一味跟风。把每一个新事物的底层原理搞清楚，把有益的部分变成自己的养分——这才是一条走得远的路。
路是人走出来的。在 AI 的洪流中，走出自己的路，才是正道。
