結論先講
自動化系統出事，幾乎都不是因為 AI 判斷錯。是因為沒人定義過「哪一層負責什麼」。
於是出現這些狀況：把去重交給模型自由發揮、把秘密放到前端、儀表板把錯誤藏起來、AI 直接寄出了一封不該寄的信。
解法是先畫兩張表：一張責任分層表，一張動作分級表。
第一張表：六層責任，各自負責與不負責什麼
| 層 | 負責 | 不能負責 |
|---|---|---|
| 資料來源 | 信箱、行事曆、搜尋 API、平台通知、網站檢查 | 不保證所有來源都完整 |
| 排程 | 固定時間啟動、保存狀態與錯誤 | 不替代來源授權與系統通知 |
| 規則 | 日期、去重、狀態、上限、停止條件 | 不靠模型自由發揮 |
| AI | 摘要、分類、比較、草稿與解釋 | 不創造來源或假造指標 |
| 儲存 | 資料、版本、來源、執行紀錄 | 不把秘密放前端 |
| 介面 | 顯示優先順序、來源、狀態與待核准 | 不隱藏錯誤與過期資料 |
右欄比左欄重要。左欄是大家都會做的，右欄是出事的地方。
「規則不靠模型自由發揮」是最常犯的錯
凡是有明確標準答案的，都交給規則，不要交給 AI：
| 該用規則 | 該用 AI |
|---|---|
| 日期比較、時間範圍 | 摘要一段文字 |
| 去重（同一筆資料出現兩次） | 分類這則訊息屬於哪一類 |
| 數量上限（一次最多處理 20 筆） | 比較兩個方案的差異 |
| 停止條件（連續三次沒有新結果就停） | 起草一封回信 |
左欄用程式寫死才穩定；交給 AI，同一份輸入跑兩次可能得到不同結果。
「AI 不創造來源或假造指標」
模型被問到不知道的數字時，傾向給一個看起來合理的。在自動化報表裡，這比答錯更危險——因為沒有人會去查。
實作上的防線：報表裡每一個數字都要能點回原始來源。點不回去的數字，不准出現在報表上。
第二張表：動作分級
這是整篇最重要的一張表。分級的依據不是動作複雜度，是能不能撤回。
可以自動執行：內部動作
這些只影響你自己的系統，做錯了改回來就好：
- 標記已讀
- 加入內部待辦
- 調整優先順序
- 查看來源與歷史
- 產生未寄出的草稿
必須人工核准：外部寫入
這些會影響第三方，送出去就收不回來：
- 寄信、轉寄
- 建立或修改會議
- 發布社群貼文或電子報
- 投遞履歷
- 修改或部署正式網站
這條線怎麼判
問一句話：「這個動作做錯了，我能不能自己收回來？」
能，就可以自動化。不能，就必須有人按下確認。
人工核准對話框的規格
「有確認視窗」不等於「有把關」。一個只寫「確定要執行嗎？」的對話框，使用者三天後就會無意識地一路按確定。
任何外部寫入前，對話框必須顯示六件事：
- 將執行什麼動作
- 對象（收件者／網址／帳號）
- 完整內容，或變更前後的差異
- 來源與依據（為什麼系統認為該做這件事）
- 是否可復原
- 執行人與時間
按鈕只能是這三個
【返回修改】 【取消】 【確認執行】
不可以用模糊按鈕，例如「OK」「繼續」「確定」。
理由很直接：「確定」沒有告訴使用者他在確定什麼。按鈕文字應該重述動作本身——「確認寄出」「確認部署」，讓人在按下去的瞬間知道自己在做什麼。
批次動作要顯示全部
要一次寄二十封信時，對話框必須顯示總筆數與全部收件者，不能只顯示第一筆然後問「確定嗎」。
這是實務上最容易出事的一處。看到一封信的預覽就按確定，結果寄了二十封——而其中三封的收件者是錯的。
三個名詞不要混為一談
自動化專案裡常把三種東西都叫「外掛」，導致討論混亂：
| 名詞 | 負責什麼 |
|---|---|
| Skill | 固化「怎麼做」——把重複的操作流程寫成可複用的步驟 |
| Connector／MCP | 連接即時的外部資料與動作 |
| App 程式碼 | 處理資料、狀態與介面 |
分清楚才知道問題該修哪裡。流程做錯改 Skill，資料抓不到查 Connector，畫面不對改程式碼——混在一起時，你會在錯的地方找問題。
介面設計：不要隱藏錯誤
這一條反直覺，但很重要。
隱藏錯誤與過期資料是自動化系統最危險的設計，因為使用者會把「沒看到錯誤」當成「一切正常」，然後基於不完整的資料做決策。
儀表板上每一張資訊卡都應該顯示：
- 資料來源
- 最後更新時間
- 抓取狀態（成功／部分失敗／失敗）
一個誠實顯示「這筆資料三天沒更新」的儀表板，比一個看起來很乾淨但其實壞掉的儀表板有用得多。
一份上線前的檢查清單
- 六層責任的「不能負責」欄，每一條都有對應的實作防線
- 所有確定性邏輯（日期、去重、上限、停止條件）都是規則，不是 AI
- 報表上每個數字都能點回原始來源
- 動作已分成「內部可自動」與「外部需核准」兩類
- 核准對話框顯示了六個必要欄位
- 按鈕文字重述動作，沒有「OK」或「確定」
- 批次動作顯示總筆數與全部對象
- 儀表板顯示來源、更新時間與抓取狀態
- 秘密與金鑰不在前端
最後一項如果沒做，前面八項都白費。
為什麼這件事比模型選擇重要
多數團隊在導入自動化時，花最多時間討論「用哪個模型」。
但實際上線後出的問題，幾乎都在這篇講的範圍內：責任分層沒定義、外部動作沒把關、錯誤被藏起來。
模型可以換，架構上的責任邊界一旦錯了，換模型也救不回來。 這也是為什麼這兩張表值得在寫第一行程式之前就畫好。
常見問題
為什麼要區分「內部動作」與「外部寫入」？
因為可復原性不同。標記已讀、加入待辦、調整優先順序這些只影響自己的系統，做錯了改回來就好；寄信、發布貼文、修改正式網站則會影響第三方，寄出去就收不回來。前者可以自動執行，後者必須人工核准——這條線不是看動作複雜度，是看能不能撤回。
每個動作都要人工確認，那自動化的意義何在？
自動化的價值在「收集、整理、分析、草稿」這四件事，那已經是八成的工作量。最後的「送出」保留人工，成本只有幾秒鐘，換來的是不會發生無法挽回的錯誤。真正該問的不是「能不能全自動」，而是「這個動作做錯了，我能不能承受」。
規則和 AI 該怎麼分工？
凡是有明確標準答案的都交給規則，不要交給 AI。日期比較、去重、數量上限、停止條件這些都是確定性邏輯，用程式寫死才穩定。AI 負責的是摘要、分類、比較與草稿——那些沒有唯一正確答案、需要判斷的部分。把規則的工作交給 AI，是最常見的架構錯誤。
人工核准對話框為什麼不能用「確定／取消」？
因為「確定」沒有告訴使用者他在確定什麼。按鈕文字應該重述動作本身，例如「確認寄出」。這件事在批次動作上特別重要——當你要一次寄二十封信，對話框必須顯示總筆數與全部收件者，而不是只顯示第一筆然後問「確定嗎」。
介面上要不要隱藏錯誤，避免嚇到使用者？
不要。隱藏錯誤與過期資料是自動化系統最危險的設計，因為使用者會把「沒看到錯誤」當成「一切正常」，然後基於不完整的資料做決策。正確做法是把錯誤與資料時間戳都顯示出來——一個誠實顯示「這筆資料三天沒更新」的儀表板，比一個看起來很乾淨但其實壞掉的儀表板有用得多。