從 Vibe Coding 到工程紀律：解構 AI 輔助開發的工作流程與團隊協作架構

一、一個文化轉折點的技術解讀

2025 年 2 月，Andrej Karpathy——OpenAI 共同創辦人、前 Tesla AI 總監——在社群媒體上提出了一個引發廣泛討論的概念：vibe coding^[1]。他描述了一種開發者完全依賴 AI 的工作模式：以語音對 AI 描述需求、不閱讀程式碼差異而全面接受產出、將錯誤訊息直接貼給 AI 修正、在程式碼超越個人理解後仍持續推進——並坦言這種方式對實驗性的週末專案「效果還不錯」。

這則發言之所以值得嚴肅分析，不僅因為發言者的身份，更因為它精準地揭示了一個正在發生的根本轉變：當 AI 的程式碼生成能力達到一定水準，開發者的角色從「撰寫程式碼」轉向「描述意圖並驗證結果」。Brooks 在 1987 年的經典論文^[2]中區分了軟體的本質複雜性與附帶複雜性；vibe coding 本質上是將附帶複雜性的處理完全委託給 AI 的極端形式。

但個人的週末專案與企業的生產系統之間存在巨大的鴻溝。本文將 Karpathy 所描述的工作流程進行系統性拆解，識別出六個關鍵操作階段，分析每個階段在企業情境下的適用邊界，並提出一個四層團隊協作架構，幫助技術決策者在速度與品質之間找到適合自身組織的平衡點。

二、解構 AI 輔助開發的六個操作階段

階段一：意圖表達的範式轉移

Vibe coding 的第一個特徵是開發者透過自然語言——甚至語音——而非程式碼語法來表達需求。開發者使用語音輸入工具直接對 AI 描述想要的功能，而非動手寫程式碼。

這反映了一個深層的轉變：開發者的認知資源從「如何實作」重新配置到「要實作什麼」。在傳統開發中，即便資深工程師也需要花費相當精力在語法細節、API 查詢與框架配置上；而在 AI 輔助的工作流程中，這些認知負荷被轉移到了 AI 端。McKinsey 的研究^[3]證實了這個效應：AI 對文件撰寫與樣板程式碼的加速效果最為顯著，正是因為這些工作的認知負荷主要來自附帶複雜性。

企業意涵：當「描述需求」取代「撰寫程式碼」成為核心操作，需求的清晰度與精確度就成為新的生產力瓶頸。團隊的能力建設需要從程式語言熟練度擴展到問題定義與需求表達能力。

階段二：結果導向的抽象指令

第二個特徵是以結果為導向的指令下達——開發者指定「做什麼」而非「怎麼做」。例如要求 AI「將側邊欄的間距縮減一半」而非自行查找 CSS 屬性並修改數值。操作的抽象層級從實作細節提升到了功能描述。

這降低了特定技術棧的入門門檻，使具備領域知識但未必精通特定框架語法的專業者也能參與軟體開發。但它同時模糊了「了解系統」與「使用系統」之間的界線——長期而言，團隊需要確保有人真正理解系統的實作邏輯與技術限制。

階段三：全量接受——審查的刻意放棄

第三個階段是最具爭議的：全面接受 AI 的產出，不閱讀程式碼差異。這最大化了開發速度，但完全移除了人類的品質關卡。

MIT Sloan Management Review 2025 年的研究^[4]提供了這種做法的量化後果：大規模程式碼分析顯示 AI 輔助開發導致重複程式碼區塊增加八倍、程式碼翻動率（code churn）增加兩倍。當開發者跳過審查時，這些品質問題以技術債的形式不斷累積。

企業意涵：這是個人實驗與企業工程之間最關鍵的分歧點。在企業情境中，程式碼審查不僅是品質控制機制，更是知識傳遞與架構一致性維護的核心流程。BCG 的研究^[5]發現，50% 的技術長無法量化 AI 對工程效能的實際影響——跳過審查使得這個度量問題進一步惡化。

階段四：錯誤驅動的迭代修正

在 vibe coding 中，除錯被簡化為：遇到錯誤，將錯誤訊息直接提供給 AI，由 AI 自行診斷並修正。這形成了一個「執行 → 報錯 → 餵入 → 修正」的快速迭代循環。

這種模式在處理表面錯誤（語法錯誤、型別不匹配、缺少依賴）時效率可觀。但它本質上是症狀導向而非根因導向——AI 修正了報錯，但不一定解決了導致報錯的深層設計問題。

企業意涵：表面錯誤的自動修正值得在所有層級採用，能大幅節省除錯時間。但涉及業務邏輯、資料一致性或安全性的錯誤，團隊仍需要系統性的根因分析，而非僅依賴 AI 的症狀性修復。

階段五：超越個人理解的程式碼規模

隨著 AI 持續產出程式碼，整體程式碼庫很快就超越了個人的理解範圍。這在個人專案中是可容忍的，但在團隊環境中具有根本性的意義。

Conway 定律^[6]告訴我們，系統的架構反映組織的溝通結構。當沒有任何團隊成員完全理解系統時，組織實質上失去了對系統架構的掌控能力。Harvard Business School 的研究^[7]更顯示，初階開發者職缺已低於趨勢線 4.7 個百分點——意味著未來更少的人會從底層開始建立對系統全貌的理解。

企業意涵：團隊需要建立「分散式理解」的機制：不要求每個人理解全部，但確保系統的每個關鍵模組至少有一位成員具備深入理解。這需要刻意的知識分配策略，而非依賴自然形成的認知分佈。

階段六：隨機性除錯策略

最後一個階段是當 AI 無法修正某個問題時，開發者透過要求 AI 進行各種嘗試性修改，直到問題消失。這是一種非確定性的除錯策略——以搜尋空間的探索取代系統性的問題分析。

對於 UI 層面的問題（樣式衝突、版面偏移），這種策略的成本低且經常有效。但對於業務邏輯錯誤、資料處理問題或安全漏洞，隨機修改可能引入新的、更隱蔽的缺陷。

企業意涵：建立明確的分級策略——UI 與呈現層問題允許快速迭代修正，但涉及資料、安全或核心業務邏輯的問題，必須經過結構化的分析與驗證流程。

三、適用邊界：從週末專案到企業系統的光譜

Karpathy 自己也明確指出，vibe coding 更適合實驗性的、用完即丟的專案。這個自我限定非常關鍵——它暗示了一個核心觀點：上述六個階段並非全有或全無的套裝，企業可以選擇性地採用。

McKinsey 追蹤 600 多個組織後的數據^[8]提供了重要的參照：最高績效組織實現了 16–30% 的生產力提升與 31–45% 的品質改善，但它們的共同特徵是同步改革了流程、角色與工作方式。成功的 AI 導入不是在「全面接受」與「全面拒絕」之間做二元選擇，而是為不同類型的工作建立分層的決策框架。

這正是我們接下來要提出的模型。

四、團隊分層協作架構：四層模型

基於上述六個階段的分析與我們的實踐經驗，我們提出以下四層 AI 協作架構。每一層對應不同類型的軟體工作，定義了不同程度的 AI 自主權與人類介入密度。

第一層：AI 直接執行層

適用範疇：原型開發、內部工具、一次性腳本、實驗性功能驗證

最接近 vibe coding 的操作模式。AI 享有最大自主權，開發者主要負責意圖表達與結果驗證，程式碼審查從逐行檢視簡化為功能層級的驗收。這一層強調速度與探索性，適合失敗成本低、不進入生產環境的工作。六個操作階段在此層幾乎全數適用。

第二層：人機協作層

適用範疇：功能開發、標準元件實作、既有系統的功能擴展

AI 負責程式碼生成，開發者負責審查與修正。類似於 pair programming 的工作模式，但 AI 擔任初階夥伴的角色。大多數的日常功能開發屬於這一層。開發者需要具備閱讀與評估 AI 產出的能力——MIT Sloan 的研究^[4]提醒我們，這個審查環節是防止技術債累積的關鍵防線。階段一、二、四在此層適用，但階段三（跳過審查）明確排除。

第三層：架構守護層

適用範疇：系統設計、API 契約定義、資料模型設計、跨服務整合

人類主導，AI 僅在實作細節上提供輔助。架構決策——包括服務邊界劃分、資料流設計、API 版本策略——完全由資深工程師與架構師負責。BCG 的研究^[9]發現，過時的系統架構會嚴重削弱 AI 工具的效益，反面驗證了架構層級的人類判斷不可替代。僅階段一（自然語言表達）在此層適用，其餘階段的自動化程度應受到嚴格限制。

第四層：品質治理層

適用範疇：安全審查、合規驗證、效能基準測試、上線前核准

人類判斷為最終決策依據，AI 作為檢測與分析的輔助工具。安全掃描、合規檢查可以利用 AI 提升覆蓋率與偵測效率，但最終的風險評估與上線決策必須由具備專業判斷力的人員做出。這一層的核心原則是：AI 提供資訊，人類做出決策。

五、Conway 定律的新詮釋與角色演化

Conway 在 1968 年提出的定律^[6]指出，系統的架構反映了設計該系統的組織的溝通結構。在 AI 時代，這個定律獲得了一個重要的推論：團隊如何劃分 AI 的自主邊界，將直接映射到軟體系統的品質特徵。

如果團隊在所有工作上都採用第一層的操作模式，產出的系統將缺乏一致的架構邏輯，技術債分布無序，維護成本不可預測。反之，如果過度保守地將所有工作限制在第三、四層，則無法充分發揮 AI 帶來的效率優勢。關鍵在於精確的分層判斷。

對具體角色而言，這意味著以下演化方向：

• 初階開發者的價值重心從「寫程式碼」轉向「與 AI 高效協作並學習審查 AI 產出」，主要在第一、二層工作，但需要資深成員的指導與監督
• 資深開發者成為 AI 產出的核心審查者，在第二、三層之間建立品質防線，同時負責將團隊經驗結構化為 AI 可消費的知識文件
• 架構師的角色從「設計系統」擴展到「設計 AI 的約束邊界」——定義哪些決策 AI 可以自主做出，哪些必須經過人類審批
• 技術主管成為跨層級的協調者，根據工作的類型與風險等級，將任務動態分配到適當的協作層級

Stanford AI Index 2025^[10]記錄了 AI 在軟體工程基準測試中能力的飛速提升——SWE-bench 解題率在一年內從 4.4% 躍升至 71.7%。可以預見各層級的邊界將持續隨 AI 能力演進而調整，但基本原則不變：越接近核心業務邏輯與系統架構的決策，人類判斷的密度越高。

六、結語：精確的分層，而非全面的接受或拒絕

Karpathy 的 vibe coding 不是一個應該被全盤採用或全盤否定的概念。它是一面稜鏡，將 AI 輔助開發的操作模式分解為可辨識的光譜——從完全自動到完全人控。企業的技術決策者需要做的，不是選擇光譜上的某個固定點，而是為不同類型的工作選擇不同的位置。

那些能夠精確地為每一類工作匹配適當人機協作密度的團隊，將同時獲得 AI 的速度紅利與工程紀律的品質保障。這需要的不是更好的 AI 工具，而是更清晰的組織判斷力——而這，恰恰是 Brooks 近四十年前所說的「本質複雜性」的一部分。

如果您的團隊正在規劃 AI 輔助開發的導入策略，或希望建立適合自身組織的分層協作框架，歡迎與我們進行深入探討。