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

随着 AI 强势重塑软件行业的规则Vibe Coding 已经变成了企业想要成倍提升生产力时绕不开的一道必答题。如果摔断了手、打了两个月石膏工作却不能停程序员该怎么办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 针对开发者关心的实战细节进行了密集解答涵盖了从个人成长到工具搭配的多个维度。提问 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 经常容易在测试里越陷越深。ErikTDD 在 Vibe Coding 中极其有用。即使你看不懂测试用例它也能帮助 Claude 变得更加自洽。但确实Claude 容易写出过度依赖具体实现的「死胡同测试」。我的做法是强制规范它「只写 3 个端到端E2E测试写一下快乐路径happy path、错误场景 1 和错误场景 2」。 引导它写极其极简的端到端测试确保这连我自己也能看懂。在 Vibe Coding 时我通常唯一会去看的代码就是测试代码。测试过关了我才觉得靠谱。提问 6Andre 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 一起动手。