Vibe Coding正以驚人的速度重塑開發(fā)者的工作流程，但AI助手的局限性也讓項目陷入'修復(fù)同一bug'的惡性循環(huán)。本文從三層架構(gòu)設(shè)計到AI協(xié)同工作流，揭秘如何通過規(guī)劃-評審-修正的閉環(huán)體系，將失敗率降低90%的實戰(zhàn)方法論。

———— / BEGIN / ————

我從2025年開始接觸vibe coding，有成功也有失敗。第一次搭建出屬于自己的頁面時很震撼，但永遠陷在某個bug里解決不了的挫敗感也很強。

所以總結(jié)復(fù)盤了這些使用經(jīng)驗，希望能給你帶來一些幫助。

工具的對比與選擇

工具大致分為兩類：

1. 全包式應(yīng)用：幫你搞定一切（托管、數(shù)據(jù)庫、部署）

2. AI 助手：給你更多控制權(quán)，但需要你自己管理基礎(chǔ)設(shè)施

如果你剛?cè)腴T，從全包式應(yīng)用開始。當(dāng)你需要更多控制權(quán)，或碰到工具上限時，再轉(zhuǎn)向 AI 助手。

我嘗試過 Replit、Lovable、Codex 和 Claude Code。Claude Code 是我目前的首選。

但小項目我更喜歡Lovable（比如寵物的健康追蹤管理），不用操心 UX，界面又好看。

Vibe Coding工具

AI 編程智能體

VS Code、Windsurf、Cursor 這類集成開發(fā)環(huán)境（IDE）我沒有列入清單，不過它們很多都內(nèi)置了自己的編碼助手。Cognition 也做了編碼助手 Devin，但感覺也不太適合放在這里對比。

也沒有包含只做設(shè)計原型的工具，因為今天我們的重點是搭建應(yīng)用。

會在哪里出問題

選好工具之后，就可以開始干活了。

然而大多數(shù)項目就是從這里開始跑偏的。如果不清楚自己想要什么，或者頻繁改主意，最后就會得到一堆混亂的代碼。

Vibe Coding的惡性循環(huán)是：總在修復(fù)同一個bug

我們在過程中經(jīng)常會發(fā)現(xiàn)，你報了bug，AI說修好了，但其實沒有。

無論怎么說、怎么做，都很難真正修復(fù)。讓人非常崩潰。

這類問題通常源于幾個原因：

• 你對想要的東西描述不夠清晰

• 頻繁改主意，代碼里全是這些反復(fù)橫跳的痕跡

• 中途切換了技術(shù)棧，代碼不同部分用了不同技術(shù)（通常也是需求頻繁變更導(dǎo)致的）

要避免這種情況，你需要稍微理解軟件是如何運作的。軟件有三層：

1. 數(shù)據(jù)層：數(shù)據(jù)存儲的地方

2. 控制層：軟件運行的邏輯

3. 視圖層：你在界面上看到的內(nèi)容

大部分問題，都出在這三層不同步。

當(dāng)你最開始描述需求時，它會對需要存什么數(shù)據(jù)、邏輯如何運行、界面顯示什么做出假設(shè)。

改主意時，AI必須記得同時更新這三層。

如果只做簡單的界面修改，可能只影響視圖層，AI通常能直接處理好。

但如果是復(fù)雜的界面改動 —— 比如想改變排序方式 —— 可能會影響全部三層?？赡苄枰薷臄?shù)據(jù)存儲方式、數(shù)據(jù)獲取時機，才能改變界面排序。

這就是容易出錯的地方。當(dāng)AI忘記跨三層同步修改，或是修改不一致時，就會出現(xiàn)難以解決的 bug。

前面提到給寵物做的健康追蹤管理就是這樣。隨著不斷迭代，需求一直在變。我想優(yōu)化界面讓輸入更方便，但有些優(yōu)化意味著數(shù)據(jù)存儲方式也要改。改得越多，應(yīng)用里的隱蔽 bug 就越多。

而且問題會不斷累積。助手工作時，會傾向于遵循它看到的代碼模式。如果它看到的是過時的視圖層，在更新數(shù)據(jù)層時就可能做出錯誤決策。

這就是打破原有的項目重頭再來的原因。第二次描述應(yīng)用時，我已經(jīng)清楚自己想要什么，需求沒有變。Lovable 才能正確搭建三層結(jié)構(gòu)，我才能得到完全符合預(yù)期的結(jié)果。

規(guī)劃 – 評審 – 修正

先想清楚，再開始工作。

每個優(yōu)秀的產(chǎn)品經(jīng)理都知道，一個想法在理論上聽起來再好，一旦開始細化規(guī)格，問題就全出來了。細節(jié)才是成敗關(guān)鍵。

用vibe coding時，如果我們邊寫代碼邊細化細節(jié)，成本很高 —— 就算是AI 助手寫也一樣。而且很容易產(chǎn)生 bug。

AI會犯錯。每次你改主意，都會帶來一點技術(shù)債 —— 舊想法的痕跡還留在代碼里。這些技術(shù)債會迷惑后續(xù)處理，導(dǎo)致惡性循環(huán)，bug 越來越多。

永遠從規(guī)劃開始，在規(guī)劃方案上迭代。

有時只有一個模糊想法，要和AI一起把它變具體；有時我想法很明確，只需要寫下來。無論哪種方式，每一次都要從規(guī)劃開始。

不是PRD或者技術(shù)文檔，而是小批量、迭代式的方式工作，不是傳統(tǒng)大型項目那套流程。

系統(tǒng)性學(xué)習(xí)PMP的敏捷流程對個人小項目真的很有用。

實操案例

比如做一個回答產(chǎn)品探索相關(guān)問題的知識庫。我對它有宏大愿景，希望它成為全能的coach。但需要時間一步步實現(xiàn)。

第一個目標(biāo)，是能訪問我所有寫過的內(nèi)容，這樣它就能回答那些我已經(jīng)有文字答案的常見問題。但我不知道怎么實現(xiàn)。于是找 Claude 幫忙，一起制定方案。

Claude 梳理出了端到端的實現(xiàn)方式，解釋了很多我不懂的東西，幫我選擇服務(wù)商（比如向量數(shù)據(jù)庫和嵌入 API）。在討論中，我不斷補充和細化需求。我們用 Markdown 一起迭代，而不是用代碼。

方案成熟后，也不是立刻開始寫代碼。而是把方案交給AI評審。

在和 Claude 的初始對話中，Claude 會學(xué)到我的偏好（這是好事），也會學(xué)到我的偏見（這是壞事），它會繼承我的思維盲區(qū)。我們倆都很可能漏掉關(guān)鍵細節(jié)，這些細節(jié)在實現(xiàn)時會引發(fā)問題。

方案評審的任務(wù)，就是用全新視角評估方案。

用來驗證：

• 方案是否符合項目的編碼規(guī)范和架構(gòu)

• 沒有過度設(shè)計

• 找出邏輯缺陷、思考漏洞、思維盲區(qū)，或任何值得注意的問題

不修復(fù)方案，只反饋問題。

然后我把評審的意見發(fā)給規(guī)劃助手，一起整合有效反饋。我們重復(fù)這個循環(huán)，直到三方都滿意：我、規(guī)劃、方案評審。

這個循環(huán)對避免 “死活修不好 bug” 的惡性循環(huán)至關(guān)重要。從一份扎實的方案開始，意味著我們不是在代碼里思考，而是在文檔里思考，只有確定至少第一個小模塊要做什么時，才開始code。

用AI做規(guī)劃時，記住這些方法：

• 頻繁開啟新對話：對話越長，AI表現(xiàn)越差，這叫 “上下文腐爛”。我常分塊規(guī)劃：先做整體概覽，理解端到端流程，寫成文檔，然后開新對話。下一輪對話深入某個模塊，完成后清空上下文，再做下一部分。這樣能保證助手始終輸出高質(zhì)量結(jié)果。

• 不只依賴AI的訓(xùn)練數(shù)據(jù)：我經(jīng)常讓第二個AI調(diào)研我們要做的東西，研究最佳實踐，找出人們最常犯的錯誤，再把報告交給規(guī)劃助手。

• 質(zhì)疑AI的建議：如果某條建議聽起來不對勁，或你不確定，讓它澄清甚至解釋理由。你不一定是專家，但你應(yīng)該理解選擇，并確保走在正確的路上。

• 讓AI解釋所有你不懂的東西：碰到不熟悉、不理解的內(nèi)容，直接讓AI解釋。如果還不懂，告訴它哪里困惑，讓它再講一遍。

方案準(zhǔn)備好后，我會開啟全新對話，重置上下文窗口。讓新AI按方案實現(xiàn)功能。

如果規(guī)劃做得好，AI應(yīng)該能獨立完成實現(xiàn)。完成后，它通常會讓我測試改動。但我不會立刻測試。相反，我要讓另一個AI檢查編碼的工作。

這就是AI 代碼評審的作用。AI 代碼評審會閱讀方案、瀏覽代碼庫、評估改動，查找：

• bug

• 重復(fù)代碼

• 不必要的新模式或技術(shù)

• 過度設(shè)計

AI 代碼評審的核心目標(biāo)，就是幫我們避開惡性循環(huán)，確保編碼遵循良好的軟件工程實踐。

我會讓代碼評審重點關(guān)注三塊：

1. 異常處理

2. 測試覆蓋率

3. 安全性

剛開始做時，我對這三塊一竅不通，但一路學(xué)到了很多。這里我簡單講一下技巧。

異常處理

簡單說，就是出問題時代碼該如何響應(yīng)。比如代碼調(diào)用 API 時，如果出現(xiàn)以下情況該怎么辦：

1. API 不可用

2. 沒有訪問 API 的正確權(quán)限

3. 得到意料之外的響應(yīng)

我們經(jīng)常只為 “理想情況” 寫代碼 —— 一切順利的場景。異常處理，就是列出所有可能出錯的情況，以及每種情況該如何處理。

你不需要懂代碼里怎么寫異常處理，AI可以搞定。但你應(yīng)該問：

• 這一步可能出什么問題？

• 每種情況我們想怎么處理？

然后和AI討論這些決策。我會明確讓代碼評審AI檢查異常處理的缺失，標(biāo)出覆蓋不足的地方。如果不確定怎么修復(fù)，就和編碼AI討論。關(guān)鍵是讓專家?guī)湍阍u審 —— 這就是代碼評審助手的價值。

測試覆蓋率

代碼評審還會檢查測試：

• 有沒有完整的單元測試和集成測試？

• 集成測試是否覆蓋所有真實使用場景？

如果你不熟悉自動化測試，那就選：

• 單元測試：單獨測試代碼片段（比如這個函數(shù)是否按預(yù)期運行）

• 集成測試：測試所有部分如何協(xié)同工作

你不需要知道怎么寫，但如果你想讓代碼穩(wěn)定運行，就必須告訴 Claude 寫出合適的測試。

Claude 很會寫單元測試，但不太會寫正確的單元測試，所以需要代碼評審AI檢查。Claude 幾乎從不記得寫集成測試，所以我會讓評審AI專門檢查這兩項。

對于集成測試，讓代碼評審AI列出代碼所有可能的使用方式，然后根據(jù)使用場景決定哪些需要寫集成測試。

安全性

早期工具在安全方面做得很差，好在現(xiàn)在很多都大幅改善了。很多常用的工具都有自帶的安全檢查。

我讓 Claude 幫我給代碼評審寫安全檢查規(guī)則，它會檢查各種常見安全漏洞：

• 依賴漏洞：過時包或虛構(gòu)包名

• 代碼中的密鑰：不暴露 API key 或其他憑證

• IAM 角色遵循最小權(quán)限原則

輸入驗證

• 日志規(guī)范：不記錄敏感數(shù)據(jù)

• 跨域資源共享（CORS）配置

你不需要懂這些是什么。關(guān)鍵是讓編碼AI幫你確保應(yīng)用安全，并讓代碼評審AI驗證。

和方案評審一樣，代碼評審AI不修復(fù)問題，只寫出問題報告。我審閱后，把報告發(fā)給編碼AI。

我以前會讓編碼助手直接調(diào)用評審助手，讓它們自行迭代，但更多的時候是無休止地修復(fù)本不需要修的東西。所以我們?nèi)肆€是得保持在循環(huán)中。

和規(guī)劃一樣，代碼直到三方都滿意才算完成：我、編碼、代碼評審。

代碼評審幫我發(fā)現(xiàn)了無數(shù) bug。這一步看起來很繁瑣，尤其當(dāng)代碼表面上運行正常時。但長期來看，它會幫你節(jié)省大量時間，不用走到某個失敗臨界點然后從0開始。

出問題時如何恢復(fù)

就算你嚴(yán)格遵循規(guī)劃 – 評審 – 修正、實現(xiàn) – 評審 – 修正循環(huán)，問題仍然會出現(xiàn)。記住，AI會犯錯。

但別慌。大概率另一個AI能幫你解決。當(dāng)你碰到編碼AI死活修不好的 bug 時，別讓它繼續(xù)瞎試，那樣只會引入更多 bug。

相反：

• 開新對話

• 讓新AI看問題

• 明確告訴它：只診斷并反饋，不要直接修復(fù)

最后一點很重要，不能讓它隨便亂改代碼。

如果是特別難的 bug，我可能會開兩個甚至三個AI，用完全相同的提示詞，看它們是否得出同一個診斷結(jié)論。

只有確信找到真正原因后，才開始寫代碼。

人們很容易想當(dāng)然地判斷問題根源，其實根本不對。如果讓助手直接開始 “修復(fù)”，它會亂改很多不需要改的地方，反而帶來更多 bug。

永遠把診斷和修復(fù)分開。

從原型到生產(chǎn)，關(guān)鍵不在 “快”，而在穩(wěn)。清晰的需求、規(guī)范的架構(gòu)、嚴(yán)格的代碼評審、理性的問題排查，這些傳統(tǒng)編程的經(jīng)驗，在 AI 時代依然有效，甚至更加重要。

與其在混亂里反復(fù)試錯，不如用一套成熟流程避開 “惡性循環(huán)”，讓 AI 真正幫我們把想法落地成可用、可靠、可上線的產(chǎn)品。

本文來自公眾號：朱莉的產(chǎn)品筆記 作者：朱莉的產(chǎn)品筆記