Vibe Coding：一個起點
「Vibe Coding」已經變成一種很強的技術，能快速做出新東西、盡情探索創意。這種做法是用 LLM（大型語言模型）生出初版草稿、把複雜的邏輯先勾勒出來，或是快速搭個原型，大幅降低一開始的阻力。它最值錢的地方，是幫你解決「白紙」問題──讓開發者從一個模糊的概念，很快跳到看得到、跑得動的程式碼。在摸索不熟的 API，或是想試試看某種新架構時，Vibe Coding 特別好用，因為它讓你不必一開始就追求完美的實作。這樣生出來的程式碼常常像創意的催化劑，給開發者一個底子去批評、重構、往上加東西。它最大的強項，就是能加速軟體開發週期裡最前面的探索和發想階段。不過，Vibe Coding 雖然很擅長腦力激盪，但要做出穩健、能擴充、好維護的軟體，就需要更有章法的做法──從單純的「生成」轉向跟專門的 Coding Agent 合作。
把 Agent 當成團隊成員
第一波熱潮聚焦在純粹的程式碼生成──也就是很適合發想的「vibe code」──但業界現在正轉向一種更整合、更強的正式開發範式。最強的開發團隊不只是把任務丟給 Agent，而是用一整套精巧的 Coding Agent 來強化自己。這些 Agent 就像不會累、各有專長的團隊成員，放大人類的創造力，也大幅提升團隊的擴充能力和開發速度。
這個演變也反映在業界領袖的說法裡。2025 年初，Alphabet 執行長 Sundar Pichai 提到，在 Google，「超過 30% 的新程式碼現在都由我們的 Gemini 模型輔助或生成，這從根本上改變了我們的開發速度。」 Microsoft 也講過類似的話。這種整個業界的轉向說明，真正的前沿不是取代開發者，而是幫他們變得更強。目標是一種互相加成的關係：人類主導架構的走向和創造性的問題解決，Agent 則負責測試、寫文件、審查這類專門又能規模化的工作。
這一章提出一套組織「人機團隊」的框架，核心理念是：人類開發者當創意主導和架構師，AI Agent 則是戰力倍增器。這套框架建立在三個基本原則上：
- 人類主導的協調（Human-Led Orchestration）： 開發者是團隊主管兼專案架構師。他們始終在決策迴圈裡，負責調度整個工作流程、設定高層目標、做最終決定。Agent 很強，但只是輔助性的協作者。要找哪個 Agent 上場、要餵什麼上下文，都由開發者決定；最重要的是，對 Agent 生出來的任何結果，開發者要做最後的判斷，確保它符合專案的品質標準和長期方向。
- 上下文至上（The Primacy of Context）： 一個 Agent 表現好不好，完全取決於它拿到的上下文夠不夠好、夠不夠完整。一個很強的 LLM 配上爛上下文，等於沒用。所以這套框架特別重視由人類親手、仔細地整理上下文，避開那種自動化的黑箱式檢索。開發者要負責替自己的 Agent 隊友準備一份完美的「任務簡報」，包含：
- 完整的程式碼庫： 提供所有相關的原始碼，讓 Agent 搞懂現有的寫法模式和邏輯。
- 外部知識： 補上特定的文件、API 定義或設計文件。
- 人類寫的簡報： 把目標、需求、pull request 的說明和風格指南講清楚。
- 直接存取模型（Direct Model Access）： 想拿到頂尖的結果，Agent 背後就得直接接到前沿模型（例如 Gemini 2.5 PRO、Claude Opus 4、OpenAI、DeepSeek 等）。用比較弱的模型，或是把請求繞經那些會模糊掉、截斷上下文的中間平台，都會讓表現變差。這套框架的基礎，就是在人類主導者和底層模型的原始能力之間，建立一條盡可能純淨的對話管道，確保每個 Agent 都發揮到極限。
這套框架的結構，是一支由專家 Agent 組成的團隊，每個 Agent 都對應開發週期裡的一項核心功能。人類開發者當中央協調者，負責分派任務、整合結果。
核心組成
為了把前沿的大型語言模型用好，這套框架把不同的開發角色分派給一支專家 Agent 團隊。這些 Agent 不是各自獨立的應用程式，而是透過精心設計、針對角色的 Prompt 和上下文，在同一個 LLM 裡叫出來的「概念人格」。這種做法能讓模型龐大的能力精準對準當下這件事──從寫初版程式碼，到做一次細緻、帶批判性的審查。
協調者：人類開發者： 在這套協作框架裡，人類開發者當協調者，是整個 AI Agent 團隊的中樞和最終權威。
- 角色： 團隊主管、架構師、最終決策者。協調者負責定義任務、準備上下文，並驗證 Agent 做的所有工作。
- 介面： 開發者自己的終端機、編輯器，以及所選 Agent 的原生網頁介面。
上下文暫存區（Context Staging Area）： 這是任何一次成功的 Agent 互動的基礎──人類開發者在這裡仔細準備一份完整、針對該任務的簡報。
- 角色： 每項任務專屬的工作區，確保 Agent 拿到完整又正確的簡報。
- 實作方式： 一個暫時的目錄（task-context/），裡面包含記錄目標的 Markdown 檔、程式碼檔案和相關文件。
專家 Agent（The Specialist Agents）： 靠針對性的 Prompt，我們可以組出一支專家 Agent 團隊，每個都為某項特定的開發任務量身打造。
- Scaffolder Agent：實作者
- 用途： 根據詳細的規格，寫新的程式碼、實作功能，或產生樣板程式碼（boilerplate）。
- 呼叫 Prompt：「你是一位資深軟體工程師。請根據 01_BRIEF.md 裡的需求，以及 02_CODE/ 中既有的寫法模式，實作這個功能……」
- Test Engineer Agent：品質守門員
- 用途： 為新的或既有的程式碼，寫完整的單元測試、整合測試和端對端測試。
- 呼叫 Prompt：「你是一位品質保證工程師。針對 02_CODE/ 裡提供的程式碼，用 [測試框架，例如 pytest] 寫一整套單元測試。要涵蓋所有邊界情況，並遵守專案的測試理念。」
- Documenter Agent：文件書記
- 用途： 為函式、類別、API 或整個程式碼庫，產生清楚、精簡的文件。
- 呼叫 Prompt：「你是一位技術文件撰寫者。請為提供的程式碼裡定義的 API 端點產生 markdown 文件。要附上請求／回應範例，並說明每個參數。」
- Optimizer Agent：重構夥伴
- 用途： 提出效能上的最佳化和程式碼重構建議，讓程式碼更好讀、好維護、更有效率。
- 呼叫 Prompt：「分析提供的程式碼，找出效能瓶頸，或是可以重構得更清楚的地方。提出具體的修改方案，並解釋為什麼這樣改是更好的。」
- Process Agent：程式碼監督者
- 批判（Critique）： Agent 先跑一輪，找出可能的 bug、風格違規和邏輯瑕疵，很像一個靜態分析工具。
- 反思（Reflection）： 接著 Agent 分析自己剛剛的批判。它把發現整合起來，把最關鍵的問題排出優先順序，把那些吹毛求疵或影響很小的建議剔掉，給人類開發者一份高層次、可以直接動手的摘要。
- 呼叫 Prompt：「你是一位正在做程式碼審查的首席工程師。第一步，對這些變更做詳細的批判。第二步，回頭反思你的批判，整理出一份精簡、依重要性排序的關鍵回饋摘要。」
到頭來，這種人類主導的模式，在開發者的策略方向和 Agent 的戰術執行之間，創造出很強的協同效應。結果就是，開發者能跳脫例行工作，把專業火力集中在最有價值的創意和架構挑戰上。
實務落地
設定檢查清單
想把這套人機團隊框架真正落地，建議做以下的設定，重點是在提升效率的同時保有控制權。
- 取得前沿模型的存取權 至少弄到兩個頂尖大型語言模型的 API 金鑰，例如 Gemini 2.5 Pro 和 Claude 4 Opus。這種雙供應商的做法方便做比較分析，也能分散單一平台的限制或當機風險。這些憑證要像對待其他正式環境的機密一樣妥善保管。
- 架設一個本地的上下文協調器 別再用臨時拼湊的腳本，改用一個輕量的 CLI 工具或本地的 Agent 執行器來管理上下文。這類工具應該讓你在專案根目錄定義一份簡單的設定檔（例如 context.toml），指定要把哪些檔案、目錄，甚至 URL 編進送給 LLM 的那份 Prompt 載荷裡。這樣一來，每次請求模型看到什麼，你都能完全、透明地掌控。
- 建立一個納入版本控制的 Prompt 庫 在專案的 Git 儲存庫裡建一個專用的 /prompts 目錄。把每個專家 Agent 的呼叫 Prompt（例如 reviewer.md、documenter.md、tester.md）以 markdown 檔存進去。把 Prompt 當成程式碼來管理，整個團隊就能一起協作、打磨，並隨時間追蹤這些給 AI Agent 的指示的版本。
- 把 Agent 工作流程接上 Git hook 用本地的 Git hook 把你的審查節奏自動化。舉例來說，你可以設一個 pre-commit hook，在你的暫存變更上自動觸發 Reviewer Agent。Agent 那份「批判加反思」的摘要可以直接顯示在終端機裡，在你敲下最終 commit 前就給你即時回饋，把品質把關這一步直接烤進你的開發流程裡。
圖 1：Coding 專家角色範例
領導這支增強型團隊的原則
要成功領導這套框架，你得從一個單打獨鬥的貢獻者，進化成一支人機團隊的主管，可以照下面這幾個原則走：
- 握緊架構的所有權 你的角色是訂出策略方向、掌握高層架構。你定義「做什麼」和「為什麼做」，用 Agent 團隊來加速「怎麼做」。你是設計的最終裁決者，確保每個元件都對齊專案的長期方向和品質標準。
- 精通寫簡報這門功夫 Agent 的產出品質，直接反映了它拿到的輸入品質。每項任務都給出清楚、不含糊、完整的上下文，把寫簡報這門功夫練起來。別把你的 Prompt 當成一句簡單的命令，而要當成給一位剛加入、能力很強的新隊友的一份完整簡報包。
- 當最後那道品質關卡 Agent 的產出永遠是提案，不是命令。把 Reviewer Agent 的回饋當成一個很有力的訊號，但你才是最後那道品質關卡。拿出你的領域專業和專案知識，去驗證、質疑、核准所有變更，當程式碼庫完整性的最後守門人。
- 投入來回的對話 最好的結果來自對話，不是獨白。如果 Agent 的初版產出不夠好，別丟掉──去打磨它。給它修正的回饋、補上把話講清楚的上下文，然後叫它再試一次。這種來回的對話很關鍵，尤其是面對 Reviewer Agent 時──它那份「反思」輸出，本來就設計成一場協作討論的開頭，而不只是一份最終報告。
結語
程式碼開發的未來已經到了，而它是「被增強過」的。單打獨鬥寫程式的年代，已經讓位給一種新範式：開發者領著一支專門的 AI Agent 團隊。這種模式不但沒有削弱人類的角色，反而把它抬得更高──它自動化了例行工作、放大了個人的影響力，也達到了以前難以想像的開發速度。
把戰術執行交給 Agent 之後，開發者現在能把腦力專注在真正重要的事情上：策略性的創新、有韌性的架構設計，還有做出讓使用者驚喜的產品所需要的那種創造性問題解決。這層根本的關係已經被重新定義了：它不再是人跟機器的對決，而是人類的巧思和 AI 之間的夥伴關係，像一支無縫整合的團隊一起運作。
參考資料
- AI is responsible for generating more than 30% of the code at Google https://www.reddit.com/r/singularity/comments/1k7rxo0/ai_is_now_writing_well_over_30_of_the_code_at/
- AI is responsible for generating more than 30% of the code at Microsoft https://www.businesstoday.in/tech-today/news/story/30-of-microsofts-code-is-now-ai-generated-says-ceo-satya-nadella-474167-2025-04-30