n8n 實戰應用：5 個我們正在規劃的自動化場景

n8n 設好了，MCP 也接上了。現在是最有趣的部分：實際要用它做什麼？

SuperPortia 有五個正在規劃或已開始實作的自動化場景。這些不是示範用的 hello world，是真實的業務需求，每一個都有具體的節點設計和資料流。最後會說一件更根本的事：當 AI 可以直接建立工作流，設計自動化的方式本身發生了什麼變化。

本系列的前三篇：

• 為什麼選 self-host：n8n Self-Hosted：為什麼我們選擇自建而非 SaaS
• 部署方法：完整教學：Docker + Cloudflare Tunnel 部署 n8n
• MCP 整合：n8n MCP Server × Claude Code：AI 直接操控工作流

場景一：部落格發布 → 社群同步

問題：SuperPortia 維護三個部落格（agentic.superportia.dev、week.nqio.dev 等）。每次發新文章，需要手動到 Facebook、X（Twitter）、LinkedIn、LINE Messaging API 各貼一遍。這件事重複、無腦、每次都要 15 分鐘。

工作流設計：

graph LR
    Webhook["Webhook Trigger\n新文章發布時呼叫"] --> Extract["Extract Metadata\n取標題/摘要/URL"]
    Extract --> Generate["AI Node\n生成各平台文案"]
    Generate --> FB["Facebook Node\n發到粉專"]
    Generate --> X["HTTP Request\nX API v2"]
    Generate --> LINE["HTTP Request\nLINE Messaging API"]
    Generate --> Wait["Wait 2 hours\n時差發文"]
    Wait --> LinkedIn["HTTP Request\nLinkedIn API"]

關鍵節點：

Astro 端的觸發設定：

Astro 的 build script 在完成部署後呼叫 n8n webhook：

# 在 CI/CD 或 npm script 加入
curl -X POST https://n8n.superportia.dev/webhook/blog-publish \
  -H "Content-Type: application/json" \
  -d "{\"title\": \"$POST_TITLE\", \"url\": \"$POST_URL\", \"summary\": \"$POST_SUMMARY\"}"

AI 文案生成的 prompt 結構：

不同平台有不同的最佳文案格式。n8n 的 AI Agent 節點可以根據目標平台生成對應格式：

• Facebook：200-300 字，含 emoji，自然口語
• X：140 字以內，含 hashtag
• LinkedIn：專業語氣，300-500 字，提出洞察
• LINE Messaging API：50 字以內，清晰直接

場景二：RSS 監控 → 內容策展 → UB 入庫

問題：SuperPortia 需要持續追蹤 AI agent 生態的最新動態（新工具、新論文、重要討論）。目前這是人工訂閱 RSS 然後手動閱讀的工作，耗時且容易遺漏。

工作流設計：

graph TB
    Schedule["Schedule\n每 30 分鐘"] --> RSSList["RSS Feed Read × N\n多個 feed 來源"]
    RSSList --> Dedup["Dedup Check\n查 UB 避免重複入庫"]
    Dedup -->|新文章| AI["AI Node\nDeepSeek V3 摘要 + 分類"]
    AI --> Score["Code Node\n計算相關性分數"]
    Score -->|分數 > 0.7| UB["HTTP Request\nUB Worker /brain/ingest"]
    Score -->|0.4-0.7| Queue["Google Sheets\n待人工審查佇列"]
    Score -->|< 0.4| Discard["丟棄"]
    UB --> Notify["LINE Messaging API\n高品質文章通知"]

RSS 來源列表（規劃中）：

Dedup 策略：

// Code 節點：計算 content hash，查詢 UB 是否已存在
const hash = crypto.createHash('md5').update($json.link).digest('hex');
const existing = await fetch(`https://ub.superportia.dev/brain/search?q=${hash}`);
if (existing.results.length > 0) {
  return []; // 跳過，已有相同 URL
}
return [$json]; // 新內容，繼續處理

和 Cloud UB 的整合：

這個場景直接接上 SuperPortia 現有的 MTAAA 分類管線。n8n 呼叫 UB Worker 的 /brain/ingest endpoint，文章進入 Dock（entries table）後，boiler_grandpa_v2.py 的分類管線自動接手分類和提升到正區（classified_entries）。

詳細的 UB 架構可以從這篇了解背景：從 Pages 到 Workers — SuperPortia 的 Cloudflare 部署演化。

場景三：KOL 敘事追蹤管線

問題：SuperPortia 追蹤 12 個 AI 領域 FB KOL 的貼文（詳見 vault 裡的 fb-ai-experts-watchlist.md）。目前用 Apify 抓取，但後續的分析、分類、趨勢判斷都是人工完成的。

工作流設計：

graph LR
    Schedule["Schedule\n每日 08:00"] --> Apify["HTTP Request\nApify Actor 觸發"]
    Apify --> Poll["Wait + Poll\n等待 Apify 完成"]
    Poll --> Items["Apify Dataset\n取得爬取結果"]
    Items --> Filter["Filter\n只保留過去 24 小時"]
    Filter --> AI["AI Agent\n敘事分類 + 情緒分析"]
    AI --> UB["UB /brain/ingest\n入庫 kol-intel 標籤"]
    AI --> Trend["Code Node\n計算敘事趨勢變化"]
    Trend --> Report["HTTP Request\n發送每日 KOL 簡報到 LINE"]

「敘事分類」的設計：

KOL 追蹤的核心不是「他們說了什麼」，而是「他們的論述重心在哪裡、和上週相比有什麼變化」。

n8n AI Agent 節點用 DeepSeek V3 對每篇貼文做三個維度的分類：

1. 主題（技術趨勢、應用落地、商業模式、社會影響）
2. 立場（樂觀、謹慎、批評）
3. 緊迫性（常規更新、值得關注、重大訊號）

這些分類和原文一起寫進 UB，tag 包含 kol-intel、kol-{作者名}、YYYY-MM。

Apify 整合細節：

n8n Code 節點無法直接透過 $env 存取 n8n Credentials（加密憑證）——那是 HTTP Request 節點的功能。正確做法有兩種：

推薦方式：HTTP Request 節點 + Stored Credentials

在 n8n 建立 Apify credential（Header Auth 類型，key: Authorization，value: Bearer <token>），然後用 HTTP Request 節點呼叫 Apify API，節點直接引用 credential，不需要在 workflow 裡出現 token 明文。

替代方式：Docker 環境變數

在 docker run 加入 -e APIFY_TOKEN=<token>，n8n 的 Code 節點可以用 process.env.APIFY_TOKEN 存取（Node.js 環境變數，不是 n8n Credentials）：

// 呼叫 Apify Facebook Posts Scraper
// APIFY_TOKEN 需透過 Docker 環境變數傳入（-e APIFY_TOKEN=...）
const runResult = await fetch('https://api.apify.com/v2/acts/apify~facebook-posts-scraper/runs', {
  method: 'POST',
  headers: {
    'Authorization': `Bearer ${process.env.APIFY_TOKEN}`,
    'Content-Type': 'application/json'
  },
  body: JSON.stringify({
    startUrls: kolUrls.map(url => ({ url })),
    resultsLimit: 10 // 每個 KOL 最新 10 篇
  })
});

場景四：圖片生成管線（Workers AI → R2 → CDN）

問題：SuperPortia 的部落格文章需要封面圖片。目前是手動用 Canva 製作，每張 15-20 分鐘。這個場景嘗試用 Cloudflare Workers AI 自動生成封面圖，存到 R2，透過 CDN 提供給 Astro 用。

工作流設計：

graph LR
    Webhook["Webhook\n新文章 trigger"] --> Meta["Extract\n取標題+描述+類別"]
    Meta --> Prompt["Code Node\n建構圖片生成 prompt"]
    Prompt --> CFWorker["HTTP Request\nCloudflare Workers AI\n@cf/black-forest-labs/flux-1-schnell"]
    CFWorker --> R2["HTTP Request\nR2 PUT\nimages/covers/{slug}-cover.png"]
    R2 --> Purge["HTTP Request\nCF Cache Purge"]
    Purge --> Update["HTTP Request\nGitHub API\n更新文章 frontmatter"]

Cloudflare Workers AI 呼叫：

// 呼叫 Workers AI 圖片生成
// CLOUDFLARE_API_TOKEN 和 accountId 透過 Docker 環境變數傳入
const accountId = process.env.CLOUDFLARE_ACCOUNT_ID;
const cfToken = process.env.CLOUDFLARE_API_TOKEN;

const imageResponse = await fetch(
  `https://api.cloudflare.com/client/v4/accounts/${accountId}/ai/run/@cf/black-forest-labs/flux-1-schnell`,
  {
    method: 'POST',
    headers: {
      'Authorization': `Bearer ${cfToken}`,
      'Content-Type': 'application/json'
    },
    body: JSON.stringify({
      prompt: `Blog cover image for: "${$json.title}". Technical blog about AI agents and automation. Clean, modern design. Dark background with geometric elements.`,
      num_steps: 4,
      width: 1200,
      height: 630
    })
  }
);

// Workers AI 回傳 JSON，圖片資料在 response.image（base64 字串）
const result = await imageResponse.json();
const base64Image = result.result.image; // base64 encoded PNG
const imageBuffer = Buffer.from(base64Image, 'base64');

R2 儲存：

// 上傳到 R2（使用 S3-compatible API）
// R2 endpoint 格式：https://<account-id>.r2.cloudflarestorage.com/<bucket>/<key>
const filename = `covers/${$json.slug}-cover.png`;
const r2Endpoint = `https://${accountId}.r2.cloudflarestorage.com/agentic-assets/${filename}`;

await fetch(r2Endpoint, {
  method: 'PUT',
  headers: {
    'Authorization': `Bearer ${cfToken}`,
    'Content-Type': 'image/png'
  },
  body: imageBuffer
});

目前狀態：這個場景是規劃中最複雜的，需要先解決 R2 public access 設定和 Astro frontmatter 自動更新的 git push 流程。預計在場景一和二驗證後才會動工。

場景五：每日簡報整合

問題：夏哥每天需要掌握的資訊來自多個來源：UB 昨日新增的重要條目、KOL 昨日動態、任何系統告警、Cloudflare 用量數據。目前這些需要分別開不同頁面查看。

工作流設計：

graph TB
    Schedule["Schedule\n每日 07:00 (Taipei)"] --> P1["HTTP Request\nUB 昨日新增條目"]
    Schedule --> P2["HTTP Request\nCF 用量 API"]
    Schedule --> P3["Read Google Sheets\nKOL 昨日高分條目"]
    P1 --> Merge["Merge Node\n整合所有資料"]
    P2 --> Merge
    P3 --> Merge
    Merge --> AI["AI Agent\n生成繁中簡報"]
    AI --> LINE["LINE Messaging API\n推送到夏哥"]
    AI --> UB["UB /brain/ingest\n備份到知識庫"]

每日簡報格式：

📊 SuperPortia 每日簡報 — 2026-03-22

📚 UB 昨日新增：12 筆
  • 高相關（≥0.8）：3 筆
    - [AI Agent 架構] LangGraph v0.5 MCP 整合變更...
    - [部署] n8n v2.14 release notes...

🤖 KOL 動態：
  • 重大訊號（3）：
    - 某KOL：對 GPT-5 的第一手評測，情緒：謹慎樂觀

☁️ Cloudflare 用量：
  • Workers：12,345 req（限額 100K）✅
  • D1 reads：234,567（限額 5M）✅

⚠️ 告警：無

完整版的場景五依賴場景二（RSS/UB 管線）和場景三（KOL 追蹤）先建好，因為它需要從這兩個場景取得資料。但有一個**簡化版（Simplified P1）**可以先跑：只整合 CF 用量 API 和 UB 昨日條目（這兩個資料來源是即時可用的），KOL 動態欄位先留空或用靜態文字佔位。這讓場景五的基本框架可以在 P1 階段驗證，完整版在 P3（場景二三建好後）再補入。

describe → deploy：設計工作流的方式變了

這五個場景有一個共通點：它們的設計流程和傳統的「打開 n8n UI 拖拉節點」不同。

傳統流程：

1. 夏哥心裡有個需求
2. 工程師翻 n8n 文件找節點
3. 拖拉節點、設定參數
4. 發現某個節點不支援這個功能
5. 找替代方案、重設計
6. 測試、除錯
7. 上線

有 MCP 的流程：

1. 夏哥說：「我要 RSS 監控，過濾 AI 相關文章，存到 UB」
2. Claude Code 用 search_nodes 找到所有相關節點，確認能力範圍
3. Claude Code 設計節點拓撲，生成 workflow JSON
4. Claude Code 用 validate_workflow 驗證
5. Claude Code 用 create_workflow_from_code 直接部署
6. 夏哥在 UI 填入 credentials（OAuth 授權這步仍然是人工的）
7. 測試執行

步驟數沒有少很多，但誰在做設計這件事改變了。工程師（或 AI）不需要熟記 400+ 個節點的 API，Claude Code 即時查詢 n8n 自己的節點文件。更重要的是，整個設計過程可以在對話裡進行，邊討論邊建構，不需要來回切換工具。

實作優先順序

五個場景不可能同時上線。SuperPortia 的規劃優先順序：

結語：自動化不是目的，時間才是

這五個場景加起來，估計可以把 SuperPortia 每週花在重複性資訊工作的時間從大約 8 小時降到不到 1 小時。釋放出來的時間去哪？去做 AI 做不好的事：判斷、決策、建立關係、思考更大的策略問題。

n8n self-hosted + Claude Code MCP 是一個組合，不是兩個獨立工具。工作流的設計和執行都在同一個 AI 協作環境裡完成，這讓「把想法變成自動化管線」的摩擦力降到了前所未有的低。

這是 多代理 CLI 協作 文章裡說的「AI 作為協調者」在自動化領域的具體實現。

本系列完結。如果你有任何問題或想分享你的 n8n 設定，歡迎在下面留言。