ARTICLE · 1013076
AI 时代的软件生命周期:从写代码到做判断的范式转移
好文精选翻译，原文链接
https://addyosmani.com/blog/new-sdlc-vibe-coding/
这是一篇“第一天”性质的入门文档，所以前面的几页介绍的都是基础概念：什么是代理（Agent），“氛围编程”（Vibe Coding）是什么意思，为什么我们的工作正从“编写代码”转向“判断和评估代码”。如果你经常看addy osmani的博客，这些内容对你来说应该已经不陌生了。所以这部分会跳过，直接写那些我觉得值得你花时间看的内容，并从中提取了六张图表。这些图表你可以随意复用。
代理（Agent）等于模型加上适配框架（Harness）
这是论文里一个让我反复琢磨的框架性观点：一个代理，就是一个模型加上一个适配框架。
模型只是其中一部分输入。除此之外的所有东西都属于适配框架的范畴：包括各种指令和规则文件、用到的工具和 MCP 服务器（MCP，即模型上下文协议，是一种让 AI 代理可以调用外部工具的标准方式）、代理运行的沙箱环境、用来生成子代理并在不同模型之间进行路由调度的编排逻辑、在特定节点运行确定性代码的钩子程序，以及用于监控代理是否偏离预期行为的可观测性系统。论文里粗略地将其划分为 10% 是模型，90% 是适配框架。这个比例听起来可能有点夸张，但等你花上一周时间去调试一个代理之后，就会明白这并不夸张。
同心圆结构展示代理等于模型加上适配框架。中心是 LLM（大语言模型），外围是框架层（包括指令和规则文件、工具和 MCP 服务器、编排逻辑、护栏和钩子），再往外是开发者接口层（CLI/IDE 集成、会话记忆、评估与测试、可观测性与追踪），最外层是云基础设施层（托管运行时、部署配置、服务与扩缩容）。图注说明：模型大约占 10%，适配框架大约占 90%。 模型是引擎，而适配框架是汽车、道路和交通法规。
几个公开的数据可以让这个观点更具体。在 Terminal Bench 2.0 基准测试中，有一个团队只改了适配框架，完全没动底层的模型，就把一个编程代理的排名从 30 名开外提升到了前 5 名。LangChain 的另一个独立实验也表明，只修改固定模型的系统提示词、工具和中间件，就在同一个基准测试上提升了 13.7 分。这两个案例都没有改动模型本身。
所以，当代理做出一些愚蠢的举动时，我学到的经验是，首先应该去调试它的适配框架。通常问题出在缺少某个工具、我写得太宽松的规则、我忘记设置的护栏，或者塞满了无用信息的上下文窗口。大多数代理的失败，本质上都是配置层面的失败。我觉得这反而让人感到欣慰，因为配置是我今天就能修复的部分，不需要等一个更好的模型出来。反正，迟早会有新的模型替换掉适配框架下的旧模型。关于这个话题，我在适配框架工程和工厂模式这两篇文章里有更详细的阐述。
上下文工程（Context Engineering）是决定你账单金额的关键
如果说适配框架是整个系统，那么上下文工程就是其中最重要的调节旋钮。论文将代理的上下文分为六种类型：指令（Instructions）、知识（Knowledge）、记忆（Memory）、示例（Examples）、工具（Tools）和护栏（Guardrails）。其中最关键、也最直接影响你账单的决策，在于区分哪些内容应该放在静态上下文（Static Context）里，哪些应该放在动态上下文（Dynamic Context）里。
左侧是六种代理上下文类型（指令、知识、记忆、示例、工具、护栏），右侧映射到两个分类中。静态上下文每次交互都会加载，令牌成本高（包括系统指令、AGENTS.md 等规则文件、全局记忆、核心护栏）。动态上下文按任务按需加载，每轮令牌成本低（包括任务匹配时触发的代理技能、执行过程中检索到的工具结果、通过 RAG 检索到的文档）。图注说明：最好的系统会把这项决策当作头等的架构决策来对待，像代码一样进行评审和版本管理。静态上下文在每轮对话中都会加载，所以它很可靠，但也很昂贵。动态上下文是按需加载的，因此你只需要为当前任务实际用到的那部分付费。
静态上下文在每一轮交互中都会被加载：包括系统指令、规则文件（比如 AGENTS.md、CLAUDE.md、GEMINI.md）、全局记忆和核心护栏。它很可靠，但也很贵，因为每一次 API 调用你都得为它付费。动态上下文则是按需加载的：比如当某个任务匹配时触发的技能（Skill）、工具返回的结果、从 RAG中拉取的文档。你只需要为当前任务实际用到的那部分内容付费。
如果平衡没把握好，朝一个方向偏得太远，你就会烧掉大量Token，同时把真正有用的信号给淹没了。朝另一个方向偏得太远，代理又可能会忘记那些保证它安全运行的关键规则。论文给出的建议——我也是赞同的——是把静态和动态上下文的边界当作一个真正的架构决策来对待：它应该通过 Pull Request来审核，并且像代码一样进行版本管理。
让动态上下文能够规模化运作的关键在于“渐进式披露”（Progressive Disclosure）的代理技能。代理在启动时只看到一点元数据（即描述自身能力的基本信息），当某个任务匹配上时再加载完整的指令，并且只有在真正需要的时候才会拉取那些庞大的参考资料。这样一来，一个代理可以携带几十项技能，但仍然只需要为它当前正在使用的那一项技能付费。
验证（Verification）是区分氛围编程和工程实践的界限
你可以用同一个代理，在从“氛围编程”到“代理工程”（Agentic Engineering）的整个光谱上找到任意位置。而决定你最终落在哪里的，是验证方式。
一条横向光谱，从左端的红色区域的“氛围编程”（随意提示词、看起来能跑就行、一次性代码），经过中间的“结构化 AI 辅助”，到右端蓝色区域的“代理工程”（形式化规格说明、自动化评估、CI/CD 质量门禁、大规模生产系统）。图注说明：区别不在于是否使用 AI，而在于如何验证输出结果。在光谱上选择哪个位置，取决于任务的风险高低。真正的技能在于知道为每项任务把界限画在哪里。
这里涉及两种机制。测试（Test）覆盖的是确定性的部分：给定这个输入，就应该产生那个输出。评估（Eval）覆盖的是那些非确定性的部分，论文对它的划分方式我觉得很有用。输出评估（Output Evaluation）是问最终结果是否正确。轨迹评估（Trajectory Evaluation）则是问代理到达这个结果所经过的路径——即它调用了哪些工具、推理过程是否合理——是否经得起推敲。这两者你都需要。一个看起来答案正确但却跳过了必要检查的代理，比一个明显出错的代理更危险。
如果让我从论文里选一句话送给管理者，那就是这句：把标准定在评估（Eval）上，而不是定在演示（Demo）上。一个演示只能说明代理在某一次能正常工作。而一套带有真实评分标准的评估套件（Eval Suite）才能证明它能稳定可靠地工作。关于这个论点我一直在强调，可以参见代理式代码审查。
每个阶段实际上发生了怎样的变化
AI 压缩了软件生命周期，但压缩得并不均衡，而这种不均衡恰恰是关键所在。实现阶段从数周缩短到数小时。但需求阶段、架构阶段和验证阶段仍然很慢，因为它们本质上是需要人为判断的工作。因此，规格说明的质量成了新的瓶颈，而验证则被移到了流程的中间位置。
对比了传统的迭代式 SDLC（需求、设计、实现、测试、审核与部署、维护，按数周的迭代周期进行）和 AI 驱动的 SDLC（规格说明质量成为新瓶颈，实现阶段压缩到几分钟到几小时，新增了输出评估和轨迹评估步骤，对代理构建的内容及其构建过程进行验证，迭代周期为几分钟到几小时）。 同样的阶段，不同的瓶颈，不同的耗时比例。
分阶段来看：
• 需求阶段 ：需求不再是一份在团队之间传递的文档。它变成了一场对话，同时产出规格说明和第一个原型。代理可以根据一份简要说明起草用户故事，发现边缘情况，并把一段描述在几分钟内变成可运行的程序。 • 架构阶段 ：这是最顽固地需要人类参与的阶段。像“一致性”与“可用性”之间的权衡，取决于模型无法完全看到的业务上下文。开发者的工作变成了做出并记录那些结构性的决策，然后由代理去具体实现。 • 实现阶段 ：这里既是收益最大的地方，也是陷阱最多的地方。调查显示生产力提升了 25% 到 39%。METR 的一项研究发现，如果把检查和修复的时间也算进去，有经验开发者在某些任务上反而慢了 19%。这两种情况都是真实的。诚实地总结就是：AI 把实现阶段从“编写”变成了“审核”。 • 测试和质量保证阶段 ：这个阶段整个颠倒过来了。你的测试和评估（Eval）成了你告诉代理什么叫做“正确”的主要方式，它们被接入一个循环中：在基准测试上运行，对失败案例进行聚类分析，修复导致问题的提示词或工具，在回归测试套件中验证，然后监控生产环境是否有新的问题出现。 • 维护阶段 ：我认为这是最被低估的一个阶段。那些因为只有原作者才理解而被认为“风险太高不敢动”的代码，现在可以由代理来阅读、重构和现代化改造。那些因为既繁琐又高风险而一直被搁置的迁移工作和废弃代码清理工作，现在开始能够落地了。
所有这些的天花板仍然是80% 问题：代理能很快完成一个功能的前 80%，但剩下的最后 20%——即各种边缘情况和系统之间的衔接部分——仍然需要模型通常不具备的上下文信息。
经济学视角：上下文和路由是财务杠杆
对管理者来说真正重要的数字不是开发速度，而是总拥有成本（TCO）。AI 时代将总拥有成本进行了拆分，这种拆分方式颠覆了我们关于“哪个选项更便宜”的通常直觉。
一张展示随时间推移和功能交付数量的累积总拥有成本曲线图。“氛围编程”曲线以低资本支出和快速起步开始，随后因“提示词税”、令牌消耗、维护税、安全风险和上下文崩溃而急剧上升。“代理工程”曲线以较高的资本支出起步，但随着回归问题被有效捕获，边际运营成本逐渐走低并趋于平缓。两条曲线在某一点交叉，之后“氛围编程”每个功能的成本开始是“代理工程”的 3 到 10 倍。 过了交叉点之后，氛围编程每个功能的成本会高出 3 到 10 倍。代码需要存活多长时间，决定了你是否能到达那个交叉点。
氛围编程是前期便宜、后期昂贵。你几乎不用花什么钱就能开始：一个订阅费加一些提示词。但之后你要付出更多。因为把无结构的文件一股脑扔给模型并让它自己修复错误，会产生大量的令牌消耗。当几个月后有人需要逆向工程那些随意写出的代码时，就产生了维护税。安全清理成本也会很高，因为快速生成代码在产生功能的同时，产生漏洞的速度也差不多快。代理工程则正好相反：前期投入更多（设计模式、测试、结构化上下文），但之后每个功能的增量成本更低。
“氛围编程每个功能的成本会高出 3 到 10 倍”这个交叉点是一个示意性的说法，并非一个精确测定的常数。我希望开发者们能从中领会的关键是：上下文工程和模型路由不仅是技术杠杆，更是财务杠杆。你不能把一个包含 10 万令牌的代码仓库塞进每一次提示词里还指望它能规模化运作。把困难的推理任务路由给大模型，把常规工作——比如测试生成、代码审查、CI 检查——路由给便宜的小模型。这样质量能保持住，账单也能降下来。这就是我所说的编排税在财务层面的体现。
原型正在变成生产环境中的代理
这是论文中我最关注的部分。以前用来生成一次性脚本的同一个终端工作流，现在可以在同样的地方生成一个生产环境可用的代理，通常只需要和你已经在使用的编程代理对话就能完成。
构建、评估和部署一个真正的代理——带有持久记忆、细粒度权限、评估覆盖和可观测性——曾经需要一套独立的工具栈和一个专门的岗位。现在它被整合到了你已经在运行的开发循环里。谷歌的 Agents CLI 就是围绕这个理念构建的。一次性安装之后，你的编程代理就能获得覆盖整个生命周期的技能，你可以用自然语言来驱动它：
# 一次性设置uvx google-agents-cli setup# 然后，在你的编程代理中：> 构建一个支持代理，用来回答我们文档中的问题。> 在 FAQ 数据集上评估它。> 将它部署到 Agent Engine。在这一个指令背后，它会自动搭建项目脚手架、编写代码、生成评估集、运行评估、部署到托管运行环境，然后给你反馈结果。昨天你在笔记本电脑上制作的原型，今天就成了服务用户的正式生产代理，中间不需要任何重写。代理之间的协调基于开放标准：MCP 用于工具调用，A2A（Agent-to-Agent，即代理间通信协议）用于将任务交给其他代理处理。
论文里有一个我经常跟人提到的实验。Anthropic 的一个团队让一组代理在两周内用 Rust 语言构建了一个可以工作的 C 语言编译器，人类在其中只负责设定方向和进行审核，而不是亲自编写代码。这大致就是未来发展的方向。
在日常工作中，你会在论文所称的 指挥家（Conductor） 和 编排者（Orchestrator） 两种模式之间切换。指挥家模式是实时的、在 IDE 里面进行的，逐键操作，适合探索性的工作或者处理你不熟悉的代码。编排者模式是异步的：你把一个目标交给一个或多个代理，然后审核它们返回的结果，适合像迁移或测试生成这类已经明确定义的工作。现在的工具同时支持这两种模式，有时候甚至在同一个小时内交替使用。我认为从指挥家到编排者的转变，首先是一种技能上的转变，然后才是工具上的转变。
给其他所有人看的图表
还有一张图，这张不是给你看的。它是给你想要带动起来的人看的：那位仍然觉得这只是高级自动补全功能的高管，那位还没有迈出这一步的同事。
一条时间线，从“自动补全”（大约 2021 年）开始，经过“内联代码建议”、“基于聊天的生成”，到“编程代理”和“自主代理”（大约 2025-26 年）。横轴从左边的“语法”和“更多人力投入”到右边的“意图”和“更多机器自主性”。 每一代都继承了前一代的能力，并不断提高单个工程师所能达到的上限。
这张图上有一些采用率数据，往往能终结“这到底是不是真的”这种争论。截至 2026 年初，85% 的专业开发者正在使用 AI 编程代理，51% 每天都在使用，大约 41% 的新代码是由 AI 生成的。
从哪里开始
论文的结尾部分为个人、领导者和组织提供了一系列更详细的建议。我就不在这里全部重复了。
如果要从这篇论文中提炼出一句话，那就是：AI 会放大它所在的任何工程文化——无论是好的部分还是坏的部分。代码生成现在已经基本解决了。剩下的工作是规格说明和验证，以及把这一切维系在一起的系统。这才是你应该去擅长的部分。