编程模式界限模糊：从“感觉编码”到“代理工程”的融合与隐忧

我最近与 Joseph Ruscio 在 Heavybit 的《高杠杆》播客中聊了 AI 编程工具：第 9 集，《与 Simon Willison 谈 AI 编程范式转变》。以下是我的一些亮点，包括一个令人不安的发现：在我自己的工作中，氛围编程和智能体工程已经开始融合。

播客真正让我享受的一点是，它有时会促使我进行即兴思考，从而揭示出一些我此前无法用语言表达的想法。

氛围编程和智能体工程开始重叠

在“氛围编程”这个概念被首次提出几周后，我发表了《并非所有 AI 辅助编程都是氛围编程（但氛围编程很酷）》，在那篇文章中，我坚定地表明了自己的信念：“氛围编程”与负责任地使用 AI 编写代码（我后来开始称之为智能体工程）是截然不同的两回事。

当 Joseph 提到这两者之间的区别时，我突然意识到，对我来说，它们已经不像过去那样泾渭分明了：

奇怪的是，对我来说，这些东西已经开始模糊了，这挺让人不安的。

我原以为我们有一个非常清晰的界限：氛围编程是指你完全不看代码。你甚至可能根本不懂编程。你可能是一个非程序员，你提出一个需求，然后得到一个结果。如果结果能用，那就太好了！如果不能用，你就告诉它不行，然后祈祷它能改好。

但自始至终，你都不真正关心代码质量或任何其他附加约束。我对氛围编程的看法是，只要你明白它何时可用、何时不可用，那它就很棒。

一个给你自己用的个人工具，如果出了 bug 只会影响到你自己，那尽管用吧！

但如果你是在为别人构建软件，那么氛围编程就是极不负责任的，因为这涉及到他人的信息。你那些愚蠢的 bug 会伤害到别人。你需要有比这更高的标准。

这与智能体工程形成对比，在智能体工程中，你是一名专业软件工程师。你理解安全性、可维护性、运维和性能等方面。你是在尽自己最大能力使用这些工具。我发现我能应对的挑战范围大幅增加了，因为有了这些工具的辅助。

但我仍然依赖自己 25 年的软件工程师经验。

目标是构建高质量的生产系统：如果你在更快地构建低质量的东西，我认为那是不好的。我想更快地构建更高质量的东西。我希望我构建的一切在各个方面都比以前更好。

问题在于，随着编码智能体越来越可靠，我不再审查它们写的每一行代码了，即使对于我的生产级项目也是如此。

我很清楚，如果你让 Claude Code 构建一个 JSON API 端点，让它执行 SQL 查询并将结果以 JSON 格式输出，它就能直接做对。它不会搞砸。你让它添加自动化测试，你让它添加文档，你知道结果会很好。

但我没有审查那些代码。现在我有了那种负罪感：如果我没有审查代码，在生产环境中使用它真的负责任吗？

真正对我有帮助的是回想我在大型组织担任工程经理的经历。其他团队构建的软件是我所在团队所依赖的。

如果另一个团队交过来一个东西说：“嘿，这是图片缩放服务，这是用它缩放图片的方法”……我不会去阅读他们写的每一行代码。

我会查看他们的文档，然后用它来缩放一些图片。接着我就会开始发布自己的功能。如果我开始遇到问题，比如图片缩放器似乎有 bug 或性能不佳，那时我才会深入他们的 Git 仓库看看发生了什么。但大多数情况下，我把它当作一个半黑箱，在需要之前不会去查看。

我开始以同样的方式看待智能体。这仍然让人感到不安，因为人类要为自己的行为负责。一个团队可以建立声誉。我可以说：“我信任那个团队。他们过去开发过优秀的软件。他们不会做出糟糕的东西，因为那会影响他们的职业声誉。”

Claude Code 可没有职业声誉！它无法为自己的行为承担责任。但无论如何，它一直在证明自己——一次又一次地，它源源不断地产出直截了当的东西，并且以我喜欢的方式把它们做对。

这里面存在一种“偏差正常化”的因素——每当一个模型在没有我密切监控的情况下写出了正确的代码，我就有可能在未来某个错误的时刻信任它，然后栽跟头。

评估软件的新挑战

过去，如果你找到一个 GitHub 仓库，里面有一百次提交、一份不错的 README 和自动化测试等等，你基本可以确定，写这个仓库的人对这个项目投入了大量的心血和关注。

而现在，我可以在半小时内搞出一个有一百次提交、一份漂亮的 README 以及覆盖每一行代码的全面测试的 Git 仓库！它看起来和那些倾注了大量心血和关注的项目一模一样。也许它确实和它们一样好。我不知道。我光看是看不出来的。即使是我自己的项目，我也看不出来。

所以我意识到，比起测试和文档的质量，我更看重的是有人实际用过这个东西。如果你有一个用“氛围编码”搞出来的东西，并且过去两周每天都在用，那对我来说，比你刚刚吐出来、几乎没怎么运行过的东西有价值得多。

瓶颈已经转移

如果你能从每天产出 200 行代码变成每天产出 2000 行代码，还有什么会出问题？事实证明，整个软件开发生命周期都是围绕“一天只能产出几百行代码”这个想法设计的。而现在，情况已经不同了。

不仅仅是下游环节，上游环节也同样如此。我听了Anthropic设计负责人Jenny Wen的一场精彩演讲，她说我们所有的设计流程都基于这样一个理念：你必须把设计做对——因为如果你把设计交给工程师，他们花三个月时间造出了错误的东西，那将是灾难性的。

之所以要建立这套非常详尽的设计流程，是因为设计结果会带来高昂的工程成本。但如果开发不再需要三个月时间，也许设计流程就可以冒更大的风险，因为一旦出错，成本已经大幅降低了。

为什么我仍然不担心自己的职业生涯

当我回顾自己与AI智能体的对话时，我非常清楚地意识到，对绝大多数人类来说，这简直就是天书。

我之所以不担心自己作为软件工程师的职业生涯就此终结——即便计算机现在能自己写代码——有一大堆理由，部分原因在于这些东西是现有经验的放大器。如果你懂行，借助它们你可以跑得快得多。[……]

在使用这些工具的过程中，我不断被提醒，我们所做的事情有多么困难。开发软件是一件极其艰难的事。就算你把全世界所有的AI工具都给我，我们试图实现的目标依然非常困难。[……]

政治评论员Matthew Yglesias昨天在推特上写道：“用了五个月，我想我已经决定了——我不想搞‘氛围编程’——我希望由专业管理的软件公司利用AI编程辅助，制造出更多、更好、更便宜的软件产品，然后卖给我。”我觉得这个说法挺对的。我要是看足够多的水管工YouTube视频，也能自己修家里的水管。但我宁愿雇一个水管工。

关于企业自行开发解决方案对SaaS供应商构成的威胁：

我刚刚意识到，这跟我之前说的那个观点是一回事——我只愿意使用你自己已经用了几个星期的副业项目。企业级的版本就是：除非至少有两家大型企业已经成功使用某款 CRM 系统六个月以上，否则我不会考虑它。[...] 你想要的是那些在你冒险尝试之前已经被证明行之有效的解决方案。

2026年5月6日