昨天把 Retry 和失敗通知加進流程之後，我原本以為自動化的穩定度已經好很多了，API 暫時連不上可以重試，真的失敗也會收到通知，至少不會再出現流程默默壞掉幾天，最後才發現資料根本沒有更新的情況。

但真的開始把流程拉長之後，我又碰到另一個問題，一條自動化可能有十幾個步驟，其中只有一個小功能失敗，結果後面全部跟著停掉，最後本來有八成可以完成的工作，因為其中一個 API 出問題，整條流程什麼都沒有留下來。

所以今天我開始處理的是「部分失敗」，讓系統知道哪些錯誤真的必須停止，哪些錯誤其實可以先跳過、記錄下來，再讓其他工作繼續跑。

先分清楚哪一步真的不能失敗

假設我有一條每天整理資訊的流程，先抓資料、去除重複內容、交給 AI 分類、產生摘要、寫進 Notion，最後再寄一封每日整理給我，以前只要中間任何一步出錯，最簡單的處理方式就是直接把整條 Workflow 標成 Failed。

但其實每個步驟的重要程度並不一樣，如果最前面的資料抓取完全失敗，那後面確實沒有東西可以處理，流程停下來很合理；可是如果只是其中一篇文章摘要失敗，剩下九十九篇其實還是可以正常整理，這時候直接把全部結果丟掉就有點浪費。

我開始替步驟分成幾種狀況，有些是 Critical，只要失敗就必須停止；有些可以 Skip，例如單筆資料處理失敗就先留下紀錄繼續下一筆；另外還有一些可以使用 Fallback，例如主要 AI 模型暫時不可用，就改用另一個比較簡單的方式先完成基本處理。

Error 不一定要往整條流程丟

以前寫 Workflow 時，我的思路比較接近「成功就往下一步，失敗就結束」，但這次開始把錯誤留在每個步驟自己處理。

例如一百筆資料要產生摘要，其中第三十七筆因為格式異常失敗，我現在會把這筆資料標記成 summary_failed，把錯誤原因和原始內容留下來，接著繼續處理第三十八筆，等整批流程跑完之後，再另外整理今天到底有幾筆失敗。

這樣最後收到的結果可能是「100 筆資料中 97 筆成功，3 筆待處理」，對我來說反而比整條流程顯示一個大大的 Failed 更有用，因為我至少知道今天大部分工作已經完成，只需要回頭看那三筆資料。

Fallback 可以讓流程先活下來

除了 Skip 之外，我也開始替一些步驟準備比較簡單的備用方法，例如原本流程會呼叫 AI 產生完整摘要，如果模型 API 暫時不能用，可以先把文章標題和前幾百字留下來；原本要自動分類成很細的類別，失敗時也可以先放進 Uncategorized，等之後再重新處理。

這些結果當然沒有原本理想，但至少資料不會整批消失，而且等服務恢復之後，我還可以只針對失敗的部分重新執行，不用從頭把所有東西再跑一次。

做到這裡之後，我也發現 Retry 跟 Fallback 的順序很重要，通常還是會先 Retry 幾次，確定真的沒辦法完成原本的方法之後才進 Fallback，不然一遇到短暫的網路抖動就立刻降級，最後反而會累積很多品質比較差的結果。

最後通知我「哪裡壞了」就好

昨天做失敗通知時，我還是以整條 Workflow 為單位，只要失敗就通知一次，但現在加入部分失敗之後，通知內容也可以變得更有用。

我不需要凌晨收到十幾封「第 37 筆失敗」「第 52 筆失敗」「第 81 筆失敗」的訊息，比較合理的方法是等流程跑完之後整理成一份結果，例如今天處理 100 筆資料、97 筆成功、3 筆失敗，其中兩筆是 API Timeout、一筆是資料格式異常，讓我隔天只處理真正需要看的部分。

這跟前幾天做資訊篩選時的感覺其實很像，自動化的目的如果是替我減少重複工作，那錯誤處理也應該替我整理好，我不想因為系統變自動化之後，反而每天花更多時間看 Error Log。

做到 Day 14，我開始覺得一條比較可靠的 Workflow 不應該只有「成功」和「失敗」兩種狀態，中間其實還有成功完成、部分完成、使用 Fallback、等待人工處理等不同情況，只要把這些狀態記錄清楚，就算某個服務突然出問題，整條流程也不需要跟著一起倒下。

下一步我想處理的是失敗之後留下來的那些工作，因為知道哪幾筆沒做完還不夠，如果每次都要我自己重新按一次執行，自動化還是少了一塊，接下來就可以開始想辦法讓系統只重新處理那些真正失敗的任務。