你不是反對自動化，你反對「不可信任的自動化」
很多人被早期工具傷害過：表面連上了，實際上半年沒真正成功。對企業與接案者來說，這類傷害的代價不是技術，是信任：客戶以為你收到了、你以為系統處理了。要做專業級自動化，第一件事不是炫耀模組數量，而是建立可觀測性：看得到跑過、看得到失敗、失敗會吵到對的人。
常見失敗不是因為「你不會」，而是因為世界本來就會壞
上游 API 逾時、欄位突然變空、OAuth 被回收、第三方改版、資料量暴增導致分頁沒跑完——這些在正常世界都會發生。你的流程設計如果假設「外部永遠成功」，那就不是業務流程，而是童話。要學會在圖上留一條「失敗的路」，而且那條路要能留下紀錄。
Router 是什麼：路口，用來把不同命運分開
Router 幫助你把流程從一條線長成一棵樹：成功怎麼走、缺資料怎麼走、上游錯誤怎麼走。你不需要一開始就複雜，但你至少要有一句原則：失敗不能無聲消失。對 Make 新手來說，最常值回票價的分流不是「很聰明」，而是「失敗就送通知給我」，並附上可定位的資訊（時間、哪一個模組、哪一個案件關鍵 ID）。
Error handler：把失敗當狀態管理，而不是當意外
你不一定馬上用到最完整的錯誤處理設定，但你要先建立態度：任何外部呼叫都可能失敗，失敗要可讀、可追蹤。搭配 Run history，你才能回答老闆或客戶那句：「到底有沒有跑？」若答不出來，就不要談自動化很專業。
讓失敗比成功更吵：通知策略的簡單版
成功可以安靜；失敗要用固定渠道、固定標題格式，讓負責人無法忽略。每個月抽一次真實案例做演練：故意製造一個失敗，看通知是否真的能把你叫醒、紀錄是否真的能還原。若你做得到，你才敢把更多流程接上去。
註冊後的第一件事：先為「失敗」留一條聲音
在你把更多場景塞進去之前，先把底線工程做好：出事會叫我。這條習慣會決定你六個月後，自動化是資產還是負債。Retry 與錯誤模組的細節請依官方文件為準；但原則永遠相同：可觀測、可回溯、可補救。
可觀測不是「_logging 很多」，是可定位
自動化成熟度的一個粗略指標：當別人問「昨晚那筆為什麼失敗」，你是否能在五分鐘內指出停在哪一模組、進了哪條 Router、輸入缺了哪個欄位。若答案永遠是「我重做就會好」，那只是把賭運氣制度化。
錯誤通知要可行動
訊息裡請包含：Scenario 名稱、Run 識別資訊（依介面為準）、建議的第一個檢查步驟。不要只寫「Error」。人會疲勞，疲勞就會已讀不回，最後變成 silent failure。Router 可以很樸素，但一定要有一條路會吵到對的人。
寫進待辦的那一行
加一條 Router：成功低調、失敗吵人。把錯誤訊息寫得像是給三周後的自己看的備忘。
另外補一句實務：遇到介面詞彙與官方改版不一致時，請以當時官網與連線對象的文件為準。 把流程命名寫得像「發生什麼事」而非「某人某月測試」，半年後你才找得到。