Make 讓你把 AI 流程接成可維護工作流

Make 把 AI 工作流接成看得見、改得動、能交接的自動化流程。

我用 Make 有一陣子了，老實說，一開始我很不爽。畫面是漂亮，模組也很整齊，但每次我想做真正能上線的流程，就會卡在一堆分支、過濾器、路由器，還有那些看起來像「不用寫程式」但其實還是很吃系統思維的細節。它不是不好用，是它太誠實了：你以為自己在搭一條自動化捷徑，最後發現你其實是在設計一條會出錯、會重試、會分流、會交接的管線。我最受不了的，是很多工具把這件事包裝得像點幾下就有魔法，但真實世界根本不是那樣。我要的是能把雜亂工具串起來、把資料送對地方、出事時還能看懂哪裡壞掉的東西，不是玩具。

後來我重新看 Make 的官方說法，這次不是用「一般自動化」的角度，而是把它當 AI workflow 的編排器來看，整個感覺就變了。它真正賣的不是「按一下就完成」，而是把每一步、每個交接點、每個失敗點都攤開來。這點很重要，因為 AI 工作流通常不是一個 prompt 結束，而是檢索、分支、補資料、格式化、人工審核，然後再來一次 AI 呼叫。促使我重新整理這套想法的來源，是 Make 官方首頁 https://www.make.com/en，它直接把產品定位成可以視覺化建立、擴充、並自動化 AI 與 agentic workflows 的工具。

Make 真正在賣的不是自動化，是編排

“Visually build, scale and automate AI and agentic workflows.”

翻譯一下就是：Make 不是要當單一用途的 chatbot 外掛，也不是那種按一下就幫你做完一件事的小工具。它想站在你的 app、你的 AI 呼叫、你的商業規則中間，幫你把流程接起來。這很重要，因為大多數真的能上線的 AI 工作，核心都不是模型本身，而是模型前後那堆協調工作：先拿到對的輸入，再決定接下來怎麼走，然後把輸出整理成下一個系統吃得懂的格式，最後還要處理那些你不想半夜被叫醒的例外情況。

我之前做過一條客服分流流程，模型分類其實很準，真正麻煩的是分類後面那一串：要不要丟到對應 queue、要不要補客戶資料、急件要不要通知 Slack、最後還要把整個過程記錄到稽核看得懂的地方。一般的 no-code 工具常常能做前半段，後面一遇到分支就開始喘。Make 的視覺模型比較適合這種場景，因為流程長相是明的。你看得到哪裡分流、哪裡合流、哪裡失敗要重試、哪裡要走 fallback。

實操寫法很簡單：不要先把「自動化」想成一個動作，要把它想成一條 pipeline。先定 trigger，再定你要收集的資料，接著放 AI 步驟，再寫分支條件，最後接目的系統。如果你連紙上都講不出五步流程，通常代表還沒到動工的時候。Make 最強的時候，是你已經知道流程長什麼樣子。

• 先做一個 trigger，搭配一個明確 outcome。
• AI 只放在真的需要判斷或轉換的地方。
• 分支拿來處理例外，不要拿來塞所有邏輯。
• 每個輸出都要讓下一個系統看得懂。

視覺化 builder 的價值，是把失敗攤開給你看

我很喜歡，也很討厭，視覺化自動化工具的一點，就是它逼你正視自己寫出來的爛架構。寫 code 的時候，很容易把一個偷懶的假設藏在 helper function 裡，然後假裝整條流程很乾淨。到了 Make，整條流程就攤在那裡，像一張你不能假裝沒看到的配線圖。這件事很煩，尤其你想快的時候。但也正因為這樣，它才適合拿來做那些會真的碰到現實世界的 AI 系統。

Make 官方不會把這件事包裝成「容易除錯」，但實際上它給你的就是這個能力。某一步把資料轉壞了，你可以直接看到是哪裡變形。某個 module 期待的是一個欄位，結果你塞進去的是另一種結構，你可以沿著流程一路追，不用猜是哪個抽象層把問題吃掉了。這在 AI 輸出上特別重要，因為模型回來的東西通常是「差一點就對」；但差一點就不夠，尤其下一個系統要的是嚴格格式。

我碰過最煩的情況，是模型回了很有禮貌的一大段文字，但我其實要的是 JSON。也遇過 filter 因為欄位多包了一層就整個失效。寫程式時那叫 bug，放到 automation 裡面就變成信任問題。Make 的視覺排布好用的地方，就是我能直接追到資料從哪一步開始不是我以為的樣子。當流程會碰客戶、發票、內部營運時，我就是要這種可見性。

實操寫法：把流程分層做。先只做 trigger 和 destination，不要碰 AI。接著再加模型呼叫。再加驗證。最後才加 branching。你如果一開始四件事一起上，出事時根本不知道是模型、mapping，還是下游 app 爆了。那不是自動化，那是幫自己加 debug 稅。

• 每個 AI 輸出都要先驗證，再進下一個系統。
• 盡量用明確 mapping，不要用「有什麼就丟什麼」。
• 先用小樣本測試，再上真實 edge case。
• 留一條 failure path，把壞 payload 記下來。

「No-code」不是不用思考，是把力氣花在對的地方

Make 自己把產品講成 user-friendly 的 no-code integration tool，這我可以接受。但我不覺得 no-code 的意思是不用想。它的意思是，我不用把力氣浪費在 plumbing 上，而可以專心設計流程。這個交換很划算，但前提是我得老實承認，我是在編碼一套邏輯，不是在排貼紙。很多人做 automation 的方式像在貼便利貼，結果一旦流程變複雜，就變成自己也看不懂的東西。

Make 厲害的地方，在於它讓非工程背景的人也能做出像樣的工作流，同時又保留足夠結構，讓工程師不會想直接把筆電丟出去。這個中間地帶很難做。太抽象，你根本控制不了；太技術，視覺化的意義就沒了。Make 就卡在這個不舒服的位置，而現在很多 AI ops 也剛好卡在這裡。

我會直接告訴團隊：把每個 module 當 function，每條 route 當 conditional，每個 scenario 當一份你忘了寫的 system design doc。隊友如果講不出某個 branch 在幹嘛，代表太複雜。兩週後的你如果看不懂這條流程，代表要整理。這就是「我做了一條 automation」跟「我做出一個維護黑洞」的差別。

實操寫法：把每一步的意圖寫在 scenario 裡。module 命名要像 function 名稱一樣清楚。用 comment 或 note 寫出這條 business rule 的目的。如果這條流程很重要，請在工具外面留一份純文字邏輯。Make 不是你的 source of truth，真正的 source of truth 是流程本身。

AI 工作流不能只有 prompt，還要有分支

很多人講 AI automation，還停在「把文字送進 model，拿文字回來」這個層級。那只是入門版。真正的工作流一定要有分支，因為真實工作本來就是條件式的。有些 input 可信度低，有些 output 要人工看，有些請求本來就應該直接送人，有些要再跑一次模型補上下文，有些則是乾脆停掉。

這也是 Make 的 agentic workflow 說法開始有意義的地方。重點不是它能不能跑 AI 呼叫，而是它能不能把 AI 呼叫前後那整個決策樹一起包住。這才是 AI 真正進到營運流程裡的樣子，不是 demo 裡那種「看起來很會」。我看過很多團隊用模型先草擬回覆，結果真正花時間的是 tone check、policy check、升級規則、存檔。那才是工作。prompt 可能只佔 20%。

我比較喜歡把流程想成一連串 gate。第一關，輸入有沒有問題。第二關，這件事需不需要 AI。第三關，輸出夠不夠可信，能不能自動化。第四關，不行的話要交給誰。Make 的價值，就是把這些 gate 攤開，讓你能改、能看、能交接。否則你最後會把政策塞進 prompt 裡，這是我看過最爛的營運管理方式之一。

實操寫法：至少設計三條路徑，一條自動化、一條人工審核、一條失敗處理。不要假設每個 AI 輸出都能直接上線。如果你需要 confidence score，就加。如果你需要 human approval，就 route。如果你需要 retry 或 fallback model，就明確接上去，不要靠心電感應。

能不能擴充，差別在少一點英雄主義，多一點可重複

Make 說它可以 scale workflows，我對這種字眼通常很懷疑。但這裡至少碰到一件真的事：一條流程能跑一次，跟一條流程在量變大、例外變多、團隊變大之後還能跑，根本是兩回事。擴充 automation 不是把同一條流程跑更快，而是讓這個流程不要每次都靠某個人記得它怎麼接的。

所以我比較信 Make 拿來做 operational glue，不太信它拿來做那種很花俏的一次性 demo。當 workflow 開始串多個 app，真正的成本不是執行，是維護。CRM 欄位改了誰來修？AI 回傳格式飄了誰會發現？下游服務 timeout，retry policy 誰負責？視覺化自動化會把這些問題攤出來，這件事很煩，但也很有用。

如果你是在幫團隊做，請先想交接。別人打開這條 scenario，看不看得懂意圖？欄位 mapping 能不能改，不會整條炸掉？新增一個 edge case 的 branch，需不需要重寫整條流程？如果答案都是否定的，那你沒有 scale，只是把脆弱性集中化。

實操寫法：workflow 盡量模組化。當邏輯開始膨脹，拆成幾條小 scenario。命名規則統一。input 和 output schema 盡量固定。只要流程變成 business critical，就在 builder 外面加監控，不要等它默默壞掉才知道。

最值得抄的骨架，其實很土：trigger、enrich、decide、route

如果把產品話術全部拿掉，我一直回到的骨架其實很普通，而且普通得很有用。大多數真的能用的 AI automation，都長得差不多：先有事件發生，再補上下文，接著讓模型幫忙決策，最後把結果路由到有用的地方。我很希望更多工具廠商直接把這件事講白，不要一直包在漂亮詞彙裡。

Make 之所以好用，是因為它讓你不用為每一條 workflow 重寫一個完整服務。這不代表你永遠不需要 code，只是你可以先做很多事，等真的需要時，再把 code 放在邊緣，而不是整條重建。這個差別很大。

如果是我帶團隊，我會這樣做：從 source system 接 trigger，補齊 AI 需要的 context，用嚴格的輸出規格跑 AI step，根據 confidence 或 classification route 到不同目的地，最後把每次結果都 log 起來。這就是核心。其他東西，不是裝飾，就是例外處理。

實操寫法：把 Make 當 orchestration layer，不要把它變成所有 business rule 的垃圾桶。AI 呼叫要窄，routing 要明確，輸出要結構化。這樣你拿到的會是可維護的 automation，不是只在 demo 時很帥的東西。

可抄的模板

## Make AI workflow template（可直接改成你的版本）

### 目標
把一個真實業務流程做成：一個 AI 步驟 + 明確分支 + 失敗回退。

### 骨架
1. Trigger：來源系統有新事件進來。
2. Enrich：抓 AI 需要的額外上下文。
3. AI step：送出範圍很窄的 prompt 或 task。
4. Validate：檢查輸出格式與可信度。
5. Route：依結果送到對應目的地。
6. Log：保存 input、output、decision path。
7. Fallback：把不確定或壞掉的案例送人工。

### Scenario 結構
- Trigger module：webhook / watch new item / scheduled run
- Data fetch module：查 customer、ticket、order、document context
- AI module：classify / summarize / extract / draft / decide
- Parse module：把 AI 輸出整理成結構化欄位
- Router module：
  - confidence 高且格式正確 → 自動處理
  - confidence 中等 → 送審核
  - confidence 低或格式錯誤 → 送 fallback
- Destination module：更新 CRM / 建立 ticket / 發 Slack / 寫資料庫
- Logging module：存 scenario ID、input、output、status、timestamp

### Prompt 形狀
你是自動化流程中的一個步驟。
只回傳結構化輸出。
如果任務不確定，請清楚標示。
如果輸入不完整，請列出缺少什麼。

### 範例輸出
{
  "status": "auto|review|fail",
  "confidence": 0.0,
  "summary": "short result",
  "reason": "why this route was chosen",
  "missing_fields": []
}

### 建置規則
- 一條 workflow 只處理一個 outcome。
- 不要把 business logic 埋進 prompt。
- 每個 AI response 都要先驗證，再路由。
- 不確定的 case 一律保留人工審核分支。
- failure 要記錄足夠資訊，方便重跑。
- 一旦流程很難用一句話講完，就拆成兩條。

### 團隊檢查表
- [ ] Trigger 已定義
- [ ] Input schema 已知
- [ ] AI output format 很嚴格
- [ ] 驗證機制存在
- [ ] 分支很明確
- [ ] Fallback path 存在
- [ ] Logging 已啟用
- [ ] Owner 已指定

### 適合的場景
- Ticket triage
- Lead enrichment
- Content classification
- Invoice parsing
- Internal request routing
- 需要人工審核的 draft generation

### 不適合的場景
- 沒有 review step 的開放式創作
- 沒有 validation 的關鍵決策
- 每一步都需要大量客製 business logic 的流程

這篇拆解的原始來源是 Make 官方首頁：https://www.make.com/en。上面那份模板是我把它的視覺化自動化思路，改寫成台灣開發者比較能直接拿去用的版本，不是照抄行銷文案。

如果你想對照工具本身，我也建議直接看 Make Help Center、Make integrations，以及常會一起串的 OpenAI 和 Notion。我這篇是原創拆解，模板是衍生整理。