用 AI 构建的两种方式
如今，每一个用 AI 构建的团队里都悄悄流转着一场争论，而且通常表现为直觉而不是辩论：有人通过描述自己想要什么，并接受模型产出的任何结果，下午就能交付一个能用的应用。另一个人则坚持逐行阅读、编写测试，并弄清楚这东西到底是如何工作的。两边用的是同一套工具。只是他们在玩截然不同的游戏。
这两种游戏现在有名字了：那种快速、松散、先描述再接收的方式叫“氛围式编程”（vibe coding）。而围绕模型、以更谨慎系统的方式构建可靠系统，更接近人们所说的“代理化工程”（agentic engineering）。把它当成一场对抗也很诱人——一边代表速度，另一边代表严谨——并因此去选边。然而这种说法错过了重点：它们并不是竞争者。它们只是适用于不同场景的不同工具，而真正的能力在于知道你此刻手里拿的究竟是哪一个。
澄清这种困惑很有价值，因为风险正在迅速上升。越来越多的软件在模型的重度帮助下被编写，而人们现在养成的习惯将决定：我们能否在这些软件之上继续构建，还是它们只是无人理解的一堆代码。分清楚差异，你会发现 AI 让你在方方面面都更快——从那些随手的实验到真正认真的系统都如此。分错了，你要么在不值得投入的原型里低头慢爬，要么交付的生产系统靠猜来维持。
本文会把整件事从头到尾讲透：每种模式到底是什么、为什么“氛围式编程”如此令人沉迷、每种方式各自在什么地方真正发挥价值、如何在当下把它们区分开，以及如何两者兼用而不自欺——让你知道某个具体任务究竟需要哪一种。途中你会看到一张对比表、一个快速决策检查、几个真实情景，以及两份你可以保留的清单。
什么是氛围式编程
“氛围式编程”（vibe coding）这个说法来自 Andrej Karpathy，他描述了一种新的工作方式：你要尽可能完全地投入模型，用纯自然语言与它对话，接受它的建议而不为细节纠结，或更准确地说，你几乎会忘记代码的存在。你不在读 diff（差异补丁）。你在“乘着氛围走”。
要理解它，先想象一场会话究竟长什么样。你打开一个聊天或代理，描述你想要的东西，然后代码就出现了。你运行它。发现哪里不对，于是把报错原封不动粘回去，请求修复，新代码又出现了。你不必认真阅读它，也许根本不读。再运行一次。能用，或者至少“够用”，于是你进入下一个功能，重复同样的动作。这个循环非常快，几乎像对话一样；在任何时候，你都不会停下来建立一个心智模型，去理解这些东西如何彼此契合。模型本身相信它会成立——或者更准确地说，根本没人真的握住那个模型。
做过这种事的人都知道它为什么会流行：它确实很令人愉悦。你以思考的速度前进，想法与可运行原型之间的阻力几乎消失，而你还能做出一些手工时根本没有耐心去做的事情。一个几乎写不出脚本的人，如今就能搭起一个能用的网页应用。一个有经验的工程师，过去需要搭环境的时间，现在足以探索五种方案。对于周末项目、一次性的实验，或只有你自己会用到的工具，这简直像超能力，而且多多少少确实是。
不过，决定性的特征并不是速度。是“放手”。在氛围式编程里，你交出的不只是打字，还有理解本身。你相信代码能工作，因为它看起来能工作，你并不太在意它如何工作。这个权衡正是让它变快的原因，也是麻烦真正开始的地方。抓住这个词——“放手”（surrender）——因为几乎氛围式编程所有好的与坏的都源自它。
为什么它感觉这么好
在讲到氛围式编程哪里会走偏之前，先认真看一眼：为什么这么多能力强的人会陷进去，因为这种“吸力”是真实的，假装没有它是没用的。
第一原因很简单，就是速度，而速度令人上瘾。描述某件东西并看着它在下一刻变成现实，这种愉悦感非常特别，也刮到了同一种痒——让最初的工作变得有趣的那种痒。手写代码一直存在很长的摩擦：样板代码、配置、查找你用过上百次的接口。氛围式编程把这些摩擦几乎压到接近零，而摩擦的缺失就像在飞行。
第二原因是反馈回路。每一个小请求都能很快产生可见结果，而“快速得到可见结果”几乎是大脑能获得的最强强化。它就是让游戏上瘾的同一种回路，也会滋养强迫式行为：你提出问题，你得到回应，你再问一次，一个小时就不见了。这个回路让人太满足了，以至于停下来读代码都像是被打断——就像暂停一场精彩的运行去检查你的动作是否到位。
第三原因是演示（demo）。在软件中，大多数压力都来自展示进度，而氛围式编程的原型能非常漂亮地展示进度。它看起来已经完成了。它能点击、能响应、能在会议里让人印象深刻。从外部看，“看起来完成了”和“真的完成了”之间的鸿沟是看不见的，而看不见的问题也不会产生紧迫感。于是激励机制悄悄地奖励“看起来已经做完”的东西，而不是“做得可靠”的东西；团队就会在没有真正做出决定的情况下慢慢滑向氛围式编程。
这一切都不是性格缺陷。它是对现实激励的理性回应，也是更好的体验本身。给它命名的目的并不是为了觉得自己比它更优越，而是为了看见那种吸力，从而决定何时要抵抗，而不是被一种你从未审视过的感觉推着走。
什么是代理化工程
代理化工程（agentic engineering）是另一种姿态。它同样严重依赖 AI，往往比氛围式编程更依赖，因为它把模型放进真实系统之中，让系统自己执行动作。不同不在于你使用了多少 AI，而在于你对 AI 产出保持多少控制。
工程师会以细致审稿人的方式对待模型输出，就像对待一个自信的初级同事的 pull request。工作也许很优秀，但它仍然是草稿，需要被检查，而不是被当成真理直接接受。实践中，这会形成一组具体的习惯：有测试——让你关心的行为被钉死，未来的变更也不能悄悄把它破坏掉。有办法看清系统做了什么以及为什么——这样出了问题你能追溯原因，而不是猜。有系统能接触的范围限制，以及在任何昂贵或不可逆的事情发生前明确的人类签字确认点。并且当工作涉及自主代理时，还会有评估（evals）——对那些真正重要的用例做可重复的测试：因为一个代理在演示里能跑一次，并不能告诉你它在现实情况下是否真的能胜任。
最重要的是理解。某个人知道这东西如何工作，并且在它坏掉时能修复；能推理它的边界；能向同事解释为什么它要这样设计。理解被视为一种交付物——它本身就是交付的一部分，和运行中的代码一样重要。因为无人理解的系统，实际上已经在失败，只是还没被注意到而已。
如果说氛围式编程是对“氛围”的屈服，那么工程就是拒绝。它保留了氛围式编程丢掉的唯一习惯：在信任之前先验证与理解。那一个习惯就是全部差异所在，而且值得直接看清楚。
它是一个光谱，而不是二元选择
在继续之前，先放下一个想法：只有两种选项。氛围式编程和完全工程化是这条范围的两端，而现实中的大多数工作都落在它们之间的某个位置。
最左边是纯氛围式编程：你接受模型给你的结果，从不去读。往里走一点，多数人实际上大多数时候做的事情是 AI 辅助编程：模型写代码，你在接受之前审查每个 diff，就像审查同事的工作。再往后是更自律的方式：规格驱动风格。你把代码必须做到的事清晰地写下来，让模型去实现，然后用测试把实现结果与规格对照核验。最右边是完全的代理化工程：模型被嵌入到有评估（evals）、可观测性（observability）和护栏（guardrails）的系统里，并把整个流程当作生产软件来对待——只是这些代码在很大程度上借助了 AI 来写出来。
当你从左往右移动，你用原始速度换取控制、理解和耐久性。这些点在一般意义上都没有“对”的答案。人们犯的错误不是选错了端点，而是根本没意识到它是个旋钮，并把它卡在习惯或心情把它设定的位置上。一个好的建设者会有目的地调动旋钮：向左滑动去探索，向右滑动去加固；而本文剩下的内容，实际上就是教你学会“用手感”判断这个旋钮应该往哪儿调。
核心差异：验证与理解
无论你站在这个光谱的哪里，随着你滑动会改变的只有一步。把纯氛围式编程和真正的工程并排放在一起，你会发现对比简单得近乎尴尬：两者都以描述你想要的目标开始，并让模型生成代码。然后它们就分岔了：氛围式编程从生成的代码直接跳到交付（shipping）。工程则在中间插入一步：你读代码、测代码，并确保在任何地方之前你确实理解它。
