Vibe Coding：AI 时代软件工程的新范式
概述
LLM 能力突飞猛进，一种叫 “氛围编码 (Vibe Coding)” 的模式正成为软件工程必然趋势。所谓氛围编码，就是开发者充分信任 AI 完成开发，甚至 “忘了代码存在”。演讲者 Erik Schluntz 认为，为了在生产环境中负责任地采纳这种模式，开发者必须将心态从 “代码编写者” 转变为 “AI 的产品经理”。这意味着我们不再逐行审查所有代码，而是通过设计可验证的抽象层、专注于非核心 “叶子节点” 的编码，并为 AI 提供清晰、完整的上下文，来确保最终产品的质量和稳定性。最终结论是，这种方法不仅能大幅提升开发效率，更是适应未来软件开发模式的关键，否则将面临被时代淘汰的风险。
重新定义 “Vibe Coding”：从模糊概念到核心原则
在探讨如何在生产环境中实践 “氛围编码” 之前，我们首先需要明确其真正的含义。Erik Schluntz 指出，许多人将氛围编码简单地等同于广泛使用 AI 工具（如 Cursor 或 GitHub Copilot）来生成代码。然而，他认为这种理解并不准确。当开发者仍与 AI 模型保持一种紧密的、来回反馈的循环，逐一审查和修改代码片段时，这并未触及氛围编码的本质。这更像是一种高效的辅助编码，而非一种全新的开发范式。
为了更精确地定义这一概念，Erik 引用了 Andrej Karpathy 的一段话，这段话被认为是 “氛围编码” 的经典定义：“有一种我称之为 ‘氛围编码’ 的新型编码方式，你完全沉浸于氛围之中，拥抱指数级增长，甚至忘记代码本身的存在。” Erik 强调，这里的关键在于 “忘记代码本身的存在”。这代表了一种深层次的信任转移：开发者将关注点从具体的实现细节，转移到更高层次的系统行为和目标上。这不仅仅是让 AI 写几行代码，而是委托其完成整个功能模块的构建。
这种编码范式的出现，极大地降低了软件开发的门槛，使得许多非工程背景的人也能参与到创造过程中，甚至独立开发出完整的应用程序，这在以往是难以想象的。然而，这种自由也带来了显而易见的风险。当缺乏技术背景的开发者进行氛围编码时，他们可能无法预见潜在的技术问题，导致应用上线后出现各种混乱，例如 API 密钥滥用、用户绕过订阅、数据库被写入随机数据等灾难性后果。正因如此，早期的氛围编码成功案例大多局限于低风险场景，比如开发视频游戏或有趣的个人项目，在这些场景中，偶尔出现的 Bug 是可以接受的。那么，我们为何要将这种看似充满风险的模式引入到严肃的生产环境中呢？答案在于技术发展的必然趋势。
指数级增长的必然性：为何我们必须关注氛围编码
我们之所以必须严肃对待并在生产环境中探索 “氛围编码” 的应用，其根本原因在于人工智能能力的指数级增长。Erik 展示了一张来自 METR 的图表，清晰地揭示了这一惊人趋势。图表显示，“AI 能够完成的任务长度大约每七个月翻一番”。几年前，AI 模型只能处理持续几秒钟的简单任务；而如今，最新的模型已经能够胜任持续近一个小时的复杂工作。
这个指数曲线预示着一个不可避免的未来：很快，AI 将有能力在一次交互中生成相当于人类工程师一天甚至一周工作量的代码。当这种情况发生时，我们当前的工作流程 —— 即由人类工程师编写或审查每一行代码 —— 将成为一个巨大的瓶颈。如果我们仍然坚持与 AI “步调一致”，即 AI 每生成一小段代码，我们就进行一次审查和修改，那么我们将完全无法利用 AI 指数级增长所带来的生产力飞跃，最终会被时代淘汰。
为了更好地理解这一转变，Erik 提出了一个与 “编译器” 发展的类比。在编译器出现的早期，许多开发者并不信任它。他们虽然会使用编译器，但仍会去阅读和检查编译器生成的汇编代码，以确保其行为符合自己的预期。然而，随着软件系统规模的不断扩大，这种做法很快就变得不切实际。如今，几乎没有工程师会去审查编译器的汇编输出，我们已经学会了信任这个抽象层。我们相信，只要我们编写的高级语言代码是正确的，编译器就能可靠地将其转换为可执行的机器码。Erik 认为，软件开发正面临着又一次类似的范式转移。我们必须找到一种方法，来负责任地 “信任” AI，从而利用其强大的代码生成能力。这引出了核心挑战：“我们如何在生产环境中安全地进行氛围编码？” 他的答案是，我们需要转变观念：“忘记代码的存在，但绝不能忘记产品的存在”。
案例研究：在生产环境中负责任地合并 22000 行 AI 代码
理论需要实践来验证。Erik 分享了一个来自 Anthropic 内部的真实案例，展示了如何在生产环境中负责任地进行大规模的 “氛围编码”。他们最近将一个由 Claude 模型深度参与编写的、包含 22160 行代码变更的 Pull Request 合并到了公司的生产级强化学习代码库中。面对如此巨大的代码量，他们并没有逐行进行人工审查，而是采用了一套精心设计的流程来确保变更的质量与安全。
这个过程的核心在于，团队将自己定位为 Claude 的 “产品经理”，而非简单的代码使用者。具体流程如下：
- 投入大量时间进行人类指导：这次合并并非源于一个简单的提示词。团队投入了数天的人力，与 Claude 进行反复的对话和规划。他们明确需求，指导 Claude 的方向，并共同确定系统的最终形态。这体现了 “不要问 Claude 能为你做什么，而要问你能为 Claude 做什么” 的核心思想。
- 专注于 “叶子节点” 的变更：团队有意识地将 AI 生成的代码变更集中在系统的 “叶子节点” 上。所谓叶子节点，指的是代码库中那些依赖关系少、不作为其他功能基础、未来不太可能被修改或扩展的部分。对于这些区域，即使存在一些技术债务也是可以接受的。而对于系统的核心架构 —— 那些如同树干和主枝干的关键部分 —— 则仍由工程师进行详尽的人工审查，以保证其可扩展性、可理解性和灵活性。
- 精心设计稳定性和可验证性：团队为这次变更设计了周密的压力测试，以确保其稳定性。更重要的是，他们设计的整个系统都具有人类可读且易于验证的输入和输出。这使得他们可以不深入阅读具体实现代码，仅通过验证输入输出是否符合预期，就能确认系统的正确性。
通过这套结合了人类智慧与 AI 能力的流程，团队最终对这次由 AI 主导的巨大代码变更充满了信心，其自信程度不亚于任何一次由人类工程师完成的修改。而这一切，仅花费了传统开发方式所需时间和精力的 “一小部分”。这个案例最激动人心之处不仅在于节省了时间，更在于它揭示了一种全新的可能性：当开发一项复杂功能的边际成本从数周骤降至一天时，整个团队的工程思维和创新边界都被极大地拓宽了。
总结：成为 AI 的产品经理
要在 “氛围编码” 的浪潮中取得成功，开发者需要进行一次深刻的转变：从一个纯粹的 “实现者” 转变为 AI 的 “产品经理”。这种转变意味着你的核心价值不再是逐行编写代码，而是引导、塑造和验证一个极其强大但需要明确指令的 “超级员工”。
- 从 “索取” 到 “给予” 的转变
- 旧模式：“我需要一个功能，AI 你能为我做什么？” 这是一种被动的、索取式的交互，开发者将 AI 视为一个按指令办事的工具。
- 新模式：“为了让 AI 成功构建这个功能，我能为它提供什么？” 这是一种主动的、给予式的思考方式。开发者需要像产品经理为新员工入职做准备一样，思考 AI 需要哪些信息才能成功。这包括：
- 项目背景：这个功能的目标是什么？它服务于哪个用户场景？
- 代码库上下文：相关的代码文件在哪里？需要遵循哪些现有的编码模式和风格？
- 明确的需求与约束：功能的具体规格是什么？有哪些性能、安全或稳定性的硬性要求？
- 将 “提示” 视为 “规划”
- 高效的氛围编码不是一次性的 “提示工程”，而是一个持续 15 到 20 分钟甚至更长的 “规划会议”。在这个过程中，你与 AI 共同协作，进行探索和决策。
- 这个过程可能包括：
- 让 AI 探索代码库，找出相关文件和依赖。
- 与 AI 讨论不同的实现方案及其优劣。
- 共同制定一个详细的、分步骤的行动计划。
- 最终产出的 “提示”，实际上是这次深度合作的结晶，是一份包含了所有必要上下文和指导的详细 “产品需求文档”。
- 技术深度决定指导能力
- 虽然氛围编码旨在 “忘记代码”，但这并不意味着技术能力不再重要。恰恰相反，只有具备深厚技术功底的开发者，才能提出正确的问题，识别潜在的风险，并为 AI 提供高质量的指导。
- 一个非技术人员可能无法判断 AI 提出的架构建议是否合理，也无法为 AI 设定正确的技术约束。因此，在生产环境中，成功的氛围编码者必须是优秀的工程师，他们能有效地将自己的专业知识转化为 AI 可以理解和执行的指令，从而成为一名出色的 “AI 产品经理”。