AI 时代的软件开发生命周期新范式

我参与撰写了一份 Google 白皮书，讨论 AI 正在如何改变软件生命周期。我不打算概述整份白皮书，而是想介绍其中少数几个我认为真正重要的观点，以及六张可供大家自由复用的图。

Google 本周发布了《The New SDLC With Vibe Coding》。这份白皮书由我与 Shubham Saboo、Sokratis Kartakis 共同撰写，也是一个短篇系列的第一篇。

这是一份面向初学者的白皮书，因此前几页介绍了一些基础概念：什么是 Agent、“vibe coding”是什么意思，以及为什么开发者的工作正在从编写代码转向评判代码。如果你一直在读这个博客，这些内容你应该已经了解了。我会跳过这些基础知识，直接聊聊我认为值得你花时间关注的部分，并摘出其中六张图。你可以在任何需要的地方复用这些图。

Agent 是模型加 Harness

白皮书中有一个我反复想到的表述：Agent 是模型加 Harness。

模型只是其中一项输入。除此之外的一切都属于 Harness：指令和规则文件、工具和 MCP server、Agent 运行所在的 sandbox、负责生成 sub-agent 并在不同模型之间路由的编排逻辑、在预设节点运行确定性代码的 hook，以及帮助你发现 Agent 何时开始偏离目标的可观测性系统。白皮书给出的粗略比例是：模型占 10%，Harness 占 90%。这个数字听起来很高，直到你亲自花上一周时间调试一个 Agent。

模型是发动机。Harness 则是汽车、道路和交通法规。

一些公开数据让这个观点更加具体。在 Terminal Bench 2.0 上，有一个团队仅仅修改了 Harness，就让一款 coding agent 从 30 名开外进入前 5，而底层使用的仍然是同一个模型。LangChain 的另一项实验则在固定模型不变的情况下，只修改模型周围的 system prompt、工具和 middleware，便在同一 benchmark 上提高了 13.7 分。两项实验都没有改动模型本身。

因此，当 Agent 做出蠢事时，我已经学会先调试 Harness。通常是缺少某个工具、我写的规则过于宽松、忘记添加某项 guardrail，或者 context window 里塞满了垃圾信息。大多数 Agent 故障其实都是配置故障。我觉得这很令人鼓舞，因为配置是我今天就能修复的部分，不必等待更好的模型。反正底层模型迟早也会被替换，而 Harness 会继续保留下来。我曾在讨论 harness engineering 和 factory model 的文章中更详细地写过这个问题。

Context Engineering 决定了你的账单

如果说 Harness 是整个系统，那么 context engineering 就是其中最重要的调节旋钮。白皮书把 Agent 的 context 分为六类：指令、知识、记忆、示例、工具和 guardrail。真正有意思、也会直接反映在账单上的决定，是哪些内容应该放进静态 context，哪些应该放进动态 context。

静态 context 会在每一轮都被加载，因此可靠，但成本高昂。动态 context 则按需加载，所以你只需要为当前任务真正需要的内容付费。

静态 context 每一轮都会加载：system instruction、规则文件（AGENTS.md、CLAUDE.md、GEMINI.md）、全局记忆和核心 guardrail。它很可靠，同时也很昂贵，因为每一次调用你都要为它付费。动态 context 则按需加载：在任务匹配时触发的 skill、工具返回的结果，以及通过 RAG 获取的文档。对于给定任务，你只需要为它实际涉及的部分付费。

如果平衡过度偏向一边，你会浪费 token，并让真正重要的信号淹没在噪声中；如果过度偏向另一边，Agent 又会忘记那些确保其安全运行的规则。白皮书的建议是把这条边界视为真正的架构决策——通过 pull request 评审，并像代码一样进行版本管理。我也认同这个建议。

让动态 context 得以规模化的关键，是采用具有渐进式披露机制的 Agent Skills。Agent 在启动时只看到少量 metadata；当任务匹配时，再加载完整指令；只有真正需要时，才获取体量较大的参考资料。正因如此，一个 Agent 可以携带几十项 skill，却只需为当前实际使用的那一项付费。

Verification 是 Vibe Coding 与工程之间的分界线

使用同一个 Agent，你可以处在从 vibe coding 到 agentic engineering 这条光谱上的任何位置。最终决定你落在哪个位置的是 verification。

这条光谱上的正确位置取决于任务的风险。真正的能力，是知道应该为每项任务把界线画在哪里。

这里有两种机制。测试覆盖确定性的部分：给定这个输入，就应该得到那个输出。Eval 则覆盖那些并不确定的部分，而白皮书对 eval 的划分方式让我觉得很实用。输出评估会检查最终结果是否正确；轨迹评估则会检查 Agent 为得到结果所采用的路径——包括工具调用和推理过程——是否合理。两者都需要。一个看起来正确、却跳过了必要检查的答案，比一个明显错误的答案更加危险。

如果只能从白皮书中挑一句话交给管理者，那就是：以 eval 为标准，而不是以 demo 为标准。Demo 只能证明 Agent 曾经成功工作过一次。具备真正评分标准的 eval suite，才能证明它可以可靠地工作。我一直在强调这个观点，agentic code review 也是如此。

各个阶段究竟发生了怎样的变化

AI 压缩了软件生命周期，但这种压缩并不均匀，而这种不均匀性正是整个故事的关键。实现阶段从几周缩短到几小时。需求、架构和 verification 依然缓慢，因为这些阶段需要人的判断。因此，规格说明的质量成为新的瓶颈，而 verification 则被前移到了流程中段。

阶段还是那些阶段，但瓶颈不同了，各阶段所占的比例也不同了。

需求不再是一份在团队之间转交的文档，而变成了一场对话：它会同时产出规格说明和第一个原型。Agent 可以根据 brief 起草用户故事、找出边缘情况，并在几分钟内把一段描述转化为可运行的东西。

架构是最顽固地需要人类参与的阶段。诸如一致性与可用性之间的取舍，依赖模型无法完整了解的业务背景。开发者的工作变成做出并记录结构性决策，然后由 Agent 负责实现。

实现阶段既集中了收益，也集中了注意事项。调查显示，生产力提升幅度在 25% 到 39% 之间。METR 的一项研究则发现，如果把检查和修复所花费的时间计算在内，经验丰富的开发者在某些任务上的速度反而下降了 19%。两者都是真的。最诚实的总结是：AI 正在把实现工作从编写代码转变为审查代码。

测试和 QA 的方式被彻底颠倒了。测试和 eval 成为你告诉 Agent“什么才算正确”的主要方式，并被接入一个循环：对 benchmark 运行测试、对失败案例进行聚类、修复导致这些失败的 prompt 或工具、通过 regression suite 检查修复结果，再到生产环境中监控新的失败。

维护是我认为最被低估的环节。过去有些代码因为只有原作者才理解，被认为“风险太高，不能碰”；现在，Agent 可以阅读、重构这些代码，并对其进行现代化改造。那些因为枯燥且风险高而一直没有开展的迁移和弃用清理工作，也开始真正发生。

这一切的上限依然受制于“80% 问题”：Agent 可以迅速完成一个功能最初的 80%，但剩下的 20%——边缘情况和系统之间的接缝——仍然需要模型通常并不具备的 context。

经济账：Context 与路由都是财务杠杆

对管理者来说，真正重要的数字不是开发速度，而是总体拥有成本。在 AI 时代，它会以一种颠覆传统成本直觉的方式发生分化。

越过成本交叉点之后，vibe coding 开发每项功能的成本会高出 3 到 10 倍。代码需要存续多久，决定了你是否会到达这个交叉点。

Vibe coding 的前期成本低，运行成本却很高。启动时几乎不需要投入什么：一个订阅，加上一些 prompt。但之后你就要开始付账。把缺乏结构的文件扔给模型，再要求它修复自己犯下的错误，会消耗大量 token；几个月后，有人不得不对这些临时拼凑的代码进行逆向理解，由此产生维护税；快速生成代码制造安全漏洞的速度，几乎和它生成新功能一样快，因此还要承担安全清理成本。Agentic engineering 则正好相反：前期投入更多——schema、测试和结构化 context——但此后每项功能的成本更低。

“越过交叉点后，vibe coding 开发每项功能的成本会高出 3 到 10 倍”只是一个说明性数字，并不是经过测量得出的固定常数。我真正希望开发者理解的是，context engineering 和模型路由不仅是技术杠杆，也是财务杠杆。你不能在每个 prompt 中都塞入一个包含 100,000 token 的代码仓库，然后还指望它能够规模化。把困难的推理任务路由给大模型，把常规工作、测试生成、代码审查和 CI 检查交给便宜的小模型。质量可以保持稳定，账单则会下降。这就是我所说的 orchestration tax 在成本层面的体现。

原型正在变成生产环境中的 Agent

这是白皮书中我最密切关注的部分。同一套能够生成一次性脚本的终端工作流，现在也可以在同一个地方生成生产级 Agent，而且通常只需与你原本就在使用的 coding agent 对话。

过去，构建、评估和部署一个具备持久化记忆、范围受限的权限、eval 覆盖和可观测性的真正 Agent，需要一套独立的技术栈和一个独立岗位。现在，这一切都被折叠进你已经在运行的开发循环中。Google 的 Agents CLI 正是围绕这一理念构建的。完成一次性安装后，你的 coding agent 就会获得覆盖整个生命周期的 skill，而你只需要使用自然语言驱动它：

# one-time setup
uvx google-agents-cli setup

# then, in your coding agent:
> Build a support agent that answers questions from our docs.
> Evaluate it on the FAQ dataset.
> Deploy it to Agent Engine.

在这一条指令背后，它会搭建项目脚手架、编写代码、生成 eval set、运行评估、部署到托管 runtime，并向你报告结果。昨天还在你笔记本电脑上运行的原型，今天就能成为服务真实用户的生产级 Agent，而且无须重写。Agent 之间的协作基于开放标准运行：使用 MCP 调用工具，使用 A2A 把工作移交给其他 Agent。

白皮书中有一项实验，我经常向别人提起。Anthropic 的一个团队让一组 Agent 在两周时间里用 Rust 构建出了一个可以正常工作的 C 编译器。在这个过程中，人类负责设定方向和进行审查，而不是亲自编写代码。这大致就是未来的发展形态。

在日常工作中，你会在白皮书所说的两种模式之间切换：conductor 和 orchestrator。Conductor 模式是实时的，发生在 IDE 中，一次处理一个按键操作，适合探索，也适合处理你还不熟悉的代码。Orchestrator 模式则是异步的：你把目标交给一个或多个 Agent，再审查它们返回的结果；它适合迁移、测试生成等规格定义清晰的工作。如今的工具已经可以同时支持这两种模式，有时你甚至会在同一个小时内来回切换。我认为，从 conductor 转向 orchestrator，首先是能力结构的转变，其次才是工具的转变。

给其他人看的那张图

还有最后一张图，但它不是给你看的，而是给那些你希望带上这趟旅程的人看的：比如仍然认为这只是高级自动补全的高管，或者还没有完成转变的同事。

每一代技术都保留了上一代已经具备的能力，同时提高了一名工程师所能完成工作的上限。

图中包含了一些采用率数据，通常足以结束“这东西现在到底是不是真的”这类争论。截至 2026 年初，85% 的专业开发者会经常使用 AI coding agent，51% 每天都会使用，大约 41% 的新代码由 AI 生成。

白皮书最后针对个人、管理者和组织给出了一组更完整的建议。我不会在这里逐条重复。

如果只能从中带走一句话，那就是：AI 会放大它所进入的工程文化，无论其中好的部分还是坏的部分。代码生成如今已经基本解决。剩下的工作是 specification、verification，以及把二者连接起来的系统。这才是我认为真正值得练好的能力。

完整白皮书就在这里。