[AI生成]20260502 周報

本周要點

其他訊息

(fin)

[實作筆記] 個人自動化平台(七) n8n 備份自動化：workflow + credentials → GitHub

前情提要

n8n 跑起來、workflow 也在跑了，下一個問題：掛掉怎麼辦？

VM 重開機沒問題，但容器砍掉重建、或換 VM，workflow 和 credentials 就都要重設。
這篇記錄怎麼用 CLI export + git 做自動備份。

備份方案決策

考慮過幾個方向：

方案 問題
備份整個 .n8n 目錄 SQLite 每次執行都寫入，幾乎天天變動，太肥
只備份 workflow JSON 沒有 credentials 無法完整還原
n8n Source Control（GitOps） Enterprise/Business 付費功能，Community 版不支援
CLI export workflow + credentials 可行，輕量，Community 版都有

最終選 CLI export + GitHub private repo，搭配 cron job 每天自動跑。

架構

1
2
3
4
GCP VM（cron job 每天凌晨 3 點）
  └─ docker exec n8n → export workflow + credentials JSON
       └─ bind mount（/home/user/.n8n）
            └─ 複製到 repo backup/YYYYMMDD-NNN/ → git commit + push → GitHub

每次跑都建立新的日期資料夾（20260430-001、20260430-002），保留最近 30 份，舊的自動刪除。就算刪了，git log 還是查得到歷史。

實作

Repo 結構

1
2
3
4
5
6
7
8
Marsen.Butler.n8n.Backup/
├── README.md
├── install.sh    ← 一次性安裝，設定 cron job
├── backup.sh     ← 每次執行的備份邏輯
└── backup/
    └── 20260430-001/
        ├── workflows/
        └── credentials/

backup.sh 核心邏輯

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
# container name 預設 n8n，可用環境變數覆蓋
N8N_CONTAINER="${N8N_CONTAINER:-n8n}"
KEEP_COUNT="${KEEP_COUNT:-30}"

# 產生日期流水號資料夾
DATE_TAG="$(date +%Y%m%d)"
SERIAL=$(printf "%03d" $(( $(ls -d backup/${DATE_TAG}-* 2>/dev/null | wc -l) + 1 )))
BACKUP_DIR="backup/${DATE_TAG}-${SERIAL}"

# 確認容器在跑，export，複製到 repo...

# 刪除舊備份（保留最近 KEEP_COUNT 份）
TOTAL=$(ls -d backup/[0-9]* 2>/dev/null | wc -l)
if [ "$TOTAL" -gt "$KEEP_COUNT" ]; then
  ls -d backup/[0-9]* | sort | head -n $(( TOTAL - KEEP_COUNT )) | xargs rm -rf
fi

# 每次都 commit
git add backup/
git commit -m "backup ${DATE_TAG}-${SERIAL}"
git push

docker inspect 自動找 bind mount 路徑，不寫死，換 VM 也通用。

install.sh

1
2
3
4
5
6
7
8
9
# 設定每天凌晨 3 點執行
CRON_JOB="0 3 * * * ${BACKUP_SCRIPT} >> /var/log/n8n-backup.log 2>&1"

# 避免重複寫入
if crontab -l 2>/dev/null | grep -q "$BACKUP_SCRIPT"; then
  echo "Cron job already exists, skipping."
else
  (crontab -l 2>/dev/null; echo "$CRON_JOB") | crontab -
fi

踩坑記錄

git clone 下來的腳本沒有執行權限

git pull 之後直接跑 ./backup.sh，結果：

1
-bash: ./backup.sh: Permission denied

原因：git 預設不保留 chmod +x，clone 下來的檔案是 644。

解法：用 git update-index 把執行權限記進 git：

1
2
3
git update-index --chmod=+x backup.sh install.sh
git commit -m "fix: preserve execute permission for scripts in git"
git push

之後 git pull 拿到的檔案就自帶執行權限，不需要手動 chmod。

Container name 不應該硬綁定

一開始寫死 N8N_CONTAINER="n8n"，但我的容器叫 n8n-01，直接報錯。

改為環境變數覆蓋，預設值 n8n：

1
N8N_CONTAINER="${N8N_CONTAINER:-n8n}"

臨時要換：N8N_CONTAINER=n8n-01 ./backup.sh，不需要改腳本。

備份會把 token 明文存進 git

備份的是 workflow JSON，而 workflow JSON 裡如果 token 是直接寫在節點裡，那備份就等於把 token 存進 git repo。

用文字搜尋就找得到：

1
grep -r "access_token\|IGAA" backup/

解法：改用 n8n Credential 存 token

n8n 的 Credential 有獨立加密機制，workflow JSON 裡只會存 Credential 的 ID，不含實際值。這樣備份出來的 workflow 就不會洩漏 token。

1
2
3
4
5
# 不好（硬寫在節點）
"access_token": "IGAAYLng3..."

# 好（引用 Credential）
"credentials": { "instagramOAuth2Api": { "id": "xxx", "name": "IG" } }

Credential 本身也可以 export 備份，但它是加密的（用 N8N_ENCRYPTION_KEY），只要 Key 沒洩漏，備份裡的 Credential 就是安全的。

VM 上安裝步驟

1
2
3
4
5
6
7
8
9
# 1. clone repo
git clone [email protected]:marsen/Marsen.Butler.n8n.Backup.git ~/n8n-backup

# 2. 安裝 cron job
cd ~/n8n-backup
./install.sh

# 3. 手動跑一次確認
./backup.sh

還原

情境一：同 VM，換新容器

1
2
3
4
5
6
7
8
9
10
11
12
13
14
docker run -d \
  --name n8n \
  -e N8N_SECURE_COOKIE=false \
  -v /home/user/.n8n:/home/node/.n8n \
  -p 5678:5678 \
  --restart unless-stopped \
  docker.n8n.io/n8nio/n8n

# 取最新備份
LATEST=$(ls -d ~/n8n-backup/backup/[0-9]* | sort | tail -1)
cp -r "${LATEST}/workflows/." /home/user/.n8n/exports/workflows/
cp -r "${LATEST}/credentials/." /home/user/.n8n/exports/credentials/
docker exec n8n n8n import:workflow --separate --input=/home/node/.n8n/exports/workflows/
docker exec n8n n8n import:credentials --separate --input=/home/node/.n8n/exports/credentials/

情境二：新 VM

從密碼管理器取出 N8N_ENCRYPTION_KEY，啟動時帶入：

1
2
3
4
5
6
7
8
docker run -d \
  --name n8n \
  -e N8N_ENCRYPTION_KEY=你的key \
  -e N8N_SECURE_COOKIE=false \
  -v /home/user/.n8n:/home/node/.n8n \
  -p 5678:5678 \
  --restart unless-stopped \
  docker.n8n.io/n8nio/n8n

clone repo 並還原最新備份：

1
2
3
4
5
6
git clone [email protected]:marsen/Marsen.Butler.n8n.Backup.git ~/n8n-backup
LATEST=$(ls -d ~/n8n-backup/backup/[0-9]* | sort | tail -1)
cp -r "${LATEST}/workflows/." /home/user/.n8n/exports/workflows/
cp -r "${LATEST}/credentials/." /home/user/.n8n/exports/credentials/
docker exec n8n n8n import:workflow --separate --input=/home/node/.n8n/exports/workflows/
docker exec n8n n8n import:credentials --separate --input=/home/node/.n8n/exports/credentials/

Credentials 是用 N8N_ENCRYPTION_KEY 加密儲存，還原時必須用相同的 Key，否則全部無法解密。Key 存密碼管理器，不存 repo。

參考

小結

  • CLI export 是 Community 版可用的最輕量備份方案
  • 每次建日期資料夾（YYYYMMDD-NNN），保留最近 30 份，超過自動 prune
  • 就算資料夾被刪，git log 還是查得到歷史
  • git update-index --chmod=+x 讓腳本執行權限跟著 repo 走
  • N8N_CONTAINER 環境變數讓腳本不寫死 container name
  • 還原關鍵：N8N_ENCRYPTION_KEY 要另外存好

(fin)

[實作筆記] 技術面試 Q&A：大流量電商系統設計實戰

前情提要

整理一次技術面試的對話紀錄，主題圍繞在大流量電商系統的設計與應變。

面試公司：H 社，北台灣，科技服務業，員工數十人。實際業務為線上遊戲平台的開發與維運；產品涵蓋自研遊戲、第三方遊戲接入，以及面向代理商與玩家的平台系統。整體採微服務架構，開發部門數十人，小組制運作。跨國營運，技術端設於台灣。

職位：後端為主的全端工程師，技術棧含 Node.js / Go、現代前端框架、SQL / NoSQL，要求具備架構設計與 CI/CD 實務能力，並承擔技術指導職責。

以下按主題整理成 Q&A，並附上現代技術視角供參考。

大流量與快取架構

Q：電商搶購時流量瞬間暴增，怎麼擋？

先接受「讓使用者排隊，不讓網站 crash」這個前提，整個設計才會清楚。

具體做法是多層 Cache 疊加：

  • 前端：搶購期間關掉非核心的資訊（推薦、廣告等），減少後端壓力
  • 後端第一層：庫存資料放 Redis
  • 後端第二層：使用 MemoryCache（.NET 4.5/4.6 內建）做本地快取
  • DB 層：DB 自身的查詢快取

流量依序被每一層擋掉，真正打到 DB 的請求量才能控制住。

現代解法：Kubernetes + HPA（Horizontal Pod Autoscaler）根據 CPU / Memory 自動擴縮容，不再需要預先備機和人工值班。Redis 依然是標準選擇，但搭配 Lua Script 或 WATCH/MULTI/EXEC 可更精確控制庫存的原子操作，避免超賣。

Q：那時候沒有 Kubernetes，怎麼做水平擴充？

用 VM 搭配手動的負載分流。備用機平時待機，搶購前預先準備好；緊急時把流量導過去。

沒有自動 scale，所以需要人工值班監控——雙 11 期間三班制，值班加 on-call 全員待命。

現代解法：Kubernetes 的 Deployment + HPA 讓水平擴充自動化，節省人力成本。搭配 Cluster Autoscaler，甚至連底層節點都能自動增減，不再需要預先開好備用機等待。

監控與事故應對

Q：系統是 crash 了才知道，還是有提前預警？

有兩個觸發條件：

  1. 資源閾值警報：CPU 或 Memory 超過 80% 就通知，不等到崩潰
  2. 錯誤日誌頻率：同類型錯誤在短時間內高頻出現，自動告警

這些監控都是自己開發的，那個年代沒有現成的 APM 工具可以直接套。

現代解法：Prometheus + Grafana 是現在的標準配置，幾乎不需要自己開發。資源閾值警報用 AlertManager 設定即可；錯誤頻率則可搭配 ELK Stack 或 Loki，對 log 做 rate 統計觸發告警。SaaS 選項如 Datadog、New Relic 更是開箱即用。

Q：真的發生過事故嗎？當下怎麼處理？

有發生過，包含主機掛掉切備用機、備用機跟著掛掉的連環情況。

第一線的原則是：先讓系統回來，問題找根因可以之後再說。

當下操作是執行預先備好的備案（切流量、重啟服務），同時通報讓有能力解決根本問題的人起來處理。

事後改進：正式搶購活動前一定先壓測，模擬預估流量的 110%，只測核心購物流程，把能關的功能全部關掉。

現代解法：事故應對流程本身可以標準化為 Runbook，記錄每種已知情境的處置步驟，讓值班工程師不需要靠記憶應急。Kubernetes 搭配 liveness/readiness probe 可自動偵測服務不健康並重啟，減少人工介入的時間窗口。壓測工具如 k6 或 Locust 可整合進 CI/CD，讓每次上線前自動跑一輪基準測試。

金流系統設計

Q：對接多個金流廠商，程式碼怎麼不變成一團亂？

用 Strategy Pattern 的概念，把金流流程切成 Workflow。

整個下單流程是一條工作站鍊：

1
商品計算（折扣、贈品）→ 訂單建立 → 金流付款

金流工作站本身的邏輯很薄：根據使用者選的付款方式，決定走哪個 Strategy。不同廠商（信用卡、超商取貨、銀行轉帳）各自封裝成獨立模組，主流程不在意裡面怎麼串接。

新增金流廠商：加一個新模組，主流程不用改。

現代解法：這個架構今天依然適用，核心概念沒有過時。如果系統更大，可以把每個金流廠商拆成獨立的微服務，透過統一的 Payment Gateway API 對外暴露，主流程完全不感知廠商差異。設計模式上除了 Strategy，也可以考慮 Plugin Architecture，讓新廠商直接以套件形式掛入，不需要改動核心程式碼。

Q：訂單成立了，金流卻失敗，怎麼處理？

訂單成立和金流付款是兩個獨立的 Transaction。

金流失敗不會 rollback 訂單，而是讓訂單保持「待付款」狀態，通知使用者重新付款或換付款方式。

好處是：金流失敗是常見的可預期錯誤，這樣設計使用者體驗比較好，也避免訂單資料不一致。

現代解法：在微服務架構下，這個問題升級為分散式交易問題。現代標準解法是 Saga Pattern：每個步驟成功後發事件觸發下一步，失敗時執行 compensating transaction 回滾前面的狀態，整個流程不依賴跨服務的 ACID Transaction。Choreography Saga 適合步驟簡單的流程，Orchestration Saga 適合需要集中管控的複雜流程。

AI 與本地部署

Q：你做的法律 AI 系統，為什麼不用雲端大模型就好？

客戶是大型企業（Sony、政府機關、醫療機構），他們不願意把公司內部資料送上雲端。

做法是把 AI 系統打包進實體機器，送進客戶的內網部署。功能類似 ChatGPT，但跑在客戶自己的機房裡。

主要應用場景是：

  1. RAG：上傳法律文件，AI 從裡面查詢相關資訊
  2. 專利風險分析：原本需要半年人工查詢各大專利資料庫，自動化後大幅縮短

現代工具：本地部署 AI 的技術棧已經成熟許多。Ollama 可以一鍵跑主流開源模型（Llama 3、Mistral 等），LlamaIndex 或 LangChain 提供 RAG pipeline 的標準建構塊，向量資料庫用 ChromaDB、Qdrant 或 Weaviate 都可以，整個 stack 都可以打包進客戶內網。對於需要更強模型的場景，也可以考慮 vLLM 搭配企業級 GPU，在不上雲的前提下跑到生產等級的推論效能。

關於 AI 對開發的影響

Q：你覺得 AI 工具對軟體開發的影響是什麼？

一個工程師現在能產出的東西，可能相當於十年前一整個小團隊的產出。

但這也帶來新的問題：程式碼產出速度快了，但架構決策、程式碼品質的門檻反而更重要。AI 可以快速生出大量程式碼，但如果架構設計不對，技術債也會累積得更快。

進一步的觀察：Coding style 和命名規範這類問題，現在完全可以交給 AI 處理——把 guideline 寫好，讓 AI 執行和稽核就好，不值得花人力在上面爭論。真正需要人把關的是 Domain 層和 Use Case 層的設計：商業邏輯有沒有被正確封裝？Unit Test 有沒有覆蓋核心行為？這兩層做對了，架構就不容易爛掉。六邊形架構（Hexagonal Architecture）或 Clean Architecture 在 AI 輔助開發的時代反而更值得落地，因為邊界清楚，AI 才不容易在錯誤的地方塞邏輯。

面試反思

用業界術語包裝已知的答案

描述分散式交易的處理方式時，邏輯是對的，但沒有說出 Saga Pattern 這個詞。面試官如果熟悉這個詞，會更快建立信心；說不出來反而讓人以為是靠直覺摸索，不是系統性的設計知識。同樣的，提到 Request ID 追蹤時，可以直接說 Distributed Tracing、OpenTelemetry，展示對現代標準的認識。術語不是裝飾，它是讓對方快速理解你程度的捷徑。

主動帶出現代解法

談電商 N 社那個年代的做法時，可以補一句「現在我會用 Kubernetes + HPA 處理這個問題」——展示持續學習的態度。技術知識有，但沒有主動說出來，廣度就沒有完整呈現。

這兩點對應的技術題目值得另外整理成文章研究：Saga Pattern、Distributed Tracing、OpenTelemetry。

小結

  • 大流量不靠單一技術解決，是多層 Cache + 系統開關 + 人工值班的組合
  • 監控要在系統崩潰前就觸發，資源閾值和錯誤頻率是兩個實用的指標
  • 事故處理分兩階段：先讓系統回來，再找根因
  • 金流複雜性用 Strategy Pattern + Workflow 拆解，廠商細節封裝進模組
  • 本地 AI 部署是企業安全性需求的實際解法，不只是技術選擇

(fin)

[實作筆記] 個人自動化平台(番外) Google OAuth redirect_uri_mismatch 除錯記錄

前情提要

在 個人自動化平台(六) 實作 IG Token 工具時，

為了修 Instagram OAuth callback URL 的問題，在 Vercel 設了 NEXT_PUBLIC_BASE_URL。

沒想到這個動作讓 Google 登入炸掉，報 redirect_uri_mismatch。

表面上是「連帶損傷」，但根本原因是 production 的 Google 登入從來沒測試過，問題早就存在，只是這次才被發現。

事件時間線

背景：production Google 登入從來沒運作過

NEXT_PUBLIC_BASE_URL 在 Vercel 上沒有設值時，env.baseUrl 是 undefined，Google OAuth 送出的 redirect URI 是：

1
undefined/api/auth/google/callback

這個字串不可能通過 Google 驗證。

但 production 上從來沒有人測試過 Google 登入，所以一直沒被發現。

本機開發設的是 NEXT_PUBLIC_BASE_URL=http://localhost:3000，Google Console 也只登記了 http://localhost:3000/api/auth/google/callback，本機正常，所以沒有警覺。

起點：IG Token 工具的 Instagram OAuth callback URL 錯誤

實作 IG Token 工具時（demo.marsen.me），Instagram 授權完成後 callback 沒有導回正確的頁面，而是跑到 Vercel 內部 URL。

原因：Instagram callback route 的 baseUrl 在 Vercel 上沒有設定，fallback 讀到的是 Vercel 執行環境的 host，不是對外的 demo.marsen.me。

修法：在 Vercel 設定 NEXT_PUBLIC_BASE_URL

在 Vercel 環境變數加上：

1
NEXT_PUBLIC_BASE_URL=https://demo.marsen.me

因為專案用 vercel build --prebuilt 方案，直接 Redeploy 不會重新 build，必須 push 新的空 commit 觸發 GitHub Actions：

1
2
git commit --allow-empty -m "chore: trigger redeploy"
git push origin main

Instagram OAuth callback 正常了。

問題浮現：第一次在 production 測試 Google 登入

設了 NEXT_PUBLIC_BASE_URL 後，第一次真正在 production 試 Google 登入。

NEXT_PUBLIC_BASE_URL 同時影響 Google OAuth 的 redirect URI（src/app/api/auth/google/route.ts）：

1
2
3
4
5
const google = new Google(
  env.googleClientId,
  env.googleClientSecret,
  `${env.baseUrl}/api/auth/google/callback`,
)

app 送出的 redirect_uri 變成：

1
https://demo.marsen.me/api/auth/google/callback

但 Google Cloud Console 只登記了本機的那條：

1
http://localhost:3000/api/auth/google/callback

不符，報 redirect_uri_mismatch。

症狀

點「Google 登入」後，Google 跳出錯誤頁面：

1
2
已封鎖存取權：這個應用程式的要求無效
發生錯誤 400：redirect_uri_mismatch

解法

進 Google Cloud Console → Credentials → OAuth 2.0 Client → Authorized redirect URIs，新增：

1
https://demo.marsen.me/api/auth/google/callback

本機那條 http://localhost:3000/api/auth/google/callback 保留，本機開發還用得到。

存檔幾分鐘內生效，不需要重新 build 或 deploy。

參考

小結

  • 根本原因不是「設定改壞了」，而是 production Google 登入從來沒被測試過，問題一直存在
  • IG Token 工具需要在 Vercel 設 NEXT_PUBLIC_BASE_URL，這個動作讓潛藏的問題第一次浮現
  • redirect_uri_mismatch 代表 app 送出的 redirect URI 和 Google Console 登記的不符
  • NEXT_PUBLIC_BASE_URL 影響所有 OAuth 服務，改了就要同步更新各 Console 的 redirect URI
  • Google Console 可以同時登記多條 URI，本機和 production 各一條，互不影響
  • 用 vercel build --prebuilt 的專案，env var 更新後要 push 空 commit 才會生效

(fin)

[實作筆記] 個人自動化平台(五) n8n 實作：處理層，Aggregate + Gemini 週報整理

前情提要

收集層跑通後，每次執行輸出統一格式的文章列表。

這篇記錄處理層：把多筆文章合併，送給 Gemini 整理成 AI 週報。

未來也可能抽換成不同的雲端或地端 AI 模型服務。

為什麼要 Aggregate？

收集層輸出的是多筆獨立資料（以 RSS 為例，一次可能拿到 10 筆）。

Basic LLM Chain 預設對每筆各送一次請求，10 筆 = 10 次 API call，超過 Gemini 免費版 5 RPM 限制。

用 Aggregate 節點先把多筆合成一筆，再送一次請求給 AI。這也更符合「週報」的本意——要的是一份完整報告，不是 10 篇獨立摘要。

1
Edit Fields → Aggregate（All Item Data）→ Basic LLM Chain（Google Gemini）

Prompt 設計

1
2
3
4
5
6
週報日期：{{ $now.toFormat('yyyy年MM月dd日') }}

以下是本週 AI 新聞，請用繁體中文整理成一份週報。
每則新聞說明「是什麼」和「為什麼重要」，條列呈現。

{{ $json.data.map(i => `【${i.source}】${i.title}\n${i.content}`).join('\n\n') }}

執行結果：日期正確，內容有條理，每篇清楚說明「是什麼」和「為什麼重要」。

踩坑：Rate Limit

第一次直接把 10 筆送給 LLM，遇到 429 Too Many Requests：

1
quota exceeded: limit 5 requests/minute (gemini-2.5-flash free tier)

解法：加 Aggregate 節點合併成一筆，從 10 次請求降為 1 次，問題消失。

參考

小結

  • Aggregate 節點把多筆合成一筆，是處理層的關鍵，解決 rate limit 也符合週報語意
  • Prompt 用 expression 動態帶入日期與新聞內容，輸出穩定

(fin)

[實作筆記] 個人自動化平台(六) n8n 實作：輸出層，Instagram API 取得 Token 全記錄

前情提要

收集層（RSS 抓資料）和處理層（Gemini 整理週報）都跑通了，接下來要實作輸出層：把 AI 整理好的內容自動發布到社群媒體。

這篇記錄從「選哪個平台」到「拿到 Instagram Long-lived Token」的完整過程，包含踩到的坑和解法。

平台選擇

想把 AI 週報自動發布到社群媒體，先評估三個選項：

平台 純文字 API 帳號門檻 難度
Instagram 不行（必須圖片） 有 Business 或 Creator 高
YouTube 影片 不行（必須影片） 有 普通 Google 帳號 最高
YouTube Community 可以 無 500+ 訂閱 —
LinkedIn 可以 有（需審查） 需要 Page 中
Telegram 公開頻道 可以 最簡單 無 低

最終決定：Instagram。不是因為它最簡單——Telegram 才是——而是因為這是我實際在用的平台，想把週報發在自己的帳號上。但 IG 必須有圖片，輸出層要加圖片生成步驟。

IG 帳號準備

Instagram API 發文需要 Business 或 Creator 帳號。個人帳號的 Basic Display API 已於 2024 年 12 月關閉。

切換 Creator 帳號（免費，不需要 Facebook Page）：

1
IG App → 設定和隱私 → 帳號類型和工具 → 切換為專業帳號 → 創作者

切換後保留所有粉絲和貼文，只是解鎖 API 權限。

Facebook Developer App 設定

App 類型要選對

建 App 時類型有坑：

  • Consumer：給舊版 Basic Display API 用，已關閉，選了找不到 Instagram Graph API
  • Business：正確選項，支援 Instagram Graph API content publishing

前往 developers.facebook.com/apps/create，選 Business。

Instagram API 流程選擇

進 App 後找 Instagram 產品，有兩種 API 流程：

Instagram Login Facebook Login
支援 Creator 帳號 是 需要連 FB Page
需要 Facebook Page 不需要 需要

選 API setup with Instagram business login（Instagram Login 流程）。

加 Tester 帳號

Step 1 要先在 Roles 頁籤加 Instagram Tester：

  1. 左側選單 → App Roles → Instagram Testers
  2. 輸入 IG username 送出邀請
  3. 在畫面下方找到連結，點開到 https://www.instagram.com/accounts/manage_access/ 接受邀請

踩雷筆記：OAuth 黑/白畫面 bug

點 Generate token 後，Instagram 授權頁面出現黑畫面或白畫面，token 無法顯示。

這是 Instagram Developer Console 已知的 rendering bug。OAuth 授權其實已完成，authorization code 在 redirect URL 裡，只是 UI 沒渲染出來。

解法：webhook.site 當臨時 Redirect URI

步驟一：前往 webhook.site，取得唯一 URL，例如：

1
https://webhook.site/98ec2192-c62e-459e-848a-334b370887f0

步驟二：加到 Instagram App → Step 3 → OAuth Redirect URLs。

步驟三：手動打開授權 URL（替換 YOUR_WEBHOOK_URL）：

1
https://www.instagram.com/oauth/authorize?client_id=APP_ID&redirect_uri=YOUR_WEBHOOK_URL&response_type=code&scope=instagram_business_basic,instagram_business_content_publish

步驟四：Instagram 授權後 redirect 到 webhook.site，從 URL 取得 code= 後面的值。

步驟五：馬上換 short-lived token（code 幾分鐘過期）：

1
2
3
4
5
6
curl -X POST https://api.instagram.com/oauth/access_token \
  -F client_id=APP_ID \
  -F client_secret=APP_SECRET \
  -F grant_type=authorization_code \
  -F redirect_uri=YOUR_WEBHOOK_URL \
  -F "code=YOUR_CODE"

步驟六：換 long-lived token（有效 60 天）：

1
curl -X GET "https://graph.instagram.com/access_token?grant_type=ig_exchange_token&client_secret=APP_SECRET&access_token=SHORT_LIVED_TOKEN"

回傳範例：

1
2
3
4
5
{
  "access_token": "IGAAYLng3...",
  "token_type": "bearer",
  "expires_in": 5165491
}

Token 更新（60 天到期前跑一次即可）：

1
curl -X GET "https://graph.instagram.com/refresh_access_token?grant_type=ig_refresh_token&access_token=LONG_LIVED_TOKEN"

加速解: IG Token Generator 工具

OAuth 流程太繁瑣，自製工具放在 demo.marsen.me/admin/tools/ig-token，下次取 token 不需要手動操作。

目前只有我能使用，如果有人有興趣可以與我聯絡我再視情況開放工具，具體還是希望 Bug 可以修複

技術棧：Next.js 16 App Router

流程設計：

1
2
3
4
5
6
7
8
9
使用者輸入 App ID + App Secret
  → POST /api/instagram/start
    → server 存 session cookie（5 分鐘 TTL）
    → 回傳 Instagram OAuth URL
  → 瀏覽器跳轉到 Instagram 授權
  → Instagram redirect 到 /api/instagram/callback
    → server 讀 cookie 取得 App Secret
    → 換 short-lived token → 換 long-lived token
    → redirect 到工具頁顯示結果

App Secret 全程只在 server-side 流通，不暴露給客戶端。

待改進項目

  • 範例資料不用真實值：截圖或 UI 展示時，input 欄位的 placeholder 不應出現真實 App ID，用假資料代替
  • Input 欄位短暫快取：App ID 和 App Secret 用 sessionStorage 快取 15～30 分鐘，避免每次授權都要重填（注意 App Secret 快取有資安風險，要考慮清楚）
  • Token 長期快取 90 天：取得 long-lived token 後存到 localStorage，90 天內重開頁面自動顯示，不需重新授權

踩雷筆記：Vercel 部署的 prebuilt 限制

這個專案用 GitHub Actions 做 CI/CD，採 vercel build --prebuilt 方案：

1
2
3
# GitHub Actions
- run: vercel build --prod    # Actions 裡 build
- run: vercel deploy --prebuilt --prod  # 上傳 build 產出物

更新 Vercel 環境變數後，不能直接 Redeploy，因為 Vercel 沒有原始碼可重新 build。必須 push 新 commit 觸發 GitHub Actions 重新 build 才能套用新設定：

1
2
git commit --allow-empty -m "chore: trigger redeploy"
git push origin main

prebuilt 的好處是 CI 與 deploy 分離，確保 lint/type-check/test 通過才部署；代價是 env var 更新要重新 build。

踩雷筆記：Meta 廣告帳號被限制

20260427 處理中

測試期間收到 Meta 通知：「Your professional ad account is restricted from advertising」。

第一反應是懷疑跟自動化發文有關，查了一下：這個限制針對的是廣告功能（投放廣告、Meta Pixel、推廣貼文），不影響 Content Publishing API。用官方 API 發文是 Meta 明確允許的行為，沒有違規。

推測原因：新開 Business App 首次觸發系統自動審查，誤判。已按「Request a Review」申訴中。

API 發文功能在申訴期間不受影響，繼續正常運作。

20260429 通過，帳號恢復正常

參考

小結

  • IG API 只支援 Business 或 Creator 帳號，個人帳號的 Basic Display API 已關閉
  • Facebook Developer App 類型要選 Business，流程選 Instagram Login（不需要 FB Page）
  • Developer Console 的 token generator 有 bug，用 webhook.site 當臨時 redirect URI 繞過
  • Long-lived token 有效 60 天，到期前用 refresh API 更新即可
  • 自製工具把 OAuth 流程自動化，之後取 token 一鍵搞定

（待補：圖片生成 + 實際 IG 發文流程）

(fin)

[產業報告] 從 DeepRacer 到 Robotaxi：Tesla vs Waymo 的無人駕駛現況

前情提要

2019 年，我在 AWS DeepRacer 工作坊裡用 Python 寫了幾行 reward function，讓一台 1:18 的小賽車學會跑彎道。

多年後，無人駕駛已經在真實道路上運作，這篇記錄一下產業現況。

兩條路線

Tesla：純視覺派

馬斯克從第一性原理出發：人用兩隻眼睛就能開車，攝影機應該也夠。

2022 年起，Tesla 把 radar 全拔掉，FSD 只靠攝影機。

基礎理論在於道路本來就是為人類視覺設計的，攝影機加上夠大的神經網路應該能學會同樣的事。

FSD v12 起改用 end-to-end 架構——8 顆攝影機的原始影像直接輸入，輸出方向盤與油門指令，中間沒有人工規則，全靠模型自己學。

每台 Tesla 行駛時都在 shadow mode 默默預測「如果 FSD 接管會怎麼做」，遇到預測與駕駛行為不符的片段就自動上傳訓練。

Waymo：多感測器派

Waymo 走另一條路：LiDAR + radar + 精密地圖，多重機制確保安全。

2025 年，Waymo 達成 1 億英里全自動駕駛里程，每週 25 萬次付費乘車，是目前唯一真正商業化的無人駕駛服務。

現況數據

資料來源：Obi report（分析 2025/11 - 2026/01 共 94,348 筆乘車紀錄）、Morgan Stanley 估算。

從 2025 年底的數據看：

| | Tesla Robotaxi | Waymo |
|　–　|　–　|　–　|
| 每公里車費 | $1.99 | $5.72 |
| 車輛硬體成本 | ~$30,000（Cybercab） | ~$200,000 |
| 等車時間 | 15 分鐘 | 5.7 分鐘 |
| 無人駕駛狀態 | 仍有安全駕駛員 | 已完全無人 |
| 鳳凰城獲利 | 否 | 是 |

商業規模

資料來源：Contrary Research、notateslaapp.com。

這個差距的根源在商業模式決定的資料規模。

Waymo 賣服務，不賣車。他們的車是改裝的 Jaguar I-Pace，加上一堆感測器，一台 $200,000。

要擴大訓練資料，就得多派車上路，成本線性增長。

截至 2025 年初，Waymo 史上累計行駛里程約 7,100 萬英里。

Tesla 賣車給消費者。全球幾百萬台 Tesla 都在 shadow mode 默默記錄「如果 FSD 接管會怎麼做」。

每賣出一台車，消費者不只付了錢，還順便幫 Tesla 訓練模型。

到 2025 年底，Tesla FSD 累計行駛里程已超過 85 億英里，整體車隊的 shadow mode 資料更遠不止於此。

兩者相差超過 100 倍。這個差距，不是砸錢買 LiDAR 能追上的。

如果視覺派能解決惡劣天氣的弱點（Tesla FSD 在大雨、濃霧下表現仍不穩定），Tesla 幾乎必勝——因為硬體成本差了 7 倍，資料規模差了超過 100 倍。

Waymo 的策略是「先把安全做到無懈可擊，再壓低成本」。

Tesla 的策略是「先把規模做到無法追趕，再解決邊界問題」。

2026 年，這場賽局還沒有結果。

小結

2019 年，我坐在工作坊裡，看著一台小車學會跑彎道，覺得強化學習很神奇，但離現實很遠。

2026 年，Robotaxi 已經在路上跑了。

技術本身不是護城河 —— 這兩家公司對產業有不同的願景看法，所以有了不同的商業模式。

可以繼續看下去，也期待台灣能早日坐到。

參考

(fin)

[實作筆記] 個人自動化平台(四) n8n 實作：收集層，RSS 資料來源

前情提要

上一篇定好了「收集、處理、輸出」三層架構，這篇開始實作第一層：收集。

目標是從四個 AI 新聞來源拉資料，輸出統一格式，交給處理層處理。

資料來源選擇

驗證過四個 RSS 來源都可用：

來源 URL 說明
OpenAI https://openai.com/news/rss.xml 官方，第一手產品更新
Google Blog AI https://blog.google/innovation-and-ai/technology/ai/rss/ 官方，涵蓋 Gemini 等產品
The Verge AI https://www.theverge.com/rss/ai-artificial-intelligence/index.xml 綜合媒體，覆蓋廣
HackerNews https://hnrss.org/newest?q=AI&points=50 社群篩選，工程師視角

Anthropic 目前無官方 RSS，是個缺口，之後另找方案補上。

CLI 驗證方式：

1
curl -s -o /dev/null -w "%{http_code} %{url_effective}\n" <RSS_URL>

n8n 節點選擇

收集層有兩種做法：

RSS Feed Trigger + 暫存層 RSS Read + Filter
抓取方式 增量，只抓新的 全量，每次重抓
重複抓取 不會 會（Filter 擋掉舊的）
Token 消耗 較省 稍多
架構複雜度 高（需外部暫存） 低（無狀態）
適合 sub-workflow 不適合（Trigger 節點限制） 適合

現況的選擇：RSS Read + Filter

現階段優先走通整條流程，不想多依賴一個外部暫存服務。

RSS Read 是普通節點，可以被 sub-workflow 呼叫，搭配 Filter 過濾近 7 天的文章，邏輯乾淨：

1
Schedule Trigger → RSS Read → Filter（只保留近 7 天文章）

等之後有需要優化 token 消耗，再評估加暫存層。

實作步驟

步驟一：建立 Workflow

新增 Workflow，命名 [收集] The Verge AI。

觸發節點選 Schedule Trigger，預設每天午夜執行即可（之後調整為週報頻率）。

步驟二：加入 RSS Read 節點

在 Schedule Trigger 後加 RSS Read 節點，填入 URL：

1
https://www.theverge.com/rss/ai-artificial-intelligence/index.xml

步驟三：Filter 節點過濾日期

在 RSS Read 後加 Filter 節點，條件：

1
isoDate → is after → {{ $now.minus({days: 7}).toISO() }}

步驟四：Edit Fields 節點標準化輸出

在 Filter 後加 Edit Fields（Set） 節點，對應欄位：

Name Value
title {{ $json.title }}
url {{ $json.link }}
content {{ $json.contentSnippet }}
published_at {{ $json.isoDate }}
source The Verge AI

執行成功，每筆輸出格式如下：

1
2
3
4
5
6
7
{
  "title": "Cloud development platform Vercel was hacked",
  "url": "https://www.theverge.com/tech/914723/vercel-hacked",
  "content": "Vercel, a major development platform...",
  "published_at": "2026-04-19T19:54:52.000Z",
  "source": "The Verge AI"
}

四個步驟完成，收集層跑通。每次執行會輸出統一格式的文章列表，準備交給處理層處理。

API Credential 的資安決策

設定 Google Gemini credential 時，有一個值得討論的選項：Allowed HTTP Request Domains。

n8n 官方說明：

Control which domains this credential can be used with in HTTP Request nodes

這個設定限制的是被呼叫端（destination）——也就是「這組 key 只能被送往哪些 domain」，不是「誰能在 n8n 裡使用這組 key」。

能防護的範圍：

  • 攻擊者透過 HTTP Request 節點把 key 帶著打到外部惡意 server

防護不到的範圍：

  • n8n 原生節點（如 Google Gemini Chat Model）
  • 直接存取 n8n 資料庫
  • 從 n8n UI 讀取 credential

決策：填 generativelanguage.googleapis.com，遵守最小權限原則。但主要防線是 Cloudflare Access（限制誰能登入 n8n），這個設定是額外的縱深防禦，不能過度依賴。

核心原則：理解每層保護的邊界，不要以為設了就完全安全。

參考

小結

  • 收集層用 RSS Read + Filter 過濾近 7 天，四個來源統一輸出格式
  • Credential 的 Allowed HTTP Request Domains 是縱深防禦，主防線還是 Cloudflare Access
  • RSS Read 是「簡單優先」的選擇，之後有需要再加暫存層優化

(fin)

[實作筆記] 個人自動化平台(三) 收集、處理、輸出：三層可插拔管道設計

前情提要

前兩篇把 GCP VM + n8n + cloudflared tunnel 都設好了，環境就緒。

這篇不急著動手，先把架構想清楚。

目標是一個可以自由擴充的個人內容自動化平台：新增資料來源、換 AI 模型、改輸出管道，都不需要重寫整個流程。

核心設計：三層分離

把整個管道拆成三層，每層只負責一件事：

1
收集（Fetch）   →   處理（Process）   →   輸出（Sink）
  • 收集：從外部拿資料，不做任何處理
  • 處理：理解資料，產生新資訊
  • 輸出：把結果推出去

每層都是介面，實作可以自由替換或組合。

每層的邊界

收集（Fetch）

負責從各種來源拉資料：RSS、API、Webhook、爬蟲……

不管來源是什麼，輸出格式統一：

1
2
3
4
5
6
7
{
  "title": "文章標題",
  "url": "https://...",
  "content": "原文內容或摘要",
  "source": "來源名稱",
  "published_at": "2026-04-20T00:00:00Z"
}

這個格式就是「收集」和「處理」之間的契約。只要每個來源都輸出這個 schema，「處理」完全不需要知道資料從哪來。

新增來源：建一個新的 sub-workflow，輸出同樣格式。
停用來源：把那個 sub-workflow 關掉。

處理（Process）

負責理解資料，產生新資訊。

目前規劃的功能：

功能 說明
摘要歸納 把長文濃縮成重點
事實查核 驗證內容可信度（未來）
創意發想 從資料延伸新觀點（未來）

AI 是「處理」層的實作細節，不是介面的一部分。

今天用 Claude，明天換 Gemini，或跑地端模型（Ollama）——主流程不在意，只呼叫「處理」的 sub-workflow，不管裡面用的是什麼模型。

「處理」層的輸出格式：

1
2
3
4
5
6
7
8
{
  "title": "文章標題",
  "url": "https://...",
  "summary": "AI 整理的重點",
  "tags": ["AI", "LLM"],
  "source": "來源名稱",
  "published_at": "2026-04-20T00:00:00Z"
}

輸出（Sink）

負責把結果推出去。

兩個維度都可以擴充：

格式：

  • 純文字
  • 簡報（未來）
  • 影音（未來）

管道：

  • Email
  • LINE
  • YouTube / Instagram / Facebook（未來）

從「處理」到「輸出」可以有多條路線，同一批摘要可以同時走不同路線，互不干擾：

1
2
3
4
處理（摘要結果）
  ├─ → Email 週報（長版純文字）
  ├─ → LINE 推播（短版）
  └─ → 存檔（JSON，備用）

在 n8n 的實作方式

n8n 的 sub-workflow 機制很適合做這件事：

  • 每個「收集」來源 → 一個 sub-workflow
  • 每個「處理」功能 → 一個 sub-workflow
  • 每個「輸出」管道 → 一個 sub-workflow
  • 主流程：用 Execute Workflow 節點串起來，用 Merge 合併多個來源，用 Switch / If 分流到不同輸出

新增或停用任何環節，只需要在主流程加減節點，不動其他邏輯。

小結

  • 三層分離（收集、處理、輸出），每層依賴介面不依賴實作
  • 各層之間用固定的 JSON schema 溝通，是可替換性的基礎
  • 「處理」層的 AI 模型是實作細節，抽成 sub-workflow 就能自由替換
  • 「輸出」層支援多路線同時輸出，格式和管道各自獨立擴充
  • n8n 的 sub-workflow 機制天然適合這個設計

下一篇開始動手實作第一條 pipeline：AI 新聞週報。

參考

(fin)

[實作筆記] 個人自動化平台(番外) 拆掉重建 GCP VM & Cloudflared Tunnel & Cloudflare Access

前情提要

前兩篇把 GCP 免費 VM + n8n + cloudflared tunnel + Cloudflare Access 都設好了。

但整個過程是邊做邊踩坑，步驟不一定是最乾淨的順序。
這篇把環境完整清理掉，再照前兩篇的步驟重建一次，驗證文章可以重現。

清理步驟

清理順序：從外到內，先 Cloudflare 再 GCP。

步驟一：刪除 Cloudflare Access Application

進 Cloudflare 主控台 → Zero Trust → Access → Applications

找到 butler.marsen.me 的 application，刪除。

驗證：開瀏覽器試 https://butler.marsen.me，如果 Access 已清除，不會再看到驗證頁面。

步驟二：刪除 Cloudflare Tunnel

SSH 進 VM，先停 cloudflared service，再刪 tunnel：

1
2
sudo systemctl stop cloudflared
cloudflared tunnel delete butler

驗證：

1
cloudflared tunnel list

butler 不在列表裡就是刪成功了。

也可以在 UI 刪：Zero Trust → Networks → Tunnels → 找 butler → 刪除。
但要先確認 tunnel 已停止（cloudflared service 停掉或 VM 已關機）。

步驟三：刪除 DNS 記錄

進 Cloudflare 主控台 → marsen.me → DNS

找到 butler.marsen.me 的 CNAME 記錄（4ba20fc4-...cfargotunnel.com），刪除。

驗證：開瀏覽器，出現 DNS_PROBE_FINISHED_NXDOMAIN 就是清除成功。

DNS 記錄目前只能透過 UI 刪除，或使用 Cloudflare API（需要 API Token）。

步驟四：刪除 GCP VM

1
2
3
gcloud compute instances delete ai-butler-vm00 \
  --zone=us-east1-b \
  --project=YOUR_PROJECT_ID

確認後輸入 Y，VM 和磁碟都會一起移除。

參考

清理完成後，照以下兩篇文章重建

小結

  • 清理順序：從外到內，先 Cloudflare 再 GCP，避免 tunnel 刪除時出現狀態不一致
  • 刪 VM 時磁碟會一起移除，n8n 資料不保留

(fin)