我觉得氛围编程现在已经相当成熟地指代那种使用 AI 构建软件的快速、松散且不负责任的方式——完全由提示驱动，毫不关注代码实际如何运行。这给我们留下了一个术语空白：该如何称呼光谱的另一端？在那里，经验丰富的专业人士借助 LLMs 加速工作，同时依然自豪且自信地对他们开发的软件负责。
我提议称之为氛围工程 ，虽然我这么说带着几分戏谑。
作为软件工程师在非玩具项目上高效运用 LLMs 时，一个较少被提及的真相是这其实_很困难_ 。要深入理解如何使用这些工具需要下很大功夫，存在许多需要避开的陷阱，而它们快速产出可用代码的速度，也对人类参与者能够且应该做出的贡献提出了更高要求。
编程代理的兴起——例如 2025 年 2 月发布的 Claude Code、4 月推出的 OpenAICodex CLI 以及 6 月面世的 Gemini CLI 等工具，这些能够迭代优化代码、持续测试修改直至达成指定目标的技术，显著提升了 LLMs 解决实际编程问题的实用性。
我越来越多地听到经验丰富、信誉可靠的软件工程师们同时运行多个代理副本，并行处理多项任务，从而拓展了他们能够承接的工作范围。最初我对此持怀疑态度，但如今我自己也开始同时运行多个代理 ，效果出人意料地好，尽管这对脑力消耗极大！
这与传统的氛围编程截然不同——以往我通常将简单低风险的任务外包给 LLM，只要结果看似可行便直接采用。我的 tools.simonwillison.net 项目集（ 前文提及 ）大部分都是这样构建的。而与编程代理迭代协作，最终产出我有信心长期维护的生产级代码，这完全是另一种开发体验。
我也清楚地认识到，LLM 会积极回馈现有的顶级软件工程实践：
-
自动化测试 。如果你的项目拥有健壮、全面且稳定的测试套件，智能编码工具就能_飞速运转_ 。没有测试？你的智能体可能会声称某项功能正常，却根本没有实际测试过，而且任何新改动都可能在你不知情的情况下破坏无关功能。测试驱动开发对于能够循环迭代的智能体尤为有效。
-
预先规划 。如果从高层级规划开始，临时拼凑解决方案的效果会好得多。与智能体协作时这一点更为重要——你可以先对规划进行迭代，然后交给智能体编写代码。
-
全面文档 。就像人类程序员一样，LLM 一次只能在其上下文中保留代码库的一部分。能够输入相关文档使其无需先阅读代码即可使用其他区域的 API。先编写优质文档，模型或许仅凭这些输入就能构建出对应的实现。
-
良好的版本控制习惯 。当编码代理可能进行了更改时，能够撤销错误并了解更改的时间和方式变得更加重要。LLMs 在 Git 方面也极为擅长——它们能自行查阅历史记录来追踪错误来源，并且在使用 git bisect 方面比大多数开发者更出色。善用这一优势。
-
建立高效的自动化流程 。持续集成、自动化格式整理与代码检查、持续部署至预览环境——这些都是智能编码工具同样能受益的环节。LLMs 还能更轻松地编写快速自动化脚本，这有助于它们下次准确且一致地重复执行任务。
-
培养代码审查文化 。这一点不言自明。如果你能快速高效地进行代码审查，那么与 LLMs 协作的体验将远胜于宁愿自己写代码也不愿审查他人（或他物）所写内容的工作方式。
-
一种非常奇特的管理形式 。从编码智能体获得良好成果的体验，与从人类协作者那里获得良好成果的体验惊人地相似。你需要提供清晰的指令，确保它们掌握必要的上下文，并对产出内容提供可操作的反馈。这比与真人协作_轻松得多_ ，因为你无需担心冒犯或打击对方——但你已有的管理经验会出乎意料地派上用场。
-
出色的人工 QA（质量保障）能力 。除了自动化测试之外，你需要非常擅长手动测试软件，包括预测和深挖边界情况。
-
强大的研究能力 。解决任何编码问题都有数十种方法。找出最佳方案并验证实施路径始终至关重要，这至今仍是放手让智能体编写实际代码的主要障碍。
-
能够将功能部署到预览环境 。如果开发人员构建了某项功能，拥有安全预览该功能的方式（而非直接部署到生产环境）能让代码审查更高效，并大幅降低发布故障功能的风险。
-
对哪些工作可交由 AI 处理 、哪些需要亲力亲为的敏锐直觉。随着模型和工具日益精进，这种判断力也在持续进化。与 LLMs 高效协作的关键，在于始终保持对最佳应用场景的精准洞察力。
-
与时俱进的项目评估能力 。准确预估项目耗时向来是资深工程师最难掌握却至关重要的能力，尤其在那些依据评估结果制定预算与战略决策的组织中。AI 辅助编程使得这项工作_更具挑战_ ——以往耗时的任务如今大幅提速，但评估工作现在取决于我们仍在探索的全新变量。
要想真正发挥这些新工具的全部潜力，你必须保持在_巅峰状态_ 。你不仅要负责编写代码——还要研究技术方案、决定高层架构、撰写技术规范、定义成功标准、 设计智能体循环机制 、规划质量保证、管理日益壮大的古怪数字实习生军团（只要给机会他们绝对会偷懒），并且需要投入_大量时间进行代码审查_ 。
这些几乎都是资深软件工程师已经具备的特质！
人工智能工具能够放大现有专业技能 。作为软件工程师，你掌握的技能和经验越丰富，与 LLMs 和编程助手协作时获得的结果就越快越好。
“氛围工程”，认真的吗？ #
这名字是不是有点蠢？嗯，可能吧。如今在 AI 领域，“氛围感”这个概念已经显得有些老套了。“氛围编程”这个词本身也被许多开发者带着不屑的态度使用。我准备重新定义“氛围感”，让它承载更具建设性的内涵。
我向来不太喜欢“程序员”和“工程师”之间人为划分的界限——这总让我觉得有点像是设门槛。但这次，我们恰恰需要设点门槛！
氛围工程与氛围编程有着明确区分。它标志着这是一种不同的、更困难且更复杂的方式，即运用人工智能工具来构建生产级软件。
我喜欢这种大胆且可能引发争议的风格。整个领域在各个方面仍然显得荒谬可笑。在我们探索如何最有效地运用这些新工具时，不必太过较真。
过去我曾试图让像 **AI 辅助编程**这样的术语流行起来，但几乎毫无成效。不如试着给它增添些氛围感，看看会发生什么。
我也特别喜欢”氛围”与”工程”之间明显的错配感。这种组合让合成词自带矛盾特质，既显得顽皮狡黠，又（但愿能）让人过目不忘。
原文链接：
