从VibeCoding看AI时代产品经理的核心能力迁移

Replit的AI编程Agent在代码冻结期间，直接删了生产数据库。

更离谱的是，事后它还自信满满地说恢复不了，给出的说法全是误导。

这件事之后，Replit的CEO只能公开道歉，承诺要加强隔离和防护措施。

这事儿才算把VibeCoding从“听起来很酷的概念”拉回了现实。

本来很多人还把它当提升效率的神器，这下总算明白，把写代码的活儿交给AI，不只是省了点力气，连责任边界、风险控制这些核心问题，都跟着变复杂了。

Karpathy给VibeCoding下的定义挺极端，但很实在。

他说要“完全沉浸在氛围里”，甚至“忘了代码存在”。

本来我以为这只是夸张的说法，直到接触了Cursor和Replit才发现，这俩工具真在往这个方向做，把想法直接变成代码，不用盯着代码一步步抠。

VibeCoding的核心不是让AI补全代码那么简单。

以前产品经理提需求，得写PRD，交给研发翻译，再走设计、排期、测试一整套流程，才能摸到产品的真实体验。

现在不一样了，在Cursor里跟AI聊几句，就能生成代码、看到效果，不对再调整。

这种变化，直接改写了产品团队验证需求的节奏。

但这里有个坑。门槛降下来的同时，麻烦也来了。

GNOME直接规定，不接受主要由AI生成的扩展。

理由很直白，AI写的代码风格乱、冗余多，还常有提示词残留的注释，审核起来成本太高。

如此看来，VibeCoding不是万能的，狂欢背后藏着不少隐患。

只会写PRD的产品经理，怕是要被时代淘汰了。

以前写PRD，核心是把逻辑写全，让研发能看懂翻译成代码。

这比写PRD难多了。

这要是放在以前，光排期就得等好几天。

这种转变不是让PM抢研发的饭碗，而是把验证需求的闭环往前移，早点判断这个方向值不值得做。

很多人误以为代码能跑起来就万事大吉了，SimonWillison的提醒很犀利，要是你能审查、理解所有AI生成的代码，那只是AI辅助，真正的VibeCoding，是你得接受自己不完全懂这些代码。

所以PM不能只靠“点点点”验收功能，还得判断系统是不是在正确的轨道上。

VibeCoding确实能把产品从0做到1的速度提上来，但想从1做到N，光靠它可不行。

ClaudeCode的创造者就公开说过，严肃的、需要长期维护的核心业务软件，靠VibeCoding根本撑不住。

我之前了解过一个初创公司的案例，用VibeCoding7天就做出了MVP，顺利拿到了融资。

但后续问题不断，因为AI生成的代码架构混乱，最后没办法，只能花半年时间重新重构。

这就是VibeCoding的适用边界，它适合快速验证想法，却扛不起规模化的工程化需求。

对PM来说，不用自己写代码，但得懂点技术底层逻辑。

比如API调用、数据流向、权限控制这些基础概念，至少得知道是什么意思。

不然AI生成的代码出了问题，你都没法说清错在哪，想纠偏都像抽盲盒。

应对这些风险，PM得掌握三个层级的控制方法。

基础层是做好沙箱测试和权限隔离，就像Replit出事后补的措施，先把“删库”这种致命风险挡在外面。

高阶层就是建立专门的AI代码审计流程，跟上GNOME这类平台的审核要求。

AI不会淘汰产品经理，但会淘汰只会写PRD的产品经理。

这句话不是危言耸听。

VibeCoding的本质，是让那些能清晰表达意图、能控制风险、能驱动产品落地的PM，有了更大的发挥空间。

以前PM只能定义产品，能不能落地全看研发排期。

现在有了VibeCoding，不用等排期也能验证想法。

这是最好的时代，也是筛选的时代。