非技術人也能看懂：AI 編程從原型到上線的完整流程

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

———— / BEGIN / ————

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

所以總結復盤了這些使用經驗，希望能給你帶來一些幫助。

工具的對比與選擇

工具大致分為兩類：

1. 全包式應用：幫你搞定一切（托管、數據庫、部署）

2. AI 助手：給你更多控制權，但需要你自己管理基礎設施

如果你剛入門，從全包式應用開始。當你需要更多控制權，或碰到工具上限時，再轉向 AI 助手。

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

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

Vibe Coding工具

AI 編程智能體

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

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

會在哪里出問題

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

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

Vibe Coding的惡性循環是：總在修復同一個bug

我們在過程中經常會發現，你報了bug，AI說修好了，但其實沒有。

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

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

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

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

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

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

1. 數據層：數據存儲的地方

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

3. 視圖層：你在界面上看到的內容

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

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

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

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

但如果是復雜的界面改動 —— 比如想改變排序方式 —— 可能會影響全部三層。可能需要修改數據存儲方式、數據獲取時機，才能改變界面排序。

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

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

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

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

規劃 – 評審 – 修正

先想清楚，再開始工作。

每個優秀的產品經理都知道，一個想法在理論上聽起來再好，一旦開始細化規格，問題就全出來了。細節才是成敗關鍵。

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

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

永遠從規劃開始，在規劃方案上迭代。

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

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

系統性學習PMP的敏捷流程對個人小項目真的很有用。

實操案例

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

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

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

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

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

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

用來驗證：

• 方案是否符合項目的編碼規范和架構

• 沒有過度設計

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

不修復方案，只反饋問題。

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

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

用AI做規劃時，記住這些方法：

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

• 不只依賴AI的訓練數據：我經常讓第二個AI調研我們要做的東西，研究最佳實踐，找出人們最常犯的錯誤，再把報告交給規劃助手。

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

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

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

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

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

• bug

• 重復代碼

• 不必要的新模式或技術

• 過度設計

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

我會讓代碼評審重點關注三塊：

1. 異常處理

2. 測試覆蓋率

3. 安全性

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

異常處理

簡單說，就是出問題時代碼該如何響應。比如代碼調用 API 時，如果出現以下情況該怎么辦：

1. API 不可用

2. 沒有訪問 API 的正確權限

3. 得到意料之外的響應

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

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

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

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

然后和AI討論這些決策。我會明確讓代碼評審AI檢查異常處理的缺失，標出覆蓋不足的地方。如果不確定怎么修復，就和編碼AI討論。關鍵是讓專家幫你評審 —— 這就是代碼評審助手的價值。

測試覆蓋率

代碼評審還會檢查測試：

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

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

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

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

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

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

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

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

安全性

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

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

• 依賴漏洞：過時包或虛構包名

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

• IAM 角色遵循最小權限原則

輸入驗證

• 日志規范：不記錄敏感數據

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

你不需要懂這些是什么。關鍵是讓編碼AI幫你確保應用安全，并讓代碼評審AI驗證。

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

我以前會讓編碼助手直接調用評審助手，讓它們自行迭代，但更多的時候是無休止地修復本不需要修的東西。所以我們人力還是得保持在循環中。

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

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

出問題時如何恢復

就算你嚴格遵循規劃 – 評審 – 修正、實現 – 評審 – 修正循環，問題仍然會出現。記住，AI會犯錯。

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

相反：

• 開新對話

• 讓新AI看問題

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

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

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

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

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

永遠把診斷和修復分開。

從原型到生產，關鍵不在 “快”，而在穩。清晰的需求、規范的架構、嚴格的代碼評審、理性的問題排查，這些傳統編程的經驗，在 AI 時代依然有效，甚至更加重要。

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

本文來自公眾號：朱莉的產品筆記 作者：朱莉的產品筆記