一份在生产环境中进行“Vibe Coding”的生存指南 • Anthropic
本文来自于 Anthropic 组织的线下分享会，从时间上看应该是 5 月前组织的线下分享会，里面不仅有 Claude 工程和算法团队的分享，还包括 Google、Amazon、Manus 甚至是创业者和学生的分享，特别值得观看，这里把其中我认为比较优质的视频内容整理出来分享给大家。本篇文章来自于视频 Vibe coding in prod，以下为原视频精华。 嘿，大家好。今天我们来聊一个大家都爱的话题——Vibe Coding。而且，我们还要聊一个可能有点争议的子话题：如何在生产环境（Prod）中负责任地进行Vibe Coding。 我叫Eric，是Anthropic的一名研究员，专注于编码智能体（Coding Agents）。去年，我骑车上班时摔断了手，打了两个月的石膏。你猜怎么着？那两个月里，我所有的代码都是Claude帮我写的。所以，如何高效地让AI为我工作，对我来说不仅仅是个研究课题，更是一次亲身实践。 到底什么是“Vibe Coding”？ 很多人觉得，只要大量使用AI生成代码，比如用Cursor或者Copilot，就是在Vibe Coding。但我认为这不完全对。当你的工作流仍然是和模型进行紧密的、快速的来回反馈时，那还不是真正的Vibe Coding。 要理解它的精髓，我们得回到Andrej Karpathy的经典定义： Vibe Coding，就是你完全沉浸于“感觉”（the vibes），拥抱指数级增长，并且忘记代码本身的存在。 关键就在于**“忘记代码本身的存在”**。 这不仅仅是工程师的自娱自乐。Vibe Coding真正让人兴奋的地方，在于它让那些圈外人——那些不懂编程的人——也开始对代码生成感到激动。他们突然发现，自己竟然可以独立构建一个完整的App。这无疑是一次巨大的解放。 当然，随之而来的就是各种“翻车现场”：API密钥被刷爆、订阅系统被绕过、数据库里出现一堆奇奇怪怪的东西。成功的Vibe Coding案例，似乎都发生那些低风险的场景里，比如做个小游戏或者有趣的个人项目，就算出Bug也无伤大雅。 既然这么“危险”，我们为什么还要关心它？ 答案是：指数级增长（The Exponential）。 AI能独立完成的任务时长，大约每7个月就会翻一番。现在，AI大概能独立处理一个小时的工作量。这还行，你可以用Cursor帮你写，或者让Claude帮你实现一个需要一小时开发的功能，然后你花点时间审查所有代码，你依然深度参与其中。 但是，明年呢？后年呢？ 当AI强大到可以一次性为你生成一整天甚至一整周的工作量时，我们根本不可能再亦步亦趋地去审查每一行代码。如果我们想抓住这个指数级的机遇，就必须找到一种方法，负责任地“放手”，让AI去驰骋。 这让我想起了早期的编译器。我敢肯定，那时候很多开发者也不信任编译器。他们可能会用，但还是会去读编译后的汇编代码，确保它跟自己手写的一样高效。但这种做法根本无法规模化。当系统变得足够庞大复杂时，你必须选择相信这个工具。 所以，未来几年整个软件行业面临的挑战就是：我们如何安全地在生产环境中进行Vibe Coding？ 我的答案是：我们可以忘记代码的存在，但绝不能忘记产品的存在。 新的思维模式：你不是码农，你是AI的产品经理 这其实不是一个新问题。想想看： 一个CTO如何管理一个自己完全不懂的专业领域的顶尖专家？ 一个产品经理（PM）在自己看不懂代码的情况下，如何验收一个工程特性？ 一个CEO在不精通财会的情况下，如何核查会计师的工作？ 这些问题已经存在了几百年，而我们也早已有了解决方案。 CTO 可以为专家的工作编写验收测试（acceptance tests），即使不懂具体实现，也能验证功能是否达标。 PM 可以亲自使用产品，确保它的行为符合预期。 CEO 可以抽查自己能看懂的关键数据和报表切片，从而建立对整体财务模型的信心。 看出来了吗？管理一个你并不完全理解其实现的“黑箱”，是人类社会自古以来就在解决的问题。几乎所有管理者每天都在做这件事。只是我们软件工程师习惯了作为纯粹的个人贡献者，习惯了掌控从上到下的每一个技术细节。 为了变得更高效，我们必须学会放手，就像管理者为了高效必须放弃对细节的微操一样。我们需要找到一个可以验证的抽象层，而无需深入了解其底层的具体实现。 唯一的例外：技术债（Tech Debt） 不过，这里有个棘手的问题：技术债。目前，我们还没有一种好方法，可以在不阅读代码的情况下，有效地衡量或验证技术债。这是个硬伤。但这不意味着我们就束手无策了，我们只需要更聪明、更有针对性地选择Vibe Coding的应用场景。 实战框架：如何在代码库中安全“放飞”AI 我的建议是：专注于代码库的“叶子节点”（Leaf Nodes）。 (想象一个树状的代码结构) 叶子节点（图中的橙色点）：这些是代码库中不被任何其他部分依赖的模块。它们通常是最终的功能、一些额外的“小玩意儿”。在这些地方，就算存在一些技术债，影响也是可控的，因为它们不太可能被修改，也不会有其他功能建立在它们之上。 主干和分支（图中的白色点）：这些是系统的核心架构。我们作为工程师，仍然需要深度理解和保护这些部分，确保它们的可扩展性、可理解性和灵活性。 当然，模型在不断进步。随着时间的推移，我们可能会越来越信任AI去编写那些更核心、更具扩展性的代码。 如何成为一名出色的AI产品经理？ 记住这句话：别总问Claude能为你做什么，要问问你能为Claude做什么。...