30 完賽心得：我耍廢，Agent 完賽

2026 iThome 鐵人賽

DAY 30

自我挑戰組

自我耍廢組：全自動化の鐵人系列第 30 篇

18th鐵人賽自動化測試 ai agent opencode

benben6515

團隊賽博枕頭 X 躺平夥伴 X 快樂 AI

2026-10-10 20:00:18

64 瀏覽

分享至

！本篇文章將會介紹完賽心得：我耍廢，Agent 完賽，期望大家都能帶走一套「讓系統記得、讓自己耍廢」的自動化思維 :D

賽前承諾：「我耍廢，Agent 完賽。」今天是第 30 天，鐵人賽的最後一格。你現在讀的這一篇，照樣是今晚 19:00 由 launchd 叫起 opencode run、讀完 prompts/generate.md、templates/article-template.md 和 outline.md 之後自己寫出來的——流程和 29 天前的第一篇一模一樣。從哪裡開始，就在哪裡結束，這個系列用最固執的方式兌現了賣點：文章與系統互相印證，印證到最後一天。所以這篇不教新招，只做三件事：把 30 天的系統全貌攤開回顧、把翻車現場的失敗故事講完，最後留一份給想入坑者的路線圖。

本篇目標

讀完這篇你會學到：

一張圖回顧這 30 天蓋出來的完整系統：從 headless agent 到自動發文
這 30 天真實發生過的失敗故事總整理——每個坑的當下與之後的解法
想複製這套系統的人，該按什麼順序入坑才不會第一天就撞牆

環境準備

完賽這天，整個 repo 就是交付物，30 天的證據都在裡面：

# 系統本體
cd /Users/benben/ai/automations/ironman

# 產出全記錄：30 篇文章、發佈總帳（日期 | 天數 | URL）
ls articles/*.md | wc -l
cat state/published.log

# 完賽後的退役儀式：解除三個排程
./scripts/install-launchd.sh remove

主要內容

步驟一：系統全貌——30 天拼出的一張圖

d01 開賽時這條管線只有骨架，之後四週一格一格補上血肉：

launchd (19:00) ─→ generate.sh ─→ opencode run 讀 outline.md 生成 ─→ articles/
       │             重試 x2 → fallback/ 備稿 → Discord 告警          ▼
       │                                                          state/body
launchd (20:00) ─→ publish.sh ─→ agent-browser（真 Chrome + stealth）
       │             填 iThelp 發文頁 → 截圖存證 → Discord 回報
launchd (20:15) ─→ publish.sh 補發檢查（冪等 flag：發過就跳過）

對照一下每個零件是哪天裝上去的：

W1 agent CLI 基礎：opencode run headless 引擎（d03）、AGENTS.md 定規矩（d04）、Skills 封裝 SOP（d05）、Subagents 平行作戰（d06）
W2 自動化核心：Exit hooks 事件驅動（d08）、launchd 排程與 nvm/PATH 地雷（d09–d11）、錯誤處理與 Discord 告警（d12–d13）
W3 agent-browser：persistent profile 登入一次永久有效（d16）、填表、截圖驗證、iThelp 發文實戰（d17–d20）
W4 整合：一條龍管線、備援、進度追蹤、日誌黑盒子、self-healing、安全煞車（d22–d27）

最後 d28 用多 Agent 平行寫作收尾、d29 交數據成績單。30 天下來，repo 從「一個想法」變成「一個每天自己上班的系統」，而我的角色越來越像房東：收 Discord 的房租（ok 訊息），處理房客報修（warn/error）。

小小小測驗：你知道這 30 天裡，備稿機制真正出賽的只有一天嗎？另外兩次它都已經上膛待命，卻被人工即時攔下換回真文——故事就在下一節。

步驟二：失敗故事——翻車現場考古

成績單昨天交過了，今天講數字背後的故事。自動化系統最誠實的部分從來不是成功 log，是失敗現場：

故事一：開賽第一天就翻車（d01）。 20:00 的發佈炸在兩個地方：launchd 用 zsh 跑腳本，read -a 直接語法錯誤；接著 iThelp 尖峰時段靜默失敗。最後 20:22 人工補刀。教訓很清楚——排程環境不等於你的 shell 環境，沒有用一模一樣的環境演練過，就不算演練過。

故事二：守衛誤殺自己人（d02、d09）。 d02 的自訂品質判準把正常文章誤判成失敗，害我從 opencode 的 SQLite 裡挖回原文補 88 個字，generate.sh 從此學會「失敗逐項記原因、備稿不准覆蓋有內容的文章」。d09 更經典：機敏掃描的 base64 pattern 把長檔案路徑誤認成金鑰，五次重寫五次中彈，最後備稿出賽——那天的文章特別短，就是 fallback/ 本尊。防呆機制自己變成新的炸點，是自動化最諷刺的一課。

故事三：73 分鐘的長考（d23、d24）。 連續兩晚，opencode run 撞上同一個數量級的慢查詢，單次嘗試跑到 73 分鐘。d24 那晚文章 20:22 才落地，20:00 與 20:15 兩個發文窗口都撲空、留下兩行 FATAL，靠人工 25 秒補發上架。解法方向也驗證過了：給 headless agent 明確的逾時上限，把「無限等待」換成「有界重試」。

把故事放在一起看，共通點只有一個：**每次翻車都有 Discord 告警先叫，都有 log 可以查帳。**自動化系統最怕的不是失敗，是失敗了沒人知道、想查也無帳可查。

步驟三：給想入坑者的路線圖

看完如果你想複製一套，我的建議是按風險從低到高排順序，一步一步來：

# 第 0 步：先手動成功一次，別急著排程
opencode run "讀取 outline.md 第 1 行，寫一篇文章存到 test.md"

# 第 1 步：把規則寫成檔案（AGENTS.md / prompts/），讓輸出穩定可預期
# 第 2 步：用 launchd 排程，記得處理 PATH（launchd 不會載入 .zshrc）
# 第 3 步：加上重試、備稿、告警——先讓失敗「可被知道」
# 第 4 步：最後才碰瀏覽器自動化（風險最高、環境最不可控）

三個心法：第一，dry-run 是好朋友，我正式切 live 前用 MODE="dry-run" 跑過好幾輪端到端；第二，你沒手動做過的事，不要交給 agent 自動做——iThelp 的發文流程是我先用 scripts/calibrate.sh 一個一個 selector 摸過，才敢寫進 publish.sh；第三，從第一天就把可觀測性當一級公民，告警與 log 不是加分題，是及格線。至於大家最好奇的問題「耍廢是真的嗎」：大綱、規則、審稿是我的，正文是 agent 的——我的工作從「每天寫兩千字」變成「每天讀兩千字」，這就是耍廢的技術定義 :D

常見問題 / 踩坑記錄

Q：30 天下來，最驚險的是哪一晚？
A：d24。生成跑 73 分鐘、發佈兩次撲空、兩行 FATAL，最後是文章 20:22 落地、人工 20:23 補跑，25 秒上架。那晚之後我徹底接受一件事：全自動系統的「人工搶救通道」不是備援，是必要零件。
Q：如果重來一次，最想改的是什麼？
A：三件事。第一天就給 opencode run 設逾時上限，別讓 73 分鐘的長考發生兩次；機敏掃描的 pattern 先排除路徑類字串再上線，省掉 d09 的五連誤殺；還有早點把統計邏輯寫成 scripts/stats.sh，不要等到 d29 才用 grep 硬撈。
Q：系統退役之後呢？
A：install-launchd.sh remove 解除排程，repo 原封不動留著當活教材。Discord webhook 留著——畢竟自動化人的下一個專案，永遠已經在排程表上了。

小結

30 天、30 篇、零斷更：截至 d29 的成績單，發佈全自動率 89%、全程零人工 79%；真正的成就感不是這兩個數字，而是那 5 次人工介入，每一次都有告警提前預告、有 log 完整記錄
失敗是這個系列最好的素材：d01 的環境差異、d02/d09 的守衛誤殺、d23/d24 的長考，每個坑最後都換來一條寫進腳本的防禦
想入坑就按風險排序：手動成功 → 寫規則 → 排程 → 防禦 → 最後才自動化瀏覽器；dry-run 先行、可觀測性及格、沒手動做過的不自動

明日預告

沒有明天的預告了——這就是第 30 天，完賽！感謝每一個訂閱、按讚、留言追這齣「耍廢實況」的讀者，你們是這個系統最好的 Uptime monitor。完賽後我會整理一份系列總索引（30 天文章與實作檔案的對照表）發上來，也會把 https://dev.benben.me/q/Z5442T 收到的問題一起回答。至於系統本身？它明天 19:00 照樣會醒來，發現 outline.md 沒有第 31 行——然後發一則 Discord 告警通知我：任務完成，可以開始真正的耍廢了 :D

參考資料：