氛围编码与智能工程正变得比我预想中更接近

# 氛围编程与智能体工程正变得越来越接近，这让我不太舒服 来源：https://simonwillison.net/2026/May/6/vibe-coding-and-agentic-engineering/ 2026年5月6日 我最近与约瑟夫·鲁西奥在Heavybit的High Leverage播客上聊了AI编程工具：[Ep. #9, The AI Coding Paradigm Shift with Simon Willison](https://www.heavybit.com/library/podcasts/high-leverage/ep-9-the-ai-coding-paradigm-shift-with-simon-willison)。以下是我的一些重点内容，包括一个令人不安的发现：氛围编程（vibe coding）和智能体工程（agentic engineering）在我自己的工作中开始趋同。 播客的一大乐趣就是，它有时会迫使你进行即兴思考，从而暴露出一个你之前无法用语言表达的想法。 #### 氛围编程与智能体工程开始重叠 在“氛围编程”这个词首次被提出几周后，我发表了文章[并非所有AI辅助编程都是氛围编程（但氛围编程很棒）](https://simonwillison.net/2025/Mar/19/vibe-coding/)，我在其中坚定地表达了我的观点：“氛围编程”与负责任地使用AI编写代码（我后来开始称之为[智能体工程](https://simonwillison.net/guides/agentic-engineering-patterns/what-is-agentic-engineering/)）是截然不同的。 当约瑟夫提到这两者的区别时，我突然意识到，它们对我来说已经不像以前那样泾渭分明了： > 奇怪的是，这些事物对我来说已经开始模糊了，这挺令人沮丧的。我原以为我们有一个非常清晰的界限：氛围编程是指你根本不看代码。你可能甚至不懂编程。你可能是一个非程序员，你要求一个东西，然后得到它，如果它有效，那太好了！如果无效，你告诉它无效，然后听天由命。但自始至终，你并不真正关心代码质量或其他任何附加约束。我对氛围编程的看法是，它很棒，前提是你知道什么时候能用、什么时候不能用。这是一个为你个人服务的工具：如果出现bug，只影响你自己，那就放心用吧！如果你在为别人构建软件，那么使用氛围编程就是极不负责任的，因为那关系到别人的信息。别人会因为你的愚蠢bug而受到伤害。你需要有更高的标准。这与智能体工程形成对比：在智能体工程中，你是一名专业的软件工程师。你了解安全性、可维护性、运维、性能等等。你在尽自己最大能力使用这些工具。我发现我能应对的挑战范围大大增加了，因为有了这些工具的支持。但我仍然依赖自己25年软件工程师的经验。目标是构建高质量的生产系统：如果你在更快地构建低质量的东西，我认为那不好。我想要更快地构建*更高*质量的东西。我希望我构建的一切在各个方面都比以前更好。问题是，随着编码代理变得愈发可靠，我不再检查它们写的每一行代码了，即使是在我的生产级项目中。我非常清楚，如果你让Claude Code构建一个JSON API端点来执行SQL查询并输出结果为JSON，它就能直接做对。它不会搞砸。你让它添加自动化测试，它就会添加；你让它添加文档，它就会添加。你知道结果会很好。但我并没有审查那些代码。现在我感到了内疚：如果我没有审查代码，那么将它用于生产环境真的负责任吗？真正帮助我思考的，是回想我在大公司担任工程经理时的经历。其他团队构建了我团队依赖的软件。如果另一个团队交给我一个东西说：“嘿，这是图片缩放服务，这是如何使用它来缩放图片的......”我不会去阅读他们写的每一行代码。我会查看他们的文档，然后用来缩放一些图片。接着我就会开始发布自己的功能。如果我开始遇到问题，比如图片缩放器似乎有bug或性能不佳，那时我才会深入他们的Git仓库看看怎么回事。但在大多数情况下，我把它当作一个半黑盒，不到必要时不去看它。我开始用同样的方式对待那些代理。这仍然让人感到不安，因为人类要为自己的行为负责。一个团队可以建立声誉。我可以说：“我相信那个团队。他们过去构建过好的软件。他们不会构建垃圾，因为这会影响他们的职业声誉。”Claude Code可没有职业声誉！它不能为它的所作所为承担责任。但无论如何，它一直在证明自己——一次又一次，它产出简单直接的东西，并以我喜欢的方式做对。 这其中有[偏差正常化](https://simonwillison.net/2025/Dec/10/normalization-of-deviance/)的元素——每次模型在我没有严密监控的情况下写对了代码，都有风险让我在将来某个错误时刻信任它，然后被坑。 #### 评估软件的新挑战 > 过去，如果你找到一个有一百次提交、一份漂亮的README和自动化测试等内容的GitHub仓库，你基本可以确定，编写它的人投入了大量的心血和关注。而现在，我可以在半小时内创建一个有一百次提交、漂亮的README和对每一行代码进行详尽测试的Git仓库！它看起来和那些投入了大量心血和关注的项目一模一样。也许它确实和它们一样好。我不知道。我光看外表看不出来。即使是*我自己*的项目，我也看不出来。所以我意识到，我比测试和文档质量更看重的是：有人*用过*这个东西。如果你有一个氛围编程出来的东西，并且你在过去两周每天都在使用它，那对我来说，比你刚刚吐出来、几乎没怎么用过的东西要宝贵得多。 #### 瓶颈已经转移 > 如果你能从每天产出200行代码变成每天产出2000行代码，还有什么会出问题？整个软件开发生命周期，原来都是围绕着“一天需要产出几百行代码”这个想法设计的。现在不需要了。不仅是下游环节，上游环节也是如此。我看到过[Anthropic的设计负责人Jenny Wen的一次精彩演讲](https://simonwillison.net/2026/Jan/24/dont-trust-the-process/)，她说：我们所有的设计流程都是基于这样一个想法——你必须把设计搞*对*——因为如果你把它交给工程师，而他们花了三个月构建了错误的东西，那将是灾难性的。你建立了一整套非常详尽的设计流程，因为这种设计会导致昂贵的开发工作。但如果构建不再需要三个月时间，那么设计流程就可以冒更大的风险，因为搞错了的成本已经大大降低了。 #### 为什么我仍然不担心我的职业生涯 > 当我观察自己和那些代理的对话时，我很清楚，这对绝大多数人类来说就像是外星语言。我不担心我的软件工程师职业生涯会因为计算机能自己写代码而结束，这有很多原因，部分原因是这些东西是现有经验的放大器。如果你知道自己在做什么，你可以用它们跑得更快。[……]我在使用这些工具时不断意识到，我们做的事情有多难。生产软件是一件*极其*困难的事情。就算你把世界上所有AI工具都给我，我们想要实现的目标仍然非常困难。[……]政治评论员Matthew Yglesias昨天[发推](https://twitter.com/mattyglesias/status/2049105745132585161)说：“五个月过去了，我想我已经决定：我不想要氛围编程——我想要专业管理的软件公司使用AI编码辅助来制造更多、更好、更便宜的软件产品，然后卖给我。”这对我来说感觉差不多。我可以自己捣鼓水管，只要我看足够多的水管工YouTube视频。但我宁愿请一个水管工。 关于公司自行开发解决方案对SaaS提供商构成的威胁： > 我只是意识到，这又回到了我之前说的：我只想用你的副业项目，前提是你自己已经用了几个星期。企业版的版本是：我不想用一个CRM系统，除非至少有两家其他大型企业已经成功使用它六个月了。[……]在冒险之前，你总想要那些已经被证明有效的解决方案。