刀哥那篇关于 PM 用 Vibe Coding 的文章，有几个点我想展开说说。

Vibe Coding 的本质不是"用嘴写代码"

很多人把 Vibe Coding 理解为自然语言编程——你说话，AI 写代码。但这个理解太浅了。

Vibe Coding 真正的变化是：把编程的反馈循环从"分钟级"压缩到了"秒级"。

传统开发流程：想清楚需求 → 写代码 → 跑起来看效果 → 改。这个循环的瓶颈在"写代码"这一步，通常需要几十分钟到几个小时。Vibe Coding 把这个环节压缩到了几秒。你描述需求，AI 立刻出结果，你看效果，不满意再说一遍，再出。

这不是"用嘴写代码"，这是用判断力编程。你不需要知道怎么写，但你需要知道"什么是对的"。而判断"什么是对的"——恰好是产品经理的核心能力。

这解释了为什么 Vibe Coding 对 PM 的赋能比对外行更大。外行连"什么是对的"都判断不了，PM 至少知道按钮该放哪、流程该怎么走、用户会卡在哪个环节。

但"能跑"和"能用"之间有一道巨大的鸿沟

文章说"用它验证想法，别用它做产品"，这句话我完全同意，但原因可能比作者想的更复杂。

Vibe Coding 生成的代码最大的问题不是质量差，而是没有设计意图。

一个有经验的开发者写代码时，脑子里有一整套架构：错误怎么处理、扩展性怎么留、性能瓶颈在哪里、未来改起来方便不方便。这些不是语法知识，而是设计思维。

AI 生成的代码是"能跑就行"。它没有设计意图，因为它不知道你要跑多久、会有多少人用、未来要加什么功能。它只是在当前约束下找到了一个能跑的解法。

这就是为什么 Vibe Coding 做原型没问题，做产品就会埋雷。原型只需要"看起来像"，产品需要"经得起考验"。

PM 的 Vibe Coding 能力边界在哪里

我觉得可以分三个层次：

第一层：交互原型。能点、能跑流程、能展示给团队和客户。这是 Vibe Coding 最擅长的，也是最安全的用途。做坏了成本很低，做对了价值很高。

第二层：内部工具：数据看板、自动化脚本、批量处理工具。这类工具用户少、容错率高、不需要高并发。Vibe Coding 做这类东西完全够用，而且效率远超等开发排期。

第三层：产品级应用。这是禁区。不是因为你写不好，而是因为你写不了。不是说 PM 没能力写好代码，而是 PM 的时间价值不在这上面。你花一周调好的并发问题，开发可能半小时就解决了。你的时间应该花在判断"做什么"上，而不是"怎么实现"上。

一个经常被忽视的收益：沟通成本

文章提到了"沟通成本砍掉一半"，但我觉得这个价值被低估了。

传统的 PRD（产品需求文档）是文字描述+静态线框图。开发看完之后，脑子里重建的是一个三维的、动态的产品模型。这个重建过程会有大量信息丢失——这就是"开发做出来不是我想要的"的根本原因。

如果 PM 能用 Vibe Coding 做一个能跑的原型，开发看到的就是一个已经存在的、可以交互的、有具体行为的东西。不需要重建模型，只需要理解逻辑。这个差距不是"一半"，可能是数量级的。

最后

Vibe Coding 不会替代开发者，但它会让那些不用它的 PM 显得落后。不是因为他们不会写代码，而是因为他们失去了一个让想法快速落地的工具。

编程的门槛正在消失。判断的价值正在上升。这对 PM 来说是个好消息。