Beyond Vibe Coding - AI 輔助開髮指南 Google 工程負責人@addyosmani 的新書，目的是糾正當前流行的“Vibe Coding” 誤區，為構建生產級軟體提供一套嚴謹的AI 輔助工程學框架。這本書我是在Oreilly 線上閱讀的，應該也能找到PDF 版本。 核心論點：從“氛圍編碼”到“AI 輔助工程” 1. “Vibe Coding” 的定義與限制 Andrej Karpathy 曾經描述過一種未來願景：「我只管看、說、跑程式碼，主要靠複製貼上，只要『感覺Vibe』對了就行。」這就是「Vibe Coding」——一種依賴高層提示詞、強調快速原型、忽略底層實現細節的開發方式。 2. “70% 陷阱” Addy 指出，Vibe Coding 雖然能讓人極速完成70% 的工作，但剩下的30%（即生產級交付）若無深厚的工程底蘊，將寸步難行。 · 進二退二模式：修復一個Bug 導致兩個新Bug，因為開發者不理解AI 產生的程式碼邏輯。 · 隱形成本：缺乏維護性、安全性漏洞（如洩漏資料庫憑證）和效能瓶頸。 · 邊際效應遞減：對於新手，AI 是拐杖；但對於資深工程師，必須從「盲目接受」轉向「嚴謹審查」。 結論：必須從「玩票性質的編碼」轉向AI 輔助工程。這要求結合AI 的創造力與傳統工程的嚴謹性（規範、測試、審查）。 關鍵方法論：AI 輔助開發的“工程學” 該指南提出了一套系統化的方法來彌補AI 生成與生產標準之間的差距。 A. 「先規劃，後編碼」原則這是最關鍵的典範轉移。不要直接讓AI 寫程式碼，而應強制執行Spec-Driven Development。 · Mini-PRD / SPEC. md：在寫程式碼前，請AI 先生成一份架構計畫或小型產品需求文件。 · 規劃模式：利用AI 工具（如Claude Code 或Gemini CLI）的規劃功能，先確認架構路徑，再進入實作。 · 糾錯前置：90% 的情況下，AI 起初會建議一個過於複雜的方案，透過規劃階段可以提前簡化。 B. 情境工程提示詞工程已過時，現在是情境工程的時代。需要將AI 模型視為CPU，將上下文視窗視為內存，透過動態載入資訊來優化輸出。 · 動態組裝：不要靜態貼上程式碼。應根據目前任務，動態抓取相關的程式碼片段、API 文件、完整的錯誤堆疊和資料庫Schema。 · 消除「上下文腐爛」：隨著對話變長，無關訊息會幹擾AI。需要定期總結並清理舊的上下文。 · 視覺脈絡：直接傳入設計圖（Figma）或瀏覽器截圖，因為“一圖勝千言”，能大幅減少前端樣式的反覆調試。 C. 提示詞的進階策略· 思考鏈：強制AI 在輸出程式碼前展示推理步驟（「第一步分析瓶頸，第二步建議索引...」）。 · 基於約束的提示：明確“負面約束”，例如“不使用外部函式庫”、“必須相容於IE11”等。 · 角色扮演：指定AI 身份，如「作為資深安全審計員，請審查這段程式碼的SQL 注入風險」。 技術堆疊演進：CLI Agent 與多智能體編排詳細探討了開發環境的未來形態，即從IDE 插件轉向終端智能體和多智能體系統。 · CLI 編碼智能體：工具如Claude Code、Gemini CLI 或Aider 直接駐留在終端機。它們不僅是程式碼補全工具，更是能執行複雜任務（如Git 操作、執行測試、檔案讀寫）的獨立實體。 · 多智能體編排： · 分工架構：一個「規劃智能體」負責拆解任務，分發給「編碼智能體」實施，再由「測試智能體」驗證，最後由「文檔智能體」更新README。 · 管線作業：類似CI/CD，但每個環節由AI 驅動。 · 沙盒與回滾：由於智能體具有自主性，必須配置沙盒環境與檢查點，以便在AI「暴走」或犯錯時一鍵回滾。 生產現實：信任與品質門禁在享受AI 效率的同時，必須建立嚴格的品質門禁。 · 像審查初級工程師一樣審查AI：永遠不要盲目信任AI 的程式碼。 · 測試驅動：讓AI 先寫測試案例（紅），再寫程式碼讓測試通過（綠），最後重構。這是確保AI 程式碼邏輯正確的最佳護欄。 · 安全第一：AI 傾向於產生「能跑通」但「不安全」的代碼（如硬編碼密鑰）。必須進行專門的安全掃描。 總結：未來的開發者畫像 Addy 透過此書/網站傳達了一個清晰的訊號：軟體開發的門檻雖然在降低，但卓越工程的標準並未降低。 未來的開發者將經歷心態的轉變： 1. 從編碼者到決策者：核心技能不再是默寫語法，而是提供高品質情境、驗證AI 輸出、並做出架構決策。 2. 從實現到意圖：專注於精準描述“想要什麼”，而不是糾結“怎麼寫”。 3. 從單兵作戰到人機配對：學會管理一個AI 智能體團隊，指揮它們協作完成複雜系統。 書籍網站
