這五種工作我交給 AI，結果更慢——後來我一件一件收回來自己做

先講結論：我交給 AI 的工作裡，大概有五分之一後來被我收回來自己做。 不是因為 AI 做不好，是因為做完之後我要花更多時間去確認它有沒有做好。

我每天用 AI 的時間超過十小時，這篇不是唱衰。恰恰相反——正因為用得夠多，我才有機會分辨哪些是真的省時間、哪些是把時間換了個地方花掉。

而讓我真正改變做法的，是一份研究。

一份讓我改做法的研究：他們以為快了 20%，實際慢了 19%

先給結論：你對「快慢」的體感，跟實際耗時可能是反向的。

研究機構 METR 在 2025 年上半年做過一個隨機對照試驗。他們找了 16 位資深的開源開發者，在他們自己熟悉的專案上完成 246 個工作項目（平均每件約兩小時），隨機指定哪些項目可以用 AI、哪些不行。

三個數字擺在一起看：

• 開始之前，他們預期 AI 會讓自己快 24%
• 結束之後，他們認為 AI 讓自己快了 20%
• 實際測量結果：可以用 AI 的時候，完成時間多了 19%

這些人不是外行，是在自己最熟的專案上工作的資深開發者。他們也不是說謊——他們是真心覺得變快了。

我第一次看到這個結果的時候，第一反應是「所以 AI 沒用嗎」。但這個結論是錯的，而且 METR 自己就把這條路堵死了。

研究團隊明確聲明：這份研究不主張「AI 不會加速多數開發者」，也不能外推到軟體開發以外的領域，更不保證隨著模型進步結論還成立。

而且他們在 2026 年 2 月發過一份更新。他們沒有撤回 19% 這個結果——那個時期的數據仍然有效——但他們坦承後續實驗遇到嚴重的選樣問題：開發者越來越不願意參加「不能用 AI」的組，有三到五成的人自承挑掉了不想在沒有 AI 的情況下做的任務，加上報酬從每小時 150 美元降到 50 美元。他們自己的結論是：生產力此後應該已經改善，但新數據只能提供「非常微弱的證據」。

所以這份研究能拿走的，不是「AI 讓人變慢」。

能拿走的是那個感知落差：預期快 24%、自認快 20%、實際慢 19%。這件事跟寫不寫程式無關，是人在評估自己的時候會犯的錯。而它可以外推——因為你評估自己有沒有變快的時候，用的是同一套不可靠的直覺。

我看完之後做的第一件事，是開始計時。結果就是下面這五種。

我交出去又收回來的五種工作

一、需要翻很多前情才能判斷的

最典型的是回一封牽涉到三個月前討論的信。

表面上這件事很適合 AI：讀信、寫回覆，都是文字工作。實際上我得先把前面五封信、兩份文件、一次會議的結論整理給它，它才有辦法寫出不離題的東西。

而「把前情整理清楚」這件事本身，就佔掉這個任務八成的時間。整理完之後，我通常已經知道要回什麼了。

判斷法：如果餵資料的時間比做事的時間長，這件事不該交出去。

二、規則零散、例外一堆的

我有一份文件格式規範，大原則五條，例外大概二十條——這種情況下、那種狀況要改成什麼樣。

我試過把規範整包餵給 AI。它會遵守前面幾條，然後在第七、第八條開始漏。更麻煩的是它漏得不一致：同一份文件裡有些地方對、有些地方錯，我沒辦法用「檢查某一項」的方式驗收，只能整份重讀。

判斷法：如果你沒辦法用抽查的方式驗收、只能整份重看，那省下來的時間會在檢查階段還回去。

三、錯了要很久才發現的

這條我在前一篇寫導入順序時也提過，因為它真的是最貴的一種。

我交出去過一次資料整理，格式漂亮、看起來完全正確，兩週後才發現其中一組數字的單位被它「順手統一」了。回頭修的成本，遠超過當初省下的四十分鐘。

判斷法：問自己「如果它錯了，我多久會知道？」答案超過一天的，先不要交。

四、我自己也講不清楚標準的

這條最尷尬，因為問題在我身上。

像是「這段語氣要再收一點」——收多少？收成什麼樣？我腦子裡有答案，但我寫不成一句話。寫不成一句話，就沒辦法變成提示詞，於是變成我改一次、它調一次，來回五六輪。

那五六輪加起來，比我自己重寫還久。

判斷法：你能不能把驗收標準寫成一句話？寫不出來，代表這件事的標準在你的直覺裡，而直覺沒辦法交接。

五、產出必須逐字校對的

繁體中文的內容特別容易踩這條。

AI 產出的繁中經常會混進簡體用詞——「視頻」「軟件」「質量」「打印」這類。單看每一句都通順，所以你不會被明顯的錯誤絆住，但它們就是不對。而要抓出來，你只能逐字讀。

逐字讀一份兩千字的文件，跟自己寫一份兩千字的文件，時間差沒有你想像的大。

我後來的做法是把這類任務拆開：讓 AI 做結構和初稿，但用詞的最後一關我自己過。這比全交或全不交都好。我在自己的部落格上寫過一篇AI 翻譯的實測與選法，裡面有整理不同場景該用哪個工具、以及繁中用詞這個坑要怎麼處理。

為什麼「感覺變快」會騙人？我後來想通三件事

等待的時間，大腦不算數

AI 跑的時候你在滑手機、回訊息、看別的東西。那段時間有流逝，但因為你不覺得自己在「工作」，它不會被記進「這件事花了多久」。

自己動手的時候，每一分鐘都是你在敲鍵盤，所以感覺很長。

同樣二十分鐘，一個感覺像五分鐘，一個感覺像二十分鐘。

修正的時間被切成碎片

自己寫，是一段連續的三十分鐘。用 AI，是「等三分鐘、改兩分鐘、再等三分鐘、再改兩分鐘」重複八次。

後者的總時間可能更長，但因為被切碎了，每一段都不長，回想起來就不覺得久。

「不用從零開始」的輕鬆感，會被誤記成「快」

面對空白畫面很痛苦。有一份草稿在那裡，就算你最後幾乎全改，心理負擔還是低很多。

低負擔會被記成「順利」，順利會被記成「快」。但輕鬆和快是兩件事——這是我自己最常犯的錯。

我現在怎麼判斷該不該交出去

不要用感覺，用碼表。方法很土但有效。

做法：挑一件你正在猶豫的任務，接下來兩次分別用兩種方式做，全程計時。

第一次，自己做。 從開始到交付，中間去回訊息也算，就是不要停錶。記下總時間。

第二次，交給 AI。 但這次要記三個數字：

• 餵資料的時間（整理前情、寫提示詞）
• 等待的時間（它在跑、你在做別的事）
• 修正的時間（從拿到產出到能用為止，包含逐字校對）

三個加起來，才是這件事真正的耗時。多數人只記第三個，甚至只記「最後改了兩處」，於是嚴重低估。

然後比較。如果 AI 版沒有比自己做快 30% 以上，我就收回來自己做。

為什麼是 30% 不是「只要比較快就好」？因為還有維護成本——提示詞會過期、流程會變、模型會更新。省不到 30%，那點差距會被維護吃掉。

這套判斷適合誰、不適合誰

適合你，如果：

• 你已經用 AI 一段時間，開始懷疑「到底有沒有比較快」
• 你手上有幾件反覆在「要交不交」之間擺盪的任務
• 你願意花兩次的時間做一次比較

不適合你，如果：

• 你才剛開始用——這階段本來就會慢，那是學習成本不是判斷依據，至少用滿一個月再測
• 你的任務量大到人工根本做不完（那時候「比較慢」也還是得交出去，這是產能問題不是效率問題）

代價：

這個方法本身要花時間。 同一件事做兩次，第一次還不能用 AI。我只對「反覆猶豫、而且每週都會發生」的任務做這件事，一次性的任務不值得測。

測出來的結果可能讓你不舒服。 我測完之後收回了五種工作，其中兩種是我一開始最得意的自動化。承認那兩個月白花了，不太好受。

那什麼還是該交給 AI？

免得看起來像在勸退，這裡講清楚另一半。

我測完之後留下來、而且省很多的，共通點很一致：輸入格式固定、輸出有明確樣板、而且我不需要逐字讀就能驗收。

具體像是：把會議逐字稿轉成待辦清單、把散落的進度回報整理成固定格式的摘要、把一種表格轉成另一種格式、大量文件的初步分類。

這些任務有個共同特徵——我可以用抽查的方式驗收。抽三筆看對不對，對了就信整份。能抽查，省下來的時間才留得住。

反過來說，前面那五種全都不能抽查，只能整份重看。這就是分界線。

FAQ 常見問題

我用了半年還是覺得比較慢，是我用得不對嗎？

有可能，但也可能是任務挑錯。先用碼表測一次再說——分開記「餵資料、等待、修正」三段。如果卡在餵資料那段特別久，是任務不適合；如果卡在修正那段，是驗收標準沒定義清楚。這兩種的解法完全不同，用感覺分不出來。

團隊成員說用了 AI 比較快，我該相信嗎？

相信他的感受，但不要拿它當成效證據。METR 那份研究裡的資深開發者也真心覺得自己快了 20%，實際慢了 19%。想知道有沒有真的變快，只有計時一途——而且要記完整三段，不能只記「最後改了幾處」。

那份研究是講工程師的，我們不是科技業，還適用嗎？

研究本身不適用——METR 自己就寫明結論不能外推到軟體開發以外的領域，這點我必須講清楚。可外推的只有「人評估自己速度時會系統性高估」這個現象，因為那是認知偏誤不是產業特性。所以請不要拿 19% 這個數字去說服你的老闆，要拿的是「我們該計時」這個做法。

收回來自己做，會不會顯得我在抗拒 AI？

我的經驗是相反的。能具體說出「這五種我測過、不划算，所以收回來；那三種省了多少，所以留著」的人，比「全部都要 AI 化」的人更有說服力——因為前者顯示你真的測過。全交或全不交都是還沒開始判斷。

參考資料

METR，Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity（2025 年 7 月 10 日）：隨機對照試驗，16 位資深開源開發者、246 個工作項目；可使用 AI 時完成時間多 19%，而受試者事前預期快 24%、事後自評快 20%。研究團隊明確聲明結論不可外推至軟體開發以外領域，亦不主張 AI 不會加速多數開發者。

METR，We are Changing our Developer Productivity Experiment Design（2026 年 2 月 24 日）：未撤回前述結果，但說明後續實驗因選樣偏誤（受試者不願參與無 AI 組、30–50% 自承挑掉部分任務、報酬調降）而僅能提供微弱證據，並認為生產力此後已有改善。