AI 導入的 KPI 怎麼訂：你省下的工時，正在從退回重做那邊還回去

先講結論：用「省下多少工時」當 AI 導入的 KPI，很容易在第一次檢討時就失準。

原因有兩個。第一，那個「省下的工時」大多是自己估的，而自己估的省時並不可靠。第二，省下的時間有很大一部分會被返工吃回去——而返工多半不會出現在產出者的報表上，它出現在收件者的桌上。

所以我會建議把 KPI 換成兩個在收件端量的數字：退回率，和追問補件率。

先交代這篇的邊界：我沒有做過企業級的 AI 導入，也沒有設計過企業績效制度。所以這篇的依據只有兩個：公開的研究與調查數據，以及我自己那套網站後台自動化裡，實際量得到、也真的影響過我決策的數字。你搜「AI 導入 KPI」，前排幾乎都是日本的顧問網站，繁中能參考的很少——這篇試著補一塊，但它不是顧問框架。

另外，〈這五種工作我交給 AI，結果更慢〉那篇已經談過「用 AI 會不會反而更慢」，這篇不重複，只回答一件事：該量什麼。

為什麼「省下多少工時」這個 KPI 撐不久？

「省下多少工時」撐不久的第一個原因，是它幾乎都來自自評，而人對「AI 省了自己多少時間」的估計並不可靠。

這件事我在〈這五種工作〉那篇拆過：METR 的隨機對照實驗裡，資深開發者做完之後自認快了 20%，實測卻慢了 19%。METR 在 2026 年 2 月的更新裡表示，現在的 AI 工具很可能已經讓開發者比 2025 年時更快，但同時再提醒了一次：開發者自評的加速「可能相當不可靠」。速度的數字會隨工具改變，自評不可靠這一點沒有變。（這組研究的對象是軟體開發，我只取「自評和實測對不上」這一點。）

回到你的 KPI：如果「省下幾小時」是請同仁每個月填一次的，你拿到的就是那個不可靠的數字。

AI 省下的時間去了哪裡？將近四成被返工吃回去

AI 省下的時間有相當比例會被返工吃回去，一份規模不小的公開數據，來自 Workday 在 2026 年 1 月發表的調查。

那份調查在 2025 年 11 月執行，訪問了北美、亞太、歐洲中東非洲的 3,200 名全職員工，受訪者都任職於年營收一億美元以上的企業、而且都在使用 AI。幾個數字：

• 85% 的員工表示 AI 每週幫他們省下 1 到 7 小時
• 但將近 40% 省下的時間，花在了返工上——修正錯誤、改寫內容、驗證產出
• 只有 14% 的員工能穩定地從 AI 得到明確的正面淨效益

先加一個但書：這是廠商發布的調查，而且是受訪者自己回報的，不是實測。但它至少把一件事量化了：「省下的時間」和「淨省下的時間」之間，有一個很大的洞。

軟體開發這邊也有類似的訊號。Google 的 DORA 2024 年度報告發現，AI 採用率每提升 25%，文件品質提升 7.5%、程式碼品質提升 3.4%——但交付吞吐量估計下降 1.5%、交付穩定度估計下降 7.2%。同一份報告裡，超過三分之一的受訪者覺得 AI 讓自己的生產力有中度到極大的提升。

DORA 的交付指標同樣來自問卷，所以這不算「感覺對上實測」。但在同一份問卷裡，覺得自己變快的人不少，交付的穩定度卻往下走——又是那個洞。

返工多半不會出現在產出者的報表上

這個洞之所以長期看不見，是因為省時和返工被記在不同人的帳上。

舉個例子：產出者用 AI 十分鐘寫完一份報告，他覺得自己「省了 50 分鐘」。收件的主管花了一段時間修改，又退回去要求補資料，產出者再花時間補——這些時間散落在兩個人的行事曆裡，很少有人會把它們加回那份報告的成本上。

所以只看產出端的 KPI，看到的只會是省下的那一半。

返工落在誰身上，也值得看

Workday 那份調查還有兩個細節：在返工負擔最重的那群人裡，將近一半（46%）是 25 到 34 歲的員工；而每天使用 AI 的人當中，有 77% 表示他們檢查 AI 產出的仔細程度，跟檢查人做的東西一樣、甚至更仔細。

我的解讀是：認真把關的人，默默吸收了很多驗證和修正的工作。 如果你的 KPI 只獎勵「省下的工時」，等於在獎勵把返工推給下游的人，而那些默默把關的人，在報表上留不下痕跡。

我自己的流程裡，讓我動手調整的是退回次數

我自己的流程裡，真正讓我動手調整的數字是「被退回幾次」，而不是「省了多少時間」。

我的網站後台有一整套自己搭的自動化，其中有一個模組，我從來沒算過它省了我多少時間。上線第一天，它跑出來的結果就被我退回，當天我就給它加上一道規則：預設不用，要先通過五題評估才能啟動。

但在那之後的三週裡，它的結果又被我退回了 3 次。四次退回，我回頭看當時的回饋，語氣一次比一次重。

我沒有它省了多少時間的數字，卻有它被退回幾次的數字——而讓我動手收緊的，是後面那個。

另一件讓我印象很深的是「修補製造返工」。有一次我修一篇排版問題時，把整段內容蓋回去，連原本的 2 張圖一起蓋掉了。為了修 A 弄壞了 B，B 又要再修一次。這種返工，在「省下工時」的統計裡是看不到的。

該量的兩個數字：退回率與追問補件率

AI 導入的成效指標，我建議改量兩個數字：退回率與追問補件率。兩個都在收件端量，因為返工發生在那裡。

退回率：多少產出需要重做或大改

定義：一段期間內的產出，被收件人「退回重做」或「自己大改」的比例。

怎麼數：收件人每收到一份，先勾一格處理結果——

• 直接可用
• 小修（改幾個字就能用）
• 自己大改（沒退回，但自己重寫了一大段）
• 退回重做

再另外勾一個：有沒有追問或要求補資料（可以和上面任何一格同時成立）。

如果能順手記一下「大概花了幾分鐘處理」更好——到了第四週，你就能把返工換算成時間，跟產出端省下的時間放在一起比。

一週統計一次。不需要系統，一張共用表格就夠。

看什麼：看趨勢，不看單週。導入初期大家還在摸索，前幾週的數字別太早下結論；如果兩三個月後還沒下降，就代表這個流程省下的時間，正在被返工抵銷。

「自己大改」為什麼要單獨一格？因為很多返工不會變成退回——收件人嫌麻煩，就自己默默改掉了。Workday 算的返工，本來就包括修正、改寫和驗證；少了這一格，最大宗的返工很可能會被勾成「小修」而消失。

追問補件率：多少產出「看起來完整，其實缺東西」

定義：收件人為了能用這份產出，回頭追問、或要求補資料的比例。

這一項是退回率抓不到的。AI 的產出很多時候不是爛到要退，而是看起來完整、格式漂亮，但少了關鍵的一段——就像我在〈跨部門週報交給 AI〉那篇寫的，AI 摘要最容易漏掉的是中段的卡關紀錄。收件人不會退回，但會多問一句：「那個卡住的事，後來怎麼樣了？」

那一句追問，就是返工。 只是它小到沒有人會記。

為什麼不量「使用率」？

使用率量的是「有沒有人在用」，不是「用了之後有沒有變好」。一個退回率很高的流程，使用率照樣可以是百分之百——每個人都在用，每個人都在返工。使用率可以當導入初期的輔助觀察，但不適合當 KPI。

這兩個數字有三個偏差，量之前先知道

• 標了「AI 參與」，收件人會看得更嚴。 Workday 那份調查裡，每天用 AI 的人有 77% 表示檢查 AI 產出跟檢查人做的一樣仔細、甚至更仔細。如果只有 AI 參與的產出被勾選，退回率會被墊高。比較公平的做法，是所有產出都勾，不管有沒有用 AI
• 下屬不太敢退主管的東西。 收件人和產出者的上下關係，會壓低退回率。解讀數字時，往下交的產出和往上交的產出要分開看
• 勾得確不確實，決定尺準不準。 只有覺得很爛才勾，數字就會偏高；忙起來就不勾，數字就會斷掉。下一節是我自己在這件事上踩過的坑

開始量之前，先確認你的尺是準的

設定 AI 導入 KPI 之前，還有一件常被跳過的事：確認量測工具本身是對的。

我自己踩過一次很大的。有一天，我根據儀表板上的數據做了大半天的分析：儀表板顯示網站每月點擊不到兩千，我據此排了一整份改善清單，甚至算出「流量有機會翻倍」。

當天晚上，我直接打開原始的數據後台對照——實際是一萬五千多，儀表板少算了大約 8 倍。

原因是儀表板彙整時有筆數上限，只加總了前面一段。更麻煩的是，同一個儀表板上的收益數字是準的，壞的只有點擊那一塊。

那天我學到的是：全錯的尺很容易發現，半錯的尺才會讓人一直相信。 你的勾選表也一樣——如果只有部分收件人在填，或只有覺得很爛的時候才填，你拿到的就是一把半錯的尺。開始量之前，先確認每一份產出都會被記到。

怎麼開始量 AI 導入成效：三個步驟，不用買系統

開始量 AI 導入成效不需要買任何系統，三個步驟、四週就能拿到第一組數字。

1. 挑一個已經在用 AI 的產出類型，例如週報、報價初稿、會議紀錄。一次只挑一種
2. 讓收件人每份勾一格處理結果、再勾有沒有追問，最好順手記處理的分鐘數，連續四週
3. 第四週結束時，把兩邊並排：產出端自評省下的時間，和收件端花在大改、退回、追問上的時間

如果收件端花掉的時間，已經接近產出端說省下的時間，那個時間其實沒有省下來，只是換了一個人在花。

如果你們導入 AI 之前沒有留下基準數據，不用懊惱——現在開始數，四週後就有自己的基準線。外部給的「正常退回率」，通常不會比你們自己的前四週準。

這套指標適合誰、不適合誰

退回率與追問補件率，最適合產出會交給別人使用、而目前只拿得出「省下幾小時」的團隊。

適合你，如果：

• 你要跟上層報告 AI 導入成效，而目前手上只有「省下幾小時」
• 你的團隊產出會交給其他人使用（主管、客戶、其他部門）
• 你隱約覺得「大家都說有省時間，但我怎麼沒有比較輕鬆」

不適合你，如果：

• AI 產出只給產出者自己用、不交給任何人——那就沒有收件端可以量
• 你需要的是財務層級的投資報酬率計算——退回率是營運指標，不能直接換算成錢

代價：

收件人要多做一個動作。 每份勾一下看起來很少，但通常會有人覺得麻煩，前兩週特別需要提醒。

數字剛出來時可能很難看。 退回率一量出來，常常會讓原本漂亮的「省時」簡報變得尷尬。要先跟推動的人講好，這是在找問題，不是在找戰犯。

團隊可能會覺得被監控。 所以只數「產出類型」，不數「誰的產出」——量的是流程，不是人。

這兩個數字，工具後台會幫你算嗎？

退回率和追問補件率，AI 工具的後台通常不會幫你算——它們要在收件端自己數。工具後台能提供的，多半是「誰用了多少」這類使用量資訊。

如果你們正在評估從個人帳號換成團隊或企業方案，各方案差在哪，可以參考我在自己部落格整理的 ChatGPT 各方案差異整理。

FAQ 常見問題

老闆只想看「省下多少工時」，怎麼說服他加上退回率？

不用說服他拿掉工時，只要並排放。下次報告時同一頁放兩欄：產出端自評省下的時間，收件端花在大改、退回、追問上的時間。如果兩邊都好看，那很棒；如果兩邊都很大，老闆自己就會開始問「那時間到底有沒有省到」——這比你去說服他有效得多。

退回率多少算正常？有沒有業界標準？

就我查到的公開資料，沒有可以直接套用的業界標準，我也不建議去找——不同產出類型、不同收件人的標準，退回率會差很多。比較可靠的做法是跟自己比：前四週的數字當基準，之後看趨勢。如果有人給你一個「業界平均退回率」，先問他那個數字是怎麼量的。

AI 參與的產出，要不要標出來讓收件人知道？

我會建議不要只標 AI 的。一旦收件人知道哪份有 AI 參與，檢查的標準就可能不一樣，退回率會被墊高。比較好的做法是所有產出都用同一張勾選表，產出者自己另外記哪幾份有用 AI，最後再分開算。這樣比的才是同一把尺。

已經導入半年才開始量，還來得及嗎？

來得及，而且半年後的數字比較不受導入初期摸索的影響，更能反映流程的真實狀態。唯一的限制是沒有「導入前」的基準可以比——那就挑幾份完全不用 AI、純人工做的產出，一起放進勾選表對照就好。

參考資料

METR，Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity（2025-07-10）：16 位資深開源開發者、246 項任務；事前預期快 24%、事後自評快 20%、實測慢 19%；研究者明言不代表軟體開發以外領域。

METR，We are Changing our Developer Productivity Experiment Design（2026-02-24）：認為現在的 AI 工具很可能比 2025 年估計時更能加速開發者；新實驗數據因開發者不願在無 AI 下工作而不可靠；自評加速可能相當不可靠。

Workday，New Workday Research: Companies Are Leaving AI Gains on the Table（2026-01-14；報告〈Beyond Productivity: Measuring the Real Value of AI〉，n=3,200，2025-11 執行）：將近 40% 省下的時間被返工吃掉；85% 每週省 1–7 小時；僅 14% 穩定獲得正面淨效益；返工最重者 46% 為 25–34 歲；每日使用者 77% 檢查 AI 產出與人工一樣或更仔細。

Google Cloud，Announcing the 2024 DORA report：AI 採用率 +25% 對應文件品質 +7.5%、程式碼品質 +3.4%，交付吞吐量估計 −1.5%、交付穩定度估計 −7.2%；逾三分之一受訪者感受到中度至極大的生產力提升。