AI 秒交卷，你卻加班收尾？別把生成速度當成省下的時間

AI 很快吐出一大段答案，你卻花了更久才敢交出去。這不一定代表工具沒用；但如果只算「第一版出現得多快」，你可能把自己的檢查、修正與重做時間，全部從帳上刪掉了。

真正該問的不是「AI 強不強」，而是：這個工具放進你手上這一類工作後，合格結果有沒有更早完成？人的負擔有沒有下降？這是兩個問題，不必強迫它們得到同一個答案。

以為省了時間，不等於真的省了

METR 在2025年公布一項隨機對照研究：16位熟悉自身開源專案的開發者，完成246件真實工作；每件工作隨機分配是否允許使用AI。結果是允許AI的工作完成時間增加19%，參與者事後卻仍估計自己省了20%的時間。

這個反差值得警惕，但它不是「AI讓所有人變慢」的證據。研究用的是2025年初的工具，參與者、專案熟悉度與工作要求都有特定條件，不能直接代表你今天使用的模型或任務。研究設計與限制見METR原始研究說明。

而且不能只停在這個舊數字。METR在2026年2月的研究更新指出：有些人不願接受不用AI的條件，也會挑選願意交給研究的任務；平行使用多個助手時，工時也更難記。團隊認為AI可能比先前更能加速，但這批資料不足以可靠判斷改善幅度。把舊結果當成永遠有效，和把體感當成秒錶，都容易誤判。

先決定什麼才叫做完

下面是原創實務建議，不是複製研究協定。開始前，先寫一句可檢查的完成條件。例如整理資料時，不是「有一份表格」，而是指定欄位齊全、數值核對、原始出處找得到；改程式時，不是「畫面跑出來」，而是需求符合、必要測試通過、結果能被下一個人接手。

這不是要把每份小作業弄成考試，而是避免一邊把草稿當完成品，另一邊卻把收尾全部算進去。比較前先訂同一個終點，才知道誰比較早到。

四段時間，不要只記最漂亮的那段

若有些工作本來就需要檢查，兩邊都要記，不是把所有檢查成本都怪給AI。工具失敗、最後改回手做的那次也要留下；只保留成功案例，得出的比較自然偏向好看。

一個虛構算例：15分鐘交稿，可能70分鐘才收工

以下完全是假設，不是研究數據或實測成果。某次不用AI，完成到可交付花60分鐘；另一次類似工作用了AI，15分鐘有初稿、25分鐘查核、30分鐘修正，合計70分鐘。看到15分鐘就說省45分鐘，漏掉的是後面55分鐘。

反過來，也不能因為某次超時就宣布AI不值得用。兩次任務可能難度不同，你也可能剛學新工具。這個算例只示範怎麼記帳，不證明任何工具會讓你多花10分鐘。

等待時間，和你真正被占住的時間要分開

假如助手在背景跑，你去做另一件事，完成時間可能拉長，但注意力負擔變小。建議分別記錄從開始到合格結果的經過時間，以及你實際投入的時間。兩件事同時跑，不要把同一段人的投入重複相加。

你也可能沒有更早收工，卻覺得比較不累、比較願意開始。這可以是價值，但應該寫成「負擔下降」，不要偷換成「速度提升」。如果產出的範圍變大，也另外註明，別讓多做的東西混進單純的省時比例。

用一小批相近工作，取代一個漂亮故事

挑你確實會重複做的同類工作，先記難度、熟悉度與完成條件，再交錯安排有AI、無AI的做法。不要把同一題做第二次當成公平比較，因為你已經知道答案；也不要只把簡單題交給工具。

留下工具版本、結果品質、所有失敗與返工。看一批工作的分布與異常原因，不只挑最好的一次。這仍是個人的探索紀錄，不是嚴格因果實驗，更不是跨職業通用的生產力排行榜。工具或工作內容變了，就重新看資料。

AI值不值得繼續用，不必靠站隊決定。把做完的標準、收尾的時間、人的負擔分開寫，你才知道自己買到的是速度、輕鬆，還是只是「很像已經完成」的感覺。

查核日期：2026-10-15。本文未獨立重現METR實驗；計時表與做法為原創建議，虛構算例不可當作效果保證。