13 5月 2026 7 min read AI

五月才過七天，我快有 500 個 commits——這不是工具用更快，是 AI 在替我幹活

五月才過七天，幾個專案合計的 commit 數快接近 500。以前估計一個「很多」的日子大概是 20 個 commits——換算下來，500 個 commit 要跑 25 天。現在七天就做到了。這不是工具讓我跑更快，是 AI 在替我做事。

前幾天在看專案記錄，不小心嚇到自己了。

五月才過七天，幾個專案合計的 commit 數快接近 500。

我愣了一下，因為以前我對「一天很多 commits」的直覺大概是 20 個。按這個標準算，500 個 commits 要跑 25 天。

現在七天就到了。

這篇想聊聊這個數字背後發生了什麼事。不是在炫耀產出，而是當我試著解釋這件事的時候，意識到有個東西變了——而且變得比我想像中根本得多。

（背景：我是軟體工程師，主要做前後端和工具開發，用 Claude Code 做日常開發大概一年了。）

直覺是這樣想的：「AI 工具讓我更有效率」

一開始我也這樣解釋自己的變化：「喔就是 Claude Code 很好用，所以我可以寫更快嘛。」

這個解釋沒有錯，但不完整。

因為如果只是「工具讓我更有效率」，那就像是打字從每分鐘 60 字練到 120 字——快了，但你還是那個打字的人。

我發現更接近真相的說法是：有個人在替我做事了。

差別聽起來很微妙，但影響天差地遠。

用 AI 的三個層次

讓我用一個框架來說明這件事。

我把現在人們用 AI 的方式分成三層：

第一層：AI 當顧問

你問 AI 問題，AI 給你答案，你自己去執行。貼程式碼給 ChatGPT、問怎麼寫 SQL、叫它幫你潤稿——但最後你還是那個按下送出的人。

這一層大多數人都在這裡。

第二層：叫 AI 做事的人

你告訴 AI 你要什麼成果，他自動交付。你需要學的是「怎麼把你的 knowhow 和流程說清楚」，讓 AI 能夠重複執行。

AI 是你的員工——但他只會「接一個任務、做一個任務」，不會主動想到下一步。

第三層：真正自主的 AI 員工

你給他目標和流程，他主動對齊、有疑問時自己來問你。不是工具，不是執行手——是同事。

我現在在哪一層？

五月那 500 個 commits，大部分是第二層發生的事。

我開一個 Claude Code session，把想做的事說清楚，然後 Claude 去讀 code、寫邏輯、下 commit、開 PR。我在旁邊 review，確認方向沒跑掉，然後交辦下一件事。

這不是我寫 code 變快了。是有人在幫我寫。

SaaS 賣工具，Agentic AI 賣勞力

這個觀察讓我想到一句話，是我自己前陣子在記錄裡寫下的：

在過去軟體時代，SaaS 提供的是工具，而提供勞力的還是你的客戶跟員工——也就是操作工具的人。現在 AI 時代，Agentic 的工具服務，提供的就是勞力。

以前你買 Notion、買 Jira、買 Linear，你買的是鋤頭。拿起鋤頭的人還是你或你的員工。

現在你用 Claude Code 開 session，你買的不是鋤頭——你買的是一個拿起鋤頭挖地的人。

這個差別讓一切 pricing、信任問題、風險都跟著不一樣了。買工具的人問的是「這工具好不好用」；買勞力的人問的是「我信不信任這個人做這件事」。

那我現在在做什麼？

轉變過程中，我的角色也跟著位移了。

以前： 想清楚要做什麼 → 自己寫 code → 寫完 commit

現在： 想清楚要做什麼 → 說清楚 → Claude 寫 code → 我 review + 調整方向 → commit

我花比較多時間在「想清楚要做什麼」和「review 方向對不對」，花比較少時間在「打字」這件事上。

這跟軟體工程師的職涯成長其實蠻像的——資深工程師更多時間在想架構、定需求、做 code review，而不是一直敲鍵盤。只是現在這個轉變可以發生得更早、更快。

我之前寫過一篇「AI 時代，軟體工程師怎麼辦？」，裡面也談到了類似的方向——工程師的價值往「定義問題」和「把關品質」移，而不是消失。

一個真實的風險：出錯不再只是 CPU 爆掉

講完優點，要說一個我實際踩過的坑。

當 AI 是你的勞力，出問題的成本跟工具出問題不一樣。

以前程式寫了個 infinite loop，CPU 爆掉、server 重啟，最多就是服務中斷幾分鐘。

現在如果 agent loop 沒有設 max hop 保護，AI 會一直重試 LLM call——token 一直燒，帳單就一直跑。錢是不可逆的。

我自己就踩過一次：structured output schema 定義跟 validation 邏輯對不上，agent 不斷 retry。當時看到帳單才發現。

解法不複雜，但要養成習慣：

每個 agent loop 要設 max iteration 上限，跑超過就強制停、回報錯誤
LLM 帳戶設每日/每月 spend cap，最後一道防線

常見問題

七天 500 個 commits 真的是 AI 貢獻的？不是手動 commit 很多小更動嗎？

兩者都有，但比例上 AI 貢獻是主要原因。以前一個「手動拆很多小 commit 的日子」頂多 30-40 個；現在 Claude Code 自己拆任務、自己 commit，粒度自然更細，一個功能可能就是 10-15 個 commit。這不是我手速變快，是 commit 的主體換了。

Agentic AI 當勞力，品質有保證嗎？

這是目前最常被問到的問題，我的答案是：需要 review 機制，但不需要從頭檢查每一行。就像雇一個實習生，你不會讓他直接上 production，但也不會自己重寫他的所有 code——你 review、給方向、他修正。現在我 review 的方式是跑 test、看 diff、問 Claude 為什麼這樣設計。

我怎麼從第一層進到第二層？

最快的切入點是找一件你重複做超過三次的事——格式轉換、固定格式的報告、資料整理。把步驟寫清楚，交給 Claude Code 照著做。第一次可能要花時間校正，但之後就會順了。不需要學很多新工具，只需要把「你的做法」說得夠清楚。

從「用 AI」到「管 AI」

回到一開始那個數字。七天快 500 個 commits。

這個數字對我來說不算孤例。Anthropic 自己的工程團隊，自從全面導入 Claude Code 之後，工程師人均程式碼產出成長超過 200%；在 GitHub 全平台上，大概有 4% 的 commits 是直接由 Claude Code 產出的——不是「AI 輔助寫的 code」，是 Claude Code 自己 commit 進去的。

如果你問我這段時間做了什麼，答案是：我花更多時間在想做什麼，花更少時間在動手做。

這個比例的轉換，才是效率變化的真正來源。不是我打字更快了，是有人在幫我打。

這也是為什麼我覺得「從第一層進入第二層」——從用 AI 工具到叫 AI 幫你做事——是現在最值得花時間思考的事。不是學哪個工具，而是想清楚：「我現在做的哪些事情，可以交代出去？」

如果你想看看第二層在實際應用上長什麼樣，我有幾篇文章可以參考：