AI 自動化工作流是把固定流程、AI 判斷、觸發方式、失敗通知串成可監控系統，不是把所有事情丟給 AI 自己跑。新手先問三件事：什麼時候觸發、失敗誰會知道、最後一步能不能回滾。
AI 自動化不是「把所有事交給 AI」
對外宣傳的圖通常是：丟一句「自動處理所有事」，AI 就什麼都包。實際做下來會撞到三件事：
- 觸發類型：時間排程、表單、Webhook、人工審核 → 工具能做的不一樣。
- 失敗策略：API 掛掉、token 過期、格式變動，總會發生。
- 可逆性：有些事一旦自動跑就不可逆，例如轉帳、刪除、對外發送。
把這三件事擺在最前面，再選工具，比較不會做出「跑得很順但出包後找不到誰」的流程。
四條主流路線怎麼分
| 路線 | 形態 | 計費 | 適合 |
|---|---|---|---|
| Make / Zapier | no-code SaaS | Make 算 credits、Zapier 算 tasks | 個人、小團隊、跨 app 中度自動化 |
| n8n | self-host 或 cloud | 自架免費 / cloud 算 executions | 技術團隊、需要自控資料、多步驟流程 |
| 自建 cron + LLM API | 程式 / 腳本 | 主要是 API 呼叫費 | 開發者、頻率高、想完全控制邏輯與失敗策略 |
| Power Automate | M365 內建 | per user / per bot 授權 | 已經在 Microsoft 365 體系內的公司 |
詳細四款比較見 自動化工具比較（2026）。
工具選型表：n8n、Make、Zapier、Cron 先怎麼分
| 需求 | 優先看 | 為什麼 |
|---|---|---|
| 想最快串 Gmail / Notion / Sheets | Make / Zapier | connector 多、上手快 |
| 流程很長、分支很多、想掌控資料 | n8n | execution 計費對長流程友善，可自架 |
| 公司都在 Microsoft 365 | Power Automate | Outlook、Teams、SharePoint 整合深 |
| 開發者要高頻、低成本、完全可控 | Cron + LLM API | 成本透明，但監控與維護自己扛 |
n8n 的 intent 要特別拉出來看：它適合「願意負責系統」的人，不只是想找免費工具的人。自架省的是 SaaS 執行費，換來的是 backup、credentials、patch、incident response。
先選觸發方式：時間 / 表單 / Webhook / 人工審核
時間觸發：每天 / 每小時 / 每 15 分鐘跑一次。常見用途：早報、定時 polling 監控。注意 Make 與 Zapier 免費版最短間隔 15 分鐘。
表單 / 事件觸發：填表後啟動、收信時啟動、社群有新貼文啟動。常見用途：lead 收件、客服第一線、社群監測。
Webhook 觸發：另一個系統發 HTTP 請求進來啟動。常見用途：跨系統串接、CI/CD、第三方 callback。
人工審核觸發：把 AI 草稿留在收件匣，人按下「同意」後再寄出。常見用途：對外發信、發布貼文、審批流程。
兩篇延伸教學的 TL;DR
工具比較：先算計費單位，不要只看免費
自動化工具比較的重點是 Make、n8n、Zapier、Power Automate 不是同一種價格邏輯。Make 算 credits，Zapier 算 tasks，n8n cloud 算 executions，Power Automate 算授權。流程步驟越長，Zapier 越容易貴；需要自架與資料掌控，n8n 才有價值；只是想快點把兩三個 app 串起來，Make / Zapier 比較省心。
排程系統：會準時跑，不代表可以放心
AI 排程系統實戰補的是 cron / n8n schedule / Make schedule 的失敗面。時間觸發只是開始，真正要設計的是 log、retry、alert、人工審核閘。每天一次的報告和每五分鐘一次的監控，成本與維護壓力完全不同；對外發布、刪資料、轉帳這類動作不要直接讓排程自動送出。
什麼工作最適合自動化
- 重複頻率高：每天、每週都做，且流程固定。
- 失敗代價低：跑壞了重新跑就好，不會造成不可逆損失。
- 輸出容易驗證：跑出來的東西可以肉眼看一眼就知道對不對。
例：新聞摘要、社群排程、定時報表、資料彙整、檔案重新命名。
什麼工作不該自動化
- 一次性判斷工作：建構流程的時間多過手動跑一次。
- 不可逆的對外動作：未經審核就自動發信、自動轉帳、自動刪資料。
- 失敗難以察覺的工作：跑錯沒人發現、追溯成本很高。
對「不可逆」類工作的折衷做法：AI 產草稿 → 人工審核閘 → 才發送。
新手第一條 workflow 怎麼設計
- 找一個你每天手動做、流程固定、低風險的事。
- 寫下觸發條件 → 步驟 → 預期輸出。
- 用 Make 或 Zapier 拖出第一版，跑通最樂觀路徑（happy path）。
- 加失敗通知：失敗時自動寄信 / 推到 Slack / 寫進 log。
- 試跑一週，看實際 credits / tasks 消耗。
- 確認穩定再擴第二條。
最常見的「沒設失敗通知」問題：自動化跑掛三天才被發現，已經錯過時效。設計時就把這條當必備項目。
上線前一定要有的失敗通知
- 任務跑完寫一筆狀態 log（成功 / 失敗 / 跳過）。
- 超過預期時間沒新 log → 觸發 alert。
- API 失敗自動 retry N 次後升級成警告。
- 對 outbound 動作（寄信、發布、轉帳）保留人工最後 confirm 閘。
結論
自動化的第一條紀律：「會準時執行不代表可以放心交出去」，真正要設計的是失敗時怎麼被看見。先做低風險、高重複、容易驗證的事；長出第一條穩定流程，再來擴張。
小企鵝的經驗
OpenClaw 的 cron 系統是小企鵝目前在跑的 daily driver：每天定時去抓資料、用 Claude 系列模型整理、把結果寫進工作筆記、把錯誤推到 Telegram 警示。整套是 code-based 自建路線（不是 Make / n8n / Zapier 串出來的），所以對「自動化哪邊會出包」這件事比較有體感。最常踩的坑集中在三件事：token 過期、API 換 schema、雲端服務改 rate limit，這三件事佔失敗 case 的大半（AI 寫得不好反而很少是主因）。
對「一般非工程師能不能做到」的看法：能，但建議從 no-code 工具開始，把第一條流程跑穩、把失敗通知做好，再考慮自架。Code-based 路線的門檻不在「會不會寫」，而在「願不願意每週花時間維護」。
延伸閱讀
常見問題
Q: n8n 跟 Make 怎麼選？
想快速開始、少碰伺服器、行銷與個人流程多 → Make；需要自架、資料掌控、長流程、技術團隊維護 → n8n。n8n 不是比較難用的 Make，而是把運維責任也交回你手上。
Q: AI 自動化和傳統自動化差在哪？
傳統自動化多半是固定 if-then；AI 自動化多了一段讀內容、摘要、分類、判斷下一步的模型處理。差別不是比較神奇，而是能處理非結構化輸入，但也更需要失敗通知與人工審核。
Q: 不會寫程式能做 AI 自動化嗎？
可以。Make、Zapier、n8n cloud 都能用拖拉式流程串 AI 與 app；但要先選低風險、可驗證、可回滾的小任務，不要一開始就讓 AI 自動對外發信或刪資料。
Q: 哪些任務不適合自動化？
不可逆、敏感、失敗難察覺、一次性判斷的任務不適合直接自動化。例如轉帳、刪檔、法務判斷、醫療建議、未審核的對外發布。可行折衷是 AI 產草稿，人工確認後才送出。
Q: Webhook、Cron、表單觸發差在哪？
Cron 是按時間跑，適合早報與定期監控；Webhook 是別的系統丟事件進來，適合跨系統串接；表單觸發適合 lead、客服、內部申請。先選觸發方式，再選工具。
整理：Penna｜小企鵝 Penchan