多數網站不允許被內嵌預覽——若下方空白或出現錯誤頁，請改用上方「複製網址」或「開新分頁 ↗」。
燈塔文摘 · LIGHTHOUSE DIGEST
*——AI／Agentic 時代的工程產出衡量，錯在哪，以及小團隊該怎麼做*
2025 年，METR 做了一件簡單的事：找 16 位資深開源開發者，在他們自己平均待了五年的成熟專案裡，隨機指派 246 個任務——一半可以用 AI 工具，一半不行。
開工前，開發者預測 AI 會讓他們快 24%。做完之後，他們回想，覺得自己快了 20%。
實測結果是慢了 19%。
感覺與事實之間差了將近 40 個百分點。而這些人不是新手，是在自己最熟的程式碼裡工作的資深工程師。
這個研究後來被過度引用，也被過度反駁。它的邊界很清楚：樣本只有 16 人、工具是 2025 年初的版本、任務都在成熟程式庫裡。它不能證明「AI 讓人變慢」。METR 自己在 2026 年 2 月宣布要改實驗設計，因為新一輪出現了嚴重的自我選擇偏誤——太多開發者拒絕參加「不能用 AI」的那一組。
但它證明了另一件更麻煩的事：在 AI 輔助的工作裡，人對自己速度的判斷是不可靠的。
而幾乎所有關於「工程師產出」的討論，都建立在某種形式的速度直覺上。
當我們說「AI 時代不能再用工時衡量工程師」，這句話對。用投入時數當個人績效分數，早就被業界丟進垃圾桶——2023 年 McKinsey 發表「你可以衡量開發者生產力」之後，Kent Beck 與 Gergely Orosz 聯手寫了一篇逐字反駁，稱那套框架「錯得離譜、註定反噬」。SPACE 框架（GitHub、微軟、維多利亞大學，2021）更早就破除了三個迷思：生產力不等於活動量、生產力不只關乎個人、單一指標永遠不夠。
問題出在替代方案。
當工時被拿掉，最直覺的填補是缺陷相關的指標：遇到幾個 bug、多快修好、多快發現走錯路。這聽起來比工時「實質」得多——工時衡量投入，bug 衡量結果。
但它更糟，而且糟在三個不同的層次。
第一，缺陷數與能力沒有穩定關係，有時甚至反向。 GitClear 分析了 2.11 億行程式碼變更（2020–2024，涵蓋 Google、微軟、Meta 等專案），發現重構碼的佔比從 2020 年的約 25% 掉到 2024 年的不到 10%，複製貼上的程式碼首度超過搬移的程式碼，重複的程式碼區塊在 2024 年增加約八倍，而「兩週內被改掉或回退」的churn 較 AI 普及前約翻倍。這是一個結構性的結果，不是個別工程師能力差。做探索性工作的人、碰新穎問題的人、寫得多的人，bug 本來就多。
第二，它會被立刻操弄。 這不是理論。文獻裡的具體案例包括：把「開啟中的 bug 數」當指標，導致工程師開始草率關票；把「關閉的 bug 數」當目標，導致一張票被拆成五張；把測試覆蓋率當目標，導致大量不驗證任何有意義行為的測試。Goodhart 法則在工程指標上不是隱喻，是每次都會發生的事。
第三，也是最關鍵的：在 agent 大量參與的專案裡，bug 已經無法歸屬於人。 當三成到七成的程式碼由模型生成，「這個 bug 是誰的」這個問題失去了意義。版本控制的足跡不再支撐任何關於理解程度的推論。
所以 DORA 官網明文列出反模式：這些指標是給應用或服務層級用的，不要做跨團隊比較，不要設成目標。DX 的 Core 4即使把「每位工程師的 diff 數」納入，也明確聲明不在個人層級追蹤、必須用開發者體驗指數對衝、且不得掛勾獎勵。
這裡是我認為多數討論沒有走到的地方。
前 OpenAI 研究長 Bob McGrew 在描述 agentic 軟體工程能做什麼時說得很直白：修一個 bug、做一次重構——這類工作需要的品味相對少，而且結果明確。
把這句話和上面的指標問題並置，會得到一個不舒服的結論：
我們想拿來衡量人的那些東西——bug 數、修復速度、缺陷率——描述的正是 agent 已經做得不錯、而且會越來越好的那一半工作。
那另一半是什麼？
Anthropic 在談 agent evals 時給了一個很好的答案：eval 的價值在於「迫使產品團隊明確定義什麼叫成功」。兩位工程師讀同一份規格，對邊界情況會有不同解讀；eval 套件消解這個歧義。Thoughtworks 的 Birgitta Böckeler 從另一個方向指到同一點：AI 時代的高價值工作是設計「harness」——指引加上感測器——並守住可維護性。
也就是說，人的差異落在：問題定義的品質、上下文工程、eval 設計，以及判斷哪些決策是不可逆的。
這四樣沒有一樣會出現在 DORA 的四個指標裡。
還有一個更基本的問題，而它幾乎不被提起。
DORA、SPACE、DX Core 4 都很好。但它們的資料要從 CI/CD 管線、事件追蹤系統、部署遙測、工單系統裡撈出來，而且需要足夠的樣本數才有統計意義。
台灣一家八人的設計工程公司，這些一項都沒有。一家精品顧問公司沒有。一個帶著 agent 群工作的獨立開發者沒有。
而這些不是邊緣案例——在 AI 大幅降低了「一個人能做多少事」的門檻之後，世界上有大量的軟體與系統工作正在這個信封之外發生。
對他們來說，主流的量測文獻不只是用不上，而是會誤導。強行套用一個為三百人工程組織設計的框架到八個人身上，得到的數字沒有意義，但看起來很有意義——這比沒有數字更危險。
那該量什麼？
我的答案是四個指標，全部可以用試算表加上既有工具收集，不需要任何遙測基礎設施：
一、每週可展示的可運作成果數。 取代部署頻率。連續兩週為零，就是有問題。
二、重工率。 交付後被打回、返修，或上線七天內需要修正的比例。這是小公司版的變更失敗率，用人工標記就能做。
三、客戶回報問題的趨勢。 不看絕對值，看趨勢，特別看「同一個問題重複回報」——那是根因未解的訊號。
四、採用率與可追溯性。 目標使用者裡有多少人真的在用，以及系統的回答能不能追溯到來源。
第四項是四個裡面最重要的，理由值得說清楚。在 AI 導入專案裡，採用率幾乎是投資報酬的最大槓桿——40% 採用率與 85% 採用率之間，淨現值可以差三到四倍。而採用率下滑最常見的原因不是功能不好，是使用者無法確認答案從哪來，於是恢復手動核對。這個模式很好認：導入後前兩週使用量衝高，然後掉下來。
最後一塊，給做 AI 導入、agent 建置、知識系統部署的人。
各家機構對 AI 專案失敗率的估計方法不同、數字不一，但根因的診斷高度一致。RAND 訪談了 65 名工程師後把首要原因寫得很清楚：業界關係人經常誤解或誤傳「要用 AI 解決的是什麼問題」，導致部署出來的模型被最佳化到錯誤的指標上，或根本不符合整體業務流程。Gartner 預測到 2027 年底會有超過四成的 agentic AI 專案被取消，理由是成本失控、商業價值不明、風險控制不足。MIT 的 Project NANDA 研究則發現，只有約 5% 的整合型 AI 試點真的產出數百萬等級的價值，絕大多數沒有可衡量的損益影響。
翻譯成一句話：失敗的不是技術，是沒有人在開始之前說清楚成功長什麼樣。
OpenAI 在其 Forward Deployed Engineering 的職缺描述裡，把這件事寫得比任何顧問方法論都具體：設定影響假設、基準線與 KPI，執行部署前後的量測，並向高層贊助者回報。Palantir 對其 Delta 工程師的定義同樣直接——他們以「對客戶目標的影響」衡量成功。
所以一份 AI 部署的成功契約，至少要有這幾樣：用客戶的話寫的問題陳述；部署前的基準線量測；雙方同意且可歸因的成功指標與門檻；共同定義的「第一個真正有用的結果」及其達成日期；明訂的量測方法與歸因方式；客戶端在推廣與訓練上的責任。
其中「部署前的基準線」是最常被跳過、也是失敗率最高的一項。沒有基準線，事後所有的成效敘述都只是敘述。
如果部署的是 agent 系統，還要多一條：驗收不能用單次成功率。 學術上有一個好用的區分——pass@k 是「跑 k 次至少成功一次」的機率，衡量能力上限；pass^k 是「跑 k 次全部成功」的機率，衡量可靠度下限。使用者對一個要被信任的系統，期待的是每次都對，不是五次裡有一次對。pass@5 很高但 pass^5 很低的系統，是「會做但不穩定」——對信任而言，那比不會做更糟。
寫完這些，我要說一個和上面所有內容方向相反、但我認為更重要的觀察。
在小團隊與個人的實務裡，我看到最頑固的失效模式不是 bug，不是速度，也不是品質。
是計畫寫完了，第一個動作沒有發生。
完整的網站規格，站是空的。建好的社群基礎建設，零個成員。寫給投資人的一頁紙，錯過的里程碑。十三項交付清單，當週一項未啟動。完整的系統架構，五個關鍵設計問題懸著沒答。
失效點永遠落在「計畫存在」與「第一個動作發生」之間。這不是思考能力的問題，是交接的問題——計畫變成了一個令人滿足的終點，而不是發射台。
而一個以產出量、文件數、交付件數為進度證據的量測系統，會精確地餵養這個失效模式。你會越量越勤奮，越量越不動。
所以如果只能留一個指標，我會留這個：
從「決定要做」到「第一個實際動作發生」之間，過了多久。
以及更有價值的那一欄：超過期限沒動的時候，寫下一行「為什麼沒動」。
累積十筆，你會看到自己真正的阻塞在哪裡。通常不是能力，不是時間，是某個沒被寫出來的猶豫。
那一行字，比任何儀表板都準。
全部 21 件來源，依支持的段落分組，逐一可點開檢視原文。