从Vibe Coding到Agentic Engineering：SDLC正在被重写

十年前，如果你要写一个新功能，得一行一行敲语法、记括号位置、记分号，然后跑一下等报错告诉你哪里敲错了。

那个画面正在快速消失。

有一份 51 页的白皮书，名为"The New SDLC With Vibe Coding"，由 Addy Osmani、Shubham Saboo 和 Sokratis Kartakis 合著，2026 年 5 月发布在 Kaggle 上。它只讲一件事——整个行业正在经历的变化：从"写代码"变成"写意图"。

开篇的数据就让人一惊：2026 年初，85% 的专业开发者定期使用 AI coding agent，一半的人每天都在用，大约 41% 的新代码是 AI 写的。

如果你想最直观地看到"软件开发生命周期"（SDLC）变了多少，看这张图就够了——左侧是我们几十年来一直在用的方式，右侧则是正在取代它的东西：

看到差异了吗——左侧，人类需要按阶段一步一步完成所有步骤；右侧，人类真正需要介入的只剩两个节点："定义意图"和"验证质量"。中间的部分交给 AI 自己在循环里跑，直到通过。

但在继续之前，我想让大家先对一个词达成共识，因为它是一切的核心。

"vibe coding" 这个词从哪来的

2025 年 2 月，Andrej Karpathy 描述了一种他称之为 vibe coding 的全新编程方式——核心理念是你"彻底向 vibe 投降，然后彻底忘记代码的存在"。你只用日常语言告诉 AI 你想要什么，接收 AI 返回的结果，如果坏了就把错误信息复制回去让 AI 修复。

这个词立刻爆火，因为它戳中了人们长期以来一直在默默做、却没有名字的事情。

但一旦火了，词义就开始混乱——用 AI 帮助实现需求完备功能的 senior engineer，和 prompt 乱写然后直接把代码莽上 production 的人，都被叫作"vibe coding"。

直到 2026 年初，Karpathy 本人出来承认原来的框架太窄了，并推荐了一个新词："agentic engineering"，用来描述更有纪律的那一端。

真正的分界线不是"用不用 AI"，而是"验证了多少"。

这才是白皮书最核心的观点——vibe coding 和 agentic engineering 不是两个完全割裂的东西，而是在同一条线上（spectrum）的两端，而区分两端的不是用不用 AI，而是我们验证 AI 输出结果的程度有多少。

意图表达——vibe coding 一侧是轻松 prompt、不想太多；agentic engineering 一侧是完整的 spec、architecture doc 和 memory file。

验证——一侧是"嗯，看起来能用吧"；另一侧是有 test suite、CI/CD gate 和 LM judge 在把关。

错误处理——一侧把错误复制给 AI 就不管了；另一侧是人先找到根因，再让 AI 实现修复。

真正的核心在于两个相互配合的验证机制：tests 验证"可定义"的部分（函数接收这个输入必须返回那个输出）；evals 验证"不可定义"的部分（agent 选的路对不对、用 tool 对不对、结果达不达标）。

白皮书直说：如果 tests 和 evals 都没有——无论 prompt 写得多好，都还是 vibe coding。

那么我们该站在这条线的哪个位置？答案取决于工作的"赌注"——周末做 prototype 可以尽情 vibe coding，但管理金融交易的 API 必须用 agentic engineering。大多数真实工作落在中间，而真正的技能是知道每份工作该在哪里画这条线。

真正的技能不是"prompt"，而是"context"

白皮书反复强调一个观点，我认为这是整份白皮书最好的礼物：AI 生成代码的质量不取决于 prompt 有多聪明，而取决于我们喂给它的 context 质量。

这就是"context engineering"这个词的由来。

换个角度想——如果你要让一个新成员来帮你写项目代码，你不会在一句话里塞给他所有东西。你会让他读 documentation、看 diagram、熟悉团队的 convention，然后才开始动手。

对 AI 也是一样的，它不需要"精心编写的指令"，而是和优秀人类员工一样需要的那种 context 才能把活干好。

这些 context 分为两个重要层次：

Static context——始终加载，例如 AGENTS.md、CLAUDE.md、项目的 memory。它很贵，因为每个 token 都存在于每次 interaction 中，无论是否必要。

Dynamic context——只在需要时加载，例如任务匹配时才被调用的 skill、从 RAG 拉取的文档、session 历史。它很省，因为只在用到时才付 token。

而管理好这两层的关键是 Agent Skills——一种知识包，agent 只在任务调用时才加载，而不是从第一秒就把所有东西塞进 system prompt。

我最喜欢这个话题的一句话是：

问题不是"怎么骗 AI 写出好代码"，而是"如果要有个新成员来帮忙，他需要知道什么，然后我们怎么把这些知识 encode 给 AI 用"。

model 不是一切——Harness 概念才是大多数人的误解

现在换换节奏，因为下一部分是我觉得误解最多的一块。

当人们用 AI coding agent 结果很差时，我们的本能反应是怪 model——"这个 model 太蠢了""新版还不够强"。但白皮书说这是错误的直觉，它会把我们引向错误的投资方向。

事实是 model 只是工厂里的一个"发动机"——单靠发动机是造不出车的，还需要传送带、齿轮和安全传感器来配合。

围绕 model 的东西——prompt、tools、sandbox、sub-agent、observability、guardrails——统称为 Harness。

Agent = Model + Harness

能让这件事被真实感知到的证据：

在 Terminal Bench 2.0 上，有团队只改了 harness 就把一个非 Top 30 的 coding agent 送进了 Top 5——model 一个都没换。

LangChain 的研究在同一 benchmark 上，仅通过调整 fixed model 周围的 system prompt、tools 和 middleware，就让 agent 分数提升了 13.7 分。

应该把这句话贴到显示器上：当 agent 犯错时，别急着怪 model——大多数时候是 configuration 出了问题，无论是 tool 丢了、规则模糊了、guardrail 没有，还是 context 里满是噪音。

80% 问题——为什么 AI 还是不能替代我们（也不应该）

那为什么我们仍然需要人待在中间？白皮书称之为"80% problem"——AI 能很快生成功能 80% 的代码，但剩下的 20%，包括 edge case、error handling、integration 点和微妙的需求，需要 model 还没有的深层知识。

更值得担忧的是 error 的性质变了——从"语法敲错"变成"理解业务逻辑错误"、"需求模糊时没有追问"、"漏掉 edge case"或"做出造成长期债务的 architecture 决策"，这些很难被发现，因为代码看起来是对的，甚至可能通过基础测试。

很多人引用的"AI 让速度提升 25–39%"这个数字需要仔细读——METR 的研究发现，有经验的开发者在某些类型的工作中用了 AI 后反而慢了 19%，因为时间被消耗在检查、修复和排查 AI 生成的代码 bug 上。

所以用 AI 用得最好的人，不是全盘接受 AI 给的一切的人，而是知道什么时候该让 AI 做（spec 清楚的工作）和什么时候该自己集中注意力（需求模糊时、architecture 有 trade-off 时、验证正确性时）的人。

vibe coding 底下藏着的钱

这部分对需要在团队或组织层面做决策的人特别重要，因为它把视角从"能写多快"变成了"总体成本是多少"。

vibe coding 起步看起来很便宜——每月付几百块的订阅费，然后一直 prompt 下去。但白皮书指出，它有三个隐藏的、会累积的 OpEx：

Token burn——把大文件无结构地塞进 context，让 AI 来回复地修，周而复始地 prompt，烧的都是冤枉 token。

Maintenance tax——来自乱糟糟 prompt 的代码没有结构，6 个月后 bug 冒出来，人得花一整天一整天去 reverse-engineer 这堆"意面代码"。

Security remediation——没有 eval harness 把控 = 代码写得快 = 安全漏洞产生得快，而 production 环境下修复漏洞的成本比设计阶段高出指数倍。

agentic engineering 这边则相反—— upfront 投入设计 API schema、写 test suite、从一开始就管理好 context 结构，初期更贵，但后续每个功能的 marginal cost 骤降，因为 AI 工作在有规则约束输出的"工厂"里，有结构、通过测试、符合标准。

而 context engineering 本身也成了一项财务策略——LLM 按我们发送的每个 token 计费，每次 prompt 都往里塞 100,000 token 的 repo 就是在烧钱，解决方案是 intelligent model routing：用大模型处理复杂任务，但把简单任务（generate test、code review、CI/CD）路由到便宜很多的小模型。

白皮书最后给了一份可操作的 checklist，我只总结我觉得最重要的部分。

如果你是 developer，从这三件事开始就够了：

为项目设置 AGENTS.md——从十行开始：stack、convention、死规则、workflow，然后每次 agent 做了不想让它重复的事，就往里加规则。

写 tests + evals 再 generate 代码——这是与 AI 的"契约"，比任何 prompt 都能更精准地传达意图。

review 即将 ship 的每一行代码——对"聪明过头"的代码保持警觉，检查 import 是否是真实的包，检查 error handling 是否完备。

如果你是 leader，最重要的事是提升团队标准：

让 context engineering 成为团队级实践——AGENTS.md、system prompt 和 eval suite 必须在 PR 中被 review，与项目同版本，且有明确的负责人。

立"eval"而不是"demo"的标准——demo 通过只意味着成功做了一次，eval 通过意味着每次都成功。

如果要把 51 页压缩成一行，我会这样总结：

我们不是不再写代码了——只是从"写语法"变成了"写意图"，然后把 implement 交给机器，人类保留剩下的：决策、品味，以及验证产出是否真的好。

而 vibe coding 的可怕与 agentic engineering 的可信之间的分界线，不在于我们选择的 tool，而在于我们在 AI 周围架设的 harness 有多严密。

📚 参考：The New SDLC With Vibe Coding — Addy Osmani, Shubham Saboo, Sokratis Kartakis（Kaggle，2026 年 5 月）🔗 原文：https://www.kaggle.com/whitepaper-the-new-SDLC-with-vibe-coding