一、Karpathy为什么急着给Vibe Coding判死刑

2026年初，Andrej Karpathy做了一件很有意思的事：他亲手给“Vibe Coding”这个词判了死刑。这个词本来就是他一年前在推上随口一说、意外成了行业热词的那个。这一次，他拿出了替代概念——Agentic Engineering（智能体工程）。

在他的表述里，“Agentic”是因为99%的时间你已经不再直接写代码了，而是在调度、审查、纠偏一群智能体。“Engineering”则是强调这不再是“凭感觉”就能搞定的事——这里面有手艺、有判断、有工程纪律。你仍然和以前一样对自己交付的软件负责，但你可以比以前快得多。前提是，你得学会怎么约束你的AI，而不是被它带着跑。

这个转向背后有一个更根本的信号：当自然语言变成了编程语言，模型之间的差距早就不在“能不能写代码”，而在“能不能在真实约束下听懂你到底想要什么”。

二、Vibe Coding到底在“Vibe”什么

传统编程是你和编译器之间精确传递指令。写错一个分号，编译器就报错。框架是死的，规则是死的，你对它说A，它绝不会理解成B。

Vibe Coding是你和大模型之间进行模糊意图的迭代对话。你说“帮我做个登录页”，模型必须在几毫秒内脑补出你根本没说出口的信息：用邮箱还是手机号？要不要图形验证码？密码强度怎么定？失败三次要不要锁定？错误提示用什么文案？这些决策你一个字没提，但模型必须猜——而且你得接受它的猜测。

换句话说，Vibe Coding做了一次认知跃迁：从“构造”转向“沟通”。代码只是对话的副产品，真正的产出是对需求的理解和对实现的决策。这也解释了为什么同一个人用不同的模型，产出的质量可以有数量级的差距——因为沟通能力和构造能力是两码事。

三、视频生成教给我们的一件事

在讨论“一次做对”之前，先看一个类比。你试过让低端视频模型生成一段10秒钟的走路场景吗？前3秒还行，人物轮廓清晰、动作自然。到第5秒，手臂开始扭曲。到第8秒，背景里的一棵树凭空消失。到第10秒，整个画面崩了。

Vibe Coding的真实场景跟这个几乎一模一样。你面对的不可能是“写一个函数”，你一定面对的是一个系统——多个文件相互依赖，状态在不同模块之间流转，业务规则以各种隐式约束散落在各处。低水平模型在单文件基准测试里表现还行，一进入多文件、多依赖、多约束的真实项目，立刻现原形——局部可行，全局必崩。

把这两个场景放在一起对比：

“人物肢体漂移”——对应代码重构时变量名冲突、状态逻辑错乱。

“物体凭空消失”——对应改A模块导致B模块功能悄悄失效，而且不是报错，是逻辑走偏。

“光影突变”——对应改UI样式时破坏整体设计语言，一个按钮的圆角改成了4px，旁边十几个组件变成了“异类”。

“违背物理规律”——对应业务逻辑里那些没法写在注释里的隐性约束：库存不能为负、权限不能越级、事务不能部分提交。

“单帧可修，视频必须重来”——对应单文件可以改，多文件联调必须推倒重来。你改了一个接口的返回格式，五个下游模块全炸。

这个类比揭示的事很残酷：能生成3秒静止画面不算本事，能生成30秒连贯叙事才是。能写一个函数不算本事，能维护一个系统才是。

四、“一次做对”是个靠不住的标尺

现在回到“一次做对”。大家喜欢拿它当试金石——需求扔进去，代码跑出来，一次过就是好模型，要修要改就是差模型。这标准看似直接，实则漏洞不少。

首先，把“一次做对”定义为“零修改直接上线”的话，没有任何模型做得到。需求本身就是模糊的。你今天说“做个登录页”，明天看到成果才想起来“哦对了还要支持手机验证码登录”。这不是模型的问题，是需求沟通的特征。

其次，有三类“非模型因素”会严重干扰这个指标：

1. 工程层的优化。推理调度、采样策略、后处理和缓存机制，跟人优化prompt一样可以人为拉高一次通过率。这不是模型强，是工程层在补锅。

2. 任务复杂度差异。一个简单的CRUD接口，弱模型也可能一次过。拿这个来判断“这个模型比那个强”，好比用俯卧撑成绩评价一个人的综合体能——样本太小，结论太偏。

3. 即使一次通过了，代码的可维护性、扩展性、架构质量这些维度仍有天壤之别。代码跑起来了但架构是烂的，三个月后改一个功能要动十几个文件——这种“一次做对”有多大意义？

所以结论很清楚：“一次做对”是最直观的观测窗口，但不是唯一的、更不是最可靠的度量标尺。真正拉开差距的，是模型在复杂约束并发处理、长上下文因果推理、意图深度理解上的底层能力。

五、数据不会说谎：“能做”和“能维护”是两码事

有几组数据值得认真对待。

中山大学和阿里巴巴在2026年3月联合发布了一项研究，构建了一个叫SWE-CI的评测基准。跟市面上已有的基准不同，它不再考“一次性修bug”，而是模拟了一个真实项目的持续维护过程——233天跨度、71次连续提交、100个真实代码库任务。

研究团队测试了18个主流大模型，累计消耗了超过100亿Token。

结论很扎眼：多数模型在75%以上的任务中会破坏原本正常工作的代码。表现最好的Claude Opus 4.6，零退化率是76%——也就是说，即使在最好情况下，每四次修改中仍有一次会引入你没发现的新问题。其余14个模型的零退化率全在25%以下。你在用这些工具改100次代码，其中至少有75次，会悄悄埋下一个要等上线之后才会爆的雷。

Anthropic在2026年初的一项随机对照试验从另一个角度补了一刀。他们把52名开发者随机分成两组，一组用AI辅助学习一个新Python库，另一组纯手写，最后一起考试。结果AI组平均得分比手动组低了17%——相当于从B+掉到了C。差距最大的恰恰是调试能力。研究团队认为，AI的“平滑体验”让开发者少了那些通过犯错和纠错才能建立的深层心理表征。

GitClear跟踪了2020至2025年间2.11亿行代码的变更轨迹，发现了一个趋势：重构的比例从约25%一路下滑到不到10%。同期的代码重复率稳步攀升，复制粘贴产生的代码量有史以来第一次超过了重构整理的量。到了2026年，这个趋势不但没有好转，代码块重复率还在继续走高。

这不是AI生成了烂代码。这是AI工具的工作方式决定的——你给它一段上下文，它给你一个局部最优解。它不会跟你说“等等，这个项目里已经有一个类似的函数了”，它直接写一个新的给你。短期看开发速度上去了，长远看维护成本在安静地爬升。而且这种成本有滞后性——你今年省下的一周时间，很可能在明后年以双倍的维护工作量找回来。

六、从“凭感觉”到“上规矩”：几条实战经验

Karpathy给出的方向是明确的：从Vibe Coding到Agentic Engineering，核心是给AI加上工程纪律。但纪律不是换个词就有，得落在具体做法上。

第一招：不让模型直接写代码，先让它列决策清单。

这招简单但最有效。别一上来就说“帮我写一个用户管理系统”。先问：模块怎么拆？状态怎么管？异常怎么兜底？未来扩展点留哪？有一个非常具体的提示模板值得收藏：

“我要做一个【核心功能描述】。在写任何代码之前，请先列出以下五项技术决策并说明理由：1. 项目目录结构（按功能模块而非文件类型划分）；2. 状态管理方案（局部/全局的选择及理由）；3. 副作用处理边界（API请求的loading/error/cancel封装）；4. 可扩展性预留点（未来增加某功能时如何接入）；5. 错误兜底策略（关键路径报错时的UI降级方案）。确认清单无误后，再基于此生成代码。”

这么做为什么有效？弱模型的默认反应是“看到输入就接下一个token”——这是系统一式的快思考。强模型有能力走“先分析、再设计、后编码”的路径。决策清单把这些步骤变成了必经环节，让强模型的优势能真正释放出来。

第二招：追问Plan B，逼模型展示纠偏力。

模型输出了一套方案之后，追一个问题就够：“如果A方案失败了，你的Plan B是什么？”这个问题测的是两件事：反事实推理和风险预判。弱模型会开始循环重复、给不出具体策略，甚至假装前面的方案还有救。强模型会立即给出回滚路径、兜底逻辑或替代技术选型。这不是在刁难模型，是在逼它暴露真正的推理深度——而这恰恰是SWE-CI研究里那个75%的破坏率最缺的东西。

第三招：差异补丁法，把修改范围锁死。

项目变大之后，最怕的是改一个功能带出一堆新bug。这时候不要直接把所有代码贴给模型。更好的做法：先让它做差异分析（当前代码和新需求之间有哪些不兼容点），再让它锁定最小改动范围（只改哪几个文件、不动哪些接口），最后只输出需要修改的函数——不变的部分直接省略。这个策略的核心不是“让模型少干活”，而是限制它犯错的空间。SWE-CI的数据已经说得很清楚了：没有约束的修改，本质上是在赌。

第四招：选对技术栈，别跟训练数据作对。

Rust写核心逻辑加Python做接口绑定，是一个被反复验证的好组合。Rust编译器的严格类型检查和所有权系统天然适合LLM纠错——编译器本身就是一道硬约束。反过来，C语言在Vibe Coding场景里是公认的高危选项：不是语言好坏的问题，而是训练数据里C语言的错误模式和过时的写法太多了，模型学的就已经带了坑。

第五招：场景分级，别什么活都让AI干。

Vibe Coding天然适合低风险场景——内部工具、原型验证、一次性脚本。核心业务系统、支付链路、安全关键模块必须回归Agentic Engineering的严格约束。谷歌某工程负责人有一句被广泛引用的原则：“把每一段AI生成的代码当成来自初级工程师的提交。逐行阅读，运行测试，不测试不合并。”这话听起来像是在泼冷水，但放在SWE-CI那个75%的数据面前，它更像是保命常识。

七、写在最后

“一次做对”是个很有诱惑力的词。它让你觉得只要找到足够强的模型，需求扔进去就等于产品扔出来。但工程从来不是按这个逻辑运转的。工程关于约束——识别约束、定义约束、在约束中找可行解。不管你是手写代码还是调度智能体，这一点都不会变。

Vibe Coding的价值在于它把门槛降到了一个前所未有的低点。Agentic Engineering的价值在于它告诉你：门槛降低不等于质量可以打折。能用自然语言让机器干活了，不代表你可以不用脑子思考它到底干了什么。

下次打开对话框的时候，问自己一句：“我要的是代码，还是一套经得起时间考验的决策？”这个问题的答案，决定了你到底是在做Agentic Engineering，还是在被Vibe Coding带着跑。

参考资料

[1] Karpathy, A. (2026). Sequoia Ascent 2026: Software 3.0, Agentic Engineering, and Jagged Intelligence

[2] Sun Yat-sen University & Alibaba Group. (2026). SWE-CI: Evaluating Agent Capabilities in Maintaining Codebases via Continuous Integration.

[3] Anthropic. (2026). How AI Assistance Impacts the Formation of Coding Skills. anthropic.com/research

[4] GitClear. (2025). AI Copilot Code Quality: 2025 Look Back at 12 Months of Data. gitclear.com

[5] GitClear. (2026). The Maintainability Gap: AI Code Quality in 2026. gitclear.com