AI 工作流的維護稅：你請假那週，你搭的那條自動化就停了｜附流程存留四問

先講結論：一條只有你會修的自動化，省下來的時間是借來的。

而它收利息的時間，通常挑在你最不方便的那一週——請假、出差，或忙到沒空看它的時候。

我自己的網站後台跑著一整套自己搭的排程和腳本：定時發佈、批次更新文章的封面與分類欄位、數據彙整。搭好的時候，我真心覺得省下了好多時間。直到某一天，我發現有 20 篇文章的封面圖不見了。

沒有報錯，也沒有任何通知。

我回頭追根因，最後追到一個很小的東西：一段模板裡寫著「圖片欄位＝空」的預設值。它被我複製進了三份設定文件和一支腳本，而每一次腳本去批次更新文章欄位，就會用這個空值把原本的封面蓋掉。20 篇裡我救回 18 篇，另外 2 篇連原圖都找不到了。

我後來在事故紀錄裡下的結論是：事故不是某一次操作失誤，是一個被複製了四次的預設值。

而這只是其中一件。前後一個月之內，我這套自己搭的流程一共出了四件事，下面會一件一件講。

先交代這篇的邊界：我沒有企業 IT 維運的經驗，這篇的主詞從頭到尾是「一個人自己搭的流程」——你用 AI 串的週報、自己做的表單自動化、同事都在用但只有你懂的那條排程。組織該怎麼管流程，不在這篇的範圍，我也沒有資格回答。

AI 自動化省下的時間，為什麼說是「借來的」？

AI 自動化省下的時間之所以是借來的，是因為它依賴的三樣東西都會變，而且變的時候不會先問你：上游服務、執行環境，還有你自己後來補上的修補。

搭好的那一刻，是這條流程和這三樣東西最對齊的一刻。之後每過一天，都在慢慢偏移。

先回應一個合理的質疑：這些壞法，其實不是 AI 才有——傳統的排程和腳本一樣會壞。AI 讓它變嚴重的地方在於門檻：以前要會寫程式才搭得出來的流程，現在一個不寫程式的人，一個下午就能串出一條。搭得越快、越多，就有越多條流程，只有搭的那個人自己懂。

一、上游會變，而通知只會寄到少數幾個人

這不是我的推測，是寫在官方文件裡的規則。

以微軟 Power Automate 為例，官方文件《Limits of automated, scheduled, and instant flows》明列了幾條「流程會被自動關掉」的條件：

• 持續出錯的流程，14 天後會被關閉
• 90 天內沒有被觸發的流程，可能會被關閉（使用進階授權的擁有者不在此限），系統會在關閉前 30 天通知擁有者與共同擁有者
• 持續被限流的流程，14 天後也會被關閉

先看第一條。官方文件在「持續出錯 14 天就關閉」這一條旁邊，沒有寫會先通知誰。如果你剛好請了兩週假，而流程在你離開後開始出錯，回來時它可能已經被關了。

再看第二條的通知對象：擁有者與共同擁有者。如果「共同擁有者」那一欄是空的，通知就只會到你一個人的信箱。

AI 模型本身也一樣。OpenAI 的官方棄用頁寫著，他們會定期淘汰舊模型，依賴這些模型的軟體「可能需要不定期更新才能繼續運作」，受影響的客戶會收到 email 通知。頁面上的例子很具體——Assistants API 在 2025 年 8 月 26 日宣布棄用，已經在 2026 年 8 月 26 日正式關閉。

一年的緩衝期看起來很長。但如果那條流程是你很久以前搭的、中間沒再碰過，那封 email 寄到的時候，你想得起來它接的是哪一個接口嗎？

二、環境會漂，而且漂的時候不會報錯

第二件事是時區。

我的排程有一道「時間檢查」：確認現在是台北時間的某個時段才執行。有一天，執行環境回傳的時間比台北慢了整整 8 小時，檢查判定「還沒到時間」，就照規則跳過了。對系統來說，這是一次完全正常的跳過。

我是發現該跑的東西沒跑、手動強制執行之後，才回頭去查。修的時候才知道影響範圍有多大：同樣的時間判斷寫在 12 份設定檔、10 支排程裡，每一處都要改、每一處都要驗。

對系統來說，它沒有壞；對我來說，它那天什麼都沒做。 這種落差，不會出現在任何錯誤訊息裡。

三、你補上的修補，會變成下一個坑

第三件最痛，因為兇手是自己。

前面那個封面事故，後來我又往下追了一層。我的發佈流程裡有一個固定步驟：每篇文章發完之後，再補送一次更新，用來修正「某個欄位發佈時會漏掉」的問題。這個步驟跑了兩週。

然後我發現，那個欄位從來沒有漏過。是當初拿來檢查的程式碼把欄位名稱寫錯了，所以永遠讀到空值，讓我以為它漏了。

更諷刺的是：那個多餘的補送更新，正是把 20 篇封面清掉的兇器。 如果那個空的預設值像子彈，這個多餘的步驟，就是每次發文都去扣一次的扳機。

為了修一個不存在的問題而加上的步驟，製造了一個真實的問題。這是維護稅裡最貴的一種：維護留下來的東西，你已經不記得它為什麼存在。

AI 自動化真正的風險：壞了沒人知道、知道了沒人會修

AI 自動化會壞，這一點我接受。讓我改變做法的是另一件事：壞掉之後，這條流程裡只有我一個人同時具備「會發現」和「會修」這兩個能力。

第四件事是一支一次性的排程，被系統清掉了兩次。同一段時間，我另外 26 支週期性的排程一支都沒掉。後來我把那支改成了週期性的——修法很簡單，前提是有人知道那件事本來應該發生。

說實話，這四件事都不是發生在我請假的時候，我運氣好，剛好都在。但每一件我事後都想過同一個問題：如果那週我不在呢？ 答案都一樣——不會有人發現，因為除了我，沒有人知道那些排程存在。

所以我現在看一條自動化，第一個問的已經不是「它省了我多少時間」，而是：

「我不在的那一週，它壞了，會怎麼樣？」

如果答案是「沒差，我回來再修」——很好，這條可以放著。

如果答案是「同事會等不到東西，而且不知道為什麼」——那它省下的時間，就是用同事的等待，加上你回來之後的救火在付的。

「個人流程壞了重搭就好」——這個反駁只對一半

「個人流程壞了重搭就好」這個反駁，在三種情況下完全成立，其他時候就站不住。我自己以前也這樣想。這三種情況是：

• 壞掉的代價只有你自己承擔：產出只給你自己看，晚一天沒人受影響
• 重搭的成本很低：半小時能從零搭回來的東西，確實不值得寫文件
• 你幾乎天天在用它：壞了當天就會發現

只要少了其中一條，「壞了重搭」就不成立。最常見的是第一條先破——你搭的東西，悄悄變成了別人的輸入。 你串的那份週報，主管每週一早上會看；你做的那張自動彙整表，業務每天拿去報價。你以為它是個人工具，別人已經把它當成基礎設施。

「重搭」本身也有陷阱。封面事故之後我修正了設定，事後盤點才發現，還有一支不在原本那四處裡的發佈腳本，停在修正之前，同樣帶著那個會清空封面的預設值。

如果那時候我選的是「整條重搭」，我很可能會照著舊筆記，把同一個坑原封不動地搭回去。重搭複製的不只是功能，還有你當初沒發現的錯。

流程存留四問：我現在怎麼決定一條自動化留不留

流程存留四問，是我現在用來判斷一條 AI 自動化該「留、降級、還是停」的四個問題。每一題都有一條及格線，最後看的是不及格的題數。

第一問：我不在的那一週，它壞了，誰會先發現？

及格線：除了我，至少還有一個人會發現——或者流程壞掉時，會自動通知第二個人。

如果答案是「只有我」，這條流程就是單點故障。最低限度的解法，是讓它壞的時候會吵：沒有產出就傳一則訊息給第二個人，而不是安靜地什麼都不發生。

第二問：發現的人，能不能在 30 分鐘內讓它停下來、改回手動？

及格線：不用會修，只要會關。

修需要懂原理，停只需要知道開關在哪。一張寫著「怎麼關掉它、關掉之後手動怎麼做」的便條，就能讓這一題及格。

第三問：它依賴的上游改版時，通知會寄到誰那裡？

及格線：至少兩個人收得到，或有人固定去看上游的公告。

前面講過，官方通知通常寄到擁有者或帳號的信箱。如果那個信箱只有你會看，而且每天有兩百封信，這一題的真實答案其實是「沒有人」。

第四問：把它關掉、改回手動，每週要多花多少時間？

及格線：關掉之後每週多花的時間，明顯多過你現在每週花在維護它的時間。

這一題是反過來算帳。如果關掉只會多花不到一小時，而你每週都在追錯、修補、回想「這段是幹嘛的」，那維護稅很可能已經超過它省下的。

判讀方式：

• 四題都及格 → 留著，每季回頭看一次
• 一到兩題不及格 → 降級（下一節）
• 三題以上不及格 → 認真考慮停掉。它可能沒有不好，只是你付不起它的維護稅

降級不是失敗：三種比整條拆掉更好的做法

AI 工作流降級，是在「全自動」和「全部拆掉」之間，找一個維護成本更低、壞了也不會出大事的位置。下面三種都比直接拆掉划算。

一、從「全自動」退成「它準備、人按下」

讓流程把東西準備好，但最後那個「送出」由人按。你會損失一點便利，換來的是：每一次執行都有一個人看過一眼。 壞掉的東西會在按下之前被看到，而不是在送出去之後。

二、同一個預設值，只准存在一個地方

我的封面事故，根源是同一個預設值散在好幾個地方——修完一批，還有一支腳本沒跟上。現在我的原則是：任何會被多處使用的設定，只寫在一個地方，其他地方去讀它。 這不是什麼高深的工程原則，但一個人搭流程的時候，複製貼上實在太方便了。

三、先寫「怎麼關」，再寫「怎麼修」

如果你只有力氣寫一份交接文件，寫「怎麼關掉它」。三行就夠：開關在哪、關掉之後誰會受影響、手動替代做法是什麼。這份東西任何人都看得懂，而你請假那週，它比任何架構圖都有用。

這套判斷適合誰、不適合誰

流程存留四問最適合的，是自己搭了自動化、而產出已經開始被別人使用的人。

適合你，如果：

• 你自己搭了兩條以上的自動化，而且至少有一條的產出會被別人使用
• 你是團隊裡「那個比較懂 AI 的人」，同事會來問你「那個東西怎麼又沒跑」
• 你曾經在休假時收到「那個報表怎麼沒出來」的訊息

不適合你，如果：

• 你的自動化純粹只給自己用，壞了晚一天也沒關係——那就享受它，不用想太多
• 你們公司已經有專人負責這些系統——先照公司既有的規定走就好

代價：

你會關掉一些其實還能用的流程。 有些東西四問不及格，但它確實每天在幫你省時間。停掉它會痛，而且短期內你會變忙。

降級會讓你失去「全自動」的爽感。 「它準備、人按下」聽起來很退步，每天多按一次，會讓人懷疑當初搭它幹嘛。

寫「怎麼關」的便條，會逼你面對自己也說不清楚的步驟。 你會發現有些步驟講不出為什麼存在——而那裡，通常就是下一個事故的所在地。

留下來的那一條，接下來要顧什麼？

決定留下來的自動化，接下來要顧的是工具層的問題：用哪一套串、哪一道使用限制會最先撞到。這篇只負責「要不要留」，這些不在這裡回答。

我在自己的部落格整理過一篇免費 AI API 接自動化的額度實測，拆了串接時最先撞到的兩道牆，可以拿來對照你留下的那一條。

下一次你搭好一條新的自動化、正覺得省下好多時間的時候，先停下來問一句：我不在的時候，誰會發現它壞了？

FAQ 常見問題

我的自動化只有自己在用，也需要想「我不在時誰修」嗎？

不一定需要。如果產出只給你自己、壞了晚一天沒人受影響，那「回來再修」就是合理的選擇。真正要注意的是「只有自己在用」這件事會悄悄改變——你把自動彙整的表格分享給主管一次，下週它就變成主管的例行輸入了。建議每季回頭看一次：這條流程的產出，現在有誰在用？

同事已經開始依賴我搭的流程了，我該先做什麼？

先做兩件最小的事：讓流程壞的時候會通知第二個人，以及確認那個人知道怎麼把它停下來、改回手動。也就是先讓四問的第一題和第二題及格。做完之後，你請假那週會少掉很多「那個怎麼沒出來」的訊息。

要不要乾脆把所有流程寫成完整的技術文件？

我不建議一開始就這樣做。完整文件寫起來很久、更新更累，而且文件寫了，不代表出事的時候會被讀到——我自己就遇過規則明明寫在文件裡，執行時還是照樣做錯的情況。與其寫完整文件，不如先把第二問顧好：讓身邊至少一個人知道開關在哪。

多久應該重新檢查一次自己搭的流程？

我會建議綁在兩個時間點，而不是固定頻率。第一個是上游寄來任何改版或棄用通知的當週，因為那是最確定會出事的訊號。第二個是每季一次的盤點，只問一件事：「這條流程的產出，現在有誰在用？」答案變了，四問就要重跑一次。

參考資料

Microsoft Learn，Limits of automated, scheduled, and instant flows：持續出錯的流程 14 天後關閉；90 天未觸發的流程可能被關閉（進階授權除外），關閉前 30 天通知擁有者與共同擁有者；持續被限流的流程 14 天後關閉。

OpenAI，Deprecations：官方說明會定期淘汰舊模型，依賴的軟體可能需要更新才能繼續運作，受影響客戶會以 email 通知；Assistants API 於 2025-08-26 宣布棄用、2026-08-26 關閉。