文章探讨了AI辅助开发从“氛围编程”到“智能体工程”的演变。随着AI智能体能力提升，业内呼吁更严谨的工程实践和“线束”系统来应对生产级挑战。
译自：From vibes to engineering: How AI agents outgrew their own terminology
作者：Darryl K. Taft
Andrej Karpathy 可能并非有意在推广“氛围编程”仅仅一年后就将其“淘汰”，但时间和技术的进步迫使他不得不这样做。开发者社区正处于一个十字路口——他们一方面坚守着一个标签，另一方面又不得不适应一个已超越这个标签的领域。
Karpathy 最近提出“智能体工程”能更准确地描述AI辅助开发的现状。这里收集了科技行业一些人士对Karpathy 将“氛围编程”重新定义为“智能体工程”的回应。
“我认为氛围编程这个词会流行起来——精灵已经从瓶子里放出来了，”《氛围编程》一书的作者、软件开发文化长期观察者 Gene Kim 告诉 The New Stack。Kim 曾与他的合著者 Steve Yegge 就这本书的命名问题争论不休。
“我当时想把书名定为‘氛围工程’，但问题是没人知道那是什么，”Kim 说。“有趣且讽刺的是，即使是 Karpathy 博士，尽管他在行业中拥有令人难以置信的地位，也无法把精灵重新装回瓶子里，这不是很可笑吗？”
Karpathy 是人工智能领域最受尊敬的人物之一。他是 OpenAI 的联合创始人，前特斯拉人工智能总监，也是将他现在正在重塑的术语普及开来的人。
从原型到生产
这不仅仅是语义问题。而是这种实践本身的变化速度超过了描述它的词语。
“氛围编程对于原型开发来说很棒，但对于现有系统或生产代码来说并不理想，”跟踪开发者体验趋势的 Forrester Research 分析师 Andrew Cornwall 告诉 The New Stack。Cornwall 表示，他认为主体式开发是专业开发人员的自然接替者。“大多数开发人员已经采用了生成式 AI 辅助，而智能体则承诺为那些能熟练使用它们的开发人员带来更高层次的益处。”
与此同时，多年来一直在研究软件开发未来的 Forrester 分析师 Diego Lo Giudice 指出，Forrester 在2024年第四季度的一项预测中曾预见到 Karpathy 的重新定义。
“到2026年底，氛围编程将转变为氛围工程，”Lo Giudice 当时写道——这比Karpathy 最近的推文早了近14个月。
对于 Lo Giudice 来说，这种转变有两个维度。“公司只有在强有力的工程产品化流程支持下才能采用氛围编程，”他告诉 The New Stack。但他指出，还有一个技能维度。
“氛围编程中蕴含着一种工程艺术——它将其转化为氛围工程——只有那些了解软件工程的人才能真正成功，”Lo Giudice 说。
氛围编程，正如 Karpathy 最初定义的那样，是一种松散的、直觉驱动的过程：描述你想要什么，接受模型生成的内容，然后快速迭代，而不必深入关注底层结构。这适用于周末项目。专家表示，在大规模应用时就会崩溃。
意想不到的飞跃
加速这场术语辩论的是人工智能智能体能力上的转变。
“Arcjet 公司首席执行官 David Mytton 告诉 The New Stack：“在过去一两个月里，智能体的编程能力发生了巨大飞跃。几个月前还需要多次人/智能体迭代才能完成的复杂任务，现在它们已经能够独立完成了。”Arcjet 为开发者提供了一个 AI 驱动的安全平台。
此外，Mytton 指出：“我发现它只有在明确的护栏到位时才有效——良好的代码文档和智能体可以运行的全面测试。这就是氛围编程与氛围工程的区别所在。‘工程’关乎纪律和结构——这样人工智能智能体才能真正地发挥作用——否则你最终会陷入‘它仍然不起作用’的反复试错循环。”
Resolve AI 联合创始人兼首席技术官 Mayank Agarwal 表示，人工智能智能体的编排是超越氛围编程的一步。Resolve AI 提供人工智能智能体，帮助企业解决事件。
“Karpathy 的观点引起了共鸣。智能体工程更准确地捕捉了工程师当前操作方式的转变。你不是直接编写代码，而是在编排智能体，这需要真正的纪律，”Agarwal 告诉 The New Stack。“代码生成的速度与高效吸收代码的速度不匹配，如果没有适当的工程实践，主体工作流只会以机器的速度生成技术债务。氛围编程作为一个标签总是显得随意。我们现在所看到的一切需要更多的严谨性，而不是更少。”
密切关注人工智能基础设施的 Futurum Group 分析师 Brad Shimmin 指出，这项技术在能力上取得了重大飞跃。他表示他喜欢“智能体工程”这个术语，因为在“规范”软件开发的背景下，他越来越不喜欢“氛围编程”这个词。Shimmin 说，一年前，当智能体工具难以超越一次性、业余爱好性质的工作时，氛围编程是一个恰当的短语。
然而，“快进到今天，我们谈论的是能够通过多个并行工作的智能体在 Rust 中构建一个完全可用的编译器的工具，”他告诉 The New Stack。“谈论这种规模和复杂性远远超出了主体编程的‘感受氛围’。”
Shimmin 说他认为这个领域正处于一个转折点。
他表示：“我们现在正在重新思考和重新架构人类用来构建软件的工具链，将这些系统——智能体线束、代码签入/签出等——转变，以适应并增强人工智能智能体的独特能力和局限性。”“这是工程，而不是‘情感工程’。”
线束是差异化因素
与此同时，云原生服务公司 Caylent 的首席技术官 Randall Hunt 表示，我们不应该过于关心这种实践的称呼，而应该关注其实际价值所在。
“Karpathy 的‘智能体工程’框架很有用，因为它将讨论从模型本身转移到了围绕模型的系统，”Hunt 告诉 The New Stack。“在 Caylent，我们一直认为模型会趋于商品化。我们最聪明的客户和企业明白，差异化不在于你选择了哪个大型语言模型，而在于主体线束。”
Hunt 所说的“线束”指的是围绕模型的完整系统：工具、上下文管理、评估和可观测性基础设施。“如果你不设计好这个线束，你就无法获得复合杠杆效应；你只会获得复合认知债务。”
Hunt 认为，2025年，技术债务是工程团队的主要负担。他预测到2026年，认知债务——管理不善的人工智能交互、上下文丢失和不可靠的智能体行为所累积的成本——将取代技术债务，成为主要威胁。
Resolve AI 首席执行官兼联合创始人 Spiros Xanthos 表示，他同意 Karpathy 的观点。
Xanthos 告诉 The New Stack：“Karpathy 说得没错，大型语言模型在软件工程领域将长期存在。氛围编程已经从初创公司蔓延到企业级工程团队，随着这些 AI 生成的代码进入生产环境，我们意识到一个新问题：生产环境的运行。瓶颈不再是代码生成。而是了解当代码出现问题时发生了什么。如果智能体工程是关于编排智能体来构建，那么下一个前沿就是编排智能体来运行和修复它们所构建的东西。”
与此同时，社会影响力技术提供商 Bonterra 的首席技术官 Tanuja Korlepra 描述了在她所在组织内部智能体工程的运作方式。
她告诉 The New Stack：“通过智能体工程，我们的开发人员大部分时间都不再手动编写代码。我们正在使用主体式 AI 编码工具，编排编写代码的智能体，并充当智能体的管理者。要做好这一点，既需要艺术也需要科学，我们的团队正在这方面建立深厚的专业知识。”
Korlepra 表示，Bonterra 将这一理念通过 Que 平台传递给客户。Bonterra Que 是一个主体式人工智能平台，专为非营利组织、基金会、企业社会责任团队、捐赠者和志愿者打造。
Korlepra 说：“一位非营利组织的筹款人可以像经理指导一名能干的团队成员一样，简单地指示 Que。告诉它划分捐助者、起草电子邮件并建立捐款表格。它处理繁重的操作工作，这样他们就可以专注于自己的使命。”
氛围编程万岁？
跟踪企业软件趋势的 Constellation Research 分析师 Holger Mueller 提出了一个务实的观点。他认为，氛围编程从未真正打算成为一种永久性的专业开发模式。
Mueller 说：“氛围编程作为一种活动，从一开始就几乎过时了，因为很明显，自主智能体将成为软件开发生命周期 (SDLC)的关键。”他指出Google 2024年12月的多智能体演示是一个早期指标。
他告诉 The New Stack：“氛围编程是赢得开发者信任的关键一环，让他们现在可以并行运行多个智能体，完成并帮助他们的工作。”
Mueller 表示，他将氛围编程视为一个入门级阶段——一种让数百万“开发者”足够适应人工智能辅助，从而进阶到更严谨模式的方式。
Gene Kim 花了一年时间就这个问题争论书名，他承认主体技术的进步，并认同 Mueller 的前提。
“氛围编程万岁，”他在我们对话的总结中告诉 The New Stack。
