M06.09｜No-Code AI 的限制與天花板
拖拉點選能做到 80 分，剩下 20 分還是需要工程師
本講學習重點
客製化限制：No-Code 只提供廠商預設的功能邊界，獨特需求難以實現
效能天花板：高並發、大資料量、低延遲需求，No-Code 平台難以應對
供應商鎖定：工作流程、資料、設定深度依賴特定平台，轉移成本極高
擴展性限制：隨著規模增長，No-Code 的管理複雜度和費用可能失控
技術債：No-Code 累積的隱性技術債與程式碼技術債同樣真實
畢業時機：需求超出平台能力、或規模大到自建更划算時
最佳實踐：No-Code 用於快速驗證，工程師開發用於規模化
🎙️ Podcast（中文）
一句話搞懂
No-Code AI 工具就像租用一間設備齊全的辦公室——入住快、維護省心，但你不能敲牆、不能改格局，房間大小是固定的；當你的業務需要一棟量身打造的大樓時，就需要找建築師（工程師）自己蓋了。
白話解說
No-Code 的真實天花板：不是工具不好，是設計使然
No-Code AI 工具的流行，讓許多人誤以為「以後工程師可能不需要了」。這個想法既高估了 No-Code 工具的能力，也低估了工程師解決複雜問題的不可替代性。No-Code 工具的限制不是因為廠商不夠努力，而是任何「讓所有人都能用」的工具，必然要在「彈性」和「易用性」之間做出取捨。廠商選擇了易用性，因此在彈性上有所犧牲——這是設計哲學的必然結果，不是 Bug。
理解 No-Code 的天花板，才能做出正確的工具選擇，而不是在錯誤的工具上浪費時間和資金。
限制一：客製化的邊界
每個 No-Code 平台都有一個「功能邊界」——它提供了一組預設的積木，你可以自由組合，但只能用這些積木。當你的需求恰好在這些積木能覆蓋的範圍內，No-Code 非常高效；一旦你的需求超出邊界，你就會撞牆。
舉個具體的例子。假設你用 Bubble（一個 No-Code 網頁應用開發工具）建立了一個客戶管理系統。系統運作得很好，直到有一天業務需求要求：「我需要根據客戶的購買歷程，用一套複雜的動態計分邏輯即時計算每個客戶的優先級，這個邏輯需要整合我們內部的機器學習模型輸出。」Bubble 提供的工作流程邏輯無法支援這種複雜的動態計算，更無法直接調用外部 ML 模型。這時候，你要麼繞路（設計讓邏輯看起來可行但其實是變通方案）、要麼放棄這個需求、要麼開始考慮自行開發。這個「撞牆」的時刻，在越複雜的業務中出現得越頻繁。
限制二：效能天花板
No-Code 平台為了服務廣大使用者，通常在底層架構上做了許多「一般性」的決策，而不是針對你的特定使用情境優化。這在業務規模小的時候感受不明顯，一旦業務規模擴大，效能問題就開始浮現。
常見的效能瓶頸表現：高並發（Concurrency）——當你的應用同時有幾百或幾千個使用者，No-Code 平台的處理能力可能遠低於自行優化的後端；大資料量——當你的資料庫有幾百萬筆紀錄，某些 No-Code 平台的查詢速度會顯著下降；即時性需求——當應用需要每秒處理大量資料（如物聯網設備資料流、高頻交易類應用），No-Code 平台的延遲通常無法達到要求。
以 Airtable 為例：對一個小型團隊管理幾千筆資料，Airtable 非常好用；但當一家中型企業試圖把 Airtable 當作核心資料庫、存放幾十萬筆資料並讓全公司 300 個人同時使用時，反應速度和限制就會讓人抓狂。
限制三：供應商鎖定（Vendor Lock-in）
當你把所有業務流程、資料和邏輯都深度建立在某個 No-Code 平台上，你就對這個廠商產生了強烈的依賴性。供應商鎖定的風險包括：
漲價風險：平台調整定價策略（這在 SaaS 業界相當常見），你幾乎沒有談判籌碼，要麼接受、要麼花昂貴的成本遷移。Zapier 就曾多次調整定價，讓重度依賴的使用者措手不及。
功能廢棄風險：平台決定停止提供某個你核心依賴的功能，或整個平台關閉（尤其是規模較小的 No-Code 新創），你的整個業務應用可能需要從頭重建。
資料遷移困難：你的資料格式、工作流程邏輯、和資料之間的關聯，通常是平台專有格式儲存的，遷移到另一個平台或自建系統需要大量的工程工作。
評估建議：在選擇 No-Code 平台之前，先問：這個廠商有提供「資料匯出」功能嗎？匯出的格式是通用格式（如 CSV、JSON）還是私有格式？如果這個平台明天消失，我需要多少成本才能重建？
限制四：技術債的隱性累積
「技術債（Technical Debt）」在傳統軟體開發中是指：為了快速推出而做的設計折衷，留下了未來需要花時間修復的問題。No-Code 環境下，技術債同樣真實存在，只是形式不同。
工作流程蔓延（Workflow Sprawl）：隨著時間推移，公司在 Zapier 或 Make 上建立了幾百個工作流程，很多已經沒有人知道是做什麼的、有沒有在用。這些「孤兒流程」消耗授權費用，也可能在安靜地出錯而沒有人察覺。
邏輯碎片化：業務邏輯分散在 Airtable 公式、Zapier 流程、Bubble 工作流程、和 Google Sheets 的 Apps Script 中，沒有任何一個地方有全貌。當需求改變時，需要在五個地方同時修改，且很容易遺漏。
缺乏版本控制和測試：傳統程式碼可以用 Git 做版本控制，可以寫自動化測試。No-Code 工具通常沒有這些機制，一個誤操作可能在幾秒內破壞整個工作流程，且難以回溯。
何時應該「從 No-Code 畢業」？
以下是幾個明確的信號，提示你的業務需求已經超出 No-Code 的合理應用範圍：
- 你在 No-Code 工具上花費了超過三個月試圖實現一個需求，仍然只有「差不多」的效果
- 平台的月費已超過一位初級工程師薪資的 30%（此時自建可能更划算）
- 你的核心業務流程中有超過五個「如果平台失效就停擺」的關鍵依賴點
- 使用者投訴應用速度慢或功能不符需求的頻率越來越高
- 你有一個 No-Code 工具完全不支援的技術需求（例如：訓練自己的機器學習模型）
「從 No-Code 畢業」不是失敗，而是業務成功增長的必然結果。最佳策略是：用 No-Code 快速驗證商業假設，當假設被驗證且規模擴大後，用工程師重新建立更穩固的自建系統。
應用場景
| 需求類型 | No-Code 能力 | No-Code 限制 | 建議做法 |
|---|---|---|---|
| 內部流程自動化（低頻、低並發） | 完全勝任 | 幾乎無限制 | 直接用 No-Code |
| 客戶面向應用（中等流量） | 部分勝任 | 高並發下效能下降 | No-Code 原型 + 評估是否自建 |
| 自定義 AI 模型訓練 | 無法實現 | 根本限制 | 必須工程師介入 |
| 複雜業務邏輯（多條件、多例外） | 勉強實現 | 維護困難、邏輯碎片化 | Low-Code 或自建更合適 |
| 大規模資料處理（百萬筆以上） | 效能不足 | 查詢速度、API 限制 | 自建資料管線 + No-Code 前端 |
| 監管合規需求（資料在地化、審計軌跡） | 有限支援 | 依賴廠商設定 | 自建或企業版 No-Code |
| 快速 MVP 驗證（1-4 週上線） | 完美場景 | — | 首選 No-Code |
| 跨系統深度整合（5 個以上系統） | 部分可行 | 複雜度增加後難以維護 | iPaaS + 部分自建 API |
常見誤區
誤區 1：「No-Code 工具夠便宜，比請工程師划算多了」
這個比較在初期通常是對的，在中長期往往是錯的。計算 No-Code 的真實成本時，需要納入：使用者授權費 × 人數、每月操作執行次數費、儲存費、進階功能的 Add-on 費。當使用規模擴大，這些費用以乘法成長。一個中型企業使用 Zapier 企業版 + Airtable 商業版 + Bubble 商業版的月費，可能已足以聘用一名全職開發人員。此外，No-Code 工具有「人工維護成本」——某個業務人員花在管理和除錯 No-Code 工作流程上的時間，也是真實的人力成本，只是從薪資帳目上「消失」了而已。做決策時應該計算「總擁有成本（Total Cost of Ownership）」，而不只是月費。
誤區 2：「No-Code 建立的應用不是真的軟體，不用擔心資安問題」
No-Code 平台建立的應用同樣運行在網路上、同樣處理使用者資料，因此面臨所有傳統軟體應用的資安風險。常見的 No-Code 資安問題：權限設定錯誤（Airtable 資料庫設定不當讓外部使用者看到所有紀錄）、API 金鑰保管不當（直接把 OpenAI API Key 寫在 Zapier 工作流程的明文欄位中）、缺乏輸入驗證（沒有對使用者輸入做過濾，導致資料注入問題）。No-Code 工具雖然降低了開發門檻，但它不會自動幫你做好資安設計。使用 No-Code 工具時，資安責任仍然在使用者身上，需要主動了解平台的安全設定和最佳實踐。
誤區 3：「No-Code 工具發展這麼快，以後所有事情都能做到」
No-Code 工具確實每年都在進步，功能越來越強大。但有一些技術需求是結構性的，不會因為工具進步而消失。第一，底層演算法和模型訓練：No-Code AutoML 工具（如 Google AutoML、CreateML）大幅降低了模型訓練的門檻，但對於需要高度客製化損失函數、複雜模型架構、或在私有資料上訓練的情境，工程師的介入仍然不可或缺。第二，系統整合的深度：把 AI 能力深度整合進複雜的遺留系統（Legacy System），需要理解各種協議、資料格式和架構模式，這遠超出 No-Code 工具的能力邊界。第三，效能優化：No-Code 工具為了通用性犧牲了部分效能，這個取捨是架構上的，不會隨著工具進步而消失——只有工程師才能針對你的特定需求做底層優化。
小練習
練習 1：判斷 No-Code 的邊界
以下是五個企業想用 No-Code 工具實現的需求。請判斷每個需求「完全適合 No-Code」、「勉強可行但有限制」、或「需要工程師介入」，並說明原因：
| 需求 | 你的判斷 |
|---|---|
| A. 用 Zapier 把 Google Form 的回覆自動整理到 Notion 資料庫 | ？ |
| B. 用 No-Code 平台建立一個即時競爭對手監控系統，每分鐘掃描 100 個網站的價格 | ？ |
| C. 用 Bubble 建立一個內部員工請假管理系統（每天約 50 人使用） | ？ |
| D. 用 No-Code AutoML 訓練一個能辨識你公司特定產品瑕疵的視覺 AI 模型（瑕疵類型有 50 種，每種需要 5,000 張訓練圖片） | ？ |
| E. 用 Make 建立一個當客戶在 CRM 狀態改變時，自動傳送個人化 Email 的流程 | ？ |
查看答案
**A. 完全適合 No-Code** 這是 Zapier 的典型使用情境：事件觸發（Form 提交）→ 動作（寫入 Notion），步驟簡單、資料量不大、無複雜邏輯。建立時間可能只需 30 分鐘。 **B. 需要工程師介入** 「每分鐘掃描 100 個網站」涉及大規模網頁爬取、處理各種反爬蟲機制（CAPTCHA、動態 JavaScript 渲染）、以及高並發的排程任務。這超出了 No-Code 整合平台的設計範圍，需要自行部署爬蟲基礎設施（如 Scrapy + 分散式排程）。即使強行用 No-Code 工具，也會面臨速率限制和穩定性問題。 **C. 完全適合 No-Code** 50 人/天的內部應用、固定的業務邏輯（申請 → 主管審核 → 核准/退回 → 通知）、資料量不大。Bubble 或 AppGyver 都能完整實現，且建立速度遠快於自行開發。注意要做好權限設定（員工只能看到自己的請假紀錄）。 **D. 勉強可行但有限制** Google Cloud AutoML Vision 等工具確實可以在相對低的技術門檻下訓練視覺模型。但 50 種瑕疵類型 × 5,000 張/種 = 25 萬張訓練圖片，涉及大量資料標記工作（這需要人力規劃），且模型的準確率、推理速度和部署彈性可能不如自行訓練的模型。**建議**：先用 No-Code AutoML 驗證「AI 視覺檢測」這個方向是否可行，如果效果達到要求，維持 No-Code；如果發現需要更高準確率或需要在本地設備（Edge Device）上執行，再考慮工程師自訓模型。 **E. 完全適合 No-Code** Make 的核心使用情境。CRM 狀態變化可作為 Webhook 觸發點，根據不同狀態用條件邏輯選擇不同的 Email 模板（或呼叫 AI API 生成個人化內容），再透過 Email 服務傳送。這是 No-Code 整合平台的最佳應用場景之一。練習 2：技術債評估與決策
一家新創公司兩年前在資金有限的情況下，全面採用 No-Code 工具快速搭建了業務系統：
- 客戶管理：Airtable（目前有 80,000 筆客戶紀錄）
- 業務自動化：Zapier（目前有 240 個 Zaps）
- 客戶門戶：Bubble（每天 500 個客戶登入）
- 月費用合計：約 NT$150,000/月
現在公司成長到 50 人，開始面臨以下問題：
- Airtable 在查詢複雜篩選時反應緩慢（3-5 秒）
- 有 30% 的 Zapier Zaps 已沒人知道是做什麼的、是否還在用
- 客戶抱怨 Bubble 應用在手機上反應慢
- 業務需求提出一個 Bubble 完全無法實現的功能
請分析：這個公司面臨哪些技術債問題？應該怎麼處理？是應該繼續優化 No-Code，還是開始引入工程師自建系統？