Vibe Coding 时代，软件工程为什么更重要了

博客

2025 年 2 月 2 日，Andrej Karpathy（OpenAI 创始成员、前特斯拉 AI 总监）在 X 上发了条随手推文，给一种新玩法起了名字："vibe coding"——完全跟着感觉走，拥抱指数进步，甚至忘掉代码的存在。他自己也坦承，这玩法适合"一次性的周末项目"（throwaway weekend projects）。

谁也没想到，这个本来说明"周末玩票"的词，一年后成了软件开发的默认语境：Cursor、Claude Code、Codex 等工具让"用自然语言描述需求、AI 生成代码"成为常态，YC 2025 年冬季批次中约四分之一的初创公司，其代码库有 95% 由 AI 生成。但当"写出能跑的代码"这件事变得空前容易之后，一个反直觉的共识在业内越来越清晰：Vibe Coding 时代，软件工程不是被淘汰了，而是更重要了。本文把这个观点的来龙去脉和各方论据整理给你。

一、词是这么来的，边界也是这么划的

先看 Karpathy 原推的完整表述：

"There's a new kind of coding I call 'vibe coding', where you fully give in to the vibes, embrace exponentials, and forget that the code even exists. It's not too bad for throwaway weekend projects, but still quite amusing."

注意最后一句：他自己给这个方法划定了适用范围——可丢弃的周末项目。遇到修不掉的 bug 就绕过去，或者"随机要求一些改动直到 bug 消失"。这种状态对原型无所谓，对生产系统则是灾难。

很多后来的争议，其实源于把这个适用于"玩票"的词，误当成了适用于"工程"的方法论。资深开发者 Simon Willison 说得很直白：

"如果 LLM 写了你代码的每一行，但你全部评审过、测试过、理解了，那不是 vibe coding——那是把 LLM 当打字助手。"

二、光有"氛围"撑不住的证据

认为"软件工程更重要"的一方，手里有几组被反复引用的数据：

  • 体感与现实的落差：METR 的对照研究发现，经验丰富的开发者使用 AI 编码工具时，实际速度反而慢了 19%——但他们自认为快了 24%。感知与现实的差距高达 43 个百分点。
  • 安全隐患：多项研究指出 AI 生成代码的安全漏洞率显著高于人工代码（有统计称约 2.74 倍），SQL 注入、XSS、认证绕过等问题并不少见。所有处理用户数据、支付、鉴权的代码，都必须过人这一关。
  • 技术债复利：AI 代码是按统计概率生成的，不是按业务意图设计的。它擅长"看起来对"，但不天然知道你的扩展性需求、边界条件和安全约束。未经架构约束的 AI 代码层层堆叠，最后往往"无法重构、无法升级"。
  • 80/20 之墙：各水平开发者的共同体验是——AI 能漂亮地完成前 80%（脚手架、样板代码、标准 CRUD），但最后 20%（状态管理、边界情况、性能优化、安全加固、部署配置）仍然极度依赖传统工程功底。做 MVP 前 80% 也许够用，做服务上千用户的生产系统，必须有人能翻过这堵墙。

一句话概括：速度不是策略。没有质量兜底的速度，只是更快地失败。

三、业内怎么看：从 Vibe Coding 到 Vibe Engineering

Simon Willison：AI 放大的是你已有的功力

2025 年 10 月，Willison 提出"Vibe Engineering"一词，与"Vibe Coding"划清界限：前者是随性的、看感觉的实验；后者是老练的、负责任的、面向生产系统的 AI 协作方式。他的核心判断是——AI 工具放大既有的专业能力。资历越深的工程师，从 LLM 和编码智能体手里拿到的产出越快越好。因为真正的工作变成了：调研方案、定架构、写规格说明、定义成功标准、设计智能体工作流、规划 QA，以及"管理一群随时会偷懒作弊的数字实习生"——这些本来就是高级工程师的看家本领。

AWS：软件工程远不止写代码

AWS 杰出开发者布道师 Darko Mesaroš 的说法是："软件工程作为一种实践，远不止编码。写代码只是其中一部分——过去它占了最多工作量，但也只是一部分。"他认为 Vibe Coding 不会消失，它在探索、原型、实验场景有明确价值；但要把实验性想法变成可靠软件，需要的是规格驱动开发（spec-driven development）这类更结构化的方法——先定义需求和设计决策，再让 AI 生成实现，规格说明就是人与 AI 智能体之间的"合同"。

吴恩达：门槛降低了，学编程的人应该更多而不是更少

吴恩达（Andrew Ng）提醒大家不要把 Vibe Coding 简单化：即使代码由 AI 生成，开发者仍然要评审与调试输出、理解边界情况和应用逻辑、做架构设计、维护与加固代码。他甚至指出，一天 AI 辅助编程下来照样很累——因为真正花脑子的判断和监督一点没少。他的态度是："编程越容易，应该有更多人去编程，而不是更少！"

YC 的观察：清理 AI 代码的人更值钱了

YC CEO Garry Tan 谈到那批 95% 代码由 AI 生成的初创公司时强调："这些都不是非技术创始人——每个人都能从零写出自己的产品。"与此同时，市场上出现了明显的"清理专员"（cleanup specialist）需求：公司专门雇开发者来重构、优化 AI 生成的凌乱代码。这个岗位的兴起说明：专业知识没有贬值，而是更值钱了。

四、这个时代，软件工程的哪些环节更重要了

把各方观点合起来看，价值重心发生了明确的迁移：

  1. 架构与系统设计：先画图、定数据流和服务边界，再让 AI 填空——AI 应该在一张设计好的蓝图上施工，而不是替你设计房子。
  2. 需求表达与规格化：自然语言成了新的"编程语言"，但大白话和专业术语生成的东西完全不同。产品定义、验收标准、约束条件都要清晰传递给 AI，描述越精确，产出越接近预期。
  3. 测试与验证："信任但要验证"。AI 写的每一行代码都应视为不可信输入：必须有单元测试覆盖边界情况，必须有严格到反过来了的代码评审——专门盯着"幻觉逻辑"和低效模式。
  4. 安全与责任：静态分析、安全扫描这类确定性工具，正好用来检查概率性生成。最终为系统稳定性、可靠性、安全性负责的只能是人——这一点 AI 无法独立承担。
  5. 判断与品味：AI 生成的软件容易千篇一律，创作者的知识积累、审美和品味会体现在产品的细腻程度里。发现真实需求、识别用户痛点的能力，反而成了新的稀缺品——毕竟"计划、打卡、记账"已经成了 Vibe Coding 三件套。

五、一句话总结

Vibe Coding 重新定义的不是"软件工程要不要"，而是"工程能力在哪里最值钱"。当写代码不再是瓶颈，架构、规格、测试、评审、安全、判断——这些从来就是软件工程核心的东西，恰恰成了新的瓶颈。正如一种被广泛引用的判断：Vibe Coding 不是软件工程的终结，而是一个更难的问题的开端——当几乎人人都能造软件，怎样才算把软件造好？这个问题，只有软件工程能回答。

参考来源

说明：本文为观点解读类文章，未做工具实测；Karpathy 原推表述引自 Ars Technica 等多家媒体对原帖的存档，其余观点分别引自上述各来源原文，具体数字以各原始出处为准。

腾讯云精选福利

发表回复

您的电子邮箱地址不会被公开。 必填项已用 * 标注

腾讯云精选福利