Replit的AI編程Agent在代碼凍結期間，直接刪了生產數(shù)據(jù)庫。

更離譜的是，事后它還自信滿滿地說恢復不了，給出的說法全是誤導。

這件事之后，Replit的CEO只能公開道歉，承諾要加強隔離和防護措施。

這事兒才算把VibeCoding從“聽起來很酷的概念”拉回了現(xiàn)實。

本來很多人還把它當提升效率的神器，這下總算明白，把寫代碼的活兒交給AI，不只是省了點力氣，連責任邊界、風險控制這些核心問題，都跟著變復雜了。

Karpathy給VibeCoding下的定義挺極端，但很實在。

他說要“完全沉浸在氛圍里”，甚至“忘了代碼存在”。

本來我以為這只是夸張的說法，直到接觸了Cursor和Replit才發(fā)現(xiàn)，這倆工具真在往這個方向做，把想法直接變成代碼，不用盯著代碼一步步摳。

VibeCoding的核心不是讓AI補全代碼那么簡單。

以前產品經理提需求，得寫PRD，交給研發(fā)翻譯，再走設計、排期、測試一整套流程，才能摸到產品的真實體驗。

現(xiàn)在不一樣了，在Cursor里跟AI聊幾句，就能生成代碼、看到效果，不對再調整。

這種變化，直接改寫了產品團隊驗證需求的節(jié)奏。

但這里有個坑。門檻降下來的同時，麻煩也來了。

GNOME直接規(guī)定，不接受主要由AI生成的擴展。

理由很直白，AI寫的代碼風格亂、冗余多，還常有提示詞殘留的注釋，審核起來成本太高。

如此看來，VibeCoding不是萬能的，狂歡背后藏著不少隱患。

只會寫PRD的產品經理，怕是要被時代淘汰了。

以前寫PRD，核心是把邏輯寫全，讓研發(fā)能看懂翻譯成代碼。

這比寫PRD難多了。

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

這種轉變不是讓PM搶研發(fā)的飯碗，而是把驗證需求的閉環(huán)往前移，早點判斷這個方向值不值得做。

很多人誤以為代碼能跑起來就萬事大吉了，SimonWillison的提醒很犀利，要是你能審查、理解所有AI生成的代碼，那只是AI輔助，真正的VibeCoding，是你得接受自己不完全懂這些代碼。

所以PM不能只靠“點點點”驗收功能，還得判斷系統(tǒng)是不是在正確的軌道上。

VibeCoding確實能把產品從0做到1的速度提上來，但想從1做到N，光靠它可不行。

ClaudeCode的創(chuàng)造者就公開說過，嚴肅的、需要長期維護的核心業(yè)務軟件，靠VibeCoding根本撐不住。

我之前了解過一個初創(chuàng)公司的案例，用VibeCoding7天就做出了MVP，順利拿到了融資。

但后續(xù)問題不斷，因為AI生成的代碼架構混亂，最后沒辦法，只能花半年時間重新重構。

這就是VibeCoding的適用邊界，它適合快速驗證想法，卻扛不起規(guī)?；墓こ袒枨?。

對PM來說，不用自己寫代碼，但得懂點技術底層邏輯。

比如API調用、數(shù)據(jù)流向、權限控制這些基礎概念，至少得知道是什么意思。

不然AI生成的代碼出了問題，你都沒法說清錯在哪，想糾偏都像抽盲盒。

應對這些風險，PM得掌握三個層級的控制方法。

基礎層是做好沙箱測試和權限隔離，就像Replit出事后補的措施，先把“刪庫”這種致命風險擋在外面。

高階層就是建立專門的AI代碼審計流程，跟上GNOME這類平臺的審核要求。

AI不會淘汰產品經理，但會淘汰只會寫PRD的產品經理。

這句話不是危言聳聽。

VibeCoding的本質，是讓那些能清晰表達意圖、能控制風險、能驅動產品落地的PM，有了更大的發(fā)揮空間。

以前PM只能定義產品，能不能落地全看研發(fā)排期。

現(xiàn)在有了VibeCoding，不用等排期也能驗證想法。

這是最好的時代，也是篩選的時代。