Vibe Coding 的真相为什么你点点点做不出好产品“Vibe coding” 火了一年了——跟 AI 说人话就能出代码。听起来很美。但为什么真正靠它做出能用的产品的人还是那几个本来就写代码的这篇文章讲真话。2025 年 Andrej Karpathy 发明了一个词vibe coding。大致意思是你不再写代码了你只是感受vibe——告诉 AI 你要什么然后一路点点点让 AI 写、AI 跑、AI 改。这个词传播得极快。因为它描绘的画面太过诱人不用学编程就能做软件。人人都是开发者。想法即是产品。一年过去了。2026 年 6 月我们来看看现实是什么。现实是vibe coding 做出了无数个番茄钟 AI 推荐任务的玩具项目但几乎没有人在完全不懂编程的情况下靠 vibe coding 做出一个真正有人用的产品。这不是 AI 的问题。这是我们对编程这件事的理解出了问题。编程的本质不是写代码先说一个反直觉的事实编程工作中写代码大概只占 30%。那剩下 70% 在干什么理解需求用户说的A 和 B 之间加个转换其实是说要调整整个数据模型排错程序没按预期跑你需要一个心智模型来推理可能的原因做取舍这个功能现在做还是下个版本做用简单实现还是为以后扩展留余地维护一致性改了登录逻辑10 个调用方全要改谁能一个不漏地找到它们测试验证不是跑通了而是覆盖了边界情况——你这周改了购物车支付流程还正常吗AI 能帮你写代码。但它不能替你做上面这些事。因为这些事情的前提是你脑子里有一个程序运行的心智模型。Vibe coding 在什么情况下能成功我见过 vibe coding 真正奏效的场景它们有一个共同特征使用者本身就懂编程。一个资深前端工程师用 AI 写一个企微机器人。他不需要 AI 教他什么是 API、什么是鉴权、什么是 JSON Schema。他只是懒得手写。所以他描述需求很精准“写一个 Express 路由接收企微的 XML 回调解析出消息内容调用 OpenAI API然后把结果用 markdown 消息发回去。”AI 秒出代码他扫一眼改两行部署。全程 15 分钟。这是 vibe coding 的理想状态你心里有蓝图AI 只是你的打字机。另一个极端是完全不会编程的人跟 AI 说帮我做一个电商网站。AI 开始生成代码。用户看不懂只能一直说页面不好看“功能再改改”。几轮之后项目膨胀成一团乱麻AI 自己也不知道之前为什么要那样设计。用户放弃。所以 vibe coding 的核心问题不是 AI 够不够强而是你跟 AI 之间缺了一个架构师。这个人得能判断 AI 的方案对不对、上下文有没有冲突、这条路能不能走到头。如果你自己当不了这个架构师那 vibe coding 的上限就是一个 demo。上下文窗口房间里的大象所有大语言模型都有一个上下文窗口——它能同时看见的信息量。当前最先进的模型大约是 200K token相当于一部长篇小说。听起来很大。但一个中型的软件项目代码量轻松突破 10 万行算上需求文档、设计稿、第三方依赖文档信息量是上下文窗口的上百倍。这意味着什么意味着AI 永远只能看到冰山一角。你让它改购物车逻辑它看得见cart.js看不见payment.js里的隐含约定。你让它加一个新字段它改了数据库模型但不知道前端有 3 个页面直接用了这个模型的 JSON 序列化结果。而一个人类工程师虽然也不能把整个项目背下来但他有一个 AI 没有的能力知道改了 A 可能会影响 B的直觉。这种直觉来自对系统架构的整体理解——哪些模块是耦合的哪些接口是敏感的哪些地方改了会炸。Vibe coding 的致命问题就在这里当你让 AI 连续迭代 20 轮之后上下文窗口里塞满了上次为什么这样改那个问题后来是怎么处理的之类的历史碎片。AI 开始犯糊涂——重复之前的错误、推翻之前确认的决策、忘掉你三小时前跟它强调过的约束。上下文窗口不是一个越大越好的硬件参数。它是一个根本性的架构限制。AI 在处理超出窗口范围的系统一致性问题时表现上限已经被物理锁定了。代码质量只是冰山一角网上关于 AI 编程的讨论90% 都在聊一个问题AI 写的代码质量高不高这个问题本身就跑偏了。对于生产级软件来说代码质量当然重要。但更重要的东西是软件在长期迭代中积累的隐性知识为什么这个函数叫processOrder但实际不处理退款因为三年前退款被拆出去独立模块了但当时为了不影响调用方没改名为什么用户表里有个legacy_id字段因为从老系统迁移的时候要保留原来的 ID 做数据对账这个约束已经没人记得了为什么这个接口允许传空数组因为有个重要客户的 ERP 系统有 bug偶尔会发空 payload你敢修它就敢断连这些东西没有任何文档记录。它们存在于老员工的记忆里、存在于某一天的线上事故复盘里、存在于别碰那段代码碰了就出事的口口相传里。一个 AI 永远不可能知道这些事情。因为它面对的不是一段代码而是一段被真实世界磨损了五年、带着各种历史伤痕的代码。Vibe coding 让你快速搭出原型。但从原型到产品差的不是代码量而是你处理这些历史伤痕的能力。这个能力 AI 完全帮不了你。真正有用的 AI 编程模式批评归批评AI 编程工具确实改变了我的工作方式。但模式不是我说它写而是一种更细粒度的协作模式一探索式学习遇到不了解的库以前是花一两个小时读文档。现在是直接让 AI 写一个最简示例改了跑跑了改跑通了就懂了。关键不是 AI 写得快而是反馈循环变密了。以前读文档是被动接收现在学新东西是提问→验证→调整的主动探索。记住率完全不一样。模式二日志驱动的排错以前排查线上问题搜日志关键词 → 点进代码 → 在脑子里建上下文 → 推理 → 加日志 → 再部署 → 再看。现在是把日志、报错堆栈、相关代码同时丢给 AI让它给假设。然后你拿着假设去验证。AI 不替你排错。它替你生成可验证的假设。这省掉了排错过程中最耗时的那个环节在不知道问题在哪的时候徒手画排查范围。模式三批处理式的代码生成需要把一个接口从 REST 改成 GraphQL。这种工作高度结构化逻辑清晰但极其繁琐——改 15 个文件每个改法都差不多。这种活是 AI 的舒适区。你描述清楚输入输出模式它一口气全改了。你在旁边当 reviewer——看 diff、提意见、合并。核心原则还是一样的你是架构师AI 是熟练工。蓝图你画砖它搬。一年后回头看Vibe coding 这个概念最大的贡献不是让你不写代码而是拉低了把想法变成原型的门槛。在 2025 年之前你要把一个想法变成能跑的东西至少要会编程。现在一个非技术人员用 AI 辅助一天就能搭出 MVP。但原型不是产品。从原型到产品中间那条沟宽度没有变窄。那条沟叫软件工程。工程不是写代码。工程是管理复杂度——让人能在不破坏已有功能的前提下持续加新功能让系统在出故障的时候优雅降级而不是全线崩溃让两年后接手的新人看得懂当初为什么要这么做。AI 目前对管理复杂度这件事的帮助基本为零。不是它不想帮而是这件事发生在上下文窗口之外、发生在代码之外、发生在技术选型和团队沟通和组织记忆这些抽象层面。这不是大语言模型的设计目标。所以 2026 年的现实是会编程的人因为 AI 效率翻倍不会编程的人能做出 demo但停留在 demo两者之间的差距比 AI 出现之前更大了这不是悲观。这是认清工具的能力边界然后把精力花在真正重要的地方。如果这篇文章让你想学编程不用从头啃教材。打开 Claude Code 或者 Cursor跟它说教我写一个最简单的网页然后跟着做。AI 是最好的编程老师——不是因为它教得好而是因为你可以用 20 倍的速度试出来的。这才是 vibe coding 的正确打开方式。