如何正确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 天内完成。当开发的时间成本断崖式下降时，工程师将有能力去推进以往由于资源限制而搁置的大规模重构与功能迭代。
进阶技巧：探索、测试与工具链协同
在长达数十分钟的问答环节中，Erik Schluntz 针对开发者关心的实战细节进行了密集解答，涵盖了从个人成长到工具搭配的多个维度。
关于学习方式：借助 AI 工具学习新东西的速度大大加快。拥有永远在线的结对程序员伙伴，只要愿意投入时间去学，Claude 会帮你弄懂它。原本需要两年才能验证的架构决策，现在六个月就能出结果。
关于信息平衡：取决于你在乎什么。如果我不关心它是怎么实现的，我连一个实现细节都不会提，只给最终需求。当你不对模型施加过度约束时，它们表现得最好。
关于 TDD：TDD 在 Vibe Coding 中极其有用。但 Claude 容易写出过度依赖具体实现的「死胡同测试」。做法是强制规范它：「只写 3 个端到端测试，写一下快乐路径、错误场景 1 和错误场景 2」。在 Vibe Coding 时，通常唯一会去看的代码就是测试代码。
关于多会话：会用 Claude Code 起手搭建框架，然后用 Cursor 去收尾修复。面对陌生的代码库，在写功能之前，先用 Claude Code 帮忙探索，建立全局视图。
来源
暂无来源