The following article originally appeared on Addy Osmani’s blog and is being republished here with the author’s permission.本文最初发布于 Addy Osmani 的博客，经作者授权转载。
I cowrote a Google whitepaper about how AI is changing the software lifecycle. I’m not going to summarize the whole thing. Instead, here are the handful of ideas in it I think actually matter, plus six figures you’re welcome to reuse.我与人合写了一份 Google 白皮书，讲 AI 如何改变软件生命周期。我不打算全盘复述。这里挑出我认为真正要紧的几个观点，还有六张图，你们拿去用。
Google published “The New SDLC With Vibe Coding” this week. I cowrote it with Shubham Saboo and Sokratis Kartakis, and it’s the first in a short series.Google 本周发布了《基于“氛围编码”（Vibe Coding）的新 SDLC》。我和 Shubham Saboo、Sokratis Kartakis 合写了这份报告，这是系列文章的第一篇。
It’s a Day 1 paper, so the early pages cover the basics: what an agent is, what “vibe coding” means, and why the job is moving from writing code to judging it. If you read this blog, you already have all of that. I’m going to skip it and write about the parts I think are worth your time, with six of the figures pulled out. Reuse the figures wherever you like.这是一篇入门级的报告，前几页讲基础：什么是 Agent（智能体），什么是“氛围编码”，为什么工作重心从写代码变成了评判代码。读过我博客的人，这些都懂。我跳过这些，只写我觉得值得花时间的部分，并附上六张图。
An agent is a model plus a harnessAgent 就是模型加外挂
Here’s the framing from the paper that I keep coming back to: An agent is a model plus a harness.报告里有个框架我反复琢磨：Agent 等于模型加外挂（Harness）。
The model is one input. Everything else is the harness: the instructions and rule files, the tools and MCP servers, the sandboxes it runs in, the orchestration logic that spawns subagents and routes between models, the hooks that run deterministic code at set points, and the observability that tells you when it’s drifting. The paper’s rough split is 10% model, 90% harness. That sounds high until you’ve spent a week debugging one.模型是一个输入。剩下的全是外挂：指令和规则文件、工具和 MCP 服务器、运行环境沙箱、负责生成子 Agent 并进行路由的编排逻辑、在特定点运行确定性代码的钩子，以及监控漂移的观测系统。报告里大体分了分：10% 是模型，90% 是外挂。没调过一周外挂的人，会觉得这比例太高了。
A couple of public numbers make this concrete. On Terminal Bench 2.0, one team moved a coding agent from outside the top 30 into the top 5 by changing only the harness, with the same model underneath. A separate experiment at LangChain added 13.7 points on the same benchmark by changing just the system prompt, tools, and middleware around a fixed model. Neither touched the model.几个公开数据能说明这一点。在 Terminal Bench 2.0 上，有个团队没换模型，只改了外挂，就把一个编码 Agent 从 30 名开外提到了前 5。LangChain 的另一个实验里，在模型固定的情况下，只改了系统提示词、工具和中间件，分数就涨了 13.7 点。谁都没动模型。
So when an agent does something dumb, I’ve learned to debug the harness first. Usually it’s a missing tool, a rule I wrote too loosely, a guardrail I forgot, or a context window full of junk. Most agent failures are configuration failures. I find that encouraging, because configuration is the part I can fix today, without waiting for a better model. The model will get swapped out under the harness sooner or later anyway. I’ve written this up at more length as harness engineering and the factory model.所以 Agent 犯傻时，我先调外挂。通常是工具少了，规则写得太松，忘了加防护栏，或者上下文里塞满了垃圾。大部分 Agent 失败都是配置失败。这倒让人宽心，因为配置是我现在就能改的，不用等更好的模型。反正模型迟早要换掉。我写过一篇《外挂工程与工厂模型》，里面说得更细。
Context engineering is the part that decides your bill上下文工程决定了你的账单
If the harness is the system, context engineering is the most important knob inside it. The paper sorts agent context into six types: instructions, knowledge, memory, examples, tools and guardrails. The interesting decision, the one that shows up on your bill, is what goes in static versus dynamic context.如果说外挂是系统，那上下文工程就是里面最重要的旋钮。报告把 Agent 上下文分为六种：指令、知识、记忆、示例、工具和防护栏。真正决定账单的决策是：哪些放静态上下文，哪些放动态。
Static context is loaded every turn: system instructions, rule files (AGENTS.md, CLAUDE.md, GEMINI.md), global memory, core guardrails. It’s reliable, and it’s expensive, because you pay for it on every single call. Dynamic context is loaded on demand: skills that fire when a task matches, tool results, or documents pulled from RAG. You only pay for the bits a given task touches.静态上下文每次都加载：系统指令、规则文件（AGENTS.md, CLAUDE.md, GEMINI.md）、全局记忆、核心防护栏。这东西稳，但贵，因为每次调用都要付钱。动态上下文按需加载：任务匹配时触发的技能、工具结果，或者从 RAG 里拉取的文档。只为任务用到的那部分买单。
Get that balance wrong in one direction and you burn tokens and bury the signal. Wrong in the other and the agent forgets the rules that keep it safe. The paper’s advice, which I agree with, is to treat the boundary as a real architectural decision: reviewed in a pull request, versioned like code.平衡没掌握好，要么烧 Token，要么淹没了有效信息。反过来，Agent 就会忘了安全规则。报告建议——我也赞同——把这个边界当成架构决策来做：要经 Pull Request 评审，要像代码一样版本化。
The trick that makes dynamic context scale is agent skills with progressive disclosure. The agent sees a little metadata at startup, loads the full instructions when a task matches, and only pulls in the heavy reference material when it actually needs it. That’s how one agent can carry dozens of skills and still only pay for the one it’s using.让动态上下文能扩展的窍门是“渐进式披露”。Agent 启动时只看一点元数据，任务匹配时才加载完整指令，真正需要时才拉取繁重的参考资料。这样 Agent 就能携带几十种技能，却只为用到的那个付钱。
Verification is the line between vibe coding and engineering验证是“氛围编码”与工程化的分界线
You can sit anywhere on the spectrum from vibe coding to agentic engineering with the same agent. The thing that decides where you land is verification.同一个 Agent，既可以做“氛围编码”，也可以做“智能体工程”。决定你落在哪个位置的，是验证。
There are two mechanisms. Tests cover the deterministic parts: this input, that output. Evals cover the parts that aren’t deterministic, and the paper splits them in a way I found useful. Output evaluation asks whether the final result is correct. Trajectory evaluation asks whether the path it took to get there, the tool calls and the reasoning, was sound. You want both. An answer that looks right but skipped its checks is more dangerous than one that’s obviously broken.有两种机制。测试覆盖确定性部分：输入什么，输出什么。评估（Eval）覆盖非确定性部分，报告里的分法很管用。输出评估看最终结果对不对。轨迹评估看路径对不对，比如工具调用和推理过程。两者都要。一个答案看着对，但跳过了检查，比明显出错的更危险。
If I had to hand a leader one line from the paper, it’s this: Set the bar at the eval, not the demo. A demo shows an agent can work once. An eval suite with a real rubric shows it works reliably. I keep making this argument; see “Agentic Code Review.”如果只能给领导留一句话，就是：以评估为准，别看演示。演示只能说明 Agent 能跑一次。有一套真实准则的评估套件，才能说明它能稳定工作。我一直强调这点，参考《智能体代码审查》。
How each phase actually changes各个阶段到底怎么变
AI compresses the lifecycle, but unevenly, and the unevenness is the whole story. Implementation drops from weeks to hours. Requirements, architecture, and verification stay slow because they’re judgment work. So specification quality becomes the bottleneck, and verification moves to the middle.AI 压缩了生命周期，但不均匀，这不均匀才是关键。实现从几周缩短到几小时。需求、架构和验证依然慢，因为这些是判断工作。所以规格说明书的质量成了瓶颈，验证环节挪到了中间。
Phase by phase:分阶段来看：
Requirements stop being a document you hand between teams. They become a conversation that produces a spec and a first prototype at the same time. The agent drafts user stories from a brief, surfaces edge cases, and turns a description into something that runs in minutes.需求不再是团队间传阅的文档。它变成了一场对话，同时产出规格说明和原型。Agent 根据简报起草用户故事，找出边缘情况，几分钟内就把描述变成可运行的东西。
Architecture is the most stubbornly human phase. Trade-offs like consistency versus availability depend on business context the model can’t fully see. The developer’s job becomes making and documenting the structural calls the agent then implements.架构是最顽固的人类环节。一致性还是可用性，这种权衡依赖于模型无法完全感知的业务背景。开发者的工作变成了做出结构性决策并记录下来，由 Agent 去实现。
Implementation is where the gains and the caveats both live. Surveys put the productivity gain at 25% to 39%. A METR study found experienced developers going 19% slower on some tasks once you count the time spent checking and fixing. Both are true. The honest summary is that AI turns implementation from writing into reviewing.实现环节既有收益也有坑。调查显示生产力提升了 25% 到 39%。METR 的研究发现，算上检查和修复的时间，资深开发者在某些任务上反而慢了 19%。两者都对。老实说，AI 把实现从“写”变成了“审”。
Testing and QA flips around. Your tests and evals become the main way you tell the agent what “correct” means, wired into a loop: run against a benchmark, cluster the failures, fix the prompt or tool that caused them, check against a regression suite, and watch production for new ones.测试和 QA 翻转了。测试和评估成了定义“正确”的主要方式，并接入循环：跑基准测试，归类失败原因，改提示词或工具，跑回归套件，再盯着线上看有没有新问题。
Maintenance is the one I think is most underrated. Code that was “too risky to touch” because only its authors understood it can now be read, refactored, and modernized by an agent. The migrations and deprecation cleanups that never happened because they were tedious and risky start happening.维护是被低估最多的环节。过去因为只有作者懂而“不敢动”的代码，现在 Agent 能读、能重构、能现代化。那些因为麻烦且风险大而一直没做的迁移和清理，现在能做了。
The ceiling on all of this is still the 80% problem: Agents get the first 80% of a feature fast, and the last 20%, the edge cases and the seams between systems, still need context the models usually don’t have.所有这些的上限依然是“80% 问题”：Agent 能快速完成功能的 80%，剩下的 20%——边缘情况和系统间的缝隙——依然需要模型通常不具备的上下文。
The economics: Context and routing are financial levers经济账：上下文和路由是财务杠杆
The number that matters to a leader isn’t velocity; it’s total cost of ownership. The AI era splits it in a way that flips the usual intuition about which option is cheap.对领导来说，重要的不是速度，是总拥有成本。AI 时代把成本拆分了，颠覆了关于什么才便宜的直觉。
Vibe coding is cheap up front and expensive to run. You pay almost nothing to start: a subscription and some prompts. Then you pay later. Token burn, from throwing unstructured files at the model and asking it to fix its own mistakes. A maintenance tax, when someone has to reverse-engineer the ad hoc code months later. Security cleanup, because fast generation produces vulnerabilities about as fast as it produces features. Agentic engineering flips that: more up front (schemas, tests, structured context), less per feature after.氛围编码前期便宜，运行起来贵。开始几乎不用花钱：订阅费加点提示词。后面就得付钱了。Token 烧得快，因为把非结构化文件扔给模型让它修自己的错。还有维护税，几个月后别人得去逆向工程那些临时代码。还有安全清理，因为生成快，漏洞产生得也快。智能体工程反过来：前期多投入（Schema、测试、结构化上下文），后期每个功能的成本就低。
The “vibe coding costs 3x to 10x more per feature” crossover is illustrative, not a measured constant. The part I want developers to take away is that context engineering and model routing are financial levers, not just technical ones. You can’t pass a 100,000-token repo into every prompt and expect it to scale. Route the hard reasoning to a big model and the routine work, test generation, code review, and CI checks, to a small cheap one. The quality holds and the bill comes down. That’s the money side of what I’ve called the orchestration tax.“高出 3 到 10 倍”只是个示意。开发者要记住的是，上下文工程和模型路由是财务杠杆，不只是技术手段。别指望把 10 万 Token 的仓库塞进每个提示词还能扩展。把复杂的推理路由给大模型，把日常工作——测试生成、代码审查、CI 检查——交给便宜的小模型。质量稳住了，账单也下来了。这就是我所说的“编排税”的钱袋子。
The prototype is becoming the production agent原型正在变成生产级 Agent
This is the part of the paper I’m watching most closely. The same terminal workflow that spits out a throwaway script can now produce a production agent, in the same place, often by talking to the coding agent you were already using.这是报告里我盯得最紧的部分。同一个终端工作流，过去只能吐出一次性脚本，现在能直接产出生产级 Agent，在同一个地方，通常就是跟你正在用的编码 Agent 对话。
Building, evaluating, and deploying a real agent, with persistent memory, scoped permissions, eval coverage, and observability, used to be a separate stack and a separate job. Now it folds into the loop you already run. Google’s Agents CLI is built around this. After a one-time install, your coding agent picks up skills for the whole lifecycle, and you drive it in plain language.构建、评估、部署一个带持久化记忆、权限控制、评估覆盖和可观测性的 Agent，过去是独立的栈和工作。现在它融入了你现有的循环。Google 的 Agents CLI 就是这么做的。安装一次，你的编码 Agent 就学会了全生命周期的技能，你用自然语言指挥它。
# 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.Behind that one instruction, it scaffolds the project, writes the code, generates an eval set, runs it, deploys to a managed runtime, and reports back. The prototype from your laptop yesterday becomes the production agent serving users today, with no rewrite. Coordination between agents runs on open standards: MCP for tools, A2A for handing work to other agents.在那一行指令背后，它搭建项目、写代码、生成评估集、运行、部署到托管环境并反馈结果。昨天你在笔记本上做的原型，今天就是服务用户的生产级 Agent，无需重写。Agent 间的协作基于开放标准：MCP 做工具，A2A 用于任务移交。
There’s one experiment in the paper I keep mentioning to people. An Anthropic team had a group of agents build a working C compiler in Rust over two weeks, with humans setting direction and reviewing rather than writing the code. That’s roughly the shape of where this is heading.报告里有个实验我常跟人提。Anthropic 的团队让一组 Agent 在两周内用 Rust 写出了一个可用的 C 编译器，人类只负责指路和审查，不写代码。这差不多就是未来的方向。
Day to day you switch between two modes the paper calls the “conductor” and the “orchestrator.” The conductor is real-time and in the IDE, keystroke by keystroke, good for exploring and for code you don’t know yet. The orchestrator is async: You hand a goal to one or more agents and review what comes back—it’s good for well-specified work like migrations or test generation. The tooling does both now, sometimes in the same hour. I think the move from conductor to orchestrator is a skills shift before it’s a tooling one.日常工作中，你在报告所说的“指挥家”和“编排者”两种模式间切换。指挥家是实时的，在 IDE 里，敲一下键盘动一下，适合探索和你不懂的代码。编排者是异步的：你给一个或多个 Agent 一个目标，然后审查结果——适合迁移或测试生成这种明确的工作。现在的工具两者都能做，有时就在同一个小时里。我觉得从指挥家到编排者的转变，首先是技能的转变，其次才是工具的。
The figure for everyone else给其他人的图
One more figure, and this one isn’t for you. It’s for the people you’re trying to bring along: the exec who still thinks this is fancy autocomplete or the colleague who hasn’t made the jump.还有一张图，不是给你们的。是给那些你想拉一把的人：觉得这只是高级自动补全的高管，或者还没跟上来的同事。
It has the adoption numbers that tend to end the “Is this real yet?” argument. As of early 2026, 85% of professional developers use AI coding agents regularly, 51% use them daily, and roughly 41% of new code is AI-generated.这图里的采用率数据足以终结“这玩意儿真行吗”的争论。截至 2026 年初，85% 的专业开发者定期使用 AI 编码 Agent，51% 每天都在用，约 41% 的新代码由 AI 生成。
Where to start从哪开始
The paper closes with a longer set of recommendations for individuals, leaders and organizations. I won’t repeat them all here.报告结尾给个人、领导和组织提了一堆建议。我不在这儿重复了。
If there’s one line to take from it, it’s that AI amplifies whatever engineering culture it lands in, the good parts and the bad parts both. Generation is mostly solved now. The work that’s left is specification and verification, and the systems that hold them together. That’s the part I’d get good at.如果只能带走一句话，那就是：AI 会放大它所处的工程文化，好的坏的都放大。生成代码现在基本解决了。剩下的工作是规格定义、验证，以及把它们串起来的系统。这才是你应该练就的本事。
You can read the full paper here.点击此处阅读完整报告。
Enjoyed this? Go deeper in Beyond Vibe Coding, my O’Reilly book on AI-assisted and agentic engineering: specs, harnesses, evals, context, and shipping production-grade software.觉得有收获？可以深入读读我的 O'Reilly 新书《超越氛围编码：AI 辅助与智能体工程》，讲规格、外挂、评估、上下文和生产级软件交付。
