Vibe Coding正引发产品经理与程序员间的激烈争论，但这场讨论却因概念混淆而陷入无谓的对抗。本文揭示了两种角色的本质分歧，并提出了产品经理最应关注的核心价值：快速试错能力的获得。在工具热潮背后，作者指出了业务理解力才是真正的天花板，并给出了清晰的使用场景判断框架。这不仅是一次关于AI工具的深入探讨，更是对产品思维本质的重新审视。

一、我为什么要写这篇文章

过去两个月，我的收藏夹里多了将近四十篇关于 Vibe Coding 的文章。

有人说它是”产品经理的第二春”，有人说它是”程序员的掘墓人”，有人用它三天做出了一个 SaaS 工具开始收费，也有人用它搭出了一个上线即崩的系统然后写了篇反思帖。我把这些文章都读完了，然后发现自己陷入了一种奇怪的困惑——每篇文章说的都好像有道理，但放在一起，它们互相矛盾。

亢奋的那批文章让我觉得不立刻上手就要被时代抛弃；悲观的那批文章让我觉得这不过是另一场泡沫。但两种情绪都没有真正帮我想清楚一件事：作为一个产品经理，我应该怎么看待这件事，怎么用它，用它来做什么？

这篇文章不是综述，也不是教程。它是我在消化了大量信息之后，试图给自己建立一套判断框架的记录。如果你也是产品经理，或者是对这个话题同样困惑的人，希望这篇文章能给你提供一个不一样的视角——不是让你更亢奋，也不是让你更悲观，而是让你想得更清楚一点。

二、我们到底在争论什么：一场被命名混乱拖累的讨论

先说一个观察：关于 Vibe Coding 的大多数争论，根本没有在讨论同一件事。

这不是在说谁对谁错，而是说——同一个词，被不同背景的人赋予了完全不同的含义。当一场争论的基础定义都没有对齐，所有的交锋都只是噪音。

我把常见的几种理解方式梳理成了下面这张图：

产品经理说的 Vibe Coding，是”我终于能把脑子里的想法快速变成可以点击的东西”；程序员说的 Vibe Coding，是”一种不负责任的、会产生技术债的开发方式”。 这两拨人压根不在同一个讨论频道里，但他们用的是同一个词，所以争论永远结束不了。

还有一个更深层的混淆：Vibe Coding 和 AI Coding 经常被混用，但它们不是一回事。

把这个区别搞清楚之后，很多争论就自动消解了。程序员批评 Vibe Coding”不可维护、没有架构”，这个批评是成立的——但它成立的前提是把 Vibe Coding 当作工程实践来评价。问题是，对于一个用 Vibe Coding 做原型验证的产品经理来说，”可维护性”本来就不是他的优化目标。

用工程师的标准评价产品经理的工具，就像用米其林的标准评价一个方便面——它当然不够好，但这不是重点。

三、产品经理视角下，Vibe Coding 真正改变了什么

说清楚了概念，再来谈本质。

很多文章在谈 Vibe Coding 对产品经理的影响时，会说：PM 现在可以自己做原型了、PM 可以做内部工具了、PM 的技术理解会加深了。这些都对，但我觉得它们都不是最核心的那一层。

最核心的改变是：验证节奏变了。

具体来说——Vibe Coding 最大的价值，不是让你能做什么，而是让你能多快看到自己错了。

听起来有点奇怪，我来解释一下。

传统的产品验证路径大概是这样的：

而 Vibe Coding 之后的路径可以变成：

注意，两条路径的终点是一样的——都是”发现方向错了”。但时间成本和沉没成本完全不同。

这意味着什么？意味着你可以更大胆地犯错，因为犯错的代价变低了。一个以前需要斟酌三周才敢提出来的方向，现在可以用两天验证一遍。这不只是效率的提升，而是产品决策方式的根本性变化。

我把这个叫做”获得快速试错的能力“，它比”PM 会写代码”这个表述要精准得多，也重要得多。PM 会不会写代码从来都不是关键问题，能不能快速拿到”足够真实的错误”才是。

四、一个被忽视的问题：你的业务理解力，决定了 Vibe Coding 的上限

聊了这么多 Vibe Coding 能做到什么，现在来聊一个更不舒适的问题——它为什么在你手里没那么好用？

大多数关于 Vibe Coding 局限性的讨论，集中在工具侧：AI 生成的代码质量不稳定、复杂系统难以维护、存在安全隐患……这些都是真实的问题，但它们都是”工具的天花板”。还有一个更值得产品经理关注的天花板，来自使用者本身。

AI 能把你的模糊想法变成可以运行的代码，但如果你的业务理解本身就是模糊的，AI 只是把这种模糊放大并具象化了。

举一个具体的例子。假设你在做一个给销售团队用的线索管理工具。你告诉 AI：”帮我做一个可以管理销售线索的系统，需要有状态流转、跟进记录和优先级排序。”AI 会生成一个看起来很完整的系统。但这里有几个问题是 AI 回答不了的：

• 销售线索的”状态”到底怎么定义？在你们公司的业务流程里，”跟进中”和”意向明确”是两个状态还是同一个状态？
• 优先级”应该根据什么来排？客户规模？上次联系时间？还是销售主管的主观判断？
• 不同销售的线索应该互相可见吗？还是只有自己能看到？

这些问题，是业务逻辑问题，不是技术问题。AI 不知道你的公司怎么运作，也不知道你的销售团队真正的痛点在哪里。你给 AI 的提示词，本质上是你业务理解的外化。你理解得越深，提示词越精准，产出越接近真正需要的东西；你理解得越浅，提示词越模糊，产出就越像一个”好看但没用”的演示。

这里有一个反直觉的推论：Vibe Coding 不是降低了对产品思维的要求，而是提高了——因为它让你没有地方藏。

以前 PM 可以靠一份写得漂亮的需求文档来掩盖业务理解的模糊。文档写得有逻辑、有框架、有数据，看起来很专业——但具体的业务细节，在实现的过程中会有研发来追问，会有 QA 来测试边界，这些环节在客观上起到了”填充业务理解漏洞”的作用。

Vibe Coding 去掉了这些中间环节。你的思维直接映射成产品，没有人帮你兜底。你理解有多少，做出来就有多少。这是 Vibe Coding 对产品思维要求更高，而不是更低的根本原因。

五、”AI 废人”与”AI 驾驶员”的分野，对 PM 同样成立

Anthropic 在一项关于 AI 辅助编程的研究中提出了一个值得关注的发现：工具相同，但使用姿势不同的开发者，能力成长轨迹完全不同。主动用 AI 来学习、试错、迭代的人，能力在持续增长；而把 AI 当成”外包对象”、只要结果不管过程的人，对工具的依赖越来越强，独立判断能力却在下降。

这个结论被很多人解读为”程序员要小心”，但我觉得它对产品经理同样成立——甚至更成立，因为 PM 本来就不是以写代码为核心职责的，这个”依赖陷阱”更难被察觉。

在 PM 群体中，我观察到两种明显不同的使用姿势：

第一种：甩手掌柜型

需求想法 → 扔给 AI → 等待产出 → 觉得差不多就用 → 再扔给 AI

这类 PM 用 Vibe Coding 的方式，和以前甩需求给研发的方式如出一辙。换了执行者，但自己的思考深度没有变。AI 给什么就用什么，碰到问题不知道从哪里改起，最终产出的质量高度依赖 AI 的”运气”。

第二种：主动校准型

需求想法 → 先自己想清楚核心逻辑 → 给 AI 结构化的描述 → 拿到产出 → 主动找问题 → 修正假设 → 重新迭代

这类 PM 把 AI 当成一个”快速执行自己思路”的工具，自己始终是思考的主体。他们用 Vibe Coding 不是为了省去思考，而是为了让思考的结果更快落地，更快被检验。

区分这两种姿势的关键，不是”你用了多少次 AI”，而是”你有没有在每次用完之后，比用之前更理解这个问题”。

工具会进化，但”用完之后对问题的理解有没有加深”这件事，是你自己决定的，AI 帮不了你。

六、什么时候该用，什么时候该停：给自己画一条线

聊到这里，很多人可能会问：那到底什么场景适合用 Vibe Coding，什么场景不适合？

大多数文章的回答是列一个场景清单：适合做原型、适合做内部工具、不适合做大型系统……这种清单有参考价值，但用起来不够顺手，因为现实情况往往是模糊的、混合的。

我更愿意给一个判断框架，而不是一份清单。核心逻辑只有两个维度：

维度一：验证成本 vs 实现成本

当一个需求的”验证成本”（搞清楚这个方向对不对需要花多少时间和资源）远高于”实现成本”（把它做出来需要多少资源）时，Vibe Coding 的价值最大。

因为 Vibe Coding 本质上是在压缩验证成本。如果验证本来就不贵，它的贡献就有限；如果验证成本很高，它的介入就能显著改变决策效率。

维度二：维护成本 vs 生成成本

当一个系统的”维护成本”（上线后持续迭代、修复、扩展需要多少投入）远高于”生成成本”（第一次做出来需要多少投入）时，Vibe Coding 的风险最高。

因为 Vibe Coding 生成的代码通常在”可维护性”上是有缺陷的，这个缺陷在一次性的验证场景中无关紧要，但在长期运营的系统中会累积成严重的技术债。

用这个框架来检验几个常见场景：

场景一：做一个新功能方向的点击原型

验证成本/实现成本：高（方向对不对很难判断，但做出来快）

维护成本/生成成本：低（原型不需要维护）

→ 强烈推荐用 Vibe Coding

场景二：为销售团队搭一个内部用的线索追踪表

验证成本/实现成本：中（需求相对清楚）

维护成本/生成成本：中（内部工具有迭代需求，但不是核心系统）

→ 可以用，但需要评估后续维护由谁负责

场景三：做一个要对接支付系统的电商功能

验证成本/实现成本：不高（需求相对明确）

维护成本/生成成本：极高（涉及安全、合规、高并发）

→ 不要用 Vibe Coding，走正规工程流程

这个框架的本质，是帮你在下手之前想清楚”这件事用 Vibe Coding 的目的是什么”。目的是验证，它是你的好工具；目的是交付可长期运行的系统，它大概率会给你挖坑。

七、工具会进化，但判断力不会自动生长

我很少在文章里写”时代来了”这样的句子，不是因为我不相信 AI 的影响力，而是因为这种句子读完会让人亢奋，但不知道该做什么。

所以这篇文章的结尾，我想说一件更朴素的事：

工具在进化，而且进化速度比我们预期的快。 今天 Vibe Coding 还有很多局限，半年后这些局限里有一部分会消失，一年后会消失更多。你今天读到的关于 AI 编程局限性的文章，里面有相当一部分结论的保质期不超过十八个月。

但有一件事，工具的进化解决不了——那就是你自己的判断力。

Vibe Coding 能帮你更快地”把想法变成可以点击的东西”，但它帮不了你判断：

1. 这个想法值不值得做？
2. 做到什么程度算够用，不需要再投入了？
3. 用户真正的问题是你以为的那个问题吗？

这三个问题，是产品经理这个职业存在的核心理由，也是任何工具都不会替代你思考的地方。

我有时候觉得，Vibe Coding 的出现，对产品经理来说是一次很好的”照镜子”机会——它在放大你的业务理解，也在暴露你的认知空洞。镜子里的结果，是你自己的。

我的建议很简单：不要把精力全部放在”学会用工具”上，要同步花时间在”加深业务理解”上。前者会越来越容易，因为工具会越来越好用；后者永远不会自动发生，因为业务理解是要靠你主动去建立的。

这不是一个”拥抱 AI”或者”警惕 AI”的问题，这是一个你想成为什么样的产品经理的问题。工具给了你更快行动的能力，但行动的方向，始终要你自己来判断。