Anthropic编程大师课教你正确掌握Vibe Coding技巧

首页

热心网友

转载

2026-05-19

想象一下，一位程序员因意外摔断了手，需要打上两个月的石膏，但工作进度却一刻也不能耽误，他该如何应对？Anthropic的研究员、《构建高效智能体》的合著者Erik Schluntz给出了一个极具前瞻性的解决方案：将核心开发工作全权委托给AI助手Claude。

这并非只是一个极端的个人实验，它精准地揭示了一个正在深刻重塑软件开发领域的核心趋势：Vibe Coding，即“氛围编程”。如今，这项技术已不再是技术爱好者的新奇玩具，而是企业寻求实现生产力指数级跃升时必须严肃思考并实践的战略路径。

数月前，Schluntz带着这段被迫“全自动化办公”的亲身经历公开分享，深入探讨了一个在业界备受关注的实战议题：如何在真实的企业生产环境中，安全、高效且负责任地推行氛围编程？他的演讲内容详实，最近几天在X平台上再度引发了广泛热议，甚至有资深开发者评价其见解“价值远超百门付费课程”。

重新定义「氛围编程」

首先，需要澄清一个普遍的认知误区。许多人认为，只要大量使用Cursor或GitHub Copilot这类AI编程工具生成代码，就是在实践氛围编程。实则不然。关键在于开发者与AI模型之间的协作模式——如果开发者仍然保持着逐行修改、逐段审查的紧密反馈循环，那么这本质上仍是一种“增强型”的传统编程方法。

对此，AI领域的知名专家Andre Karpathy给出了一个更为精准的定义：真正的“氛围”，意味着开发者完全沉浸于更高层级的抽象思考中，拥抱技术发展的指数级曲线，并且，彻底将具体的代码实现细节交由AI处理。

这种模式无疑极大地降低了软件开发的门槛，使得即使缺乏深厚工程背景的人员也能独立构建出功能完整的应用。然而，在过去，这种模式的成功案例大多局限于个人游戏开发或低风险的兴趣项目。一旦非专业人士将这套“放手不管”的逻辑直接套用到真实的企业生产环境中，往往会导致一系列失控局面：例如API调用额度被瞬间耗尽、订阅验证机制被无意绕过、甚至核心数据库被意外篡改。

为何必须拥抱指数级增长？

既然在商业环境中存在如此显著的风险，我们为何还要积极拥抱并系统化推进这项技术？最核心的驱动力，在于AI能力展现出的令人瞩目的“指数级增长”趋势。

目前，AI能够独立、连贯处理的任务复杂度与长度，大约每7个月就会翻一倍。今天，AI能稳定完成耗时约1小时的编码任务，人类工程师尚有精力进行逐行审查。但展望明年甚至后年，当AI能够一次性生成相当于人类工程师一天甚至一周工作量的复杂代码时，如果还固守传统的同步审查模式，人类工程师必将成为制约整体生产力爆发的瓶颈。

历史总是相似的。我们可以回顾编译器的演进史。早期的开发者可能并不完全信任编译器，仍会去检查其生成的底层汇编代码。但随着软件系统规模呈指数级扩大，开发者必须学会信任更高层级的抽象。面向未来，整个软件工程界同样需要提前布局：如何在生产环境中，构建安全且高效的流程，以接纳由大语言模型直接生成的复杂系统。

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

在企业生产环境中实践氛围编程，有一个必须坚守的核心理念：你可以不关心具体的代码实现，但必须始终掌控产品的最终形态与质量。

这其实与现代企业管理的逻辑一脉相承。CTO依靠验收测试来管理技术团队，产品经理通过用户体验来验证功能设计，CEO借助关键业务指标来把握公司运营。他们都没有深入到最底层的执行细节中。软件工程师也需要建立类似的、无需阅读底层源码即可进行有效验证的抽象层。

一句话总结：找到并定义你可以有效验证的抽象层级！

然而，当前AI辅助编程面临一个棘手的技术阻碍：技术债务的积累。除了通读全部源代码，我们目前极难通过其他系统化手段来衡量或验证代码中悄然积累的技术债。

基于这一现实挑战，Erik Schluntz提出了一个务实的落地策略：将AI编程的重点聚焦于代码库中的“叶子节点”。

所谓“叶子节点”，指的是那些不被其他任何核心模块依赖的末端功能、独立工具或附加组件。在这些区域，即便产生了一定的技术债务，其风险也是相对可控的，因为它们变更频率低，也不会成为后续系统开发的阻塞点。相反，对于系统的主干逻辑与核心底层架构，工程师仍需深入理解并严密守护其可扩展性、健壮性与性能。

值得注意的是，随着大模型能力的快速进化，我们能够信任AI接管的代码层级正在不断下移。以Anthropic内部测试的新版模型为例，AI生成高质量软件架构设计的成功率正在稳步提高，这条信任边界本身就在动态扩展。

成为大模型的全职产品经理

要驱动AI输出高质量、可用于生产环境的代码，开发者需要彻底转换思维角色：把自己当成Claude的“全职产品经理”。核心思路不是追问“Claude能为我做什么”，而是思考“我能为Claude的成功交付创造什么条件”。

面对复杂的开发任务时，开发者需要像指导一位第一天入职的资深新员工一样去引导AI。直接抛出“实现这个功能”的模糊指令，注定会导致低质量输出。你必须向AI提供详尽的代码库上下文导航图，并清晰无误地阐述业务需求、功能规格与所有技术约束条件。

Schluntz强调了他的一套标准前置工作流。在让Claude真正动手编写代码之前，他通常会花费15到20分钟与模型进行深度对话。这包括引导AI探索代码库结构、查找所有相关文件，并共同制定一个清晰、可执行的开发计划。随后，将这些经过全面梳理的上下文信息和规范汇总到一个独立的、信息完整的大型提示词中，再交给Claude去执行。遵循这一严谨流程，模型任务的成功率会得到指数级的提升。

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

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

为了负责任地完成这次大规模合并，团队系统性地采取了四项核心策略：

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

通过这套组合拳，一个原本需要人类工程师耗费两周时间进行逐行编写与审查的巨大工程，被压缩到了1天内高质量完成。当开发的时间成本呈现断崖式下降时，工程师团队将有能力去推进那些以往因资源限制而被迫搁置的大规模架构重构与功能迭代，从而彻底改变软件研发的节奏与创新可能性。

进阶技巧：探索、测试与工具链协同

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

提问1：关于学习与知识积累

问题：过去，我们通过大量时间处理语法、库文件或组件连接问题来学习。现在该如何有效学习？如何积累足够的知识去胜任AI智能体的“产品经理”角色？

回答：这是个很好的问题。确实，我们将不再经历那些“痛苦死磕”底层细节的学习过程。但这未必是坏事，就像今天的应用层程序员不再需要手写汇编代码一样。

乐观的一面是，借助AI工具，学习新技术、新框架的速度大大加快了。我经常直接问Claude：“嘿，我没见过这个库，给我系统讲讲。你为什么在这个场景下选它？”拥有这样一个永远在线的结对编程伙伴，意味着懒惰的人可能会蒙混过关，但只要你愿意投入时间去深究原理，Claude能帮你真正构建起深刻的技术理解。

此外，借助AI，我们可以进行更多次、更低成本的“架构试错”。原本需要两年项目周期才能验证的架构决策，现在可能通过快速原型在六个月内就能看到明确结果。只要保持主动探索的意愿，工程师在同样的自然时间里，能积累到数倍于以往的经验与洞察。

提问2：关于规划与信息平衡

问题：在任务预先规划过程中，如何平衡提供给AI的信息量？有没有一个标准化的需求模板？

回答：这完全取决于你的关注点和项目的约束条件。如果我不关心具体的实现细节，我连一个实现细节都不会提，只清晰地阐述最终的商业需求目标。如果我对那块代码库非常熟悉，我会深入到具体使用哪些设计模式、参考哪个现有的最佳实践示例。

不过，大量经验表明，当你不对模型施加过度刻板的约束时，它们往往能发挥出更好的创造力。所以，不建议花费太多精力去制定严苛的格式模板，就像和一个聪明的新人工程师沟通那样，保持指令的自然、清晰和上下文完整即可。

提问3：关于安全与风险平衡

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

回答：这又回到了第一点：做好产品经理。你需要懂行，知道哪些操作是危险的，哪些设计模式是安全的。媒体报道的那些严重漏洞，大多是完全不懂编程安全的人盲目尝试搞出来的，所以在个人项目和玩具里实验没问题。但对于生产系统，你必须具备足够的知识来问出正确的问题，以引导AI规避风险。我们那个22,000行代码的案例，是一个完全在隔离环境、离线运行的计算任务，因此我们能够从根本上确信没有外部安全风险。

提问4：关于普惠开发与安全框架

问题：全球真正懂软件工程的人可能不到0.5%。为了让普通人更容易安全地构建软件，同时避免API密钥泄漏这类基础安全问题，现有的开发平台和产品需要做出怎样的进化？

回答：如果能涌现出更多能够实现“数学证明级别正确性”的开发框架和低代码平台，那就太棒了。例如，有人能构建出一种系统，后端把重要的身份验证、支付网关、数据隐私等核心部分都牢牢封装并保障好，只留出一个“填空式”或“可视化组装”的前端安全沙盒，让用户可以在其中尽情地进行氛围编程，而无需担心底层安全。

最简单的例子就像Claude Artifacts，它完全托管在云端，只提供前端交互，不涉及敏感权限和支付逻辑，所以用户怎么折腾都是安全的。业界需要更多这样能作为安全基座和补充的优秀工具与框架。

提问5：关于测试驱动开发（TDD）

问题：关于测试驱动开发，在氛围编程中你有什么实用技巧吗？Claude经常容易在测试用例里越陷越深，写出过于复杂的测试。

回答：TDD在氛围编程中极其有用。即使你看不懂AI生成的具体业务逻辑代码，一套好的测试用例也能帮助验证Claude的输出是否符合预期，使其变得更加自洽和可靠。

但确实，Claude容易写出过度依赖具体内部实现细节的“脆弱测试”，一旦实现微调测试就失败。我的做法是强制规范它：“只写3个关键的端到端测试，分别覆盖一下主流程（快乐路径）、一个典型的错误场景1和一个边界错误场景2”。引导它写出极其简洁、高层次的端到端测试，确保这些测试连我自己也能一眼看懂其意图。

在氛围编程时，我通常唯一会去仔细阅读和审查的代码就是测试代码。当所有测试都通过了，我心里才觉得这个功能是踏实可用的。

提问6：关于“指数级增长”的含义

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

回答：指数级增长的核心，不仅仅是持续线性变好，而是它们能力提升的速度远远超出我们基于历史经验的线性想象。就像技术发展的散点图一样，开始是平缓上升，然后某个拐点后突然就呈现垂直狂飙的态势。

回顾90年代从事计算机行业的人，从几KB内存到今天的TB级存储，那不是好了两倍，而是好了数百万倍。所以我们不该用线性思维去想“20年后模型比现在好两倍会怎样”，而是要去思考“如果它的综合能力比今天强大一百万倍会发生什么”。这听起来极其疯狂，也充满了颠覆性的可能性，这才是所谓拥抱“指数级”技术浪潮的真正含义。

提问7：关于工作流与上下文管理

问题：你有两种主要工作流，一种是在终端里使用Claude Code，一种是在VS Code或Cursor里，你通常如何选择？多久会清理或压缩一次对话上下文？因为时间长了模型容易遗忘或偏离主题。

回答：我两边都会根据场景使用。主要的、大规模的代码修改和生成是Claude Code在终端里完成的，而我同时会在VS Code或Cursor里边实时浏览生成的代码（或者更常见的是，审查它生成的测试代码）。

我通常在感觉到一个“自然任务段落”完成时，就进行一次上下文压缩，这类似于人类程序员会停下来喝杯咖啡或吃个午饭的节点。我的标准起手式是：先让Claude探索代码库并找出所有相关文件，制定一个详细计划，然后让它把这些关键信息全写进一个独立的Markdown文档里，接着我立刻开启一个新会话并导入这个文档。这样就能丢掉制定计划时耗费的那大量Token历史，从一个只有几千个Token的、干净且目标明确的上下文重新开始，效率非常高。

提问8：关于多会话协作与陌生代码库

问题：你会同时开启多个Claude Code会话然后合并结果吗？面对一个你极不熟悉的庞大遗留代码库，如何以工程化的方式提交高质量的PR，而不是让AI乱写一气？

回答：是的，对于复杂任务，我会用Claude Code来搭建初始框架和主体逻辑，然后用Cursor这类IDE插件去进行收尾、调试和修复细节。对于那些我知道具体在哪几行的小范围修改，我会直接用Cursor手动完成以提高效率。

面对完全陌生的庞大代码库，在动手编写新功能之前，我会先用Claude Code帮我进行系统性探索。我会问：“用户认证的核心逻辑代码在哪？”、“告诉我哪些现有功能模块和这个新需求在架构上类似”、“列出我实现这个功能前应该查阅的核心接口和类”。先在脑海中建立起一个清晰的代码地图和全局视图，确保我能稳妥地掌控变更的影响范围，然后再和Claude一起动手实施具体编码。

来源:https://www.163.com/dy/article/KQVG5Q620511AQHO.html

免责声明：游乐网为非赢利性网站，所展示的游戏/软件/文章内容均来自于互联网或第三方用户上传分享，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系youleyoucom@outlook.com。

上一篇：Excel多工作表数据合并技巧下一篇：22岁开发者开源Mythos架构解析MoE与注意力机制设计