[AI 分享] Vibe Coding 專案不失控的工作流

 [AI 分享] Vibe Coding 專案不失控的工作流

摘要 : 用 AI 做 Vibe Coding 前先定需求、打地基、立規矩；開發中小步迭代、限制變更與守住安全，才能避免專案失控。

內容:

最近 Vibe Coding 很火，很多人用 AI 推進專案的速度非常快，但常見的問題是：前期很順，後期程式碼卻越來越亂，最後變成難以維護的「屎山」。一旦持續在混亂的基礎上修改，就容易牽一髮動全身，甚至讓整個專案崩盤。

問題的核心不在於 AI 強不強，而在於 Vibe Coding 並不是把工作直接丟給 AI 就好。真正重要的是，人仍然需要建立一套工程流程去駕馭 AI。以下整理出一套標準工作流，分成「開發前 9 個步驟」與「開發中 5 個關鍵點」，目的就是提高專案成功率。

開發前的 9 個步驟，可以理解為在 AI 寫下第一行程式碼之前，先把地基打好。這 9 步又可分成三個階段：定圖紙、打地基、立規矩。

第一階段是「定圖紙」。第一步不是急著寫程式，而是先導需求。可以像和朋友聊天一樣，把痛點、目標使用者、使用場景，以及理想中的核心功能都告訴 AI。這個階段先追求資訊量，不必過度強調形式上的嚴謹。

第二步是把需求整理成 PRD 文件。這份文件最好結構化，包含功能列表、使用者流程、頁面清單等內容。但更重要的是，每個功能都要補上驗收標準。所謂完成不能只寫一句「登入成功」，而是要定義清楚：登入失敗會怎麼提示、是否會鎖定帳號、登入成功後跳轉到哪裡。若沒有驗收標準，AI 往往會越寫越發散。

第三步是提早定好視覺方向與頁面框架。可以找兩到三個參考網站，或請 AI 提出幾種風格方案，再從中決定導航欄配置、頁面區塊差異，以及整體風格是簡約、華麗或其他方向。這樣做是為了避免 AI 在開發功能時，同時不斷推翻 UI 設計。

第二階段是「打地基」。第四步是明確專案邊界與非功能需求。可以先回答三個問題：這個專案是本地自用還是要公開上線？是否涉及使用者資料、支付或隱私合規？效能與成本有沒有上限？安全、效能、可用性、成本這些非功能需求若沒先說清楚，後面通常都得返工。

第五步是鎖定技術棧。原則不是越新潮越好，而是越可驗證越好。主流技術通常更穩定，因為資料較多、工具鏈成熟，AI 也比較不容易亂編。但真正關鍵的是：你選用的技術是否有足夠的官方文件、社群資源、清楚範例，並且能跑測試、能做 code review。重點不是追求最新，而是追求可控與可查證。

第六步是請 AI 先產出一份輕量化架構草案。內容可以包含目錄分層方式、核心模組、資料模型，以及哪些邏輯必須放在服務端。這份架構不需要一開始就寫死，它應該可以迭代，但每次調整都必須記錄原因，避免架構演變失去脈絡。

第三階段是「立規矩」。第七步是把專案核心資訊固化成文件，作為 AI 的全域上下文。可以至少準備三份文件，例如 PRD.md、Arc.md、Project.md。前者描述需求，第二份描述架構，第三份記錄專案目前進度、已知問題與下一步計畫。每逢重大變動，這三份文件都要同步更新，否則 AI 會依照舊的理解去產生新的程式碼。

第八步是制定開發規範並建立參考資料。要讓 AI 有標準可依循，例如明確規定使用 TypeScript、元件命名方式、檔案大小上限等。同時也可以建立一個 Reference 資料夾，放入自己認可的按鈕、表單、彈窗等標準實作，讓 AI 能照著一致風格去生成。

第九步是在開始寫第一行程式碼前，就先把 Git 與品質閘門建立起來。Git 是版本管理工具，也可以視為安全帶。當 AI 把程式碼寫壞時，可以快速回溯到先前穩定版本；透過分支管理，也能讓不同功能並行開發，降低互相干擾與衝突風險。

完成開發前的 9 個步驟後，就進入開發中的 5 個關鍵點。這裡最重要的一句話是：人負責邊界與驗收，AI 負責體力活。

第一個關鍵點是堅守小步迭代與 MVP 原則。不要一次讓 AI 寫一大坨功能，而是一次只做一個可驗證的小切片。例如先做到頁面能打開，再做到表單能提交，再做到服務端能儲存，接著驗證權限，再到列表展示。每完成一個可跑通的小切片，就測試、檢查、提交 Git 一次。

第二個關鍵點是人類必須介入模組拆分。不能放任 AI 把所有程式碼都塞進同一個檔案。雖然短期看起來進展很快，但後期要查找某個功能、維護某段邏輯時，會非常痛苦。

第三個關鍵點是限制 AI 權限，禁止它擅自主導變更。可以透過狀態摘要管理上下文，也可以在每次任務結尾明確補充限制，例如：「只修改我指定的檔案與範圍，不要順手重構，不要改 UI 風格，不要動無關邏輯。」因為你只是叫它修一顆按鈕，它卻可能順便把整頁都重寫。

第四個關鍵點是守住安全底線，而且這必須是一份具體清單，而不是口號。AI 寫程式常常只求能跑，不會預設替你做好安全設計。因此至少要盯住幾個底線：API key 不要放前端，不要提交進版本庫，要透過環境變數與服務端調用；服務端必須進行驗證與授權校驗，不能信任前端輸入。

第五個關鍵點是要科學地處理報錯。遇到錯誤時，可以先把錯誤資訊交給 AI 修一次；但如果連續兩次都沒有新增證據，只是在猜，就應該立刻停下來，不要讓它繼續盲修。正確的做法分三步：第一，先做最小重現，把問題縮小到最小輸入；第二，加日誌、加斷點，列印關鍵變數與分支；第三，在有新證據的前提下再讓 AI 協助分析與修復。

總結來說，AI 能大幅提升 Vibe Coding 的速度，但不能取代工程紀律。真正穩定的做法，是在開發前先定需求、定驗收、定架構、定規則；開發中則堅持小步迭代、人類把關、限制 AI 變更範圍、守住安全底線，並用有證據的方法處理錯誤。這樣才能讓 AI 成為加速器，而不是把專案一步步推向失控。