M06.08｜整合與 API 串接：讓 AI 工具跟現有系統對話
AI 再強，不能跟 ERP 和 CRM 串接就是孤島
本講學習重點
API：應用程式之間的標準通訊介面，如餐廳服務生傳遞訂單
REST API：GET（取資料）、POST（新增）、PUT（更新）、DELETE（刪除）
Webhook：事件發生時主動推送通知，不需要輪詢（Push vs Pull）
Zapier：No-Code 整合，超過 7,000 個 App 連接，適合個人和中小企業
Make（前 Integromat）：視覺化流程設計，支援更複雜的邏輯和資料轉換
n8n：開源自架，適合有技術能力但想省授權費的團隊
常見整合模式：CRM+AI 客戶洞察、ERP+AI 異常偵測、Email+AI 分類
🎙️ Podcast（中文）
一句話搞懂
API 就是讓不同軟體系統互相說話的「共同語言」——有了 API，你的 AI 工具才能讀取 CRM 裡的客戶資料、把分析結果寫回 ERP、或是在客戶下單的瞬間自動觸發後續流程。
白話解說
API 是什麼：餐廳服務生的比喻
想像你走進一間餐廳。廚房在後面，你坐在前台。你不能直接走進廚房告訴廚師你要什麼（系統安全和秩序的考量），也不需要懂得如何料理——你只需要把需求告訴服務生（API）：「我要一份牛排，五分熟，不加醬。」服務生把你的需求傳達給廚房（後台系統），廚房做好之後，服務生把餐點送回你的桌上。
API（Application Programming Interface，應用程式介面）就是軟體世界裡的服務生。它定義了：一個系統可以接受什麼樣的「點餐」（Request）、每種點餐需要提供哪些資訊（Parameters）、系統會回傳什麼樣的「料理」（Response）。不管是前端網頁、手機 App，或是另一個後端系統，只要按照 API 的規格「點餐」，就能取得服務，而完全不需要了解背後的系統怎麼運作。
這就是為什麼 API 是現代軟體整合的基礎：它讓不同公司、不同技術棧的系統能夠互相溝通，而不需要修改任何一方的內部程式碼。
REST API：現代系統整合的通用語言
目前最主流的 API 設計風格是 REST（Representational State Transfer）。你不需要深入理解它的學術定義，只需要知道 REST API 的四個基本操作，對應到日常的資料操作：
| HTTP 方法 | 操作 | 日常比喻 |
|---|---|---|
| GET | 取得資料 | 「查詢」——問服務生今天的菜單 |
| POST | 新增資料 | 「下單」——告訴服務生我要點什麼 |
| PUT / PATCH | 更新資料 | 「改單」——我剛才點的牛排改成七分熟 |
| DELETE | 刪除資料 | 「取消」——不好意思那份牛排不要了 |
每個 API 操作都有一個 URL（端點，Endpoint） 指定要操作的資源，例如 https://api.crm.com/customers/12345 代表「客戶 ID 12345 的資料」。一個 GET 請求到這個 URL 就會回傳這位客戶的資訊；一個 PUT 請求則可以更新他的資料。
對 No-Code 使用者來說，不需要自己寫 HTTP 請求的程式碼——Zapier、Make 等工具已經把這些封裝成圖形介面操作了。但理解 REST API 的基本概念，有助於在遇到問題時能正確診斷和溝通。
Webhook：讓系統主動來找你
傳統的資料同步方式是輪詢（Polling）：你的系統每隔一段時間（例如每五分鐘）主動問另一個系統「有沒有新資料？」。這就像每五分鐘打一次電話問「我的包裹到了嗎？」——大多數時候答案都是「還沒」，浪費了大量資源。
Webhook 反轉了這個邏輯：你事先在另一個系統登記「當事件 X 發生時，請打電話通知我」。當事件真的發生時（例如：客戶下了一筆新訂單、GitHub 有新的程式碼推送、或是表單有人填寫），系統主動向你指定的 URL 發送通知，就像快遞送達時主動簡訊通知你，而不需要你不斷追蹤。
Webhook 在 AI 整合中非常重要。典型的場景：客戶在官網填寫詢問表單 → 表單系統透過 Webhook 立即通知整合平台 → 整合平台觸發 AI 分析客戶需求 → AI 結果自動寫入 CRM 並指派給業務 → 整個流程在幾秒內完成，完全無需人工介入。
No-Code 整合平台：Zapier vs Make
對沒有工程師的團隊來說，整合平台（iPaaS, Integration Platform as a Service） 是讓 AI 工具連接現有系統的最快途徑。
Zapier 是市場上最知名的整合平台，強調「任何人都能在五分鐘內串接兩個 App」。它預建了超過 7,000 個 App 的連接器（包括 ChatGPT、Salesforce、Gmail、Slack、HubSpot 等），透過「觸發事件 → 執行動作」的兩步驟邏輯（稱為 Zap），讓即使完全不懂技術的使用者也能建立自動化流程。它的限制是：複雜的邏輯分支、資料轉換和多步驟流程在 Zapier 上會變得笨拙，且每個 Zap 的執行次數費用累積起來可能不低。
Make（前身 Integromat） 走視覺化工作流程設計的路線。它的介面看起來更像一張流程圖：每個「模組」代表一個操作，模組之間用箭頭連接，可以設計複雜的分支邏輯、資料過濾、和迭代處理。Make 特別適合需要做資料轉換（例如把 JSON 資料重新格式化後再傳給另一個 API）的情境。它的定價以「操作次數」計費，比 Zapier 更具彈性。
n8n 是開源的整合平台，可以自己架設在伺服器上，沒有按次收費的壓力，適合有一點技術能力但想節省授權費用的中小型技術團隊。
把 AI 能力注入現有系統：常見整合模式
有了 API 概念和整合平台後，以下是幾個讓 AI 真正融入工作流程的典型串接模式：
CRM + AI 客戶洞察：每當 CRM（如 HubSpot、Salesforce）收到新的客戶服務工單，自動把工單內容傳給 AI（如 OpenAI API），讓 AI 分析問題類型、客戶情緒、緊急程度，再把分析結果寫回 CRM，作為優先順序排序和指派的依據。業務人員打開工單時就能看到 AI 已整理好的摘要。
ERP + AI 異常偵測：ERP 系統每天匯出庫存或財務資料，AI 模型分析後如果發現異常（庫存跌破安全水位、費用異常暴增），自動透過 Slack 或 Email 通知相關主管，並附上 AI 的初步分析。
Email + AI 自動分類與回覆：新 Email 到達時，透過 Webhook 觸發 AI 分析郵件主旨和內容，自動分類、加標籤，對於標準問題生成 AI 草稿回覆，再讓客服人員一鍵確認送出。
應用場景
| 整合場景 | 觸發點 | AI 功能 | 目標系統 | 工具選擇 | 效益 |
|---|---|---|---|---|---|
| 客服 Email 智慧分類 | 新 Email 到達（Webhook） | AI 分類問題類型 + 情緒分析 | Zendesk / Freshdesk CRM | Zapier + OpenAI | 分類速度從人工 30 分鐘到即時 |
| 社群留言自動監控 | 新留言發布（Webhook） | AI 偵測負評或危機訊號 | Slack 通知 + 電商後台 | Make + Claude API | 品牌危機發現時間從數小時縮至分鐘 |
| 銷售提案自動個人化 | CRM 新潛客建檔（Trigger） | AI 根據客戶資料生成個人化提案草稿 | Google Docs + Email | Zapier + GPT-4 API | 提案準備時間從 2 小時縮至 15 分鐘 |
| 會議紀錄自動整理 | 會議結束（Zoom Webhook） | AI 轉錄 + 摘要 + 行動項目提取 | Notion / Confluence | Make + Whisper API | 會議紀錄整理從 45 分鐘縮至即時 |
| 庫存異常警示 | ERP 每日資料同步（排程） | AI 分析庫存趨勢，預測缺貨風險 | Line / Slack 通知 | n8n + 自訂模型 | 缺貨事件提前 5-7 天預警 |
| 合約審核輔助 | 新合約上傳（檔案 Webhook） | AI 擷取關鍵條款、標記異常條款 | 內部審核系統 + Email | Make + Claude API | 法務初審時間從 1 天縮至 2 小時 |
常見誤區
誤區 1：「只要有 API 就能串接，整合很簡單」
API 存在是整合的必要條件，但不是充分條件。真正的整合挑戰往往不在技術層面，而在資料語義層面。例如：你的 CRM 裡「客戶名稱」欄位儲存的是公司名稱，但 ERP 裡同樣的資料卻叫「法人名稱」而且格式不同（CRM 存「台積電」，ERP 存「台灣積體電路製造股份有限公司」）。兩個系統都有 API，但要讓資料正確對應，需要寫轉換規則。此外，還有身份驗證（如何取得 API 金鑰並安全儲存）、錯誤處理（API 呼叫失敗時怎麼辦）、速率限制（API 每分鐘最多允許多少次呼叫）等技術細節。「有 API 就能串接」在概念上沒錯，但在實務上低估了整合工程的複雜度。
誤區 2：「用 Zapier 串接就不需要考慮資料安全」
Zapier 和 Make 這類整合平台，在幫你傳遞資料的過程中，你的業務資料確實會經過他們的伺服器。如果你串接的是包含個人資料（姓名、Email、電話、身份證號）、財務資訊、或商業機密的工作流程，就必須確認：整合平台是否符合你所在產業的資料合規要求（GDPR、個資法、金融業相關法規）？資料在傳輸過程中是否加密？整合平台的資料保留政策是什麼（你的資料在他們的伺服器上保留多久）？對資料敏感度高的企業，自架 n8n 或使用企業版整合平台的私有雲部署，可能比使用公共 SaaS 整合平台更合適。
誤區 3：「整合平台搭建好之後就不需要維護」
整合工作流程是依賴各個外部 API 的連接而運作的，一旦任何一端的 API 發生變化（版本升級、端點廢棄、身份驗證機制更改），整合流程可能靜悄悄地失效——而且通常是在最需要它運作的時候才被發現。整合流程和軟體一樣，需要定期監控和維護。 良好的整合系統應該包含：失敗通知機制（流程執行錯誤時立即通知負責人）、定期測試（每週或每月驗證關鍵流程仍正常運作）、以及文件記錄（每個流程的目的、觸發條件、和依賴的外部系統）。否則幾個月後沒有人記得某個關鍵流程的運作邏輯，問題發生時也找不到根因。
小練習
練習 1：API 概念理解測驗
一家線上書店開放了以下 API。請根據 HTTP 方法，判斷以下操作應該使用哪個方法，並說明原因：
| 操作 | 你的答案 |
|---|---|
| 查詢書籍 ISBN 9789861342314 的詳細資訊 | ？ |
| 客戶在購物車結帳，新增一筆訂單 | ？ |
| 客戶將訂單的收貨地址從台北改為台中 | ？ |
| 客戶取消了一筆尚未出貨的訂單 | ？ |
| 查詢所有「科幻類」書籍的清單 | ？ |
查看答案
| 操作 | HTTP 方法 | 原因 | |------|---------|------| | 查詢 ISBN 書籍詳細資訊 | **GET** | 只是「讀取」現有資料，不修改任何東西 | | 客戶結帳，新增訂單 | **POST** | 在系統中「新增」一筆原本不存在的訂單記錄 | | 修改收貨地址 | **PUT 或 PATCH** | 「更新」已存在的資料；PUT 通常用於完整替換，PATCH 用於部分更新單一欄位 | | 取消訂單 | **DELETE** | 「刪除」或使一筆記錄失效（有些系統用軟刪除，但語義上是 DELETE）| | 查詢科幻類書籍清單 | **GET** | 同樣是「讀取」，只是附帶了篩選條件（category=sci-fi 作為 query parameter）| **補充說明**：GET 操作是「安全且冪等」的——呼叫一次或呼叫一百次，對系統的狀態沒有影響。POST 每次呼叫都會產生新的資源（呼叫兩次會建立兩筆訂單）。在設計 API 整合時，了解這些特性有助於正確處理「重試邏輯」——GET 失敗可以安全重試，POST 失敗需要先確認是否已建立成功，再決定是否重試。練習 2：設計整合流程
一家中型人力資源顧問公司想要建立以下的自動化流程：
目標：當公司網站的「職缺應徵表單」有人填寫時，自動讓 AI 分析應徵者的履歷（表單附件），生成「資格符合度摘要」，然後通知 HR 人員並把分析結果記錄到 Google Sheets。
已知條件：
- 表單工具：Typeform（支援 Webhook）
- AI 服務：OpenAI API（可分析文字）
- 通知工具：Slack
- 記錄工具：Google Sheets
- 技術能力：HR 團隊無工程師背景，但有基本電腦能力
請設計這個整合流程：使用哪個整合平台？整個流程的步驟是什麼？每個步驟做什麼事？