Vibe Coding正在掀起一场关于AI编程的讨论风暴，它到底是赋能非技术人员的创作工具，还是让开发者能力退化的糖衣炮弹？本文通过腾讯员工真实案例与Anthropic最新研究，拆解AI编程的两面性：从约饭App的快速落地到17%的能力退化，揭示技术普惠背后的关键变量——不是工具本身，而是使用者的思考方式与业务场景的匹配度。

有人问我：「我用 Cursor 做了个小程序，算不算 Vibe Coding？」

我回他：「你用过 Cursor 吗？」

「用过，但很多地方看不懂，基本靠 AI 帮我改。」

「那你 Vibe 的挺好的。」

「那我是不是已经是程序员了？」

哎，这就是问题所在了。

Vibe Coding 这个词，火得太快，快到大部分人还没搞清楚它到底是什么，就已经开始在朋友圈里晒成果了。有人说它是「人人都是程序员」的开始，有人说它是「AI 时代最大的骗局」，还有人说它正在「玩废」整整一代开发者。

我觉得吧，这些判断都有点用力过猛。

Vibe Coding 既没那么神，也没那么废。它只是被人误解了。

先说一件让我印象很深的事

前段时间，腾讯内部有篇文章在圈子里传得很广，讲的是鹅厂员工都用 Vibe Coding 搞出了什么好玩的东西。

里面有个叫 @lexis 的产品策划，文科艺术生背景，零代码经验，靠着 Cursor，花了 3 个月，单枪匹马做出了一个叫「饭之」的约饭 App 小程序——2000 多个腾讯人在用，她自己也靠这个产品认识了很多有意思的人。

还有个叫 @yufang 的内容运营，只花了 2 小时，用 Codebuddy + 微信云开发做出了一个健康打卡小程序。她说，看到自己的小程序真的跑起来的那一刻，「超有满足感」。

3D 角色设计师 @kak 做了一套 AI 短剧制作工作台，一句话输入，AI 跑完从剧本到成片的全流程，内置六步流水线，还接了七个视频模型。

这些人，没有一个是传统意义上的「程序员」。

但他们做出来的东西，是真实在用的。

所以，Vibe Coding 真的让「人人都是产品经理」成为了可能吗？

我觉得——有可能，但你得先搞清楚一件事。

你以为的 Vibe Coding，可能根本不叫 Vibe Coding

这是我觉得现在讨论最混乱的地方。

很多人把「用 AI 辅助写代码」和「Vibe Coding」混为一谈。这两件事，差得远呢。

平安保险技术平台的负责人张森森给过一个很清晰的区分：AI Coding 是开发者借助 AI 提效，整个流程还是由架构师和工程师主导，AI 只是个「角色程序员」；而 Vibe Coding，是让非技术背景的人，通过自然语言描述意图，让 AI 实现端到端的代码生成。

换句话说，Cursor 帮你补全代码、Claude Code 帮你重构逻辑，这叫 AI Coding；你对着 AI 说「帮我做一个约饭 App」，然后等着收菜，这才叫 Vibe Coding。

前者面向专业开发者，是效率工具。后者面向非技术人群，是创作工具。

用户画像不同，产品逻辑不同，评价标准也完全不同。

把这两件事混在一起讨论，就像把「会开车」和「会修车」混在一起——你可以不会修车，但你得知道自己开的是什么车、开到哪里。

那 Vibe Coding 的用户，到底是谁？

不是「小白」。

依我看，这个词其实挺侮辱人的。真正在用 Vibe Coding 的人，大多是有明确需求、有创作动机，但被技术门槛挡在门外的人。

产品经理、运营、设计师、内容创作者——他们不是不聪明，他们只是没有时间和动力去系统学编程。

鹅厂那篇文章里的案例，恰恰印证了这一点。那些做出好玩东西的人，没有一个是「随便试试」的，他们都有非常具体的痒点：

视觉设计师因为太爱吃寿司，就做了个寿司评分 App；客户端开发觉得 iOS 相册搜索功能太烂，就自己搓了一个本地相册搜索工具；内容运营想做健康打卡，2 小时就上线了。

强烈的创作动机 + 明确的使用场景，这才是 Vibe Coding 真正的燃料。

没有这两样东西，工具再好用，也只是玩具。

但有一件事，我觉得大家都低估了

Anthropic——就是做 Claude 的那家公司——前段时间发了一篇论文，标题叫《AI 如何影响技能形成（How AI Impacts Skill Formation）》。

说实话，这篇论文出来的时候，我愣了一下。

因为他们是 Claude 的爹，Claude 是 Vibe Coding 圈子里最受欢迎的工具之一。结果他们自己跑出来，用数据告诉大家：过度依赖 AI 写代码，你的能力会退化。

实验很简单：50 多位有经验的 Python 程序员，分成两组，一组只能看文档和 Google，一组可以用 AI 助手。任务结束后统一考试。

结果：AI 组平均分比手动组低了 17%。

更讽刺的是，完成任务的时间，两组几乎一样——AI 组平均 23 分钟，手动组 24.7 分钟。

快了 1.7 分钟，换来了 17% 的能力退化。这笔账，怎么算都不划算。

为什么会这样？论文里提到了一个概念，叫「交互税」。

你以为用 AI 是在省时间，其实你把时间花在了写提示词、等待生成、验证结果、循环修复上。有人在一项 35 分钟的任务里，花了 30% 的时间在想怎么跟 AI 说话。

而且，AI 太顺滑了。

手动组平均每人遇到 3 次报错，他们被迫停下来，盯着错误信息思考，查文档，搞清楚为什么。AI 组平均只遇到 1 次报错，代码跑得很顺，但脑子里什么也没留下。

论文里有句话，我觉得说得很准：「遭遇并独立解决错误，是技能形成的关键一环。」

AI 把摩擦都消除了。但摩擦，恰恰是学习发生的地方。

同样用 AI，有人超神，有人变废——差别在哪？

这才是这篇论文最有意思的部分。

研究员通过录屏分析，把 AI 组的程序员分成了六种类型。

低分的三类，我称他们为「AI 废人」：

甩手掌柜型——直接把题目扔给 AI，复制粘贴，交卷。速度最快，学到的东西为零。

半途而废型——开始想自己做，遇到报错就崩了，「算了 AI 你来吧」，彻底躺平。

盲目试错型——遇到 Bug 不看错误信息，直接截图丢给 AI，AI 给代码就跑，不对再丢。这是最惨的一类，时间花了最多，分数最低，完全沦为 AI 的「人肉测试员」。

高分的三类，我称他们为「AI 驾驶员」：

1. 打破砂锅型——几乎不让 AI 写代码，只问概念：「为什么要用 await？」「这个原理是什么？」搞懂了再自己写。把 AI 当导师，不是当外包。
2. 先斩后奏型——让 AI 生成代码，但粘贴之前追问：「解释一下这行为什么这么写？」把 AI 的输出转化成自己的知识。
3. 混合双打型——直接在提示词里要求：「写代码，并解释每一步的逻辑。」强制 AI 输出推理链，自己跟着理解，也方便后续 Debug。

用的是同一个 AI，结果差了 40% 以上的分数。

区别不在工具，在姿势。

Vibe Coding 的天花板，比你想的要低很多

说到这儿，可能有人会说：「那是程序员的问题，我又不需要学编程，我就是要让 AI 帮我做东西。」

这个逻辑没问题，但有个前提——你得清楚自己想做的东西，复杂度在哪个区间。

业内专家给过一个量化的参考：

Demo 级别的小工具，AI 胜任率接近 99%，没什么问题。中型独立项目，比如企业内部小工具，胜任率约 70~80%，还行。一旦涉及复杂业务系统，比如微服务、支付、高并发，胜任率直接跌到 40~50%。银行级系统重构，可能不到 20%。

前段时间有个很能说明问题的案例：有人让 AI 连续运行 7 天，写出了数百万行代码的 Chrome 项目。听起来很厉害对吧？结果被社区发现，那堆代码无法运行、无法修复、无法复现——连「屎山代码」的资格都没有，被称为「AI 泔水」。

复杂度是 Vibe Coding 真正的天花板。 不是模型不够聪明，是隐性的业务上下文、架构决策、历史遗留的边缘处理，这些东西 AI 目前根本无法内化。

所以，鹅厂那些做出好玩东西的人，做的基本都是「Demo 级」到「中型独立项目」区间的东西。这个区间，Vibe Coding 真的好使。但如果你想用 Vibe Coding 搭一套生产级的复杂系统，那我只能说，先洗洗睡吧。

那 Vibe Coding 到底值不值得玩？

值得。

但你得想清楚你在玩什么。

如果你是产品经理、运营、设计师，有一个具体的痒点，想快速验证一个想法，Vibe Coding 是目前最低成本的路径。3 个月做出 2000 人在用的 App，2 小时上线一个健康打卡工具——这些真实发生了。

如果你是开发者，想用 AI 提效，那你需要的不是 Vibe Coding，是 AI Coding。两件事别搞混。

如果你只是跟风，觉得「我也要 Vibe 一个」，但没有具体的需求场景，那大概率你会在循环 Debug 里消耗掉所有热情，最后得出「AI 也没那么好用」的结论。

还有一件事我觉得很重要，不管你是哪类用户：

别被 AI 的速度带跑。

方案先行，想清楚再让 AI 展开。遇到不懂的，停下来问清楚，而不是继续催生成。定期回顾 AI 做了什么，重新建立你自己对这个产品的心智模型。

Vibe Coding 本来是为了延展人的创造边界，不是为了让人变成 AI 流水线上的一个按钮。

当 AI 把所有摩擦都消除之后，我们还剩下什么？

这个问题，我觉得每个在用 Vibe Coding 的人，都值得认真想一想。