我们必须停止把所有事物都称为“氛围编码”

在长时间的间歇后，我重新开始编程，而 Lovable 成了我再次上手的地方。应用看起来很棒，乍一看能够运行，并且在几小时内就凑齐了。起初，这让我感到非常惊艳。但当我想要了解代码到底在做什么——以及为什么这么做时，这种感觉就不再足够。这时，我的做法开始转变。

区别不在于工具本身，或 AI 为你编写了多少代码。关键在于你对产出所接受的契约:你是否能够解释刚刚发布到世界上的东西，还是不能。

“氛围编码”在最初的意义上指的是在没有仔细检查或理解其底层实现的情况下，接受 AI 生成的软件。AI 辅助开发则不同。模型仍可能编写大部分代码，但构建系统的人仍需对其行为负责，测试其假设，并决定是否可以发布。

对于只在自己的机器上进行的临时实验，这种区分可能影响不大。但一旦软件被部署、被他人使用或连接到真实数据时，这种区别就变得极其重要。

“氛围编码”失去意义的过程

“氛围编码”一词由 OpenAI 联合创始人 Andrej Karpathy 于2025年2月提出。他的例子故意随意——一个“随手的周末项目”，通过自动点击“全部接受”，忽视差异并让代码超出他的理解范围。

几周后，开发者兼工具制作者 Simon Willison 发现该词被用得大相径庭——作为任何 AI 辅助编程的代称，他认为这稀释了概念，并给出一种对负责任的 AI 辅助开发能够实现的效果的错误印象。

值得注意的是，Karpathy 最终也认同了这一点。一年后，他提出了另一个术语，用于更有纪律性的编码代理工作。他将“代理工程”(agentic engineering) 描述为一种工作流：开发者指导并监督代理，而不是单纯接受它们的产出。这一区别很重要——专业的 AI 辅助开发需要规划、审查和问责，而随意的氛围编码则不具备这些要素。

界限在于责任

Willison 的规则很简单，也能作为任何人的测试:不要提交你无法向他人解释的代码。这并不意味着要阅读每一行代码——在代理一次生成数百行的情况下，即使是经验丰富的开发者也不再这样做。关键是要理解核心逻辑，并能够说明代码为何如此运作。如果你能做到这一点，代码是模型写的还是你写的都无关紧要——这不是氛围编码，而是使用工具构建软件。

2025年12月发表的研究支持了这一区分。研究者基于现场观察和对专业开发者的定性调查发现，经验丰富的从业者仍然保持对软件设计和实现的控制，而不是把整个过程交给 AI。他们将代理视为合作者，仔细规划工作并持续参与监督。

因此，仅凭经验不足以解释问题。关键在于你是否愿意为 AI 生成的内容承担责任。这是每位开发者在每个项目中反复面临的抉择。

缺乏控制会导致什么

在不了解或未验证安全性的情况下发布软件的后果并非抽象概念。旨在帮助女性约会时保持安全的应用 Tea 泄露了数万张身份证照片和超过一百万条私人信息，共发生了两起安全事故。故障包括未受保护的存储桶以及可在未认证情况下访问的独立数据库。

相同的根本问题——软件表面可用但授权逻辑严重错误——也出现在基于 Lovable 平台构建的应用中安全研究发现授权逻辑被颠倒，导致已登录用户被锁定，而未认证的攻击者可以自由进入，影响了超过 18,000 名用户，包括学生。

这些并非只发生在“糟糕”项目中的孤立案例。根据Google 2025 年 DORA 报告，90% 的开发者在工作中使用 AI，而约三分之一的人对其生成的内容几乎没有信任。

AI 的使用已经非常普遍，尽管信任度仍受限。这使得在生成的代码涉及身份验证、权限或敏感数据时，仔细审查尤为重要。

控制是层层构建，而非一次性完成

就我而言，我并没有一开始就进行正式的安全审计。我只是当无法解释某个行为时就停止前进——这是一种我作为分析师在工作中自然带来的本能。我更关注结果是否符合最初需求，而不是语法本身。如果不符合，我会继续深挖。

随着项目变得更为严肃，我的工作流也变得更有结构。除了依赖提示，我开始在生成任何内容之前准备规格说明。我记录业务需求、技术栈和集成方式。随后为主要用户旅程编写单元测试和 Playwright 测试。

安全检查以类似方式加入。我审查 AI 选取的库，并为上传的文件引入恶意软件扫描。每一次检查都源自于思考下一步可能出错的地方，而不是遵循事先准备的控制清单。

这种习惯在一次项目中捕捉到了问题。AI 引入了一个与我使用的框架版本不兼容的库。应用并未立即崩溃，导致不兼容性很容易被忽视。若等到后期才发现，定位原因将会更加困难。

与 Tea 和 Lovable 案例相比，这只是一个普通问题。我提前发现并修复，随后继续前进。这正是实际审查的常态。大多数情况下，它能防止小问题演变成大灾难。

我并不是因为代码是 AI 生成的就不信任它，也不是因为应用能够运行就盲目信任。测试和审查是我判断其是否按预期行为的手段。

从氛围编码到代理工程

Karpathy 从“氛围编码”转向“代理工程”并非仅是词汇的变化。“代理工程”为专业开发的方向提供了更有意义的名称。开发者可能亲自编写的代码行数减少，但这并不降低他们的责任。它将工作重点转向规定系统应做什么、指导代理、测试输出并决定哪些是安全可发布的。

危险不在于 AI 能快速生成代码，而在于生成速度可能超过理解速度。当这种情况发生时，表面的生产力掩盖了未经充分审查的风险。

值得坚持的规则

停止把“氛围编码”当作所有 AI 辅助开发的标签——这会稀释概念并抹去重要的控制区别。设定一个简单规则:不要发布你无法解释的内容。并且在项目成长过程中，层层加入控制，随着风险的出现逐步添加检查。

AI 可能编写了大部分代码，但它无法为发布承担责任。那仍然是我们的职责。