n8n、Claude Code、Google AI Studio 怎樣選？自動化、開發與部署決策指南

n8n、Claude Code 和 Google AI Studio Build 都會出現在「AI 開發」討論中，但三者解決的主要問題不同。把它們放在同一條直線比較，很容易問錯問題：不是哪一個可以取代其餘兩個，而是哪一個應該擁有流程、程式庫、介面、資料和部署責任。

本文先用一張決策矩陣把三者定位，再用五個真實場景拆解何時單用、何時組合。教學畫面、預覽與編輯部資訊圖均逐項人工覆核：不含講者、人像、帳戶、作者、頻道、字幕、社交平台標記或宣傳資訊；亦已排除載入、模糊和重複畫面。

2026 年 7 月重要校正：錄製示範中的兩個分類已過時。第一，Claude Code 不是 IDE，而是可在終端、IDE、桌面和網頁等介面工作的 agentic coding tool。第二，Google AI Studio Build 已支援全端 web app、Node.js server runtime、Secrets、npm、Firebase／外部資料庫、GitHub 與 Cloud Run，不能再說成只做前端 prototype 或沒有 server 連接能力。

一、60 秒答案：先看你要交付甚麼

簡化判斷：主要動詞是「收到、轉換、路由、通知、排程」時偏向 n8n；主要動詞是「設計、實作、測試、重構、維護程式庫」時偏向 Claude Code；主要動詞是「把概念迅速變成可試用 App」時偏向 AI Studio Build。

延伸閱讀：本文回答的是「n8n、Claude Code、Google AI Studio 應怎樣分工」。如果你的下一個問題是「2026 年是否仍值得學 n8n」，以及想看一條由收件、分類到人工覆核的完整 Inbox Triage 工作流，請讀2026 n8n 自動化用途與學習決策指南；兩篇的選型層級和實作層級並不重複。

二、不要按畫面相似度分類：三者的執行邊界不同

「都可以用自然語言」只描述操作方式，不代表底層責任相同。真正的比較單位應是：誰接收事件、誰持有狀態、誰執行副作用、誰維護 source code、誰提供 runtime，以及錯誤時由哪一層恢復。

三、n8n：把既有服務編排成可觀察流程

n8n 官方把產品描述為 fair-code workflow automation tool：可連接有 API 的應用、轉換資料、加入程式或 AI 節點，並以 Cloud、npm、Docker 等方式運行。它最適合「已有多個服務，現在要按事件把它們穩定串起來」的問題。

工作流：客戶表單跟進
Trigger：收到已驗證的表單 webhook
步驟：
1. 驗證 request_id、email、consent 和 payload 大小
2. 以 request_id 去重
3. 寫入指定 Google Sheet 欄位
4. 發內部 Telegram 通知
5. 只在 consent=true 時建立確認電郵草稿
失敗：429 指數退避；驗證失敗不重試；其餘進人工 queue
成功：保存 sheet row ID、message ID 和 execution ID
禁止：不得自動建立不存在的客戶資料或把完整 payload 寫入 log

n8n 擅長甚麼

• 接收 webhook、排程、表單或 SaaS 事件。
• 在服務之間映射、過濾、合併和轉換資料。
• 把 deterministic 規則、模型判斷、人工批准和副作用放入同一 execution。
• 按節點查看輸入輸出、錯誤和重試，建立營運可見度。
• 以 HTTP、GraphQL、MCP 或自訂節點連接沒有現成 connector 的服務。

n8n 不會自動替你解決甚麼

• 外部服務沒有合適 API、webhook 或授權時，n8n 不能憑空產生可靠接口。
• 把幾個節點連起來不代表有冪等、資料一致性、補償、權限和事故處理。
• Code node 能寫程式，不代表 n8n 是完整 web framework 或適合承擔所有 domain logic。
• 自託管帶來控制，也把 TLS、database、備份、升級、監察和 on-call 責任交回團隊。

想深入建立帶 guardrails、人工批准和 evals 的 Agent Workflow，可延伸閱讀AI Agent 與 n8n 可靠工作流設計；需要一個完整節點實例，可看n8n Structured Output 與 Switch 語意路由。

四、Google AI Studio Build：由快速 App 到全端 runtime

Google 現行官方文件說明，AI Studio Build 可建立全端 web app 和原生 Android app。web 預設可有 React client 和 Node.js server runtime；server 可安全調用 API、使用 npm、讀取 Secrets、連接外部資料庫，也可由 Agent 配置 Firebase Firestore、Google 登入和 Workspace API。這已超過早期「只做前端示範」的定位。

建立一個繁體中文問答 App，目標是驗證 Gemini 動態出題是否可行。

使用者流程：
- 選擇主題和難度 → 取得 5 題 → 逐題回答 → 顯示解釋和總分
- 重新開始必須清除舊狀態

架構：
- React client；Gemini 呼叫只可在 server-side
- GEMINI_API_KEY 從 Secrets 讀取，前端 bundle 不可包含 key
- 以 JSON Schema 驗證題目、選項、正確答案和解釋
- 429、timeout、無效 JSON 要有 retry 上限和使用者訊息

驗收：
- 鍵盤可操作、手機版不橫向溢出、loading／empty／error 狀態齊全
- 加入單元測試、整合測試和 README；不要自動部署

何時直接留在 AI Studio

• 要快速試驗 Gemini、Live API、圖像、語音或 Workspace 整合。
• 產品範圍清楚，Build 內的程式、Secrets、Firebase 和 Cloud Run 已滿足要求。
• 團隊接受 Google runtime 和部署方式，並已建立監察、測試和成本上限。

何時推到 GitHub 再整理

• 要合併既有 monorepo、設計系統、CI/CD、測試框架或雲端基建。
• 要做逐檔 code review、dependency policy、security scanning 和可重現 build。
• 要使用另一個 hosting、database、identity provider 或自訂網絡。
• 多人長期維護，而且需要 branch protection、release、rollback 和 ownership。

AI Studio 可把程式下載成 ZIP 或推到 GitHub，也可直接部署 Cloud Run。Google Cloud Starter Tier 目前讓合資格帳戶最多發布兩個全端服務而毋須先建立完整計費環境；標準部署需要 Cloud project 和 billing。資格、配額、region、API 與 Cloud Run 費用會變，不能把「一鍵發布」理解成永久免費。

需要逐步介面操作和發布檢查，可配合Google AI Studio Build 生成網站與反覆改版教學。

五、Claude Code：是 coding agent，不是 IDE 名稱

Anthropic 的官方定義是：Claude Code 會讀取 codebase、編輯檔案、運行指令，並整合開發工具。它可在 terminal、VS Code／其他支援 IDE、desktop、web 等介面使用。把它和 VS Code、Xcode 並列為同一種 IDE，會混淆「代理」和「編輯／建構環境」。

先不要改檔案。請讀取 repository、AGENTS／CLAUDE 指示、package scripts 和現有測試，然後回答：
1. 目前前端、server、database、auth 和 deployment 邊界
2. 要加入「每月帳單分析」功能會改哪些檔案
3. API contract、migration、權限、失敗模式和回復方案
4. 最小 vertical slice 與測試計劃

我批准計劃後才實作。每一輪：
- 只處理一個可驗收 slice
- 先寫或更新測試，再改 code
- 運行 lint、typecheck、unit／integration tests
- 列出實際 diff、未解風險和人工驗收步驟
- 不讀取 .env，不部署，不推送，不改 production 資料

Claude Code 擅長甚麼

• 跨多個檔案理解現有架構，追查 bug 和實作 feature。
• 運行 test、lint、build、migration dry-run 和 Git 操作。
• 以專案指示、skills、hooks、MCP 和 permissions 固化工作方式。
• 在你已有的框架、database、CI 和 hosting 選擇上工作，而非綁定單一 runtime。

使用邊界

• 它能運行你可運行的命令；權限過大會把模型錯誤變成實際副作用。
• read-only、file edit、shell、deploy 和 production access 應分開批准。
• 自動生成測試不代表測試正確；重要行為仍要由人定義 oracle 和邊界案例。
• Claude Code 不會替你提供應用 hosting、database SLA 或 workflow runtime，這些仍屬你的系統。

安全預設：先用 Plan／唯讀方式了解 repository；限制可寫目錄和命令；不要為方便在日常主機啟用跳過所有權限。Anthropic 官方亦只建議在隔離 container 或 VM 等環境使用完全繞過批准的模式。

六、12 維決策矩陣：用需求打分，不用品牌投票

實際評分時，先把「必須自託管」「指定資料地域」「必須使用現有 monorepo」等列成 pass／fail gate；其餘項目按 1–5 權重評分。硬性要求不能由漂亮 UI 或大量 connector 的高分抵銷。

七、五個場景：舊式二分法在甚麼地方失準

場景 1：收到客戶電郵後分類並轉發

先選 n8n。電郵 trigger、schema 驗證、模型分類、Switch、人工 queue、草稿和 execution log 都是 workflow 問題。模型只負責語意分類，不應自行決定收件人或直接發出高風險回覆。

場景 2：腦中有 App 概念，要在會議前做 Demo

先選 AI Studio Build。用結構化 prompt 快速生成可操作 App，驗證使用流程和 Gemini 能力。Demo 成功後再決定是否留在 AI Studio、推到 GitHub，或重用設計而重新架構。

場景 3：長期客戶管理系統，要登入、資料庫和 API

不再能簡單回答「一定要離開 AI Studio」。現行 Build 已可提供 server runtime、Firebase／外部 database、Secrets 和 Cloud Run。若產品需要既有 monorepo、複雜 RBAC、審計、特定 database、廣泛 CI 或多環境治理，Claude Code 配合成熟 framework 會較有控制；若 AI Studio 的全端能力已滿足範圍，也可在原平台繼續，但同樣要做 production QA。

場景 4：WhatsApp AI 客服、專屬知識庫和管理後台

通常採組合架構。AI Studio 或一般程式庫負責 API、auth、RAG、database 和管理 UI；n8n 負責 provider webhook、排隊、重試、通知和人工轉接。也可以完全以程式服務直接接 WhatsApp provider；是否需要 n8n 取決於流程可見度、整合數量和營運能力。

場景 5：AI Studio prototype 已獲批准，要變成產品

先做一次 production gap analysis，而不是立即重寫：列出 auth、資料、API、測試、無障礙、監察、成本、備份、rate limit、合規和 rollback。差距小便在 AI Studio 補齊並部署；差距主要來自 repository 和平台治理，便推到 GitHub，由 Claude Code 或開發團隊整理；跨 SaaS 業務流程再交給 n8n。

八、三種可靠組合架構

組合 A：AI Studio → GitHub → Claude Code

1. 在 AI Studio 用真實使用流程驗證 App。
2. 移除假資料、過時模型名稱和不需要依賴；把 Secrets 留在 server-side。
3. 推到新的 GitHub branch，不要直接覆蓋 production。
4. 由 Claude Code 先做唯讀 audit：架構、依賴、安全、測試和 deployment gap。
5. 逐個 vertical slice 重構，CI 全綠後才合併。

組合 B：Claude Code 建 API → n8n 編排

1. 在程式庫建立 versioned endpoint、auth、schema 和 idempotency。
2. 提供 OpenAPI／JSON Schema、sandbox URL、錯誤碼和 rate limit。
3. n8n 只傳最小必要資料；429／5xx 用有上限的退避重試。
4. 所有寫入帶 request ID；人工批准綁定實際 payload。
5. 以 end-to-end trace 串聯 API request ID 和 n8n execution ID。

組合 C：AI Studio App → 自訂 API／database → n8n

AI Studio server runtime 可安全保存第三方 key 並連接網絡可達的 database／API。n8n 可用 webhook 或 API 接受事件。不論由哪一端發起，都要指定唯一的 state owner；不要讓 App 和 workflow 同時「最後寫入」同一欄位而沒有版本控制。

Integration contract
Endpoint：POST /v1/support-events
Auth：短期 service token；每個環境獨立
Request：event_id、tenant_id、type、occurred_at、payload_version、payload
Idempotency：event_id 唯一；重播返回原結果
Response：202 + job_id；驗證失敗 4xx；暫時故障 429／5xx
Timeout：10 秒；最多 3 次退避重試
PII：只傳處理所需欄位；log 遮蔽內容
Ownership：API 寫業務狀態；n8n 只保存 orchestration state

九、第一星期學習路線：每一天都要有可驗收輸出

1. 第 1 日—HTTP 和資料：理解 JSON、webhook、status code、API key、OAuth、database 與 client／server 邊界。
2. 第 2 日—n8n：做一條 webhook → validate → transform → response 流程；加入一個失敗案例。
3. 第 3 日—AI Studio：用規格建立小 App；檢查 Code、Secrets、error state 和手機版。
4. 第 4 日—Git／Claude Code：在測試 repository 用 Plan 模式讀取架構，再實作一個有測試的小改動。
5. 第 5 日—API contract：讓 n8n 調用一個 mock endpoint，測 timeout、429、重播和 schema 錯誤。
6. 第 6 日—安全：輪換 sandbox key、收窄 scope、遮蔽 log，加入人工批准和成本上限。
7. 第 7 日—選型報告：比較完成時間、成功率、人工改寫、p95 延遲、單次成本和營運責任，再決定下一步。

若首個目標是自託管，可先閱讀Windows Docker 安裝、更新和備份 n8n；不要把「成功打開 localhost」當成已完成 production hosting。

十、費用與用量：用 2026-07-20 快照，不寫成永久價格

價格未含稅，地區、匯率、方案、資格、模型和限額可改。採購前要開啟官方定價頁和帳戶 Usage／Billing 畫面；不要以文章快照代替報價。

統一計算方式

每個成功任務總成本 =
平台／execution
+ 模型 input、output、cache、媒體
+ 第三方 API、database、storage、egress
+ hosting、logs、monitoring、backup
+ 人工批准、改寫、事故和維護

最少量度：成功率、p50／p95 延遲、p50／p95 成本、重試率、人工改寫率。

十一、安全與可靠性：三張不同清單

n8n 上線前

• 所有 webhook 有認證、payload 上限、schema 和 replay 防護。
• credential 以最小 scope 保存，不寫入節點文字或 execution log。
• 副作用有 idempotency key；error workflow、重試上限和人工 queue 已測。
• production／staging 分開；workflow 版本可匯出、審查和回復。
• 自託管有 TLS、database 備份、encryption key 備份、更新和復原演習。

Claude Code 上線前

• 先讀 project instructions；未知 repository 用 Restricted／Plan／唯讀方式。
• 限制 Bash、MCP、網絡和可寫路徑；不准讀 secrets 或操作 production。
• 每個改動有 diff、測試、lint、typecheck、build 和人工 code review。
• dependency、migration、auth、資料刪除和 rollback 另行審查。
• commit、push、PR、deploy 和發外部訊息是不同批准。

AI Studio 上線前

• Gemini 和第三方 key 只放 server-side Secrets；檢查 client bundle 和 Git history。
• 驗證 Firebase／database rules、Google OAuth scopes、tenant boundary 和刪除流程。
• 所有模型輸出有 schema、錯誤狀態、rate limit、cost cap 和 abuse control。
• 對共用 App 做權限測試；使用者可能看到 code 或 fork 的分享設定要核對。
• Cloud Run 的 region、billing、concurrency、logs、monitoring、backup 和 rollback 已安排。

十二、常見錯誤與修正

十三、最後建議：由主要風險決定第一件工具

• 最大風險是跨服務流程經常漏步或靠人複製：先用 n8n，保留明確驗證、重試和人工批准。
• 最大風險是不知道 App 概念是否可行：先用 AI Studio Build 做可操作原型，並按現行全端能力評估能否直接演進。
• 最大風險是現有程式庫難改、測試差或需要自訂架構：先用 Claude Code 做唯讀分析和一個小 vertical slice。
• 三種風險同時存在：不要找「全能工具」；先畫責任圖，以 API contract、state owner 和 trace ID 把三層接起來。

真正的能力不是熟記某個按鈕，而是能把需求分解成 UI、domain、data、integration、runtime 和 operations，再為每一層選擇可驗證工具。當 AI Studio、Claude Code 或 n8n 下一次更新時，這套判斷仍然有效：重新核對官方能力和價格，用同一個 prototype 測試，再按證據調整架構。