如何正确Vibe Coding?这是来自Anthropic编程智能体负责人大师课

编辑｜+0、Panda

如果摔断了手、打了两个月石膏，工作却不能停，程序员该怎么办？Anthropic 的研究员、《构建高效智能体》合著者 Erik Schluntz 的答案是：全权交给 Claude

如今，随着 AI 强势重塑软件行业的规则，Vibe Coding 已经变成了企业想要成倍提升生产力时，绕不开的一道必答题。

几个月前，Schluntz 带着他被迫「全自动化办公」的奇妙经历走到台前，和大家一起探讨一个略带争议的话题：如何在生产环境中负责任地进行 Vibe Coding？

这个演讲干货十足，最近几天又在 X 上火了起来，网友 Movez 甚至盛赞其胜过 100 门付费课程。

本着 Vibe Coding 的精神，我们也在 AI 的帮助下对 Schluntz 的演讲进行了整理。

定义「氛围编程」

很多人将重度使用 Cursor 或 Copilot 等 AI 工具生成代码等同于氛围编程。事实并非如此，只要开发者依然与模型保持着逐行修改与审查的紧密反馈循环，这就无法称之为真正的「氛围」。

Andre Karpathy 对此给出了更为精准的定义：「完全沉浸于氛围，拥抱技术发展的指数级增长，并且彻底忘记代码的存在。

这种工作模式彻底降低了开发门槛，让缺乏工程背景的人群也能独立开发完整应用。但在过去，这种开发模式的成功案例往往局限于个人游戏或低风险项目。一旦非专业人士将这套模式搬入真实的生产环境，常常会导致耗尽 API 额度、绕过订阅验证甚至随意篡改数据库等失控情况。

为什么要拥抱指数级增长？

既然高风险的商业环境中存在不可控因素，我们为何还要推进这项技术？核心驱动力在于AI 能力的「指数级增长」

目前，AI 能够独立处理的任务长度大约每 7 个月就会翻一倍。今天 AI 能够稳定完成耗时 1 小时的编码任务，开发者尚有精力逐行审查。到了明年甚至后年，当 AI 能够一次性生成相当于人类 1 天甚至 1 周工作量的代码时，如果依然坚持传统的同步审查与修改，人类工程师必将成为算力爆发的瓶颈。

我们可以参考编译器的发展史。早期的开发者可能并不信任编译器，依然会去检查底层的汇编代码。随着系统规模的扩大，开发者必须学会信任更高层级的抽象。面向未来，整个软件工程界同样需要提前思考：如何在生产环境中安全且负责地接纳大模型直接生成的系统。

寻找可验证的抽象层与「叶子节点」策略

在生产环境中实践氛围编程的核心理念在于：忘记代码的存在，但必须始终关注产品的存在。

在现代企业管理学中，CTO 依靠验收测试来管理技术专家，产品经理通过体验产品来验证功能设计，CEO 借助关键数据切片来抽查财务模型。他们都没有深入到最底层的执行细节中。软件工程师也需要建立类似的、无需阅读底层代码即可验证的抽象层。

核心在于：找到你可以验证的抽象层！

然而，目前的 AI 编码存在一个棘手的技术阻碍，即技术债。当下除了通读源码，我们极难通过其他系统化手段来衡量或验证技术债。

基于此，Erik Schluntz 提出聚焦代码库中的「叶子节点」（Leaf nodes）

这些节点指的是不被其他任何模块依赖的末端功能或附加组件。在这些区域，即便产生了一定的技术债也是可以接受的，因为它们极少变动，也不会阻碍后续模块的构建。相反，对于系统的主干与底层架构部分，工程师仍需深入理解并严密保护其可扩展性。

值得注意的是，随着模型能力的提升，我们能够信任 AI 接管的代码层级正在向下延伸。以 Anthropic 内部近期测试的新版模型为例，AI 生成优质架构的成功率正在提升，这种边界正在发生动态变化。

做好大模型的全职产品经理

要让 AI 输出高质量工程代码，开发者需要转换思维，把自己当成 Claude 的产品经理。不要问 Claude 能为你做什么，要问你能为 Claude 做什么。

在面对复杂的开发任务时，开发者需要像带教第一天入职的新员工一样引导 AI。直接抛出「实现这个功能」的指令注定会失败。开发者需要向 AI 提供详尽的代码库导航，并明确需求规格和限制条件。

Erik Schluntz 强调了他的一套标准前置工作流。

在让 Claude 真正动手写代码之前，他通常会花 15 到 20 分钟与其进行互动。这包含让 AI 探索代码库、查找相关文件，并共同制定一个清晰的执行计划。随后将这些经过全面梳理的上下文和规范汇入一个单独的提示词中，再让 Claude 去执行。在此流程下，模型的任务成功率会呈现指数级跃升。

22000 行代码的生产环境合并案例

在演讲中，Erik Schluntz 披露了 Anthropic 内部的一个极限实战案例。其团队近期在强化学习代码库的生产环境中，成功合并了一次高达 22000 行的代码修改，其中绝大多数由 Claude 编写。

为了负责任地完成这次 merge，团队采取了四项核心策略：

1. 产品经理视角的深度引导：耗费数天时间进行前期的人工规划与需求梳理。
2. 严格划定修改范围：将代码变更严格限制在允许存在技术债的叶子节点上。
3. 核心区域人工介入：对于必须保证底层扩展性的核心逻辑，团队执行了严格的人工审查。
4. 建立可验证的检查点：设计针对系统稳定性的长时间压力测试，并确保整个系统具备极易被人类验证的输入和输出标准。

通过这种方式，原本需要人类工程师耗费两周时间逐行编写与审查的巨大工程，被压缩到了 1 天内完成。当开发的时间成本断崖式下降时，工程师将有能力去推进以往由于资源限制而搁置的大规模重构与功能迭代。

进阶技巧

探索、测试与工具链协同

在长达数十分钟的问答环节中，Erik Schluntz 针对开发者关心的实战细节进行了密集解答，涵盖了从个人成长到工具搭配的多个维度。

提问 1：在过去，我们花很多时间处理语法、库文件或是代码组件之间的连接问题，我们在这个过程中学习。现在该如何学习？如何积累足够的知识去做好 Agent 的产品经理？

Erik：这是个很好的问题。确实，我们将不再经历那些痛苦的死磕。但我认为这没什么，就像现在的程序员不用手写汇编代码一样。

乐观的一面是，我发现借助 AI 工具，我学习新东西的速度大大加快了。很多时候我会问：「嘿 Claude，我没见过这个库，给我讲讲。你为什么选它？」拥有这样一个永远在线的结对程序员伙伴，意味着那些懒惰的人会蒙混过关，但只要你愿意投入时间去学，Claude 会帮你弄懂它。

此外，借助 AI 我们可以进行更多次「试错」。原本需要两年才能验证的架构决策，现在六个月就能出结果。只要愿意尝试，工程师在同样的自然时间里能学到四倍的经验教训。

提问 2：在预先规划过程中，如何平衡给它的信息量？有没有一个标准化的模板？

Erik：这取决于你在乎什么。如果我不关心它是怎么实现的，我连一个实现细节都不会提，只给最终需求。如果我很熟悉这块代码库，我会深入到具体用哪些类、参考哪个示例。

不过，当你不对模型施加过度约束时，它们表现得最好。所以我不建议花太多精力去弄严苛的格式模板，你就把它当成一个初级工程师去沟通就好

提问 3：如何平衡有效性和网络安全？比如之前有报道说，很多不懂代码的人做出的 Vibe 编程应用存在严重漏洞。

Erik：还是回到第一点：做好 PM。你需要懂行，知道什么是危险的、什么是安全的。媒体报道的漏洞大多是完全不懂写代码的人搞出来的，所以这在游戏和玩具项目里没问题。但对于生产系统，你需要问出正确的问题去引导。我们那个 22,000 行代码的案例，是一个完全离线运行的任务，所以我们确信没有安全风险。

提问 4：全球懂软件的人不到 0.5%，为了让普通人更容易地构建软件，同时避免泄漏 API 密钥这类安全问题，现有的产品需要做出怎样的改变？

Erik：如果能涌现出更多能够实现「数学证明级别正确无误（provably correct）」的产品和框架，那就太棒了。比如有人能构建出一种系统，后端把重要的身份验证、支付部分都锁死保障好，只留出一个「填空式」的前端沙盒让你尽情去 Vibe Code。

最简单的例子就像 Claude Artifacts，它托管在云端，只有前端，没有权限和支付，所以怎么瞎折腾都安全。希望能有人开发出这样能作为补充的好工具。

提问 5：关于测试驱动开发（TDD），你有什么技巧吗？ Claude 经常容易在测试里越陷越深。

Erik：TDD 在 Vibe Coding 中极其有用。即使你看不懂测试用例，它也能帮助 Claude 变得更加自洽。

但确实，Claude 容易写出过度依赖具体实现的「死胡同测试」。我的做法是强制规范它：「只写 3 个端到端（E2E）测试，写一下快乐路径（happy path）、错误场景 1 和错误场景 2」。 引导它写极其极简的端到端测试，确保这连我自己也能看懂。

在 Vibe Coding 时，我通常唯一会去看的代码就是测试代码。测试过关了，我才觉得靠谱。

提问 6：Andre Karpathy 说「拥抱指数级增长」，这到底意味着什么？是不是模型会在我们期待的每一个维度变好？

Erik：指数级的核心不仅仅是持续变好，而是它们变好的速度远远超出我们的想象。 就像散点图一样，刚开始是平缓上升，然后突然就狂飙突进了。

回顾 90 年代搞计算机的人，从几 KB 内存到今天的 TB 级存储，那不是好了两倍，而是好了数百万倍。所以我们不该想「20 年后模型好两倍会怎样」，而是要想「如果它比今天聪明一百万倍会发生什么」。这极其疯狂，这才是所谓的拥抱「指数级」。

提问 7：你有两种工作流，一种是在终端里（Claude Code），一种是在 VS Code/Cursor 里，你通常用哪种？多久会压缩（Compact）一次上下文？因为时间长了它容易脱轨。

Erik：我两边都用。主要修改是 Claude Code 做的，我在 VS Code 里边走边审查代码（或者审查测试）。

我通常在感觉到了一个「人类程序员会停下来吃个午饭」的停顿点时，就进行一次压缩（Compact）。我的起手式通常是：先让 Claude 找出所有相关文件并制定计划，然后让它把这些全写进一个文档里，接着我立刻进行压缩。这样就能丢掉制定计划时耗费的那 10 万个 Token，压缩成只有几千个干净的 Token。

提问 8：你会同时用多个 Claude Code 会话然后合并结果吗？面对极不熟悉的代码库，怎么以工程化的方式交 PR 而不是乱写？

Erik：是的，我会用 Claude Code 起手搭建框架，然后用 Cursor 去收尾修复。对于我知道具体在哪几行的修改，我会直接用 Cursor 手动去改。

面对陌生的代码库，在写功能之前，我会先用 Claude Code 帮我探索。 我会问：「处理 Auth 的代码在哪？」、「告诉我哪些功能和这个类似」、「列出我应该查阅的类」。在脑海中建立起全局视图，确保我能稳妥地掌控正在发生的事情，然后再和 Claude 一起动手。