LowCode 本來是給誰用的？
先把歷史拉清楚。LowCode / NoCode 的源頭，來自 Salesforce 生態系的 workflow builder，目的是讓業務人員在不打擾工程團隊的情況下，自己做簡單的提醒、自動化通知。後來 Zapier、IFTTT、Make（前身 Integromat）、n8n 沿著這條路線發展。
這些工具的甜蜜點（sweet spot）很明確：
- 個人工作者：Gmail 分類、Notion 同步、Slack 通知
- 中小新創 MVP：快速驗證概念，通常三個月內會重寫
- 行銷 Ops：Facebook Lead → HubSpot → Slack 提醒業務
這些場景有共通點：都不是關鍵業務、都不碰底層系統、都能容忍偶爾出錯。
問題是，過去三年台灣 B2B 市場被 LowCode 廠商洗腦式行銷。講師開班教「人人都能 automation」、廠商 YouTube 廣告鋪天蓋地、LinkedIn 貼文瘋傳「不用工程師也能做自動化」。結果一堆中型企業把 SAP 周邊、ERP 資料流、財務對帳這類生死攸關的流程，也交給了 LowCode 工具。
這就是出事的開始。
6 個工程理由：為什麼 LowCode 不該碰關鍵業務
客戶資產被廠商綁架
你用 Make.com 做了 50 個 scenarios，每個 scenario 的邏輯都存在廠商的資料庫裡。廠商的商業決策你無法掌控：哪天他們改名（Integromat → Make.com 那波漲價記憶猶新）、調漲定價、被併購、甚至倒閉，你的自動化邏輯瞬間變成廢紙。
這不是極端情境。LowCode 市場過去五年死過 Tray.io 早期版本、IFTTT Pro 強制收費、Workato 大幅調整方案等等。你的業務 SOP 被寫在別人的資料庫，就是一種低調的資產抵押。
Python程式碼 100% 客戶持有，Git 版控，永久資產
SAP 深度整合的物理限制
這是最致命的一點。LowCode 工具的「SAP 整合」，99% 只支援 OData 或 HTTP API endpoint。但任何做過 SAP 整合的工程師都知道，B2B 生產環境真正要打的 SAP 介面是：
- SAP GUI Scripting：SAP 原廠提供的合法腳本介面，透過 SAPGUI 以合法帳號登入執行標準交易（ME2N / CO41 / CS11 / CO02 等）。需 BASIS 於 RZ11 開啟
sapgui/user_scripting=TRUE。這是現場 SAP 自動化最實用、最廣覆蓋的路線。 - BAPI：走 RFC 協定，是 SAP 官方封裝的業務函式，常與 Python 的 PyRFC 搭配
- IDoc：EDI 格式訊息，跨系統標準整合
- RFC（Remote Function Call）：SAP 原生呼叫協定
這些 LowCode 工具裡幾乎都沒有。n8n 有社群做了半套 SAP node，但只支援基本的 OData。想用合法帳號自動跑 ME2N / CO41 標準交易？做不到。想做月結自動化、財務對帳？卡死。
Python原生支援 SAP GUI Scripting（需 BASIS 開啟）、PyRFC、BAPI、IDoc，關鍵業務能打
擴充性的天花板
每個 LowCode 平台都有 module marketplace，看起來很豐富。但實際上 module 的開發速度由廠商決定，不是你。
實際情境：客戶要串某個冷門的 SaaS（例如台灣本土的 ERP、POS、會計軟體），marketplace 沒有。你只能：
- （A）等廠商開發（等不到）
- （B）自己寫「Custom Code Node」（於是你發現你其實在寫 JavaScript）
- （C）放棄這個 scenario
走到 B 的時候，諷刺的事情發生了——你在 LowCode 平台裡面寫 code，只為了繞過 LowCode 的限制。那為什麼不直接寫 Python 就好？
Python通用語言，任何 API、任何協定都能串
廠商黑盒 + Debug 地獄
生產環境出錯，最恐怖的是你看不到內部到底怎麼了。
正常 Python 程式出 bug：看 stack trace、看 log、看變數、三分鐘定位。
LowCode 平台出 bug：看 execution history（通常只給最近 30 天）、看廠商有限的 log 視圖、發 ticket 等廠商技術支援。
真實案例：某公司用 Make.com 做月結自動化，某天 scenario 突然停了，log 只顯示 "Error 500"，等廠商 ticket 回 72 小時。當月財務月結延遲，老闆震怒。
把公司管理神經系統的除錯權限交給一個你永遠打不通電話的新創公司，這不叫自動化，這叫自我麻痺。
Python程式碼開放、日誌完整、三分鐘定位
總持有成本比帳面高很多
雲端 LowCode 的定價策略很狡猾：入門便宜、擴展致命。
- 剛用：每月 $29，「啊這比請工程師便宜太多了」
- 三個月後：資料量上來，connector 數超限，$200/月
- 一年後：scenario 數限制、operation limit、資料傳輸量 → $1,500/月
- 兩年後：發現某個關鍵 integration 在免費/低階版已被砍，被迫升級 → $5,000/月
這時回頭算：兩年花了 $10 萬美元（台幣 320 萬）做一些自動化。同樣的邏輯如果用 Python 一次開發、本機執行，總成本不到 50 萬台幣，而且是永久的。
「那我用 n8n 自架，不就沒有月費？」——看起來如此，但換來的是另一種隱性成本。n8n 自架版需要你自己管伺服器或 Docker 環境、追安全漏洞、手動升級版本，出問題靠社群論壇，沒有技術支援 SLA。n8n 版本迭代快，breaking change 並不罕見，工作流可能需要整批重測。對企業生產系統而言，這是把 DevOps 維運壓力換掉月費帳單——成本換位，不是成本消失。
n8n 自架版無月費，但需 DevOps 維運、自行修補安全漏洞、SLA 為零
Python 本機一次開發、長期使用，無月費、無廠商依賴、程式碼 100% 客戶持有
DSL 綁死，換平台就要重寫
n8n 的 workflow JSON、Make 的 scenario blueprint、Zapier 的 Zap 設定檔——三家格式互不相通。
當你最終決定要遷出的時候，不管是因為廠商倒閉、漲價、還是你終於悟了，你會發現：
- 過去三年累積的所有 workflow 邏輯，要從頭重建
- 業務人員學的平台操作知識，要從頭再學新的
- 沒有遷移工具，沒有 export-and-import 標準
對比 Python：無論你放在 AWS、GCP、Azure、客戶機房、筆電，程式碼都一樣跑。這就是標準技術的複利。
Python標準語言，任何平台都能跑，永久資產
那 LowCode 什麼時候用才對？
✅ 這些場景，LowCode 真的好用
- 個人工作流：Gmail 自動歸檔、Notion 頁面同步、Slack 提醒
- 中小新創 MVP：三個月內會重寫的 hack，先跑起來再說
- 輕量行銷 Ops：Facebook Lead → CRM → Slack 通知（不碰核心業務）
- 個人知識管理：RSS → Readwise → Notion
- 跨 SaaS 小水管：Calendly 預約自動建立 Zoom 連結
這些場景有共通點：容忍偶爾錯、錯了業務不會倒、不需要資安稽核、資料量小。這是 LowCode 該待的地方。
對 B2B 關鍵業務的工程建議
三個「如果」，有一個中就不該用 LowCode
- 如果你的自動化一個月要跑上萬次——不用 LowCode（成本會滾雪球）
- 如果流程要碰 SAP / Oracle / 自建 ERP——不用 LowCode（深度整合做不到）
- 如果系統要穩定跑 3 年以上——不用 LowCode（廠商風險太高）
那替代方案是什麼？
Python + Claude Code 是 2026 年的正確答案
過去 LowCode 能贏 Python 的理由只有一個：寫程式學習曲線太陡。但 2025 年之後，Claude Code 這類 AI coding 工具出現，改寫了整個遊戲規則。
現在用 Claude Code 寫 Python 自動化，速度已全面超越 LowCode 拖拉，而得到的是：
- 可版控（Git）
- 可稽核（code review）
- 可測試（pytest）
- 永久資產（任何平台都能跑）
- 無限擴展（Python 生態系是所有程式語言中最豐富的）
這不是理論。我們自己所有的客戶產品，從 SAP 線外系統、憑證分類、租約管理、到記帳查帳工具，全部都是 Python + Claude Code 寫的。沒有一行 n8n、沒有一行 Make、沒有一行 Zapier。
SAP 環境遇上 LowCode：為什麼第一步就卡死
不需要案例——從技術規格就能直接判斷。
台灣大多數製造業用的 SAP，都是 ECC 6.0 時代的環境（EHP4 ~ EHP8），不是 S/4HANA 雲端版。LowCode 工具的 SAP 模組，設計基礎是針對 S/4HANA OData V2/V4 REST API——這是 SAP 現代雲端版才有的協定。
ECC 6.0 的標準自動化路線是：
- SAP GUI Scripting：透過 SAPGUI 以合法帳號登入執行標準交易，需 BASIS 於 RZ11 開啟
sapgui/user_scripting=TRUE - RFC / BAPI：SAP 原生函式呼叫協定，Python 側搭配 PyRFC
- IDoc：跨系統 EDI 訊息格式
這些協定，Make、n8n 的 SAP 模組完全碰不到。在 ECC 環境打開 Make 的 SAP 模組，根本找不到入口。想自動跑 ME2N / CO41 / CS11？做不到。想做財務月結、生產排程抓單自動化？第一步就卡死。
這不是 LowCode 工具設計不好——是架構完全不對路。用 HTTP REST client 去開一扇不是 REST endpoint 的門，不是效果差，是根本敲不到。
Python + SAP GUI Scripting 才能打到這一層：自動登入、執行標準交易、排程每日抓單、深度場景再以 PyRFC / BAPI 補強。這就是為什麼在 SAP 周邊自動化上，Python 不只是「比 LowCode 好一點」，而是 LowCode 根本進不了場。
結論：把 LowCode 放在它該放的位置
我們不是反對 LowCode。LowCode 有它的位置，就是別放在關鍵業務。
B2B 決策者要問自己的問題：
- 這套自動化如果明天廠商倒了，我的業務會停擺嗎？
- 這套自動化如果月費漲三倍，我能轉移嗎？
- 這套自動化如果出 bug，我能自己查到原因嗎？
如果三個答案有任何一個是「不能」，那這個自動化就不該用 LowCode 做。
把公司管理神經系統交給工程能掌控的技術，而不是廠商月費——這是 B2B 企業該有的工程紀律。