最近在整理一批 AI 自動化排程時，我又被一個很小、但很真實的問題敲了一下頭：排程明明都有跑，資料也有產出，可是最後送到使用者面前的東西，並不一定是「可用的」。
這句話聽起來有點廢。程式有跑完、檔案有生成、log 沒爆紅，不就成功了嗎？
以前我也很容易這樣想。但當 AI 開始接管更多日常工作流，尤其是每天固定產出報告、摘要、提醒、建議時，「有輸出」跟「有價值」中間其實隔著一條很深的溝。那條溝通常不是模型能力造成的，而是我們把輸出格式、傳遞通道、閱讀情境想得太簡單。
排程成功，不代表工作完成
很多工程師看 cron job 的直覺，是看三件事：
- 有沒有準時啟動
- process exit code 是不是 0
- 產物有沒有落在指定位置
這三件事當然重要。沒有它們，整個系統連基本可靠性都談不上。
但如果這是一個「給人看的 AI 工作流」，光是這三個指標其實不夠。因為真正的終點不是檔案存在，而是某個人在對的時間，用最低成本讀懂它，然後能採取下一步行動。
最近我看到的狀況就很典型：AI 排程照時間跑完，報告也寫得不差，但因為內容太長，最後被當成附件丟出去。從系統角度來看，這很合理——平台訊息有長度限制，長文就變成檔案嘛。可是從使用者角度來看，體驗立刻變差。
原本期待的是早上打開聊天工具，直接看到今天的重點；實際拿到的卻是一堆 Markdown 附件。要點開、下載、切換閱讀器，甚至還要猜哪個檔案是最重要的。這中間每多一步，資訊被真正消化的機率就下降一截。
技術上成功，產品上失敗。這種落差在 AI 自動化裡特別常見。
AI 報告不是檔案，是一次溝通
我現在越來越傾向把 AI 產出的日報、週報、提醒，看成「一次溝通」，而不是「一份文件」。
文件可以長，可以完整，可以留存。溝通則要考慮情境：對方現在在哪裡看？手機還是桌機？有多少時間？這份內容是要提醒、決策、追蹤，還是單純存檔？
同一份資訊，在不同通道應該有不同形狀。
例如技術分析報告放在 knowledge base 裡，可以有完整脈絡、資料來源、細節推導；但如果要丟到聊天工具，就應該先出一版「可掃讀」摘要：三個重點、兩個風險、一個建議。需要細節的人再點連結或看附件。
這不是把內容變短而已，而是重新設計資訊的入口。
AI 很擅長生成長文，這反而讓我們更需要節制。因為生成成本下降後，閱讀成本就變成真正瓶頸。以前人寫報告會因為累，所以自然收斂；現在模型不會累，一不小心就把所有上下文、所有推論、所有但書都塞進去。看起來很負責，實際上常常是在轉嫁理解成本。
身為技術主管，我會更在意這件事：AI 工作流不是把人從寫作中解放出來，然後讓另一群人被閱讀淹沒。真正好的自動化，應該連「怎麼讀」都一起設計。
通道限制不是例外，是規格
另一個踩坑點是通道限制。
聊天平台有字數限制、格式限制、附件預覽限制；Email 有版面和垃圾信風險；Dashboard 有載入速度和權限問題；內部系統有通知疲勞。這些東西很煩，但它們不是部署後才處理的小麻煩，而是工作流設計的一部分。
我以前看這類問題，會把它歸類成「傳送層」。也就是內容先產生，最後再想辦法送出去。但現在我覺得這個分層不太對。對 AI 報告來說，傳送層會反過來決定內容形狀。
如果目標通道是聊天訊息，就要一開始就要求模型產生適合分段的結構：每段獨立可讀、有清楚標題、不依賴前一段才能理解。這樣當系統需要拆成多則訊息時，才不會把語意切爛。
如果目標通道是 Email，就要有摘要、目錄、錨點與明確標題，避免使用者在一大坨文字裡迷路。
如果目標是長期留存，就要補 metadata、來源、日期與版本，否則三週後回來看，只會變成一堆失去脈絡的漂亮文字。
通道不是最後一步；通道應該進入 prompt、資料結構、驗證規則與測試案例。
「半死狀態」比直接失敗更危險
這次整理過程中，還有另一個提醒：自動化系統最討厭的狀態，不是死掉，而是半死。
死掉很好處理。監控會叫，服務會紅，使用者也會很快發現。真正麻煩的是 process 還在，pid 還活著，某些 log 看起來也正常，但關鍵 adapter 已經停了，或者某個外部連線沒有恢復。系統表面上活著，實際上不再完成它該完成的工作。
AI 工作流特別容易遇到這種問題，因為它常常串很多東西：排程器、模型 API、資料來源、檔案系統、訊息平台、權限設定、長連線 gateway。任何一段進入半死狀態，最後使用者看到的可能只是「今天怎麼沒收到」。
更麻煩的是，AI 產出有時不是強一致需求。少一份早報、晚一個提醒，系統不會像金流失敗那樣立刻爆炸。但長期下來，信任會慢慢流失。使用者開始不確定它到底會不會準時、內容到底是不是最新、沒出現時是沒有事件還是壞掉。
信任一旦掉下去，自動化就從助手變成噪音。
所以我現在會把「健康檢查」看得比以前更廣。不是只看 process alive，而是看工作流是否真的完成：今天應該送出的訊息有沒有送？送到哪個通道？內容是不是被降級成附件？有沒有被拆段？拆段後是否仍可讀？如果沒有新內容，是否有明確 silence 規則，而不是讓使用者猜？
讓 AI 工作流可被營運
這些問題最後都指向同一件事：AI 工作流不能只被開發，還要能被營運。
傳統程式很多時候只要規格穩定，維護成本就可控。但 AI 工作流比較像一個會每天「出版」的系統。它會接觸新資料、產出新文字、面對新的邊界案例，也會因為外部平台限制改變而突然失準。
因此我會建議至少保留幾個營運面設計：
- 每個排程要有明確的「成功定義」，不是只有 exit code
- 長文輸出要同時設計摘要版與完整留存版
- 聊天通道要預先處理分段，而不是超長才硬切
- 沒有新內容時要允許安靜，不要為了交差硬產文
- 失敗時要能看出卡在哪一層：資料、模型、格式、傳送、權限或通道
- 重要設定變更後，要有自動驗證，而不是靠人肉祈禱
這些聽起來都不炫。沒有新的模型，沒有 fancy demo，也沒有讓人眼睛一亮的 AI magic。
但實務上，這些才是 AI 自動化能不能長期活下來的關鍵。
小結：別只問 AI 能不能寫，還要問人能不能用
現在很多團隊導入 AI，第一個問題都是「它能不能幫我產出？」
這當然是起點，但不是終點。下一個更重要的問題應該是：「產出之後，人能不能真的用？」
能不能在通勤時快速看懂？能不能在開會前抓到重點？能不能在需要追溯時找到完整版本？能不能在系統沒東西可講時安靜？能不能在壞掉時讓維護者知道哪裡壞？
這些問題看起來不像 AI 問題，比較像產品設計、SRE、資訊架構與團隊流程的混合體。但我覺得，這正是接下來 AI 應用會拉開差距的地方。
模型能力會越來越普及，大家都能產生一份看起來像樣的報告。真正稀缺的是，把那份報告放進一個可靠、可讀、可營運的工作流裡。
AI 排程不是有跑就好。它每天送出去的每一則訊息、每一段摘要、每一個沉默，其實都在累積使用者對系統的信任。
而信任，才是自動化最難重建的基礎設施。