iT邦幫忙

2026 iThome 鐵人賽

DAY 1
0

Day 1|我讓 Claude Code 自己跑了五個月

封面

我改了一份共用的環境變數白名單,漏掉一個變數。

下游有個 agent 因此拿不到真實憑證。它沒有報錯,也沒有停下來,而是自動退回去用測試用的假後端,繼續把整輪工作跑完,最後回報一切正常。整條鏈上沒有任何一個地方亮紅燈。

它那段時間做的事,全部沒有落到真的地方。而我是後來為了另一件不相干的事去翻紀錄,才看見這件事。

這就是無人監督的自動化跟你平常用 Claude Code 最大的差別。你在旁邊的時候,它出錯你看得見。你不在的時候,它出錯的樣子是「一切正常」。


五個月的帳

先把數字攤開,這樣後面講的每件事都有個尺度。

我從 2026 年 3 月 15 日開始寫一個平台,把 Claude Code 當成底層 runtime,往上加排程、記憶、驗收、權限。到今天為止:

項目 數字
開發天數 155 天
commit 905
發過的版本 257
Rust 程式碼 531,025 行
crate 數 23

平均一天 5.8 個 commit,一天 1.6 個版本。這個節奏之所以撐得住,是因為寫程式的大部分工作已經交給 Claude Code 了。

我要講的重點跟這些數字關係不大。真正值得寫成 30 天的,是另一組數字:這五個月裡,我修過五類「它自己跑的時候才會出現」的問題,每一類都不會在你盯著螢幕的時候發生。

你盯著看的 Claude Code,和沒人看的 Claude Code

你平常這樣用它:

$ claude
> 幫我修這個 bug

它讀檔、搜尋、改 code、跑測試,你在旁邊看。錯了你按 Esc,它停下來。這個模式非常好用,我一天用幾十次。

現在把「你在旁邊」這個條件拿掉。

$ claude -p "檢查昨天的錯誤日誌,有異常就通知我"

丟進 cron,每天早上八點跑。表面上只差一個 -p 和一行排程設定。實際上你剛剛跨過一條線,線的另一邊有五件事在等你。

一、它不記得昨天

claude -p 每次都是全新的一次對話。今天早上它看過的錯誤日誌,明天早上就不存在了。你以為它在「持續監控」,它其實每天都在第一次認識這個系統。

你可能會想:那我把歷史塞進 prompt 不就好了。可以,然後你會遇到第二件事。

二、它每次醒來都要先付一筆過路費

我實際量過,在一個空資料夾裡叫它回一句「OK」,還沒開始做任何事之前,固定要吃掉 51,673 個 token,帳單 0.335 美元。這裡面有系統提示、工具 schema、專案設定、目錄結構。如果你一天叫醒它 100 次,光是「開機」就燒掉 517 萬 token。

這筆錢我後來砍掉了 88%,砍法在 Day 6,只需要兩個參數。

三、它說做完了,就真的做完了嗎

開頭那個事故就是這個問題的實例:它全程回報正常,而正常的定義是它自己下的。這類失敗還有一種更常見的長相:工具回傳空結果,模型把「沒有內容」讀成「沒有異常」。

沒有人在旁邊看的時候,唯一會說話的就是它自己。你拿它的自我回報當驗收標準,等於讓考生自己改考卷。

四、它的權限比你以為的大

互動模式下,每個危險操作都會問你。切到 -p 之後,很多人會加 --dangerously-skip-permissions,因為不加就會卡住。加了之後,那個在你面前會停下來問「要刪除這個檔案嗎」的東西,變成不會問了。

我在 Day 12 會講怎麼用能力宣告取代這個開關,讓它照樣自動跑,但踩不到不該踩的地方。

五、它會靜默失敗

這是五個裡面最難處理的,也就是開頭那個白名單事故的本質。

程式壞掉會噴 stack trace,agent 壞掉常常什麼都不噴。它只是換一條路走完,然後回報成功。而它換的那條路,往往是你自己在別的地方為了方便留下的備援。

這件事的完整拆解在 Day 28,我會把它寫成一個通用的模式:改共用機制時,你必須主動掃過所有消費端,因為壞掉的那一端不會告訴你


這 30 天要造什麼

我把上面五件事對應成五層工程,一層一幕,每幕六天。

天數 解決什麼
為什麼停在工具 Day 1–6 常駐化的最小骨架、spawn 成本
手與腳 Day 7–12 MCP、工具設計、沙箱與能力
記憶 Day 13–18 跨次醒來還記得、事實會被改寫
驗收 Day 19–24 自我回報不算數、判官怎麼寫
它會咬你 Day 25–30 注入、憑證、靜默失敗、成本

https://ithelp.ithome.com.tw/upload/images/20260817/20183634u63PJQOjEr.png

這不是 Claude Code 教學。第 7 天以後的東西,你換成 Codex、Gemini CLI 或任何一個會呼叫工具的模型都成立,我在 Day 11 會示範怎麼把它們掛在同一個介面下。

我會用自己那個平台當案例來源,因為那是我手上唯一有五個月連續 log 的東西。程式碼我會抽成 20 到 60 行的最小版本,用什麼語言寫都能照做。

每篇你能拿走什麼

每天四段,固定不變:

  1. 問題現場:一個具體的失敗,附 log 或數字
  2. 為什麼:機制層面的解釋
  3. 最小實作:可以複製貼上的程式碼
  4. 代價:這個做法犧牲了什麼,什麼情況下不該用

第四段我特別在意。網路上關於 AI agent 的文章,十篇有九篇只寫到第三段就收尾,讀起來每個方案都完美。實際做過就知道,每一層都在跟別的層搶資源:記憶塞越多,context 越貴;驗收越嚴,速度越慢;權限收越緊,能做的事越少。

我會把這些取捨寫出來。


明天講第一個具體的差距:「幫我修這個 bug」和「幫我看著這件事」,中間到底缺了什麼。

我會把那五個能力缺口畫成一張圖,那張圖是接下來 29 天的地圖。


系列文
Claude Code 下班之後:30 天把 CLI 工具養成會自己交差的 AI 員工1
圖片
  熱門推薦
圖片
{{ item.channelVendor }} | {{ item.webinarstarted }} |
{{ formatDate(item.duration) }}
直播中

1 則留言

0
Wolke
iT邦研究生 4 級 ‧ 2026-08-17 19:58:39

把那個漏掉白名單變數的事故寫得超有畫面,agent 默默退回假後端還一路回報正常,真的比直接報錯更讓人背脊發涼;前面 51,673 個 token、0.335 美元的開機成本也很扎實,瞬間懂為什麼要把常駐化、驗收、權限一層層補起來,這也很像在做 AI 開發時先把門檻拆小,才有辦法真的跑久。手邊有多的 Lovable 額度想送給有緣人,有興趣可從連結看看我的系列。 https://ithelp.ithome.com.tw/articles/10401174

我要留言

立即登入留言