谷歌：氛围编程 SDLC 指南

2025 年 2 月，Andrej Karpathy 发布了一条帖子，悄然打破了互联网。他描述了一种新的编程方式，你"完全沉浸在氛围中，拥抱指数级增长，忘记代码的存在"。提示。接受。运行。如果出错，粘贴错误并重试。

这个术语瞬间走红。不是因为它是新的——开发者已经在这样做了。它只是终于有了一个名字。

十六个月后，谷歌发布了一份 50 页的白皮书，标题为《The New SDLC With Vibe Coding》，由 Addy Osmani、Shubham Saboo 和 Sokratis Kartakis 共同撰写。这篇论文技术含量高，结构严谨，值得通读。但其核心信息令人不安：氛围编程在原型阶段运作良好。它正在悄然摧毁生产系统，而大多数工程团队还没有意识到，因为损害是缓慢积累的。

这篇文章将分解指南的实际论点，它在哪里划下了严格的界限，以及这对 2026 年使用 AI 代理构建软件的任何人意味着什么。

1、为什么氛围编程不再足够

氛围编程之所以成功，是因为它降低了门槛。开发者可以在几分钟内原型化功能，非工程师可以构建功能性工具，想法和运行代码之间的反馈循环从几天缩短到几小时。这是真正有价值的。完全否定它是工程势利。

但门槛不是问题。天花板才是。

随着 AI 代理变得更加有能力，团队开始将同样的随意、提示并接受的工作流程应用于生产系统——支付 API、认证逻辑、数据管道、医疗保健工具。输出看起来很干净。它通常通过基本测试。它发布了。然后，几周或几个月后，某些东西以一种昂贵且难以追踪的方式损坏了。

原因是结构性的。氛围编程从未设计用于处理生产级的正确性要求。它是为了让某些东西快速运行而设计的。这些是根本不同的目标，而这条界线的模糊就是当前危机所在。

谷歌的论文本质上是试图给工程团队词汇和框架，以停止模糊这条界线。

2、光谱：你实际在哪个层次运作？

论文描绘了一个从一端的氛围编程到另一端的代理式工程的光谱。大多数从业者处于中间某个位置，不知道具体在哪里——这本身就是问题。

整个光谱中唯一的区分因素不是你使用哪个模型，不是你的提示有多复杂，不是工具。而是输出如何被验证。

如果没有确定性测试（这个函数在给定这个输入时是否产生正确的输出）和轨迹评估（代理是否采取了正确的推理步骤序列来达到那个输出），无论你的设置看起来多么复杂，你都在进行氛围编程。跳过验证步骤的流畅、格式良好的输出不是成功。它是比可见错误更危险的失败，因为它在生产中出现之前是不可见的。

这就是严格的界限。它解释了为什么许多运行复杂代理工作流程的团队在技术上仍在进行氛围编程。

3、代理 = 模型 + 框架

这是整篇论文中最重要的技术重构，也是大多数开发者最容易出错的地方。

当代理行为不当时，默认反应是指责模型。模型太弱、太慢、太容易产生幻觉。修复必须是更好的模型。这种推理几乎总是错误的。

模型只是一个组件。围绕它的一切——提示、工具、上下文策略、执行沙箱、子代理、可观测性基础设施——被称为框架。代理行为更多地由框架质量而非模型质量主导。

论文引用了两个数据点来具体说明这一点。在 Terminal Bench 2.0 上，一个团队仅通过改变框架（完全没有改变模型），将编码代理从前 30 名之外提升到前 5 名。另外，一项 LangChain 研究仅通过改变固定底层模型周围的系统提示、工具和中间件，将编码代理的基准分数提高了 13.7 分。

框架完全由团队负责。模型提供商提供引擎。团队围绕它构建工厂车间。大多数代理故障，诚实地检查，不是模型故障。它们是配置故障：缺失的工具、模糊的规则、缺失的护栏、被无关噪音淹没的上下文窗口。模型被责怪是因为它是可见的表面。框架才是实际故障所在。

这种区别对于团队如何投入时间至关重要。追逐模型升级而忽视框架质量，相当于购买更快的引擎并将其安装在没有刹车的汽车上。

4、上下文工程：真正的竞争护城河

提示工程作为一门独立学科，基本上已经过时了。取代它的技能是上下文工程——为代理提供有关其运作的代码库、架构、约定和意图的丰富、结构化信息的实践。

论文确定了每个代理需要的六种上下文类型：指令、知识、记忆、示例、工具和护栏。每一种都可以是静态的（始终加载到每个交互中）或动态的（仅在任务需要时按需加载）。

静态上下文成本高昂。无论是否相关，每个令牌都存在于每次模型调用中。过多的静态上下文浪费令牌，稀释信号，并且可以通过将关键规则埋在噪音中来主动降低代理性能。动态上下文效率高——它从 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

语法是次要的。重要的是作为约束编码的意图。代理知道它是什么，它可以触摸什么，什么触发专家行为，以及它在没有将所有内容加载到每个上下文窗口中时永远不能做什么。这就是在数百个任务中保持可靠的代理与在第一个 dozen 后不可预测地漂移的代理之间的区别。

5、80% 问题：为什么速度是陷阱

AI 代理可以为任何给定功能快速生成大约 80% 的代码。这 80% 通常看起来很干净，通过表面级审查，并且没有事故地发布。这就是陷阱所在。

剩下的 20% 是系统死亡的地方。边缘情况。存在于机构记忆中但不在任何文档中的隐式业务逻辑。由不同团队在多年前构建的服务之间的集成点。只有在真实负载或真实用户行为下才会变得可见的微妙正确性要求。

这特别危险的原因是 AI 错误的性质已经演变。早期的 AI 编码工具产生明显的语法错误——容易在审查中发现。当前一代的代理产生概念性失败：对业务逻辑的错误假设、看起来合理的缺失边缘情况、创建隐藏的长期维护债务的架构决策。代码看起来正确。它可能通过测试套件。失败是结构性的、延迟的，并且通常比预防它昂贵得多。

这就是为什么轨迹评估——不仅检查输出，还检查代理产生它所采取的推理路径——在生产代理系统中不是可选的。输出评估回答：函数是否产生了正确的结果？轨迹评估回答：代理在生成函数之前是否正确理解了问题？两个问题都是必要的。只检查输出就是 20% 未被检测到的方式。

最有效地驾驭这一点的开发者不是试图通过接受代理产生的一切来更快。他们更快是因为他们将自己的判断力精确地集中在 AI 判断力在结构上最弱的地方——模糊的需求、架构权衡和系统边界的正确性验证。

6、指挥家还是编排者：正在发生的角色转变

论文描述了开发者在两种操作模式之间移动，它们之间的转变是当前软件工程中最实际重要的职业转变。

指挥家模式是实时的、动手的。开发者在 IDE 中，看着代码出现，用更正指导代理，对每个更改保持细粒度的控制。这种模式保留了大多数工程师所训练的直觉和理解感。风险在于吞吐量——如果开发者亲自指导每次交互，来自 AI 的生产力收益从根本上是有限的。

编排者模式在更高的抽象级别上操作。开发者定义目标，将它们分配给代理，并审查输出——但不是逐行观看代码实现。代理并行运行，在后台沙箱中，有时运行数小时，将拉取请求作为输出产生。开发者定期签到，评估结果，并提供纠正。

编排者模式需要一套完全不同于指挥家模式的技能：

指挥家技能集中在深入的语言和语法知识、快速调试、代码库直觉和实时错误解释。编排者技能集中在精确的规范、任务分解、输出评估速度和系统设计——设计约束、测试和反馈循环，使代理能够在没有持续监督的情况下可靠运行。

大多数高级开发者是训练有素的指挥家。编排让人感到不舒服，因为它感觉像失去控制。有时它确实是。这正是为什么在重大编排开始之前，框架基础设施、评估覆盖和上下文工程必须到位。在没有验证基础设施的情况下委托不是工程。它是大规模的氛围编程。

7、没有人在谈论的经济学

论文引入了一个成本模型，将整个氛围编程与代理式工程的辩论重新构建为经济学问题，而不是方法论辩论。

氛围编程的前期成本几乎为零——没有规范纪律，没有评估基础设施，没有框架设计，没有 AGENTS.md 维护。但它快速积累隐藏的运营债务：来自非结构化上下文的令牌浪费、来自未经验证输出的复合错误面、开发者花时间调试本应被自动评估捕获的故障。

代理式工程需要真正的前期投资。规范严格性、评估基础设施、框架设计、上下文架构。资本支出是真实的，而且是前置的。但一旦系统构建完成，每个功能的边际成本会大幅下降。每个新的代理功能都受益于相同的框架、相同的评估套件、相同的上下文架构。

在小规模下——单个开发者、原型、副业项目——氛围编程经济学显然更好。没有要保护的生产，债务永远不会危险地复合。

在团队规模下，交叉点比大多数人预期的更快到达。五名工程师团队进行三个月的氛围编程很容易达到这样的状态：他们三分之一的能力被调试和返工所吸收，而系统性验证本来可以防止这些。代理式工程基础设施的前期投资会收回成本，但前提是团队在债务复合超过临界点之前就进行投资。

8、这意味着什么

谷歌的论文不是产品公告。它是一个框架文档，并且比大多数框架文档更有用，因为它的核心主张是经验可测试的。

框架效应是真实且可衡量的——论文引用的基准数据证明了这一点。80% 问题是真实的，并且随着代理被信任处理更复杂的任务而变得更加尖锐。指挥家到编排者的转变已经在每个认真运作的工程组织中进行。

论文故意留下未解决的问题是：任何给定团队应该在光谱的哪个位置运作。答案取决于利害关系、团队规模、截止日期压力和技术成熟度，没有任何框架文档可以规定。论文提供了词汇和心理模型。判断力仍然是人类的。

这可能是它能说的最诚实的话。

结构化能扩展。氛围不能。现在内化这种区别的开发者正在与那些将在生产中以昂贵方式学习的开发者建立在根本不同的基础上。

原文链接：Google’s New SDLC Guide Draws a Hard Line Between Vibe Coding and Agentic Engineering

汇智网翻译整理，转载请标明出处