昨天替 Workflow 加上狀態紀錄、Retry、錯誤分類和 Resume 之後，流程遇到暫時性的失敗已經不會直接整條重跑，例如 API Timeout 可以重試，某一步真的失敗也能從原本的位置繼續，至少比前幾天一出錯就得自己重新按一次穩定不少。

不過今天早上我想到另一個問題，如果這條流程以後真的每天自己執行，而我也慢慢習慣不去看它，那我要怎麼知道它其實已經壞了？

這種問題跟手動執行很不一樣，自己按按鈕的時候，錯誤跳在畫面上一定看得到，但自動化流程可能凌晨三點跑、可能一次處理幾十筆資料，就算其中五筆失敗，只要整個 Workflow 最後沒有直接 Crash，我甚至可能幾天之後才發現某些資料根本沒進來。

所以 Day 12 我開始替這條自動化補 Monitoring。

先記錄流程到底有沒有正常跑完

我一開始沒有做很複雜的 Dashboard，先從最基本的執行紀錄開始，每一次 Workflow 啟動時產生一個 Run ID，接著記開始時間、結束時間、總共處理幾筆資料、成功幾筆、失敗幾筆，以及最後的 Workflow Status。

這樣做之後，原本只存在 Log 裡的一堆訊息開始比較像真的可以追蹤。

例如今天預期每天應該整理一百則資訊，結果某一次 Run 顯示 Success，但 processed_count 只有 12，從程式角度看它沒有 Error，從使用結果來看其實已經很不正常，如果我只監控「流程有沒有成功結束」，這種問題就完全抓不到。

所以我後來沒有只留下 Success 和 Failed，而是也開始記數量。

對目前這條流程來說，我比較在意的幾個數字是 Input Count、Processed Count、Success Count、Failed Count，以及最後真正被送進 Digest 的 Item Count，如果其中某個數字跟平常差太多，就算程式沒有丟 Exception，我也會把它當成值得看的異常。

AI 那一段也要單獨看

前面做到文章摘要、分類、GitHub Issue 分流之後，流程裡已經有幾個地方會呼叫 LLM，這時候又多出另一種很麻煩的情況：API 沒壞、Workflow 也完成了，但 AI 的輸出品質慢慢跑掉。

像是分類原本大部分都能正常放進 Bug、Feature、Question，某天開始大量落到 Other；或者摘要原本控制在固定長度，換了一個 Prompt 之後輸出突然變得很長，這些東西不一定會讓流程報錯，可是最後產生的結果已經跟原本期待的不一樣。

所以除了技術上的 Success Rate，我也替 AI 步驟留下幾個很簡單的紀錄，例如每次呼叫使用哪個 Model、Prompt Version、Token 數量、執行時間，以及分類結果分布。

我現在還沒有打算做很複雜的 AI 品質監控，只是先讓這些資料存在，至少之後真的發現結果怪怪的時候，不需要靠記憶去猜「是不是前幾天剛好改過 Prompt」。

通知也不能什麼都丟給我

做到 Monitoring 很容易出現另一個極端，就是什麼事情都通知。

一筆資料失敗寄一封信、API Retry 一次再寄一封、分類結果不確定又通知一次，最後手機整天響，過幾天最有可能發生的事情就是我開始完全不看這些提醒。

所以今天我也順便替通知分層。

像是單筆資料第一次失敗，只要 Retry 之後成功，我會留在 Log 裡就好；連續失敗或超過一定比例才需要通知；整條 Workflow 沒有執行、資料量突然掉到很低，或需要人工確認的項目累積太多，才比較值得真的把訊息送到我面前。

這跟前幾天做大量資訊篩選時的想法其實有點像，自動化的目的本來就是減少我需要處理的東西，如果 Monitoring 做完反而每天製造更多通知，整套系統只是把原本的工作換了一種形式丟回來。

我開始能回答「昨天到底發生什麼」

今天做到最後，我最有感的反而不是某個新的 AI 功能，而是我終於可以很快知道一條 Workflow 昨天到底跑了幾次、處理多少東西、哪一步最常失敗，以及有沒有重試後仍然救不回來的資料。

前幾天我一直在想怎麼讓 AI 多做一點工作，到了 Day 12 之後，注意力慢慢轉到另一邊，當我真的把事情交出去之後，我還需要知道它現在是不是健康的。

因為真正會長期運作的自動化，大部分時間其實不需要我碰它，但這不代表可以完全看不到它在做什麼，理想的狀態應該是平常安靜執行，有異常時留下足夠的資訊，而且只在真的需要人工介入時再把我叫回來。

明天我想再往這一步走，開始記每一條 Workflow 到底花了多少 Token 和 API 成本，看看當自動化從每天幾十筆慢慢放大到幾百、幾千筆之後，有沒有哪一些原本看起來很方便的 AI 步驟，其實根本不需要每次都呼叫模型。