Back to Blog
automationdev-workflowclaude-codereliability
August 6, 2026·2 min read

我的自動化 pipeline 默默死了四個月, 我今天才發現

網站四個月沒更新, 我以為是缺一套自動化 workflow。排查之後發現 workflow 一直都在, 只是它死了, 而且死得毫無聲息。這篇講 automation rot: 為什麼會失敗的自動化不可怕, 失敗了沒人知道的自動化才可怕。

我的自動化 pipeline 默默死了四個月, 我今天才發現

我的自動化 pipeline 默默死了四個月, 我今天才發現

今天我看了一眼自己的網站, 最新一篇文章停在四個月前。我的第一反應是: 該來做一套自動化 workflow 了, 讓 blog 和 project 頁面可以自己更新。

排查完之後我發現一件更尷尬的事: 這套 workflow 我早就做過了。知識庫, 內容生成, 草稿產出, 一整條 pipeline 都在。它不是不存在, 它是死了。而且死了四個月, 我完全沒有發現。


排查: 我以為的問題 vs 真正的問題

我原本的內容系統長這樣: 一個 LLM 維護的 wiki 知識庫, 每次開發 session 結束後把踩坑和決策 ingest 進去, 累積到一定程度就從 wiki 生成 blog 草稿。drafts/ 資料夾裡躺著 10 篇草稿, 最後一篇的日期是 4 月 10 號。

所以問題不是「沒有內容可發」, 是這條線某個環節斷了。我開始往回找, 找到的斷點比預期的蠢:

WIKI="/mnt/c/Users/Joey Chen/Desktop/.../wiki"

這是寫死在工具設定裡的絕對路徑。四個月前我把整個工作目錄從 Windows 桌面遷移到 WSL 底下, 遷移本身很順利, 檔案都在。但這行路徑沒有跟著改, 於是每一個 wiki 指令從那天起都會失敗在同一個地方: 找不到檔案

真正值得記下來的不是這個 bug 本身, 是它的失敗方式: 沒有告警, 沒有錯誤通知, 什麼都沒有。工具只有在被呼叫的時候才會失敗, 而我因為忙別的專案, 根本沒有呼叫它。一個只在被使用時才會暴露故障的系統, 配上一個不再使用它的人, 結果就是四個月的靜默。


為什麼四個月都沒發現

事後看, 這條 pipeline 有兩個結構性的洞, 路徑失效只是把它們引爆而已。

第一, 尾端靠人。生成是自動的, 發布是手動的。草稿寫進 drafts/ 之後, 要靠我自己想起來, 打開後台, 貼上去, 按發布。這種「半自動化」的斷裂點就是人: 人一忙, 整條線就停, 而且停下來的樣子跟正常待機一模一樣。

第二, 沒有排程。整條 pipeline 只在我主動呼叫時運轉。沒有任何東西定期跑它, 也就沒有任何東西會在它壞掉時撞上錯誤。錯誤監控有一個盲區: alert 只會在錯誤發生時響, 但一個從來不被執行的系統, 連錯誤都不會產生

會失敗的自動化不可怕, 失敗了沒人知道的自動化才可怕。因為你以為它在跑, 所以你連手動做都省了。

這比完全沒有自動化更糟。如果我從頭到尾都是手動發文, 四個月沒發文我心裡是有數的。正因為「我有一套系統」這個認知還在, 我才安心地什麼都沒做。


修復: 止血之外, 把洞補上

修路徑只是止血, 五分鐘的事。真正的修復是把那兩個結構性的洞補掉。

補尾端: 寫了一個 90 行的 publish-draft.mjs, 讀草稿的 frontmatter, 打到網站的 API。有一個細節值得一提: script 會先用 slug 查文章存不存在, 存在就走更新, 不存在才新增。這樣排程重複跑同一篇草稿時不會撞資料庫的 unique constraint, 對真實環境測第一次就抓到這個 edge case。

補排程: 每天掃一次各專案的 git 活動, 有實質 commit 才 ingest 進 wiki; 每週從累積的素材產一篇文。日抓知識, 週產文, 因為個人站要的是品質不是產量。

風險上限: 自動產出的文章一律以草稿身分進後台, published: false, 我在管理介面審過才上線。自動化可以壞, 但它能造成的最大傷害被鎖在後台, 公開站永遠不會出現一篇沒人看過的 AI 文。


這件事的通用版本

把場景抽掉, 這其實是一個很普遍的模式, 我叫它 automation rot: 自動化系統的靜默腐化。它的成因幾乎都是同一組:

  • 寫死的環境假設。絕對路徑, 機器名稱, 憑證位置。換一台機器或搬一次目錄, 所有 hardcode 的工具同時失效, 而且是靜默失效。
  • 鏈條裡藏著人。號稱自動化的流程裡只要有一步靠人記得, 那一步就是整條鏈的可用性上限。
  • 只監控錯誤, 不監控沉默。「跑了但失敗」會產生訊號,「根本沒跑」不會。

對應的解法也不複雜: 路徑假設集中到一行設定, 讓遷移只需要改一個地方; pipeline 尾端接上排程, 讓「沒跑」變成看得見的異常; 最後, 監控產出的新鮮度而不是只監控錯誤。「超過兩週沒有新文章就告警」這種土方法, 恰好能接住前面所有機制都接不住的失敗。

我認為最後這點是關鍵。這次讓我發現系統死掉的訊號, 不是任何監控, 而是我自己看到「網站好久沒更新」。產出的新鮮度本身就是最誠實的 heartbeat, 只是這次負責讀取它的感測器是我的眼睛, 遲到了四個月。把這個感測器換成程式, 才算是把洞真正補上。


這篇文章本身就是修好的 pipeline 產出的第一篇: 今天的修復過程被 ingest 進 wiki, 再從 wiki 生成這篇草稿, 自動上傳到後台等審。至於它能活多久, 至少這次, 它死掉的時候我會知道。

Joey Chen

Joey Chen

Build things that are interesting. All made by AI.

AIWeb3