中文精炼导读
核心观点
- Addy Osmani 与 Shubham Saboo、Sokratis Kartakis 合写了 Google 白皮书《The New SDLC With Vibe Coding》（系列第一篇），本文是他提炼的"真正重要的几个想法"加六张可复用的配图——AI 压缩了软件生命周期，但压缩得不均匀，这种不均匀才是全部故事。
- 核心框架："agent 是模型 + harness"——模型只是一个输入，其余都是 harness（指令与规则文件、工具与 MCP 服务器、沙箱、编排逻辑、钩子、可观测性）；粗略比例是 10% 模型、90% harness。实证数字：Terminal Bench 2.0 上某团队只改 harness 就把编码 agent 从 30 名外送进前 5（同一模型），LangChain 一个实验只改固定模型周围的系统 prompt/工具/中间件就加了 13.7 分——所以"agent 做蠢事时先调试 harness，多数 agent 失败是配置失败"。
- 上下文工程是决定账单的旋钮：上下文分六类（指令、知识、记忆、示例、工具、护栏），关键决策是"什么进静态上下文（每轮都加载、可靠但昂贵）vs 动态上下文（按需加载、只为任务所需付费）"；平衡失衡要么烧 token 埋没信号、要么让 agent 忘记保命规则；边界应被当作真正的架构决策（进 PR 评审、像代码一样版本化）；让动态上下文可扩展的技巧是"带渐进披露的 Agent Skills"——启动时只看元数据、任务匹配才加载完整指令、真正需要时才拉入重型参考材料。
- 验证是"vibe coding 与工程之间的分界线"：同一 agent 可以落在从 vibe coding 到 agentic engineering 光谱的任何位置，决定落点的是验证；两个机制——测试覆盖确定性部分、evals 覆盖非确定性部分，其中"输出评估"问最终结果是否正确、"轨迹评估"问到达结果的路径（工具调用与推理）是否可靠，两者都要；给领导者的一句话是"把标杆定在 eval，而不是 demo"。
- 各阶段变化：需求从"团队之间传递的文档"变成"同时产出规格与首版原型的对话"；架构是最顽固地需要人的阶段（一致性 vs 可用性这类权衡依赖模型看不见的业务上下文）；实现把"写作"变成"评审"（调研给 25-39% 生产率增益，但 METR 研究发现经验开发者计入检查与修复时间后部分任务慢 19%——两者都真）；测试 QA 翻转为"用测试与 evals 告诉 agent'正确'是什么、接进闭环"；维护最被低估（"只有作者能懂所以不敢碰"的代码可以被 agent 阅读、重构与现代化，从未发生的迁移与弃用清理开始发生）。
内容精讲
文章开门见山：Google 发布了《The New SDLC With Vibe Coding》，作者不打算总结全文，而是挑出"我认为真正重要的几个想法"，外加六张可复用的图。白皮书是 Day 1 论文，早期页面覆盖基础（agent 是什么、vibe coding 是什么意思、为什么工作从写代码转向评判它）——这些他的博客读者早就有了，所以跳过。
第一个重要想法是"agent 是模型 + harness"。模型是一个输入；其余一切都是 harness：指令与规则文件、工具与 MCP 服务器、运行的沙箱、派生子代理并在模型间路由的编排逻辑、在设定点运行确定性代码的钩子、告诉你何时漂移的可观测性。论文的粗略划分是 10% 模型、90% harness——这听起来偏高，直到你花一周调试一个 agent。模型是引擎，harness 是车、路与交通法规。几个公开数字让它具体化：Terminal Bench 2.0 上，一个团队把编码 agent 从 30 名之外带到前 5，只改了 harness、底层模型没变；LangChain 的一个实验只改固定模型周围的系统 prompt、工具与中间件，就在同一基准上加了 13.7 分——两者都没碰模型。所以当 agent 做蠢事时，作者学会"先调试 harness"：通常是缺工具、规则写得太松、忘了护栏、或上下文窗口塞满垃圾。多数 agent 失败是配置失败——这令人鼓舞，因为配置是今天就能修的部分、不用等更好的模型；而且模型迟早会被换掉，harness 底下换模型是常态。
第二个重要想法是"上下文工程是决定账单的旋钮"。如果 harness 是系统，上下文工程就是里面最重要的旋钮。论文把 agent 上下文分成六类：指令、知识、记忆、示例、工具、护栏。有趣的决策（出现在你账单上的那个）是"什么进静态 vs 动态上下文"。静态上下文每轮都加载：系统指令、规则文件（AGENTS.md、CLAUDE.md、GEMINI.md）、全局记忆、核心护栏——可靠但昂贵，因为每次调用都付钱；动态上下文按需加载：任务匹配时触发的技能、工具结果、从 RAG 拉取的文档——只为给定任务触碰到的部分付费。平衡搞错一个方向就烧 token 并埋没信号，搞错另一个方向 agent 就忘记保它安全的规则。论文的建议（作者认同）是把这条边界当作真正的架构决策：在 PR 里评审、像代码一样版本化。让动态上下文可扩展的技巧是"带渐进披露的 Agent Skills"：agent 启动时看到一点元数据、任务匹配时加载完整指令、真正需要时才拉入重型参考材料——这样单个 agent 能携带几十个技能、却只为正在用的那个付费。
第三个重要想法是"验证是 vibe coding 与工程之间的分界线"。用同一个 agent 你可以坐在从 vibe coding 到 agentic engineering 光谱的任何位置，决定落点的是验证；正确的落点取决于利害关系，技能在于为每个任务知道线画在哪。两个机制：测试覆盖确定性部分（这个输入、那个输出）；evals 覆盖非确定性部分——论文把它们拆成两种：输出评估问最终结果是否正确，轨迹评估问到达那里的路径（工具调用与推理）是否可靠。两者都要：一个看起来正确但跳过了检查的答案，比一个明显坏掉的更危险。如果只能给领导者一句话，就是"把标杆定在 eval，而不是 demo"——demo 证明 agent 能工作一次，带真正 rubric 的 eval 套件证明它能可靠工作。
第四个重要想法是"每个阶段如何真正变化"。AI 压缩生命周期但不均匀，不均匀是全部故事：实现从数周降到数小时；需求、架构与验证保持缓慢，因为它们是判断性工作——于是规格质量成为瓶颈、验证移到中段。同样的阶段、不同的瓶颈、不同的比例。逐阶段看：需求不再是团队之间传递的文档，而变成"同时产出规格与首版原型的对话"——agent 从简报起草用户故事、暴露边缘情况、把描述变成几分钟内可运行的东西；架构是最顽固地需要人的阶段——一致性 vs 可用性这类权衡依赖模型看不全的业务上下文，开发者的工作变成"做出并记录结构性的调用、再由 agent 实现"；实现是增益与警示并存的地方——调研给出 25-39% 的生产率增益，但 METR 研究发现经验开发者在计入检查与修复时间后部分任务反而慢 19%，两者都真，诚实的总结是"AI 把实现从写作变成评审"；测试与 QA 翻转——你的测试与 evals 成为告诉 agent"正确"是什么的主要方式，接进循环：对基准跑、聚类失败、修复导致它们的 prompt 或工具、对回归套件检查、盯生产找新的；维护是最被低估的——"只有作者能懂所以太冒险不敢碰"的代码现在可以被 agent 阅读、重构与现代化，那些因繁琐与高风险而从未发生的迁移与弃用清理开始发生。这一切的天花板仍是"80% 问题"：agent 快速拿到功能的前 80%，最后 20%（边缘情况与系统之间的接缝）仍需要模型通常没有的上下文。
第五个重要想法是"经济学：上下文与路由是财务杠杆"。领导者真正关心的数字不是速度而是总拥有成本（TCO）。AI 时代把它拆开的方式翻转了通常"哪个便宜"的直觉：越过交叉点后，vibe coding 每个功能要贵 3 到 10 倍。代码要活多久决定你是否能到达那里。Vibe coding 前期便宜、运行昂贵——开始时几乎不花钱（订阅加几个 prompt），之后付：token 燃烧（把非结构化文件丢给模型、让它修自己的错）、维护税（几个月后有人要逆向工程那些临时拼凑的代码）、安全清理（快速生成产生漏洞的速度与产生功能一样快）。Agentic engineering 翻转：前期更多（schemas、测试、结构化上下文）、之后每个功能更少。作者澄清"3-10 倍"是示意性的而非实测常数；真正想让开发者带走的教训是：上下文工程与模型路由是财务杠杆而不只是技术杠杆——你不能把 10 万 token 的仓库塞进每个 prompt 还指望扩展；把硬推理路由到大模型、把常规工作（测试生成、代码评审、CI 检查）路由到小便宜模型，质量保持、账单下降——这就是他所称"编排税"的金钱面。
第六个重要想法是"原型正在变成生产 agent"。这是作者最密切关注的论文部分：同一终端工作流（吐出一次性脚本的）现在能在同一处产出生产 agent，常常通过与你在用的编码 agent 对话实现。构建、评估并部署一个真正的 agent（带持久记忆、限定权限、eval 覆盖与可观测性）过去是单独的栈、单独的工作；现在它折叠进你已经在跑的循环。Google 的 Agents CLI 就围绕这个构建：一次性安装后，你的编码 agent 学会整个生命周期的技能，你用自然语言驱动它——`uvx google-agents-cli setup` 一次性设置，然后在编码 agent 里说"构建一个回答我们文档问题的支持 agent""在 FAQ 数据集上评估它""把它部署到 Agent Engine"；在这条指令背后它会搭好项目、写代码、生成 eval 集、运行、部署到托管运行时并回报。昨天笔记本上的原型变成今天服务用户的生产 agent，无需重写。
阅读价值
适合软件工程领导者、平台工程师与所有在用 AI 改造开发流程的人：这篇文章把 Google 白皮书的要点浓缩成"agent = 模型 + harness""上下文工程决定账单""验证是 vibe coding 与工程的分界线""各阶段如何不均匀地变化""上下文与路由是财务杠杆""原型变成生产 agent"六条，每条都有可复用的图与实证数据；对设计 AI 化的软件生命周期与理解其经济性很有价值。
本文为中文精炼导读,由 AI 基于原文整理,内容与图片版权归原作者所有。原文: https://addyosmani.com/blog/new-sdlc-vibe-coding/