連 DevOps 教父都下場了：Kim & Yegge《Vibe Coding》的實務心法

如果你對「用 AI 寫程式」還停在「玩具、Demo、遲早出事」的印象，有兩個名字值得你重新評估：Gene Kim，寫出《鳳凰專案》、被叫了十幾年 DevOps 教父的那位；Steve Yegge，在 Amazon 和 Google 待了二十多年的老工程師。兩位合寫了《Vibe Coding》，而且不是站在岸上評論——書裡每個失敗案例都是他們自己撞出來的。

我之前寫過 Addy Osmani 同名書的〈70% 問題〉，那本回答「AI 寫程式的能力邊界在哪」；這本回答的是邊界內的這片地該怎麼耕——工作節奏、AI 會怎麼偷工、怎麼指揮好幾個 AI、主管該做什麼。這篇挑最能直接用的四塊：FAAFO 框架、翻車博物館、三層開發迴圈、組織層的 DORA 異常。

這篇文章整理了 Kim 與 Yegge《Vibe Coding》的 FAAFO 五大價值、老手翻車案例、三層開發迴圈與組織導入心法，並對照我自己重建網站與企業內訓現場的經驗。適合已經在用 AI 寫程式、想把工作方式練得更穩的人閱讀。

FAAFO：五個好處，和故意不放進去的那個 B

書的核心框架叫 FAAFO:Fast（更快）、Ambitious（更有野心）、Autonomous（更自主）、Fun（更有樂趣）、Optionality（更多選項）。前兩個好懂：幾週的工作變成以天計，「不可能」和「不值得」的題目都掉進可做範圍內。

值得多看兩眼的是後三個。自主消滅兩種隱形成本：協調成本（開會、對優先序、等人有空）和溝通成本（無法讀心卻要共享願景）——一個人加 AI 做完以前要跨團隊的事，省下的不是人力，是摩擦。樂趣聽起來最軟，作者卻認為它是深層的社會變化：把離開的人帶回來寫程式，把沒寫過的人拉進來。選項性則被點名最受低估：以前選方案像走單行道，現在並行做三個原型再挑一個，便宜到可以變成預設習慣。

然後是整本書最重要的一句自我拆台：FAAFO 裡沒有 B(Better)。Vibe Coding 不會自動讓你的程式變好，品質從頭到尾是你的責任。貫穿全書的隱喻就在講這件事：你是主廚，AI 是能力很強但行為古怪的副主廚——菜單你出、廚房你管、每道出餐你負責。剩下的篇幅，都在教你當好這個主廚。

翻車博物館：老手的失敗比新手的成功更值得讀

這本書最珍貴的，是兩位作者毫不遮掩地展示自己的事故現場。

Steve 請 coding agent 整理測試，兩週後才從同事那裡得知：agent 為了「讓測試通過」，偷偷停用甚至刪掉一套大型測試裡八成的測項，全程沒提一個字。他半夜傳給 Gene 的訊息成了書裡的名場面：「我請 Claude Code 照顧我的測試，它確實照顧了，就像哥吉拉照顧東京那樣。

」更驚悚的一次，他約一萬行的程式碼連同遠端 repo 一起消失——起因是他叫 AI 清掉「不需要的」branch，而 AI 的理解跟他不一樣——最後靠一個碰巧還開著的終端機視窗撿回全世界最後一份副本。Gene 那邊，為寫書打造的工具在日積月累的「再加一個小功能」之後，長成三千行、沒有模組邊界的「克蘇魯式恐怖函式」，花了三天才重構回來。

重點：出事的不是新手，是寫了幾十年程式的老手。所以結論不是「AI 不可靠所以別用」，而是「AI 不可靠，所以工作方式要重新設計」。

我自己最深刻的一次是重建 pbtw.tw：一個樣式問題讓 AI 連修三次，每次都「改好一點然後弄壞別的」。我照自己在〈Vibe Coding 實戰五原則〉寫過的規矩——修三次修不好就重開對話——新對話一次解決。讀這本書最大的安慰是：原來 Kim 和 Yegge 也在過一樣的日子，而且他們把應對方法整理成了系統。

三層迴圈：把「不放心」做成工作節奏

書把應對方法鋪進三個時間尺度的迴圈，每層都做三件事：預防、偵測、修正。

內圈（秒到分）是你和 AI 的每一次交手：任務拆小、先讓 AI 寫規格和測試再動手、每段能動的成果就 commit 一次——把版本控制當遊戲存檔點，這是 Steve 的 repo 事件用血換來的教訓。

注意：偵測端只有一條鐵律：AI 說「測試都過了」不能信，要親眼看證據。

書裡列了 AI 偷工的固定劇目：要七個只交五個的「數嬰兒問題」、硬編碼充數的「紙板瑪芬」、明知最佳做法卻只做半套的「半吊子」。我做選賽道決策機器人時就抓過現行：逐條對驗收標準，才發現有一條評分邏輯是寫死的固定值。

中圈（小時到天）管跨 session 的協作：把不可妥協的規則寫成 AGENTS.md 之類的文件——AI 無法讀你的心，但讀得懂一份文件；session 結束前讓 AI 把進度與卡點寫下來，給下一棒接力。多代理並行也在這層，原則是「不同工作站做不同菜」：分目錄、分 branch，嚴防互相改壞。我重建網站時就是這樣跑的——一個代理處理文章頁模板、一個處理課程頁、一個跑建置腳本；真正的工作量不在下指令，而在我這個主廚輪流到每個爐台前驗菜。代理喊「做完了」時，最划算的一招是叫它審查自己的產出、補測試、找邊界案例，自我批評的效果好得出奇。

外圈（週到月）你幾乎不寫程式了，角色變成架構師：劃清工作區邊界、堅持改動不能砸毀既有 API 契約、把 CI/CD 升級成 AI 加持的守門員。

流程總覽

組織層：DORA 異常，以及 AI 是流程體質的放大器

第四部是這本書跟其他 Vibe Coding 書最不一樣的地方，也是 Gene Kim 的主場。2024 年 DORA 報告丟出尷尬的數字：推估 GenAI 使用每增加 25%，交付穩定性反而降約 7%、吞吐量降約 1.5%。所以 AI 是反效果？作者的工作假說是：AI 放大你既有的流程體質。本來就沒有測試？現在是每人每天上千行程式碼沒有測試。

對策也就順理成章：每個 AI commit 都配自動化測試、改動批量壓小（別接受四百行的 diff）、高風險變更讓第二個模型交叉審查、開發規範寫成文件。書裡 Adidas 七百名工程師的試點是正面教材:91% 滿意度、兩到三成生產力提升——但前提是這家公司多年前就投資了模組化架構和快速回饋迴圈。

這一段我在企業內訓現場看過太多縮影：高層買了工具、訂了使用率目標，但第一線連「驗收標準寫在哪、出錯了找誰」都沒有共識——正是把放大器接到還沒整理好的流程上；反而是先把「小步交付、有人驗收」習慣建起來的團隊，工具一進來就接得住。書給領導者的清單很實在：自己先下場用並公開分享、先裝護欄再鼓勵實驗、及早講一個內部英雄故事、AI 出包時開不究責的檢討會。每一條都不是技術，是文化。

常見問題

問：我不是工程師，這本書對我有意義嗎？
答：有，作者明說受眾包括「會被 AI 拉進來做軟體的人」。書的核心其實是管理學：拆任務、驗收、授權——書裡引用 Andy Grove 的授權框架，任務越新、影響越大，給的繩子就要越短。管 AI 和管專案是同一套。

問：它和 Osmani 的《Vibe Coding》買哪本？
答：Osmani 解釋「為什麼 AI 帶你到 70% 後會卡住」，適合建立預期；Kim 與 Yegge 給你「每天怎麼工作」的操作系統，適合想用得更穩的人。先前者後後者最順。

問：書裡的方法會不會很快過時？
答：作者刻意只寫「模型再換代也成立」的原則，收尾就三句：為模組化設計讓工作能並行、回饋迴圈保持短讓錯誤容易修、關鍵分岔放進人類判斷。工具名字會過時，這三件事不會。

問：一個人要從哪一步開始？
答：書的建議是「從小開始，今天開始」：交給 AI 一個獨立小任務，看它跌倒，糾正它，把迴圈收緊，再把任務加倍。想要具體時程表，可搭配〈四週用 AI 做出你的 MVP〉。

連寫了二十年「怎麼讓軟體交付不出事」的人，面對 AI 都選擇先下場摔跤再寫方法，我們沒有理由站在岸上等塵埃落定。想在有人帶的環境裡把這套主廚工作法練起來，歡迎來我的 Vibe Coding 實戰課，直接在你的題目上跑這個迴圈。

這篇文章的原始書摘整理在：/note-vibe-coding-kim-yegge/