前言

現在寫程式，遇到不懂的地方可以問 AI，想新增功能時，也能請 AI 直接幫忙寫 Code。開發速度確實變快了，但有時候改著改著，專案反而變得更難維護。

原本只是想新增一個功能，AI 卻順手改了好幾個檔案，發現有 Bug 之後，再請 AI 修正，結果又冒出其他問題。最後花在檢查和修改的時間，可能比自己動手寫還多。

這就是使用 AI Coding 時很容易遇到的狀況。AI 可以快速產生程式碼，但要讓它寫出符合需求、容易維護的 Code，還是需要一些方法。

Vibe Coding 是什麼？

Vibe Coding 指的是透過自然語言描述需求，讓 AI 協助產生程式碼，再根據執行結果持續調整的一種開發方式。

例如，我們可以直接告訴 AI：「幫我做一個登入頁面」，讓它產生 HTML、CSS 和 JavaScript；也可以請它替 Express 專案新增 API，省下查文件和撰寫程式碼的時間。

這種方式很適合快速驗證想法，或是製作小型作品。不過，當專案開始有資料庫、使用者權限和多個 API 時，只靠幾句話就讓 AI 開始寫程式，很容易讓功能逐漸偏離原本的設計。

尤其每次遇到問題，都直接請 AI 修改程式碼，卻沒有先了解原因，程式就可能越補越多，原本的架構也會慢慢失去一致性。

為什麼一句「幫我做登入功能」還不夠？

假設我們正在開發一個使用 Node.js、Express 和 PostgreSQL 的個人筆記系統，現在想新增登入功能。

如果只告訴 AI：

幫我做登入功能。

AI 就得自己推測我們需要什麼。它可能自行決定 API 路徑、資料表欄位、密碼驗證方式，甚至選擇一套和專案原本設計不同的做法。

例如，前後端原本已經約定使用 HttpOnly Cookie 傳遞登入憑證，AI 卻改成要求前端透過 Authorization Header 傳送 Bearer Token，整合方式就會和原本的規劃不同。

這兩種方式都有適合的使用情境，問題在於 AI 沒有遵守專案已經確認的設計。當需求沒有說清楚時，AI 就只能根據常見的做法自行判斷，產生的程式碼自然不一定符合我們的預期。

因此，在請 AI 動手之前，可以先想清楚幾件事：這個功能要解決什麼問題、使用者會輸入哪些資料、系統應該怎麼處理，以及什麼情況才算完成。

如果連需求都還沒想清楚，也不用急著叫 AI 開發，可以先請它協助整理想法，找出還需要討論的地方。

先確認專案現況，再決定怎麼做

新增功能時，除了要說清楚需求，也需要考慮目前專案的狀況。

假設我們已經把 API 分成 routes、controllers、services 和 entities 等目錄，也有統一的錯誤處理 Middleware。如果 AI 沒有掌握這些設計，就可能把資料庫查詢、資料驗證和商業邏輯全部寫在同一個 Controller 裡。

功能也許能正常運作，但程式碼會逐漸偏離原本的架構，之後要新增功能或修正錯誤，就會變得比較麻煩。

如果是既有專案，開始修改之前，應先確認目前有哪些相關功能、這次修改會影響哪些地方，以及哪些原有設計需要沿用。這樣能減少 AI 重複建立功能，或是修改到不相關程式碼的機會。

如果是從零開始的新專案，情況就不太一樣了。因為還沒有既有架構可以參考，需要先決定產品要做什麼、第一個版本包含哪些功能，再逐步規劃技術選型、資料表和模組分工。

例如，想開發一個個人筆記系統，可以先完成註冊、登入和筆記 CRUD，之後再加入全文搜尋或 AI 問答。先確認最重要的功能，能避免 AI 一開始就產生大量還沒確定是否需要的程式碼。

既有專案需要理解原本的設計，新專案則需要建立自己的設計。兩者的起點不同，但都應該在實作前先確認要做什麼，以及準備怎麼做。

至於如何提供專案資訊、讓 AI 掌握架構與開發規範，則會在下一篇再進一步介紹。

Spec → Plan → Implement：把開發流程拆開

想減少 AI 產生的程式碼越改越亂，可以把開發過程拆成三個階段：先確認需求，再規劃做法，最後才開始實作。

這套流程適用於既有專案，也適用於從零開始的新專案。差別在於，既有專案需要考慮原本的架構；新專案則要先定義產品需求，再逐步建立架構與開發規範。

Spec：先把需求說清楚

Spec 是 Specification 的簡稱，可以理解成需求規格。這個階段要先把功能、預期行為和限制整理清楚，讓 AI 知道要完成什麼，以及哪些事情需要特別注意。

如果是從零開始，可以先釐清產品要解決什麼問題、預計給誰使用，以及第一個版本需要哪些核心功能。等到大方向確定後，就可以挑選其中一項功能，整理成具體的需求。

以下以已經建立的 Express 專案為例，假設目前使用 TypeORM 操作 PostgreSQL，現在要新增建立筆記的 API，可以先寫出以下規格：

功能：建立筆記

API：POST /api/notes

輸入資料：
- title：必填字串
- content：字串，可為空

處理流程：
- 確認使用者已通過登入驗證。
- 檢查 title 是否符合要求。
- 使用目前登入者的身分建立筆記。
- 將筆記儲存至 PostgreSQL。

錯誤處理：
- 未登入時拒絕建立筆記。
- 缺少 title 時回傳適當的錯誤訊息。
- 建立成功時回傳 201 Created。

限制：
- 沿用現有的 Express、TypeORM 和錯誤處理架構。
- 不新增不必要的套件。
- 不修改與這次功能無關的程式碼。

這份規格包含功能目標、輸入資料、處理流程、錯誤情況和限制，AI 就能根據這些條件規劃工作，完成後也比較容易確認結果是否符合預期。

需求不必一開始就寫得非常完整，可以先整理目前知道的資訊，再請 AI 找出還需要確認的地方。重點是讓雙方對功能有一致的理解，減少後續反覆修改的機會。

Plan：先確認要怎麼做

需求確認後，可以請 AI 先提出實作計畫，暫時不要直接修改檔案。

如果是既有專案，計畫應該說明哪些檔案需要修改、如何沿用目前的架構，以及可能影響哪些功能。如果是從零開始，則還需要討論技術選型、資料表設計、資料夾結構與模組分工。

以建立筆記 API 為例，可以這樣要求 AI：

請根據上述規格，先規劃建立筆記 API 的實作方式。

請列出：
1. 預計新增或修改的檔案。
2. 每個檔案負責的工作。
3. API 的執行流程。
4. 預計如何處理錯誤情況。
5. 完成後需要測試哪些案例。

請先提供計畫，等待確認後再開始實作。

收到計畫後，就可以檢查 AI 的安排是否合理。例如，是否重複建立已經存在的 Middleware、是否需要修改資料表，以及有沒有把不相關的功能一起改掉。

如果是全新專案，也可以在這個階段確認資料夾結構是否符合需求、資料表之間的關係是否合理，以及目前選用的技術是否真的有必要。

架構不需要一開始就設計得非常複雜，只要能支援目前的功能，並保留合理的擴充空間就好。先確認計畫，可以讓我們在程式碼產生之前發現設計上的問題，減少後續大幅修改的機會。

Implement：分階段開發

確認計畫之後，再讓 AI 開始修改程式碼，並要求它遵守剛才確認的需求與範圍。

請按照已確認的實作計畫開始開發。

請遵守以下原則：
- 沿用已確認的程式碼與架構。
- 只修改這次功能需要的檔案。
- 不自行增加未列入規格的功能。
- 完成後說明修改了哪些檔案，以及修改原因。
- 執行適合的測試，並回報實際測試結果。

這裡有一個很重要的觀念：不要一次讓 AI 寫完整個專案。

比起一次生成所有功能，更好的方式是先完成一條完整的開發流程。例如，先完成建立筆記的 API，確認資料確實寫入 PostgreSQL，API 也能正確回傳結果，再繼續開發其他功能。

每完成一個階段，就執行適合的測試，確認功能是否符合預期。這樣發生問題時，比較容易找出原因，也不會讓尚未驗證的程式碼不斷堆疊。

如果開發途中發現新的需求，也可以先更新規格，再調整實作計畫，不必一路靠臨時指令修補。

AI 寫完程式碼，為什麼還要 Review？

即使需求寫得很清楚，也不能直接假設 AI 產生的程式碼一定正確。

AI 可能誤解程式邏輯、使用不適合的函式，或是漏掉一些不容易從正常操作中發現的問題。即使 API 可以成功執行，也不代表它已經符合安全性、資料一致性和維護性的要求。

因此，完成實作之後，還是需要進行 Code Review。

首先，可以檢查 AI 修改了哪些檔案，以及每個修改是否真的有必要。如果只是新增一支 API，卻大幅調整其他模組，就應該確認原因，避免無關的修改增加後續維護成本。對於全新專案，也要確認新增的結構是否符合原本的規劃，避免出現重複的功能或不必要的複雜設計。

接著，可以對照需求規格逐項驗收。以建立筆記 API 為例，即使 API 回傳了 201 Created，還是需要確認筆記是否真的寫入資料庫、資料是否關聯到目前登入者，以及缺少必要欄位時是否有正確處理錯誤。

最後，還要確認測試是否涵蓋重要情況。除了正常流程，也要檢查未登入、缺少欄位和資料格式錯誤等案例。若 AI 回報測試成功，應確認它實際執行了哪些測試指令，以及結果是否符合預期，而不是只根據 AI 的文字回報就認定沒有問題。

如果不確定修改的內容，也可以請 AI 協助檢查：

請對照原本的需求規格，檢查這次修改的程式碼。

請找出：
1. 可能不符合需求的地方。
2. 潛在的安全性或資料處理問題。
3. 沒有必要的修改。
4. 尚未測試的情況。

請先列出問題與理由，不要直接修改程式碼。

不過，AI 自己檢查自己的程式碼仍然可能漏掉問題，因此可以搭配測試、Lint、型別檢查，以及人工閱讀 Git Diff。涉及身分驗證、權限或重要資料操作時，更應該仔細確認每個環節。

Code Review 的目的，是確認程式碼是否符合需求、修改是否合理，以及還有哪些風險需要處理。即使功能可以執行，也不代表整個實作就已經完成。

結語

AI 可以協助產生程式碼、整理需求，甚至提出架構方案，但這些結果仍然需要經過判斷與驗證。

從零開始的專案，要先決定產品方向與架構；接手既有專案，則要先理解原本的設計。接著透過 Spec、Plan 和 Implement，把大任務拆成可以逐步完成的小任務，再透過測試與 Code Review 確認結果。

當每一步都有明確的目標，也能逐步驗證成果，就比較不容易陷入不斷修改程式碼的循環。

不過，光是每次下指令時交代清楚還不夠。如果希望 AI 在不同任務中，都能掌握相同的專案資訊與開發規範，就需要進一步了解 Prompt、Context，以及專案指令檔的作用。

下一篇就來看看，如何讓 AI 更了解自己的專案，減少反覆交代的成本。