！ 本篇文章將會介紹 量化回顧：30 天自動化的數據成績單，期望大家都能 學會用 log 幫自己的自動化系統打分數 :D

「我耍廢、Agent 完賽」喊了 29 天，耍廢是真的，完賽也是真的——但口號誰都會喊，數字不會說謊。今天是這個系列的自動化系統交成績單的日子：生成成功率、耗時分佈、token 成本、人工介入次數，全部攤開。所有數據都出自 logs/ 和 state/ 裡的真實紀錄，沒有一個是編的——畢竟這個系列最核心的賣點，就是「文章與系統互相印證」，成績單當然也要經得起查帳。

本篇目標

讀完這篇你會學到：

• 怎麼從 log 目錄算出自動化系統的核心指標：成功率、耗時、重試次數
• 這套 19:00 生成 → 20:00 發文管線 29 天來的真實表現，包含所有翻車現場
• 自動化系統的「人工介入成本」怎麼量化，以及為什麼這個數字比成功率更重要

環境準備

成績單的原料就是系統自己留下的紀錄，打開 repo 就有：

# 進到系列 repo，所有證據都在這
cd /Users/benben/ai/automations/ironman

# 每天一份生成 log（含開賽前的測試）
ls logs/generate-*.log | wc -l

# 發佈總帳：日期 | 天數 | 文章網址，一行一筆
cat state/published.log

主要內容

步驟一：數據從哪來——log 就是資料庫

先說一個誠實的笑點：講了 29 天自動化，這份成績單是拿 grep 對著 30 多份 log 硬撈出來的。generate.sh 每個關鍵動作都會蓋時間戳——開始生成、第 N 次嘗試、機敏掃描命中、成功——所以統計其實就是配對「開始」與「成功」兩行：

# 撈出每天的開始與成功時間戳，兩兩相減就是生成耗時
grep -h "開始生成\|成功：" logs/generate-2026*.log | grep "^\["
# 輸出範例（簡化）：
# [2026-10-08 19:00:05] 開始生成 d28
# [2026-10-08 19:03:17] 成功：articles/2026-10-08-d28.md（1646 個中文字）

明天完賽之後，第一件要做的事就是把這篇的統計邏輯寫成 scripts/stats.sh——自動化人的待辦清單永遠比產出長 :D

步驟二：生成側成績——82% 一次過，11% 靠備稿

d01 到 d28 共 28 個正式比賽日，生成側的戰績如下：

28 天，28 篇文章，零斷更。但「備稿介入」三天的內幕很不一樣：d02 和 d06 的備稿都被人工即時攔下換回真文，真正讓備稿出賽的只有 d09 一天——它發佈的就是 fallback/ff2-cli-coworker.md，所以如果你那天覺得 d09 特別短（2.5 KB，不到平常的三分之一），你不是錯覺，那就是保命機制本尊。

生成耗時的部份，23 個一次過的日子裡：最快 3 分 12 秒（d01 與 d28 並列，頭尾呼應頗有儀式感）、最常態的區間是 3–7 分鐘、中位數約 5 分半。離群值有兩個：d07 跑了 27 分 21 秒，d24 更誇張，單次嘗試跑 73 分鐘才寫出檔案。有趣的是 d23 那晚第一次嘗試也是 73 分鐘級別——連續兩晚撞上同一個數量級的慢查詢，像是服務端塞車的指紋。

品質方面，有留下字數紀錄的 25 篇平均約 1,700 個中文字（最低 d17 的 1,505、最高 d27 的 2,171），全部落在規範的 1500–2500 區間。28 篇累積約 328 KB 的 markdown——這個系列本身的體積，就是產能最好的證據。

小小小測驗：你知道這 28 天機敏掃描總共隔離了 6 篇文章，但真正抓到漏網之魚的只有 1 次嗎？剩下 5 次全是誤殺，兇手我們踩坑記錄見。

步驟三：發佈側成績——89% 全自動，人工出手 5 次

發佈側 state/published.log 28 行，一行都不少，28/28 全數上架。其中 25 天是 20:00 整點全自動一次到位（89%），正常的發佈流程快得驚人——從 d25 的 log 來看，20:00:05 開始、20:00:26 發佈成功，21 秒完成填表、截圖、發佈、驗證，比人類打開編輯器還快。

剩下 3 天是人工補刀：

• d01：launchd 用 zsh 跑腳本炸掉 read -a，加上 iThelp 尖峰時段靜默失敗，20:22 人工點擊成功
• d23：文章 21:40 才生成完，錯過 20:00 與 20:15 兩個窗口，21:42 人工補跑
• d24：生成跑 73 分鐘，發佈側撲空兩次留下兩行 FATAL，20:22 文章落地、20:23 人工補跑，25 秒上架

把兩側合計，28 天裡人工真正出手的紀錄是 5 次（d01 補發、d02 搶救、d06 補跑、d23 補發、d24 補發），平均每 5.6 天一次；反過來說，79% 的日子（22/28）從 19:00 生成到上架成功，全程沒有人碰過電腦。這就是「耍廢」的量化定義。

步驟四：token 成本——月費固定的快樂與盲點

成本這題，先看事實再看估算。事實：log 裡每晚的模型都清清楚楚是 glm-5.3-flash，走訂閱制方案，所以 30 天的現金成本就等於一個月月費，邊際成本趨近於零。

# 每晚用的 model，log 第一手紀錄
grep -m1 "build ·" logs/generate-20261008.log
# > build · glm-5.3-flash

# 輸出體積：28 篇文章的總 bytes，輸出 token 的下界證據
du -ck articles/*.md | tail -1
# 328	total

估算的部份要老實標注「量級粗估，不是帳單」：輸出側可從 328 KB 的正文反推，每篇約 1,700 字加上 code block，粗估 3–5K token；輸入側每天要讀規則、模板、大綱，再加 repo 探索和自我檢查的來回，量級比輸出大得多。全部加總，30 天整個管線的 token 用量是「數百萬」這個量級——如果換成按量計費的 API，這大概是一頓簡餐的錢；用訂閱制，就是月費裡的一個零頭。真正貴的從來不是 token，是那 5 次人工介入的夜晚——還好那些夜晚都有 Discord 告警先吵過一輪，隔天才有帳可查。

常見問題 / 踩坑記錄

• Q：機敏掃描連續誤殺 5 次（d09）是怎麼發生的？
  A：兇手是 SECRET_PAT 裡的 base64 通用 pattern [A-Za-z0-9+/]{40,}——它本意是抓長隨機字串，但這個字元類包含 /，結果任何超過 40 字的檔案路徑（例如 logs/launchd-generate 開頭的一長串、developer.apple.com 的深層文件 URL）都會命中。d09 那天 agent 在文章裡引用了長路徑，五次重寫五次中彈，最後備稿出賽。教訓：寬鬆的防呆 pattern 本身就是新的炸點，修正方向是把路徑類字串先排除再掃。
• Q：d04 被隔離那次是真的抓到東西嗎？
  A：是，貨真價實的一次攔截——那天的初稿真的把 Discord webhook URL 的開頭路徑片段原封不動寫進了文章。掃描命中後隔離到 state/quarantine-d04-190404.md、自動重寫，第二次就乾淨了。程式守衛加 LLM 去識別化規則的雙保險，這次是守衛單獨立功。
• Q：生成跑到 73 分鐘，當下該等還是該砍？
  A：d24 證明「等」是有價值的——73 分鐘後它真的把文章寫出來了；但代價是錯過兩個發文窗口，得靠人工補跑。比較健康的解法是給 opencode run 一個明確的逾時上限，逾時就重試，把「無限等待」換成「有界重試」，這樣補發保險才接得住。

小結

• 28 天零斷更：生成一次過 82%、發佈全自動 89%、全程零人工 79%——三個數字都比直覺想像的高，也都有 log 背書
• 備稿機制 28 天只真的出賽 1 天（d09），但它的存在讓另外兩次翻車有台階可下；機敏掃描抓到 1 次真洩漏、誤殺 5 次，防呆的價值與代價同框
• token 是訂閱制月費、量級數百萬，真正稀缺的資源是人工介入的注意力——自動化系統的 KPI 不該只看成功率，要看「每週需要人類出手幾次」

明日預告

下一篇我們要介紹 30 完賽心得：我耍廢，Agent 完賽，敬請期待！

參考資料：

• opencode 官方文件
• Apple 官方：Scheduled Jobs and Scheduled Scripts（launchd）

有任何疑問但沒有 iT 邦幫忙帳號，或是想匿名提問？
歡迎到 https://dev.benben.me/q/Z5442T 提問或加油打氣，沒意外的話會在完賽之後一起回答 :D