資深工程師用 AI 反而慢 19%：coding agent 該放手的六個時機

2025 年七月，METR 做了一個實驗。

他們找來有經驗的開發者，在自己熟悉的專案上用 AI 工具，隨機分組對照。

結果這些人慢了 19%。

更值得玩味的是後半段：他們事前預測自己會快 24%。而且做完之後，仍然覺得自己變快了。

四十三個百分點的落差，不是因為模型不好用。是因為「什麼時候該接手、什麼時候該放著」這件事，沒有人教過他們。

這篇拆六個判斷點，每一個都給你一句可以當場用的判準。

這項技能三年前根本不存在

系列第一篇講吳恩達那張技能圖時提過，四項技能裡「使用 coding agent」是最新的一項。三年前沒有任何一份職缺會寫這條。

而且它不是一組提示詞技巧。

指揮 coding agent 是一組判斷力：知道它的限制在哪、判斷該介入多少該放手多少、管理它看得到什麼、以及知道哪些事情絕對不能交出去。

吳恩達原文列了七項能力，我把它重整成六個你實際會遇到的分岔點。

1. 這個任務該交出去嗎

判準是驗證成本，不是任務難度。

他在五月劃過一條線：coding agent 對 frontend 加速最多，對 research 幾乎沒用。

這個排序背後的原因不是 frontend 比較簡單。

是 frontend 錯了你三秒鐘就看得出來。畫面沒跑出來、按鈕沒反應、版面歪掉，一眼就知道。research 的錯要幾週後才浮現。

所以判準可以寫成一句話：錯了你當場看得出來，就放手讓它跑；錯了要等到上線、等到下一季、等到客戶回報才發現，就在它動手之前先介入。

Backend 落在中間。有測試覆蓋的部分靠近 frontend，跨服務的狀態一致性靠近 research。

2. spec 要寫多細

判準是這個任務有沒有唯一正確答案。

有唯一解的探索型任務，寫 spec 是浪費時間。「這支查詢為什麼變慢」「這個 test 為什麼在 CI 上掛掉」，你把現象丟給它就好，它會自己去找。你寫的任何 spec，都只是在限制它的搜尋範圍。

開放式任務剛好相反。「做一個訂閱管理頁面」沒有唯一解，你不寫，它就會自己編一個。編出來的通常能跑，但不是你要的那個，而且它不會告訴你它編過。

還有一種中間狀態值得認出來。

你自己也不確定要什麼的時候，先讓它做一個能跑的版本，再拿那個版本當 spec 的草稿。對著空白畫面想需求，比對著一個具體的錯誤版本想需求難得多。

spec 該寫進什麼、不該寫進什麼，是這個系列最後一篇的主題。

3. context 給多少

直覺是給越多越好。

實際上剛好相反。

ECC 那篇裡有一組官方數字很值得記住：外掛裝太多，會把大約二十萬的對話窗口吃到只剩七萬。因為 agent 每次開工都要先把已安裝清單讀一遍，菜單越長，能拿來想你問題的空間就越少。

你實際感覺到的是什麼？它變慢、愛打官腔、一開口先列十個選項、剛講過的需求下一句就忘。

很多人這時候會怪「這個模型變差了」。常常不是模型變差，是菜單太長。

官方建議是一個專案少於十個外接工具。

那如果你的 context 就是很大，砍不掉呢？那是另一個問題，要用壓縮解決，不是節制。Headroom 那套本地壓縮層把 tool output、RAG、檔案、歷史全部壓過再送，省 60 到 95% 的 token 而答案一樣。

一句話收：東西太多但用不到就砍掉，太多但都要用就壓縮。

4. 規劃跟執行怎麼配

這是吳恩達原話裡的「在規劃與執行之間做取捨」，也是 Loop vs Graph 那篇在吵的東西。

兩種模式。Loop 是讓模型自己決定下一步，適合路徑未知的任務，探索空間大，但可能繞路。Graph 是你先畫好合法路徑，它只能在裡面走，適合流程已知的任務，可預測，但畫圖本身要成本。

那篇的結論是這不是選邊題，是加閘門的問題。loop 裡本來就可以有閘門，關鍵是閘門加在哪、加幾個。

實務上的判準，看這個任務你自己做過幾次：做過很多次、流程你講得出來，就畫成 graph 讓它照走；沒做過、你自己也在摸，就開 loop，但在花錢或改狀態的地方加閘門。

5. 什麼時候該加驗證器

六個判斷點裡，這個最被低估。

吳恩達的原話是「提供 verifier 或 evals，讓 agent 能自己把迴圈收掉」。意思是與其你每一輪都去看它做對沒有，不如給它一個能自己判斷的機制。

驗證器可以很土。一個會跑的測試、一條 lint 規則、一個型別檢查、一個 curl 出來要拿到 200 的腳本。

有這些東西的時候，agent 可以自己跑十輪。沒有的時候，每一輪都要你當人肉裁判。

真正需要判斷品質而不是對錯的時候，驗證器就得升級成評分器。那正好是系列上一篇的 evals 閉環在講的東西。

一句話：沒有驗證器的自主迴圈，只是讓模型自我感覺良好得更快。

6. 什麼時候拆成多個 agent

多 agent 不是規模越大越好。是要有東西可以平行。

判準兩條，缺一不可：子任務彼此獨立，不用交換中間狀態；而且全部塞進同一個 context 會爆。

兩條都成立才值得拆。有順序依賴的話，多 agent 只是把「等待」換成「協調」，通常更慢。

真的要拆的時候，協調機制比 agent 數量重要。Claude Code 的 dynamic workflows 那套 implementer、verifier、fixer 三角，關鍵不在能跑上百個 agent，在於執行順序是嚴格保證的。

沒有那個保證，agent 越多打架越兇。

六個判斷點總表

三件不能交出去的事

前面六個判斷點都是程度問題。這三件是開關問題。

正式環境資料庫的寫入與遷移。 吳恩達在技能圖裡直接點名了這一項。agent 讀 production 資料通常還好，寫就是另一回事。

憑證與金鑰。 不要讓它有能力把 service role key 貼進任何檔案。

不可逆的對外動作。 發布、寄信、刪除、付款。這些要人按下去。

判準很簡單：這個動作出錯之後，能不能用一個指令復原？不能的話，就不是 agent 的工作。

這項技能會過期，所以你要有更新機制

吳恩達在這一項的最後補了一句，我覺得比前面整份清單都重要。

因為 agentic coding 變化太快，這項技能不只是「知道當下的最佳做法」，還包括有沒有一套持續試新工具、持續更新工作流的習慣。

這是四項技能裡唯一一個今天學會、半年後可能要重學的。多 agent 協調尤其明顯，dynamic workflows 那套做法一年前根本不存在。

實務上怎麼做？把它變成例行工作。每一季挑一個你現在工作流裡最痛的環節，花半天試市面上的新做法。不是每次都會換，但你至少會知道自己落後多少。

利益揭露：以下是聯盟連結。長時間盯著 agent 跑的人，桌面環境的影響其實比機器規格大，桌面開發者 4 件套（機械鍵盤、USB-C Hub、螢幕掛燈、站立書架）是常見的 CP 值組合。

常見問題

coding agent 什麼時候該介入、什麼時候該放手？

看驗證成本。錯了你三秒鐘就看得出來，放手讓它跑。錯了要等到上線才發現，就在它動手之前介入，先確認方向。

要不要每次都寫詳細的 spec？

不用。判準是這個任務有沒有唯一正確答案。有唯一解的探索型任務寫 spec 是浪費，直接給它現象讓它查。開放式任務才需要，因為它會自己編一個你不想要的答案。

context 給越多越好嗎？

不是。ECC 專案的官方數字是外掛裝太多會把大約二十萬的對話窗口吃到只剩七萬。官方建議一個專案少於十個外接工具。

什麼時候該拆成多個 agent？

子任務彼此獨立、而且合起來會塞爆單一 context 的時候。有順序依賴或要共享中間狀態的話，多 agent 只會增加協調成本。

哪些事情絕對不能交給 agent 自己做？

不可逆的操作：正式環境資料庫的寫入與遷移、憑證與金鑰、刪除、對外發布。

回到開頭那個 19%。

METR 那個實驗最有意思的地方其實不是「AI 讓人變慢」，是那些開發者事後仍然覺得自己變快了。

他們對自己的判斷沒有感覺。

所以真正的問題不是「你的 agent 好不好用」。是你上一次認真量過「有 agent」跟「沒 agent」做同一件事的時間差，是什麼時候？