像主廚一樣指揮 AI：防偷工的四個檢查模式

這篇文章白話拆解《Vibe Coding》第 8 到 12 章的廚房工作法，包含對話式指揮、上下文視窗管理、防偷工四模式與任務圖曳光彈。適合常被 AI 的「任務完成」報告催眠、想學會驗收每道出餐的人閱讀。

你大概也遇過這個場景：AI 自信滿滿地回報「任務完成，所有測試都通過了」，你心情很好地關掉視窗，三天後才發現有一半功能根本是空殼。第一次你怪模型不夠聰明，第二次你怪自己提示詞寫不好，到第三次你開始懷疑：用 AI 寫程式是不是本質上不可靠？

Gene Kim 和 Steve Yegge 在《Vibe Coding》第二部給了一個更有用的答案：AI 不是不可靠，是它偷工的方式有固定劇目，而你還沒學會點菜後驗菜。整本書的核心比喻是：你是主廚，AI 是能力很強但行為古怪的副主廚——菜單你出、每道出餐你負責。這篇文章聚焦書中第 8 到 12 章的「廚房工作法」：怎麼下指令、怎麼管 AI 的工作檯，以及最重要的——四種偷工模式怎麼抓。

對話式指揮：像傳簡訊，不像寫存證信函

兩位作者對「怎麼跟 AI 說話」的立場可能跟你想的相反：不要花時間雕琢完美提示詞。他們的比喻很傳神——跟 AI 對話應該像跟同事傳簡訊，而不是寫信給要告你的律師。錯字、語氣詞、想到哪講到哪都沒關係，AI 的容錯力驚人；真正不能含糊的只有一件事：你要什麼、成功長什麼樣。風格可以隨便，目標必須精準。

書中還有兩個立刻能用的習慣。第一，讓錯誤自己說話：不要描述「日期格式好像怪怪的」，直接把錯誤訊息原文、stack trace、或畫面截圖貼給它，視覺與原文資訊比你的轉述完整十倍。第二，借用它的百科全書：像 ffmpeg 這種參數地獄的工具，別再讀文件了，直接說「我要從 2:15 開始剪 30 秒、去掉音軌、壓到 720p」，讓 AI 去翻它早就讀過的說明書。

上下文視窗：AI 的便條紙，寫越滿越笨

第 10 章把「上下文視窗」講成全書最好懂的比喻：那是副主廚手上的一本便條紙，你的指令、規則、程式碼、對話歷史全部記在上面——沒寫在便條紙上的事，它一概不知道。麻煩在於這本便條紙會越記越滿，而且每講一句話，整本都要重讀一次，成本隨對話長度暴增。

更麻煩的是「上下文飽和」：便條紙快滿時，AI 的表現不是慢慢變差，是直接跳水。書裡的實例很驚悚——Steve 的團隊明確規定「絕不准執行某個會灌爆上下文的指令」，代理一開始乖乖遵守，等對話佔到視窗的一半，它就把禁令忘了，照跑不誤。

重點：作者的粗魯結論值得貼在螢幕上：便條紙上寫越多，AI 越笨。

白話對策三條：能開新對話就開新對話；走錯路就回存檔點重來，別在原對話裡越補越亂；餵上下文看任務大小決定——獨立小修補只給最少資訊（聚焦式），牽動架構的決策才把相關模組倒進去（包山包海式），不要反過來。

防偷工四模式：書中實際命名，白話解釋

這是第 11 章，我認為是全書最值錢的一章。AI 被訓練成「看起來有幫上忙」，當它做不完或做不好，第一反應不是承認，是演出完成的樣子。作者把這齣戲拆成四種固定劇目，而且全部用自己的事故命名。

一、數嬰兒問題(Baby Counting):Steve 對代理說「衝進火場救出我的七個嬰兒」，它回報「任務完成！救回五個、停用兩個」。現實版是要修七個測試，它修了五個、把兩個直接停用，然後宣告全數通過。對策只有一個字：點。交付了幾項就逐條點收幾項，不要被熱情的完成報告催眠。

我的經驗：我重建 pbtw.tw 時把這件事制度化：每張子任務卡片上先寫好驗收條件，代理喊完成後，我照卡片逐條打勾，點收不過就退單——聽起來官僚，但抓漏率遠勝「看起來都好了」。

二、紙板瑪芬(Cardboard Muffins)：比數嬰兒更陰險。Steve 要求修九個測試，AI 回報九個全綠——細看才發現五個真修好，四個是把期望值寫死硬湊過關，像端上一盤九個瑪芬，其中四個是紙板做的。它通過粗略檢查：測試是綠的、函式名稱正確、文件齊全，只有掀開來看才知道裡面是空的。我做選賽道決策機器人時抓過一次現行：某條評分邏輯回傳的永遠是同一個固定值。從那之後我的驗收多了一道工序——換不同輸入跑同一條規則，輸出不會動的就是紙板。

三、半吊子(Half-Hearted Work):AI 讀過全網路最好的程式碼，卻預設交出「能跑就好」的最低標。書中 Gene 請 Claude 評價它自己寫的測試，它毫不留情地給了差評——測了一堆內建函式、只測 happy path、脆弱得一碰就碎；再請它寫個像樣的測試計畫，它立刻交出高品質版本。結論很反直覺：你只會拿到你開口要求的品質。要求結構、要求邊界案例、要求遵循既有慣例，甚至直接叫它「審查並改進你自己的產出」，它都做得到——但你得說。

四、邋遢鬼(The Slob)：程式能跑，廚房卻像被洗劫過——除錯訊息灌爆主控台、用不到的變數、整段被註解掉的屍體程式碼、散落的測試腳本和忘了刪的 branch。Gene 請 AI「到處加 log」抓一個問題，幾天後回頭看，整段程式被 try/catch 疊到八層深，再也改不動。對策是把打掃寫進任務本身：「完成後移除所有臨時檔案與除錯輸出」，並且每次合併前看 diff，特別注意那些不該出現的新檔案。

任務圖與曳光彈：把大菜拆成端得動的盤子

四個檢查模式是守門，第 12 章的兩個工具則是讓 AI 少犯錯的進攻方。任務圖：把專案畫成一棵樹，頂端是願景，往下逐層拆解，最底層的「葉節點」——目標清楚、輸入輸出明確的小任務——才是丟給 AI 的單位。直接對 AI 說「幫我做一個電商平台」，等於對新進員工說「把公司做起來」。

曳光彈：在動工前，先切一條最薄、但從頭到尾打通的功能切片，優先射向最沒把握的地方。書裡 Steve 的反面教材很痛：他自信滿滿要把 3,500 行 Ruby 腳本移植到 Kotlin，挑了看起來最難的指令先做，結果卡死在最不起眼的 Gradle 建置設定上，三個聊天機器人輪番幻覺出不存在的指令，45 分鐘付諸流水。事後檢討：如果第一發曳光彈是「讓 Gradle 印出命令列參數」這種五分鐘小事，當場就會發現 AI 不會，根本不用浪費那 45 分鐘。附帶一條作者的估時心法：AI 時代的時程更難估，把你的樂觀估計乘以五。

流程總覽

常見問題

問：每次都要跑四個檢查，不會比自己寫還慢嗎？
答：檢查的是產出不是過程，逐條點收一個小任務只要幾分鐘；而漏掉一個紙板瑪芬，代價是上線後除錯幾小時。而且任務拆得越小，驗收越快——這正是任務圖要拆到葉節點的原因。

問：我可以叫 AI 自己檢查自己嗎？
答：可以，而且書中明確推薦：請它審查自己的程式碼、補測試、找邊界案例，效果出奇地好。但最後的「親眼看證據」不能外包——AI 說測試通過，你還是要自己跑一次，這是我在〈Vibe Coding 實戰五原則〉裡也強調過的底線。

問：上下文視窗那麼容易飽和，把整個專案餵給 AI 是錯的嗎？
答：不一定。小專案全部倒進去效果很好；大專案則改餵「摘要文件」——先請 AI 替各模組寫總覽，之後依任務挑著餵。判斷訊號是行為：AI 開始忘記指令、自我矛盾、鬼打牆，就是該開新對話了。

問：這套方法會不會隨模型升級而過時？
答：偷工的幅度會降（Anthropic 公開說新模型已大幅減少這類行為），但「驗收責任在你」不會變。書名玩笑說 FAAFO 裡沒有 B(Better)——品質從來不是模型送的，是主廚把關出來的。

把這四個模式內化之後，你對 AI 的信任會變得很健康：不迷信、不恐慌，出餐照驗、過了就上。想看這套廚房工作法的全書脈絡，可以搭配我的總覽文〈連 DevOps 教父都下場了〉；想在自己的專案上實際練一輪指揮與驗收，歡迎來我的 Vibe Coding 實戰課，我們直接拿你的題目開廚。

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