氛围编码与代理工程：谷歌新软件开发生命周期论文的观点
谷歌关于新软件开发生命周期的白皮书概要：验证作为分界线、利用而非模型、上下文工程、80%陷阱以及指挥者与协调者。
来源: Google’s New SDLC Guide Draws a Hard Line Between Vibe Coding and Agentic Engineering
从口号到白皮书
2025年初，安德烈·卡帕西提出了一种编程理念：完全顺应直觉，跟随指数级发展趋势，甚至不再关心代码的存在。其流程为：输入指令、接受结果、运行程序，若出错则将错误信息反馈回来。这一概念迅速传播开来，尽管人们早已以这种方式工作，只是此前缺乏一个专门的名称。
大约16个月后，谷歌发布了由Addy Osmani、Shubham Saboo和Sokratis Kartakis撰写的50页白皮书《基于Vibe Coding的新软件开发生命周期》，标题为《The New SDLC With Vibe Coding》。这份文档内容详实、结构严谨，其观点发人深省：Vibe Coding虽适用于原型开发，但正在逐渐对生产系统造成损害，许多团队因危害是逐步积累的而未能察觉。以下内容将阐述该文档的观点、明确的界限，以及这对2026年使用AI智能体进行开发的人士意味着什么。
Vibe Coding为何有效，以及其局限性何在
Vibe Coding之所以流行，是因为它降低了入门门槛。制作原型只需几分钟，非工程师也能组装出可用的工具，将想法转化为可运行代码的时间也从几天缩短到几小时。这极具价值，忽视这一点便是工程领域的傲慢表现。不过，问题从来不在入门门槛，而在于上限。
当开发人员的能力提升后，团队开始将那种随意的“提示即接受”习惯应用到实际生产环境中，包括支付API、身份验证逻辑、数据管道以及医疗保健工具。这样的代码看起来整洁，通常也能通过基础测试，因此会被直接投入使用。但几周或几个月后，就会出现一些难以追踪且后果严重的故障。
问题的根源在于结构层面。“氛围编码”旨在让代码快速运行，而非满足生产环境所需的严格正确性标准，二者目标本就不同。将二者混为一谈正是当今问题的来源。那份白皮书试图为团队提供相应的术语和框架，以避免这种混淆。
以一个划分标准构成的谱系
该论文描绘了一个谱系，一端是氛围编码，另一端是智能体工程。大多数从业者处于两者之间，却无法准确界定自己的位置，而这本身也是问题所在。
这个谱系涵盖三个维度：意图的指定方式、验证的严格程度以及风险等级。将两端区分开来的因素并非所使用的模型、提示语的巧妙程度或所选工具，而是输出结果的验证方式。
需要两种类型的验证。确定性测试用于判断函数对于给定输入是否能返回正确的输出；轨迹评估则用于判断智能体是否遵循了正确的推理步骤才能得到该结果。缺少其中任何一种，无论设置多么复杂，都只是所谓的“凭感觉编码”。未经验证就得到的完美流畅结果并非成功，反而是一种比显式错误更危险的失败，因为它会在实际应用中一直隐藏存在。这就是不可逾越的底线，也解释了为何许多拥有先进智能体工作流的团队在技术层面依然属于“凭感觉编码”。
模型并非核心变量
这或许是本文中最重要的一项技术性重构，但许多开发者都理解错了。当智能体表现不佳时，人们的惯常反应是将其归咎于模型太弱、太慢或容易产生幻觉，进而认为换一个更好的模型就能解决问题。但这种思路几乎总是错误的。
模型只是其中的一部分。其余的要素，即提示词、工具、上下文策略、执行沙箱、子智能体以及可观测性，共同构成了支撑框架，智能体的行为在很大程度上取决于这个支撑框架而非模型本身。本文中的两个数据点便证明了这一点：在Terminal Bench 2.0测试中，有一支团队仅通过修改支撑框架，就将某个编程智能体的排名从30名之外提升到了前5名；在另一项LangChain研究中，在保持模型不变的情况下，对系统提示词、工具及中间件的调整，使该编程智能体的测试成绩提升了13.7分。
规则文件、工具、沙箱环境、编排逻辑、约束机制以及可观测性功能都属于该集成框架的组成部分，而构建这一框架的全部工作由团队负责。供应商提供核心引擎，团队则围绕它搭建相应的应用环境。坦白说，大多数智能体故障都是配置问题：缺少某些工具、规则表述模糊、缺乏约束机制，或是上下文窗口被大量冗余信息占据。人们往往将责任归咎于模型，因为它是最外层的可见部分，而实际的缺陷其实存在于集成框架中。一味追求模型升级却忽视集成框架的优化，就好比给一辆没有刹车的汽车安装更强劲的引擎。
上下文工程取代提示工程
作为独立学科的提示工程已逐渐消失，取而代之的是上下文工程。这意味着要为智能体提供关于其所工作的代码库、架构、规范及目标的丰富且结构化的信息。该论文列出了每个智能体所需的六种上下文类型：指令、知识、记忆、示例、工具以及约束规则。这些上下文类型可能是静态的，在每次交互中都存在，也可能是动态的，根据需求才被引入。
静态上下文成本很高，因为每次模型调用时都会携带所有标记，无论这些标记是否有用。过多的标记会浪费资源、削弱信号强度，还会因关键规则被噪声掩盖而影响性能。动态上下文则更为经济，它来自RAG流程、任务匹配触发机制或需求出现时的工具输出。决定哪些内容放置何处是一个核心的工程权衡，而非简单的配置细节，因此需要版本控制、审核，以及与其他设计决策相同的重视程度。
最佳的解决方案是“智能体技能”：这类结构化、可移植的程序化知识包仅在任务需要时才会被加载。与其将专业知识塞进系统提示词中，不如通过技能让智能体始终保持轻量级的通用性，仅在被调用时才转变为专业角色。一份处理得当的AGENTS.md文件可能如下所示：
# Project: PaymentService API
## Architecture
- REST API, Node.js, PostgreSQL
- Never modify /src/core/billing without explicit approval
## Agent Skills (load on demand)
- skill:stripe-integration → load when task involves payments
- skill:database-migrations → load when task involves schema changes
## Hard Constraints
- No hardcoded credentials
- All new endpoints require integration tests before merge
确切的语法结构并不如作为约束条件而编码的意图更为重要。智能体能够了解自身能做什么、可以触碰什么、什么会触发特定行为以及哪些行为未经许可是被禁止的，而这些信息无需全部存储在每个上下文窗口中。这正是能够在数百项任务中保持稳定表现的智能体与在最初十几项任务后就表现不佳的智能体之间的区别。
80%的陷阱
智能体可以快速编写出某个功能约80%的代码。这部分代码通常看起来很整洁，能够通过初步审查，并顺利发布，正是由此形成了陷阱。而剩下的20%则是系统出问题的地方：边缘情况、存在于人们记忆中而非文档中的业务规则、由不同团队多年后构建的服务之间的集成点，以及只有在实际负载或真实用户行为下才会显现的精细正确性要求。
人工智能错误的性质也发生了变化。早期的编程工具会生成明显的语法错误，很容易被审查发现。而现在的智能体则会出现概念性错误：对业务规则的错误假设、看似合理却遗漏的边界情况，以及会带来隐性长期维护问题的架构选择。这些代码表面上看似正常，也可能通过测试套件，但其问题本质上是结构性的，后果会延迟显现，且修复成本通常远高于预防成本。
正因如此，在生产级的智能体系统中，轨迹评估——即检查智能体的推理路径及其输出结果——是不可或缺的。输出评估旨在确认函数是否返回了正确结果，而轨迹评估则要判断智能体在生成任何内容之前是否已理解问题。这两个方面都至关重要，仅关注输出结果会让最后20%的问题得以通过。那些表现最佳的开发者并非通过全盘接受一切来提升效率，而是将自身的判断力运用到人工智能判断力最薄弱的环节：模糊的需求、架构上的权衡以及系统边界处的正确性问题。
指挥者模式与协调者模式
该论文介绍了两种操作模式，而在当今的软件工程领域，切换这两种模式或许是最具实际意义的职业转变。在指挥模式下，开发者直接在集成开发环境中工作，实时观察代码的生成过程，通过修改来引导开发方向，并对每一处更改进行精细控制。这种方式能够保留工程师们经过训练后所具备的直觉与理解能力。但其代价是效率降低，因为需要亲自处理每一项交互，这限制了人工智能带来的优势。
协调模式则处于更高的层级。开发者设定目标后将其交给自动化代理，再查看代理返回的结果，而无需逐行观察代码的生成过程。这些代理会在后台的沙箱环境中并行工作，有时甚至会运行数小时，之后再返回拉取请求。开发者定期查看这些结果，根据需要进行调整。
指挥模式是实时的、手动操作的，且由单个代理执行。编排模式则是异步的，通过多个并行代理处理，并以拉取请求作为输出结果。大多数开发者最初都是作为指挥模式来工作的，转向编排模式意味着角色上的重大转变。
所需技能也有所不同。指挥者需要扎实的语言和语法知识、快速的调试能力、对代码库的深刻理解以及实时错误分析能力。而协调者则需要精确的规范、任务分解、快速的成果评估以及系统设计能力，也就是说要制定出各种约束条件、测试方案和反馈机制，以确保在无需密切监督的情况下，各个组件仍能稳定运行。许多资深开发者都是出色的指挥者，而协调工作让他们感到不适，因为这似乎意味着要放弃控制权。在某些情况下确实如此，因此在扩大协调范围之前，必须先完善基础设施、评估覆盖率并做好上下文工程。没有验证机制的授权根本算不上真正的工程实践，那不过是大规模的“凭感觉编码”罢了。
一个经济学问题
本文将“氛围编码与智能体工程”的争论视为成本问题而非方法问题。氛围编码的初期成本几乎为零：无需规范制定、无需评估基础设施、无需工具设计，也无需维护AGENTS.md文件。然而，由于非结构化上下文导致的令牌浪费、未经检查的输出所带来的日益增多的错误，以及本应由自动评估系统捕捉的故障所消耗的开发者时间，这些都会迅速积累起隐性的运营成本。
智能体工程则需要在前期投入大量资金用于规范制定、评估基础设施、工具设计以及上下文架构。之后，每个新功能的边际成本会大幅下降，因为每一种新的智能体能力都可以复用相同的工具、评估套件和上下文架构。
对于个别开发者而言，无论是用于原型开发还是业余项目，氛围式编码在成本方面显然更具优势。无需保护任何生产系统，代码债务也不会积累到危险的程度。团队达到需要转向其他方法的临界点的时间比预期更早。五名工程师采用氛围式编码工作三个月，其三分之一的时间很可能被调试和返工所占据，而这些本可通过系统化的验证来避免。只要在代码债务超过临界点之前引入代理式基础设施，其成本就能得到回报。
该论文解决了什么问题，又未解决什么问题
这篇论文并非产品推销文，而是一份框架文档，且比大多数同类文档更为实用，因为其核心主张是可以被验证的。正如文中引用的基准测试所示，“马具效应”确实存在且可测量。80%的问题也是真实存在的，而且随着智能体承担更复杂的工作，这一问题会愈发突出。而在各个规模较大的专业工程组织中，从“指挥者”向“协调者”的转变已经悄然发生。
显然有意未作明确规定的，是某个团队在该谱系中的具体位置。这一位置取决于风险程度、团队规模、时间压力以及技术成熟度等因素，而这些是任何框架都无法预先规定的。这篇论文提供了相关术语和思维模型，最终的决策仍需由人们自行判断，这或许是最为坦诚的态度了。
架构可以按比例扩展，但氛围却无法如此。现在就能理解这一点的开发者，所构建的基础与那些在生产环境中以高昂代价才学到这一点的开发者截然不同。
相关阅读
- DS-STAR详解：谷歌的数据科学智能体及其优势所在 —— 本文详细介绍了谷歌的DS-STAR数据科学智能体：其七个模块、DS-STAR+报告机制、已发布的提示词、消融实验结果以及现存的局限性。