Vibe coding 通常被描述為：人提出意圖，模型將它轉化為可運作的程式碼。這對原型很方便，作為交付流程卻有風險。成果出現得越快，就越容易忽略任務悄悄改變的時刻：模型新增依賴套件、在各層之間轉移責任、放寬驗證，或建立第二個事實來源。

問題不在於 AI「寫出糟糕的程式碼」；人也會這麼做。問題在於速度不對等：模型在相同時間內產生的變更多於人能仔細檢查的量。因此，品質取決於圍繞模型建立的管控流程能處理多少檢查，而非模型本身有多強。

先訂出任務契約

在交給代理之前，先確認四件事：可觀察的行為、變更界線、禁止的操作與驗證指令。「加入搜尋」是不夠明確的任務。「依標題篩選六篇本機文章，不新增伺服器和依賴套件；沒有相符結果的查詢顯示空白狀態；以指定測試驗證」才是可執行的契約。

  • 行為：變更後使用者能做什麼。
  • 範圍：允許修改哪些檔案、服務與資料。
  • 不變條件：哪些相容性與安全性必須維持。
  • 證據：測試、建置、差異分析或可重現的情境。

MCP 是權限界線，而非魔法

Model Context Protocol 透過 host、clients 與 servers，將 AI 應用程式與工具及資料連接。這套架構的價值不只在於通用連接方式，而在於可以授予有限能力：閱讀特定文件、檢查任務、取得結構定義，或執行受限操作。伺服器不應自動看見整段對話及所有相鄰資料來源。

實務上，這意味著最小權限原則。讀取儲存庫的工具不必具備推送權限；查看行事曆不應能建立會議；存取正式環境記錄不需要修改環境變數的能力。工具介面越具體，代理需要猜測的地方就越少，人也越容易評估呼叫後果。

測試表明意圖，差異顯示代價

新增功能時，先要有因預期原因而失敗的測試。完成最小實作後，該測試應通過，整套檢查也應維持成功。這個順序很重要：在程式碼之後才寫的測試，很容易迎合已選定的方案，而且可能從未證明它能抓出錯誤。

測試之後還要檢查差異。重點不是風格，而是責任的改變：資料現在來自哪裡、誰驗證輸入、在哪裡處理錯誤、新增了哪些權限，以及是否出現新的網路請求或依賴套件。好的變更應該小而清楚，且只包含任務契約要求的內容。

  • 失敗的測試應因缺少預期行為而失敗，而非因為打字錯誤。
  • 最少量的程式碼讓測試通過，且不暗中擴大範圍。
  • 建置、型別與 lint 檢查分別以獨立指令執行。
  • 新增依賴套件須有實際必要性，並記錄在鎖定檔中。
  • 關鍵權限與外部操作需要人工確認。

哪些決策仍由人負責

模型可以提出架構，卻不知道遷移的實際成本與企業能承受的風險。它可以產生 SQL，但不應自行決定哪些資料可以刪除。它可以草擬郵件，但寄給外部收件者是另一項操作。實用的分工很簡單：AI 研究與執行，人確認不可逆的後果與完成標準。

對程式碼來說，資料結構、存取權、計費、驗證、外部訊息與正式環境部署的變更，都應設置這類關卡。事先為每項關卡操作指定負責人、檢查方式與復原方法。這不是官僚程序，而是在犯錯代價高的地方控制速度。

單一任務的實作流程

  • 訂出契約，並在產生程式碼前閱讀現有程式碼。
  • 只提供代理必要的脈絡與有限工具。
  • 要求先加入會失敗的測試，並說明預期失敗原因。
  • 允許最小實作，然後執行完整檢查。
  • 檢查差異中的資料界線、權限、錯誤與依賴套件。
  • 建立小型提交後，再進入下一項行為。

當「感覺完成了」由可觀察的證據取代，Vibe coding 才成為工程工具。此時，模型的速度便不再與品質衝突：速度用於小步迭代，而非製造大量未經驗證的程式碼。

如何在團隊中導入流程

不要從全面允許「使用 AI」開始，而是先選一類低風險任務：現有行為的測試、文件、小幅介面調整，或不改變契約的局部重構。用十項任務衡量到完成成果的時間、差異規模、審查退回次數與合併後缺陷。應比較完成的工作，而非產生第一個檔案用了幾分鐘。

為了能重複執行，保留簡短的任務範本：目標、允許修改的檔案、不變條件、驗證指令與停止條件。旁邊也要有決策記錄：新增了哪個依賴套件、為何放棄替代方案，以及人在哪裡承擔了風險。這些紀錄能幫助下一位審查者還原意圖，避免脈絡只存在於與模型的聊天中。

  • 開始前：負責人訂出行為與風險等級。
  • 工作中：代理超出允許範圍時停止。
  • 合併前：另一人檢查差異與證據，而非模型的轉述。
  • 發布後：將缺陷對應到遺漏的管控，改善流程，而不只是改善提示詞。

另外也要留意表面上的節省。如果開發者十分鐘就拿到程式碼，卻花了兩小時釐清隱藏關聯，就沒有加速。好的指標是一次審查通過、且無須復原的任務比例。它能同時約束提出需求者與工具使用者：小範圍、明確測試與可見的變更代價，比試圖用一則訊息完成整個功能更能帶來速度。