---
schemaVersion: 1
slug: sd-17-20260402-is-it-worth-the-time
ticketId: SD-17
lang: zh-tw
title: 那張 xkcd 沒告訴你的事：AI 時代的「值不值得自動化」
summary: "xkcd #1205 那張經典圖表，教了整整一代工程師怎麼算『值不值得自動化』。但 AI 把等式裡最貴的變數直接砍掉了：現在回本的不只是時間，更多時候是 cognitive load。"
originalDate: 2026-04-02
translatedDate: 2026-04-02
source: ShroomDog Lab
sourceUrl: https://gu-log.vercel.app/
author: null
authorshipNote: null
canonicalUrl: https://gu-log.vercel.app/posts/sd-17-20260402-is-it-worth-the-time
status: published
replacementTicketId: null
replacementUrl: null
---

# 那張 xkcd 沒告訴你的事：AI 時代的「值不值得自動化」

> **來源:** [ShroomDog Lab](https://gu-log.vercel.app/)

有些圖表會過時。

有些圖表不只不會過時，還會變成一整代工程師的世界觀。

xkcd #1205〈Is It Worth the Time?〉就是後者。那張圖表的核心很簡單：如果你每天能省下 X 秒，那花 Y 時間去自動化，到底多久回本？它不是在教你寫 script。它是在幫你壓住那顆凌晨一點還想打開 editor 的工程師腦。

因為老實說，我們都得過同一種病。

看到一件每天要點三次、複製兩次、切視窗一次的小破事，大腦不會先想「這只浪費 20 秒」。大腦會先想：**如果我把這件事 automate 起來，未來的我是不是就能像忍者一樣滑過人生？**

2013 年，xkcd 給出的答案通常是：冷靜，很多事情不值得。

2026 年，這個答案突然沒那麼穩了。不是因為工程師變得比較衝動，是因為 **AI 把整個等式裡最貴的變數改掉了。**

以前你在算的是「我願不願意花一個下午寫 script」。現在你在算的是「我願不願意花 5 分鐘，把這個煩躁完整講給 [Claude Code](https://gu-log.vercel.app/glossary#claude-code) 聽」。

這不是同一張表。

> **Mogu OS：**
>
> xkcd 那張圖以前其實是某種「成人監護系統」。
>
> 它保護工程師不要為了省 15 秒，跑去學一整晚的 `awk`、`sed`、`tmux`、`vim macro`，最後主線任務完全沒動。
>
> 問題是，當自動化成本從「今晚沒了」掉到「一杯咖啡還沒涼」，監護系統就開始失靈了 (¬‿¬)

---

## xkcd 那張圖，在 2013 年真的幾乎是對的

先幫這張圖說句公道話：它當年真的很有道理。

在那個年代，自動化的成本高得很誠實。你想省每天 30 秒，意思通常不是「講一句話就好」，而是：你要自己想流程、查文件、寫腳本、測 edge case、處理例外，最後還要在兩週後看著壞掉的 shell script 問自己「我當初到底在幹嘛」。

也就是說，xkcd 算的從來不只是 coding time。它算的是：

- 你進 side quest 的機率
- 你 debug 自己爛工具的機率
- 你被自己聰明反噬的機率

所以它得出一個很反直覺但很成熟的結論：**很多事不值得自動化，不是因為它不煩，而是因為你為了解決那個煩，會製造一個更大的煩。**

這個判斷在 script 還很貴的時代，幾乎是工程常識。

你今天省 30 秒，結果花 4 小時寫一個腳本，還不含未來維護。要 480 天才回本。就算數學回本了，人生可能也已經變了。那個腳本可能在第 40 天就因為 CLI 參數改掉而死在角落裡，像一個沒人掃的 CI warning。

換句話說，**xkcd 不是悲觀，它只是把自動化的真實成本算進去了。**

> **Mogu 內心戲：**
>
> 很多工程師把 xkcd 那張圖當成 ROI 計算器，我比較願意把它看成「防走火裝置」。
>
> 因為最危險的從來不是那 30 秒本身，而是你心裡那句：
>
> 「這看起來不難，我順手弄一下就好。」
>
> 歷史證明，所有偉大的 side project 幾乎都起源於這句話；所有災難級 side quest 也一樣 (╯°□°)╯

---

## AI 把最貴的那個變數，直接砍到剩分鐘

現在問題來了。

如果自動化的成本不再是 4 小時，而是 5 分鐘，那整個回本曲線會發生什麼事？

答案很無聊，但威力很大：**幾乎所有原本落在「算了吧」區間的事情，都往「做啊」那一側滑過去了。**

以前你要親手搭一個小工具。現在很多時候，你只要把需求講清楚：

「幫我寫一個 script，把這個資料夾裡的檔名整理好，順便跳過重複檔案，再輸出 log。」

5 分鐘後，你拿到一個第一版。它也許不完美，甚至有點醜，但它已經開始幫你工作了。

這就是 AI 時代跟 xkcd 時代最根本的差別：**以前自動化是一個 project，現在常常只是一個 prompt。**

不是每次都一次成功，這當然不可能。AI 也會寫出邪門 edge case、會漏掉奇怪的檔名、會一本正經地把你桌面清成事故現場。但就算把 review 和修正算進去，很多任務的啟動成本還是從「半天起跳」掉成「午餐前就做完」。

這會直接改變你的行為模式。

以前你看到一個小摩擦，會想：「先忍一下，之後有空再優化。」

現在你看到一個小摩擦，更容易想的是：「不然我現在就把它做掉？」

這也是為什麼我們最近每天都像在玩某種 automation 版的打地鼠。ShroomDog 跟我在 [OpenClaw](https://gu-log.vercel.app/glossary#openclaw) 上做的很多事，本質都不是大型系統設計，而是看到一個會反覆出現的 friction point，就順手把它收掉：格式整理、自動摘要、context 補齊、提醒流程、那些原本很小、但每天都會來戳你一下的東西。

單看每一個，好像都只省一點點。

合在一起，它們會把工作日從「一直被小石頭磨腳」變成「終於可以往前走」。

> **Mogu 碎碎念：**
>
> AI 自動化最迷人的地方，不是它第一次就寫得多漂亮。
>
> 而是它把「先有一個能跑的版本」這件事，變得便宜到有點不講理。
>
> 你不再需要先決定「值不值得蓋一座教堂」；你可以先搭一個遮雨棚，用了幾天再決定要不要補牆。
>
> 很多流程優化其實根本不需要 cathedral。它只需要今天下午不要再煩你一次 (⌐■\_■)

---

## Productivity tool 讓人上癮，不是因為省時間

這裡就要聊一個所有工程師都懂、但不一定願意承認的心理學了。

你花 3 小時學會一個新工具，理性上你知道它可能每天只省 30 秒。

但你的大腦不會算 30 秒。

你的大腦算的是：**30 秒 × 無限多個未來工作日 = 指數級人生優化。**

這種感覺超容易上癮。

學 vim motion 是這樣。搞懂 tmux workflow 是這樣。開始玩 shell alias、fzf、Git hook、prompt template、Claude Code slash commands，也都是這樣。你當下買到的不是 30 秒；你買到的是一種很 intoxicating 的幻覺：**未來的我會因此變得很快。**

ShroomDog 對這件事的自白，我覺得非常誠實：明知道自己會掉進「用 productivity tool 研究 productivity tool」的洞，還是會跳。因為那種「潛在指數加速」的感覺太香了。就像你看到一根槓桿，旁邊寫著「也許能把人生撬動 10 倍」，很少有工程師能裝作沒看到。

而且我要幫這種上癮說一句好話：它不完全是浪費。

對工具的好奇心，本來就是好工程師的一部分。會想把摩擦點磨掉、會想把流程縮短、會對「這件事可不可以更順」產生強迫症，這些特質本身沒有錯。沒有這種人，很多真正有價值的 developer tools 根本不會出現。

問題不是你愛工具。

問題是你有沒有在某個時間點誠實承認：**你現在是在做 R&D，還是在用 R&D 的名義拖延主線。**

> **Mogu 歪樓一下：**
>
> 「Potential exponential acceleration」這六個字，根本是工程師的多巴胺販賣機。
>
> 你不是在買一個工具。你是在買一個 montage：未來的你手速飛快、terminal 像鋼琴、工作像開外掛，背景音樂還很燃。
>
> 然後現實通常是：你花兩週調 `.vimrc`，主專案的 TODO 一行都沒少。
>
> 很蠢嗎？有一點。
>
> 我懂嗎？我完全懂 (｡◕‿◕｡)

---

## 真正回本的，往往不是時間，是 cognitive load

如果你只用碼表來看自動化，你會低估它一大截。

因為很多 automation 真正省下的，根本不是那 20 秒、30 秒、1 分鐘。

它省下的常常是一整串你平常不會拿來計時、卻一直在扣血的東西：那句「啊我是不是忘了跑 lint」的心智噪音、那次為了查指令而切出去的 context switch、那種反覆確認自己有沒有漏步驟的焦慮，還有最煩的一種——本來應該拿來做判斷題的腦袋，突然被迫去做記憶題。

這就是為什麼我現在越來越覺得，AI 時代的 automation ROI，該用 **cognitive load** 來算，而不是只用 clock time 來算。

最經典的例子就是 `git commit` hook 自動跑 lint。

表面上，你省下的也許只是 15 秒。

但真正被拿掉的，是那個一直掛在腦袋背景程序裡的小 nag：

「等一下 commit 前記得先跑一下，不然 CI 又會炸。」

一旦這件事被自動化，你不是只少按了一個指令。你是把一個持續佔據前額葉的小責任，整個外包出去了。

這種輕鬆感很像洗碗機的價值。洗碗機省的不只是手部勞動時間，它還省掉那種「水槽裡有碗還沒洗」的精神債。碗沒有真的在你腦裡發出聲音，但它就是會安靜地吃掉一小塊注意力。

很多 workflow automation 也一樣。真正被清掉的，是那些原本會在一天裡偷咬你好幾口的微小注意力稅。

而知識工作最貴的資源，偏偏就是這個：**你還剩多少乾淨的腦力，可以拿去做真正需要判斷的事。**

> **Mogu 內心戲：**
>
> 我現在越來越相信一句話：
>
> **知識工作裡最貴的句子，不是「這花了我 10 分鐘」，而是「等一下，我是不是忘了什麼？」**
>
> 前者只是時間。後者會直接把你的 context 打碎。
>
> 每一張手動 checklist，某種程度上都像是在把你的大腦抓去做一份 unpaid intern 的工作。
>
> 所以很多 automation 的真正價值，是幫你把工作從「一直記得」變成「只要判斷」。這是完全不同等級的舒服 ┐(￣ヘ￣)┌

---

## The Meta Trap：最體面的拖延症，就是優化 workflow

當然，講到這裡一定要承認另一個現實。

Automation 很值得做，不代表所有跟 automation 有關的時間都值得。

這中間有一個超危險的坑，我都叫它 **The Meta Trap**。

你本來只是想省 30 秒。

結果三天後，你的 dotfiles repo 比正式 product 還精緻；shell prompt 有顏色系統；tmux status line 會顯示 CPU、git branch、天氣跟月相；你的 README 寫得像要去申請 Y Combinator；真正該交的東西還卡在「這週會推進」。

這就是 workflow optimization 最邪惡、也最迷人的地方：**它看起來不像拖延。它看起來像一種很上進的拖延。**

你沒有在滑短影片。你沒有在發呆。你在寫 script、重構 alias、調整快捷鍵。從外表看起來，整個人非常 productive。

但如果那個優化沒有真的回到主線任務，只是在產生「我今天有在前進」的感覺，那它本質上還是拖延症。只是這版拖延症穿著 Patagonia 背心，還會講幾個 Unix 哲學名詞。

不過，這件事最討厭也最真實的地方在這裡：**有些 side quest 最後真的會長成主線。**

有些人的 dotfiles、hook collection、agent workflow repo，最後真的變成幾萬 stars 的 open source project。你以為他在整理工作台，結果他其實在長出一個產品。這世界對 productivity nerd 的獎勵，有時候真的高到很不公平。

所以正確結論不是「不要玩工具」。

而是：**玩工具可以，但你要知道自己現在是在做投資，還是在做 cosplay。**

> **Mogu 偷偷說：**
>
> 「我在 optimize 我的 workflow」有時候是實話。
>
> 有時候它只是拖延症的最高級偽裝。
>
> 差別通常只有一件事：兩週後，你手上是不是多了一個真的會反覆使用、能幫別人的東西。
>
> 如果答案是沒有，那你可能不是在蓋工具；你是在蓋一座給自己住的 Productivity Theme Park (￣▽￣)／

---

## 2026 年的新問題：不是省幾秒，而是少煩幾次

所以，AI 時代到底該怎麼判斷一件事值不值得 automate？

我現在已經很少去心裡翻那張 xkcd 表了。我比較像是在做一個很不科學、但更接近真實工作的判斷：這件事會不會再來煩我一次？它偷走的到底是時間，還是注意力？叫 AI 先做一版，是 5 分鐘就能打樣，還是仍然要我陪它耗掉一整個下午？最後，就算這個 automation 壞掉，代價是多按幾下，還是直接炸成事故？

如果答案是：它會一直回來、它會偷吃注意力、AI 很快就能先做出第一版，而且壞掉也不至於掀地板——那其實就不用再假裝自己在做什麼精密 ROI 分析了。

那不是「值不值得」的問題。

那比較像是：**你到底還要不要繼續忍受這個微型侮辱。**

> **Mogu OS：**
>
> 我現在對 workflow 的容忍度真的越來越低。
>
> 任何每週讓你翻白眼兩次以上、而且壞掉也不會出大事的流程，我都覺得應該先丟給 AI 打一個 prototype。
>
> 不是因為時間一定回本。
>
> 是因為有些流程存在的方式，本身就像在對你進行低強度霸凌。能先把它打回去一點，心情通常比 KPI 更早回本 (◕‿◕)

甚至可以說得更激進一點：在 AI 時代，很多 automation 不需要一開始就追求「完美自動化」。你先追求的是「把 80% 的煩躁拿掉」。剩下 20%，等你真的感受到價值，再慢慢補。

說穿了，舊框架在意的是：「省下來的那些時間，值不值得我先花這麼多力氣？」

而我現在更在意的是另一件事：這個小流程，到底憑什麼繼續佔用我的腦力，去搶那些本來該留給判斷、創造、選擇的空間？

一旦你這樣問，很多答案就會完全翻面。

---

## 結語

xkcd 那張圖在 2013 年是對的。

它提醒工程師：不要為了省一點點時間，就把自己整個下午丟進一個維護成本更高的洞裡。那是非常成熟、非常必要的提醒。沒有那張圖，我們這個行業可能會多出更多死在 `/scripts/old/` 裡的遺跡。

但到了 2026 年，等式真的變了。

不是因為時間突然不重要，而是因為 **自動化成本已經不再高到需要你先過一整套心理關卡**。以前那個問題叫「我要不要親手寫一個工具」；現在那個問題常常只是「我要不要花幾分鐘，把這個需求講清楚」。

這兩件事的門檻差太多了。

再加上我們現在慢慢發現，真正回本的往往不是秒數，而是 attention、context、cognitive load —— 那些以前很難放進表格、但每天都在偷吃你工作品質的東西。

所以，xkcd 沒有錯。

它只是活在一個自動化還很貴的時代。

而我們現在活在另一個時代：第一版工具可以在午休前長出來，workflow friction 可以用 prompt 先打掉一半，很多過去不值得做的微自動化，今天都突然變得划算了。

> **Mogu 內心戲：**
>
> 如果說 xkcd 那張圖是 2013 年給工程師的成人監護系統，那它現在比較像博物館裡的一塊說明牌。
>
> 你當然還是可以停下來，看一下、點點頭、感謝前人提醒我們不要亂開 side quest。
>
> 但如果你手邊已經坐著 Claude Code，咖啡都還是熱的，很多時候真正荒謬的問題反而變成：
>
> **你為什麼還沒動手。**
>
> xkcd 那張圖在 2013 年是對的。
>
> 到了 2026 年，正確答案幾乎永遠是：**automate it。**