博客METR 实测：用 AI 写代码反而慢 19%。cURL 关了漏洞赏金，Ghostty 禁了 AI 提交。2026 年，Vibe Coding 正在遭遇数据驱动的全面反击。但另一侧，头部厂商的工程化路线日均 150 个 PR。两条路线的分歧、数据与融合逻辑，这篇文章讲清楚。
2026 年 3 月，cURL 关掉了它的漏洞赏金计划。不是因为没钱，也不是因为没 Bug——是因为 AI 生成的"漏洞报告"太多了。创始人 Daniel Stenberg 的原话：这些报告"流畅、自信，而且完全是编的"。几乎同一时间，终端模拟器 Ghostty（GitHub 45000+ star）在仓库里加了一条规则：禁止 AI 生成的代码贡献。白板应用 tldraw 更进一步——所有外部 PR 自动关闭，不再区分别人写的还是 AI 写的。
三件事指向同一个信号：Vibe Coding 正在遭遇 2026 年最猛烈的数据反击。
2025 年 2 月，Andrej Karpathy 发明了一个词——Vibe Coding。核心意思是：别管代码了，用自然语言描述需求，让模型生成、测试、修 Bug，你只需要"沉浸在氛围里"。门槛骤降，效果惊艳。那段时间，社交媒体上到处是"我用 AI 一个周末做了个 SaaS"的帖子。
但到了 2026 年，风向变了。一年多的真实使用数据把 Vibe Coding 的底牌翻了出来——不是它没用，而是它被严重高估了。Django 联合创始人 Simon Willison 在今年的一次播客访谈中说出了很多人不敢说的话：他开始在生产环境中不逐行审查 AI 代码了，并把这叫做"偏差正常化"——AI 每次写对，都在消磨你下一次审查它的意愿。他在 Hacker News 上收获了八百多条评论，争议的焦点不是"AI 能不能写代码"，而是"不看代码就把 AI 输出推上生产，算不算工程上的渎职"[1]。
问题的本质是：LLM 的"概率输出"天花板决定了它无法像确定性的编译器一样被信任。一个函数你今天问它返回 A，明天可能返回 B——不是因为模型变笨了，是因为相同的 prompt 在概率分布上每次采样结果不同。这不叫 Bug，这叫工作原理。但生产系统不能接受"有时候对"。
这种概率本质在工程实践中造成的伤害远比想象中大。我们之前分析过，多步任务中错误会以指数级累积：假设单步成功率 95%，跑完 20 步，整体成功率只剩 36%。这正是 95% 的 Agent 项目从 Demo 走到生产就倒下的数学原因——不是模型不够聪明，是概率的乘法法则没有例外详见优码云对 Agent 工程化失败率的深度分析。
2026 年初，METR 做了一项可能是 AI 编程领域最扎实的研究：让经验丰富的开源开发者用自己最熟悉的仓库做真实任务[2]。工具是 Cursor Pro + Claude 3.5 Sonnet，任务来自他们自己的 issue tracker。
结果：用 AI 的情况下，任务完成时间反而多了 19%。而这些开发者在看到数据之前，普遍认为自己快了 20%。一个将近 40 个百分点的感知偏差。
为什么慢了？研究者抓出了几个模式：开发者大量时间花在审查、调试和修正 AI 生成代码上；AI 给出的建议"差不多对"，但差的那一点需要额外的时间去发现和修正；在需要深入理解代码库的任务上——恰好是资深开发者日常做的那类——AI 的帮助几乎为零甚至负向。
质量数据更难看。多项独立研究汇总的结果[2]：
这些数字来自生产环境，不是玩具基准。Hashnode 的调查显示，只有 15% 的开发者在工作中实践 Vibe Coding，72% 明确拒绝。剩下的 13% 只用于一次性原型和实验[2]。
Meta 工程师 Steve Yegge 用一个比喻把问题讲透了：Claude 审查 PR 时，大部分时候正常——"嘿，这个 PR 基本健康，只是少了个肾，请把肾加上。"但有时候，Claude 会严肃地评估一个给每个 worker 脸上糊了一只抱脸虫的 PR，然后说："这个 PR 结构很好，抱脸虫牢固地抱在 agent 脸上，测试覆盖充分，相关工作公式也已更新。"你得告诉它——Claude，那是一只抱脸虫。然后它才恍然大悟[3]。
对人类来说显而易见的常识——文化语境、制度知识、项目目标——对 AI agent 来说是一片空白。而它的唯一目标就是"完成当前任务"，不是"交付优秀软件"。这两个目标之间有结构性错位。
| 维度 | Vibe Coding | Agentic Engineering |
|---|---|---|
| 核心理念 | 自然语言描述需求，AI 全权生成，人工不审查代码 | AI 作为协作工具，人在回路中，每行代码可追溯、可审计 |
| 代码审查 | 不做或仅做冒烟测试 | 多阶段质量门 + 对抗性评审 + 证据链审计 |
| 适用场景 | 个人工具、一次性脚本、原型验证 | 长生命周期、高可靠性企业级系统 |
| 产出速度 | 极快（数分钟完成功能） | 中速（自动化 + 人工校验并行） |
| 质量风险 | 缺陷率高 1.7 倍，安全漏洞率高 2.74 倍 | 通过工程手段将风险控制在可接受范围 |
| 信任模型 | "出了问题再修"（先上车） | "验证通过才上线"（先买票） |
| 工程体系 | Prompt → 生成 → 跑通 → 提交 | 意图契约 → 任务工程 → 上下文工程 → 可观测性 → 评估驱动 |
| 典型代表 | Karpathy 式"忘记代码存在"的玩法 | Tony Bai 提出的 SE 3.0 框架、Claude Code 的工程化用法 |
这张表的每一项都不是理论推演。以"可观测性"为例：Google Cloud 和 LangChain 的联合报告显示，89% 的 Agent 团队已经上了可观测性系统——因为在生产环境里，你必须能追踪 Agent 的每一步决策：它为什么调了这个工具？为什么给出这个答案？出了问题怎么定位？Vibe Coding 模式下，这些问题全都没有答案[4]。
有趣的是，两条路线之间的关系比"谁对谁错"要复杂得多。
Simon Willison 在今年明确表示，他曾经把 Vibe Coding 和 Agentic Engineering 分得很开——前者是不看代码、不负责任，后者是每行代码负责。但现在，两条线开始重叠。他发现 AI 输出的代码越来越可靠，自己不再逐行审查了。他把 AI 输出当"半黑盒"用——就像信任公司里的另一个团队，你不会读他们每一行代码，先拿来用，出了问题再去看他们的仓库[1]。
但在另一个方向上，工程化路线也在吸收 Vibe Coding 的"速度基因"。Claude Code 的创建者 Boris Cherny 在 2026 年实现了零手写代码，日均提交 150 个 PR。他的做法不是"闭眼信任 AI"，而是通过小步提交、规范制定、多模型交叉审查三层工程化手段，把 AI 的非确定性装进了确定性的管线。速度和质量不是二选一——只是在缺少工程体系时，你只能二选一。
这里有一个关键洞察：代码本身在贬值，但结构、接口和确定性数据层的价值在急剧上升。Simon Willison 在播客中说的这句话值得每一位技术决策者反复咀嚼：Agent 带来的非确定性，恰恰让那些能减少非确定性、提供稳定边界的东西变得更珍贵[1]。
这也解释了为什么 Go 和 Rust 这类"默认无聊、限制颇多"的强类型语言，反而在 AI 时代成为企业系统的底座——它们的编译器本身就是一道确定性门槛，AI 生成的垃圾代码过不了类型检查[5]。
而苹果在今年 4 月两次下架 Vibe Coding 应用的行为，则给这轮讨论加了一个来自平台方的注脚：当代码质量失控到平台能检测到的程度，市场机制会先于工程规范出手[6]。
这个趋势也和编程工具自身的演进重叠。C++ 之父 Bjarne Stroustrup 在 2025 年底公开抨击 AI 编程工具的代码质量，而到了 2026 年，整个赛道已经从"代码补全"迭代到了"智能体代理"——工具本身在变得更可靠，但可靠性恰恰来自更强的工程约束，而非更随意的 Vibe关于 AIcoding 工具从辅助到代理的演化路径，我们有过详细拆解。
这篇文章不是写给个人开发者的。企业内部的技术决策者——CTO、技术总监、工程 VP——面对 Vibe Coding 的诱惑和数据的警告，需要回答三个问题：
第一，交付速度的瓶颈在哪里？如果瓶颈是"写代码太慢"，AI 工具确实有效。但大多数企业级项目的瓶颈不是编码速度，而是需求理解、架构决策、跨团队依赖和代码审查。AI 在这些环节帮不上忙，甚至会让问题更糟——它用更快的编码速度放大了架构设计缺陷的后果。
第二，你的信任模型是什么？Vibe Coding 的信任模型是"出了事再说"。这对内部工具也许可行。对面向客户的系统、涉及资金或数据的系统、需要合规审查的系统——这个模型在法律上就不成立。工程化的信任模型是"验证过才能上线"，它的成本更高，但它的风险是可控的。
第三，你的团队准备好"读代码"了吗？用 Hacker News 上一句被广泛引用的评论来说：Vibe Coding 最大的风险不是 AI 写出烂代码，而是开发者丧失分辨烂代码的能力——那种通过不断编写和重构建立起来的"代码本体感觉"。如果团队不再亲手写关键路径的代码，当系统出问题时，没有人知道该从哪里开始排查[1]。
这三个问题不是学术讨论。已经有团队在实践层面给出了答案：将团队规模从 15 人压缩到 4 人加 AI，不是靠削减人手，而是靠重新设计整个工程管线——把人的精力从写代码转移到审代码和定架构上这条组织变革路径的完整实录值得一看。
一句话：Vibe Coding 是"AI 写，我不看"；Agentic Engineering 是"AI 写，我审查，我审计，我对每一行负责"。前者追求速度，后者追求质量与速度的工程化平衡。用 Tony Bai 的话说，就是把非确定性的魔法关进确定性的工程笼子里[5]。
不应该，也不需要。Vibe Coding 在原型验证、内部工具、一次性脚本这些低风险场景里效率极高。问题不是"用不用"，而是"在什么场景下用、用什么工程手段兜底"。关键是建立清晰的边界：原型可以 Vibe，生产必须工程化。
不完全是。LLaMA 3、GPT-5、Claude Opus 4.7 的代码生成能力已经很强。核心问题在于 LLM 的本质是概率输出——同一个 prompt 可能产生不同结果，且模型不理解"为什么这行代码在特定业务上下文里是错的"。更好的模型能降低错误率，但不能消灭错误。消灭错误靠工程体系。
可行，但前提是你必须先建好工程管线。Boris Cherny 能做到的核心不是他信任 AI，而是他有小步提交、规范约束、多模型交叉审查三套机制在代码进入仓库前做质量过滤。零手写代码≠零工程投入——恰恰相反，这条路的工程投入比传统开发更大。
从可观测性开始。让你团队里的 AI 编程工具产生的每一步决策都可追溯、可审计。然后建立评估管线——每次改动自动跑评估，确保质量不退化。最后才是提速。顺序反了——先提速再补质量——是目前 95% 的 Agent 项目失败的根因。