前情提要

AI Coding 工具迭代太快，半年就是一個世代。
趁 2026 年中把目前市場上的 Agent Coding 工具盤點一次，
排名依據是實際開發者採用度、Agent 能力、社群討論度、企業導入率，不是單純的 IDE 補全。

結論先講：2026 最主流的組合是 Cursor + Claude Code，不是單一工具。

總排名

功能比較

以我的情境怎麼選

我的背景：技術主管、Python / FastAPI、Azure / GCP、系統架構、DevOps、AI 應用開發。

第一名：Claude Code

適合的場景：

• 重構大型專案
• 架構分析
• Code Review
• 寫 ADR
• 拆 Epic

目前幾乎是 Agent 能力的天花板，缺點就是貴。

第二名：Cursor

適合日常寫程式：FastAPI、Terraform、Docker、Kubernetes，體驗最好。

值得注意的是，很多人現在的用法是 Cursor + Claude 模型，
而不是用 Cursor 自己的 Agent。

第三名：OpenAI Codex

如果你想要的是：

• 一次開 10 個任務
• Agent 自己修 Bug
• Agent 自己開 PR

Codex 的雲端 Sandbox 架構很有潛力，背景執行是它的主場。

開源派排行

不想被平台綁定的話：

代價是 UX 與 Token 成本要自己扛。

趨勢：三年三個世代

• 2024：Copilot 時代
• 2025：Cursor 時代
• 2026：Claude Code vs Codex 時代

很多工程師的演進路徑是：

1

Copilot → Cursor → Claude Code

而目前最常見的組合是：

1

Cursor IDE + Claude Code Agent + Claude Opus

單一工具吃全場的時代已經過去了。

參考

• 14 Best AI Coding Agents (2026): Full Rankings - Morph
• Best AI Coding Agents in 2026: Claude Code vs Codex vs … - Admix
• An Accel VC says the vibe coding market is big enough for Cursor and Claude Code - Business Insider
• Open-Source AI Coding Agents 2026 - We The Flywheel
• Every AI Coding CLI in 2026: The Complete Map (30+ …) - DEV Community

小結

• 2026 年中的格局：Claude Code 是 Agent 能力天花板，Cursor 是體驗最好的 IDE，Codex 押注雲端背景執行。
• 排名看綜合採用度，但選工具要看自己的場景：重構與架構工作用 Claude Code，日常開發用 Cursor。
• 要省成本或不想被綁平台，開源派看 Aider 與 Cline。
• 最主流的答案不是二選一，是 Cursor + Claude Code 的組合。

(fin)

本周要點

• 秘密向 SEC 提交 S-1 註冊聲明草案：OpenAI 宣布已向美國證券交易委員會（SEC）秘密提交了 S-1 格式的招股說明書草案，準備進行首次公開募股（IPO）。這標誌著該公司在商業化與資本市場化道路上的重大里程碑。more
• 智能時代的產業政策：OpenAI 提出了針對智能時代的產業政策藍圖，強調需要建立強大的 AI 基礎設施，包括能源、晶片及數據中心。此政策旨在確保國家競爭力並促進 AI 技術的民主化與安全發展。more
• 築夢：為更具幫忙能力的 ChatGPT 提供更好的記憶力：OpenAI 推出名為「Dreaming」的新技術，旨在升級 ChatGPT 的記憶機制。透過在後台進行「夢境」般的離線整合，ChatGPT 能更有效率地整理與回顧過往的對話上下文，提供更具連貫性且個人化的互動體驗。more
• 旨在造福大眾：我們的計劃：OpenAI 發表了其未來的發展計劃，重申確保通用人工智能（AGI）造福全人類的使命。該計劃詳細說明了治理結構的優化以及如何將 AI 技術帶來的經濟價值公平地分配給社會各界。more
• 介紹 GPT-Rosalind 的全新功能：OpenAI 宣布為 GPT-Rosalind 引入全新功能，提升其在科學研究與複雜邏輯推理方面的表現。這次更新將使該模型能更有效地協助生物學及其他前沿科學領域的研究人員進行探索。more
• 推出 OpenAI 經濟研究交流平台：OpenAI 成立了「經濟研究交流平台（Economic Research Exchange）」，旨在與全球學術界和政策制定者合作，共同研究 AI 對勞動力市場、生產力以及整體經濟結構的深遠影響。more
• 智能時代的生物防禦：本文探討了在 AI 快速發展的時代下，如何利用先進模型來強化全球生物防禦系統。OpenAI 強調了制定安全防護措施的重要性，以防止技術被濫用，同時利用 AI 預防與應對潛在的生物安全威脅。more

其他訊息

• 從數據到決策：LSEG 如何擴展可信賴的 AI
• Nextdoor 的工程師如何利用 Codex 進行無限創意的構建
• Codex 為 Notion 釋放了什麼潛能
• Endava 如何圍繞 AI 代理重新設計軟體交付

(fin)

前情提要

Hero 要放一支滿版自動播放的背景影片。

Hero 區塊是網頁最頂部的全版區塊，通常含標題、說明文字與背景，是訪客進站看到的第一眼。

素材要放哪，已在上一篇整理好了，結論是放 public/，URL 字串直接用。

這篇專注在另外兩個問題：

1. 流量控管：滿版自動播放背景影片是首頁最吃流量的東西，怎麼估、怎麼省？
2. UI 體驗：背景影片要無控制列、自動播放、靜音、循環——原生 <video> 還是嵌入 YouTube／Vimeo？

自存影片：會吃多少流量？

會，而且滿版自動播放的背景影片，是整頁最吃流量的東西。

粗估一下：一支壓到 SD 的背景影片約 3.5MB，每個訪客每次載入首頁就抓一次（瀏覽器會快取，回訪者不重抓）。

1

3.5MB × 10,000 次造訪/月 ≈ 35GB/月

對小型品牌站通常還在額度內，但要注意兩件事：

1. 行動裝置上，這 3.5MB 是吃訪客自己的行動數據，UX 不友善。
2. 影片越大支越可怕，HD 1080p 動輒 12MB 起跳。

重點觀念：走 CDN ≠ 不算流量

很多人以為「丟到平台、平台有 CDN」就沒事了。

以主流部署平台來說，public/ 的靜態檔確實會由它的 Edge Network（CDN）快取分送——但傳輸量仍然計入你的方案額度。

CDN 解決的是「分送速度與快取」，不是「免費流量」。要真正卸載流量，得換 host。

要省流量：CDN / 影音 host 比較

影片放在 public/ 的話，流量算在部署平台的額度裡。

以我們用的平台　Vercel 免費方案只有 100GB/月，一支背景影片流量大的時候很快就吃光。

解法是把影片搬到外部 host，讓別人的伺服器去扛流量。

好消息是，只要程式碼只用 URL 字串引用影片，換 host 就是換那個字串，不用改程式碼：

1
2
3
4
5

// 原本放 public/
<video src="/hero.mp4" />

// 搬到 R2 後，只改這一行
<video src="https://pub-xxx.r2.dev/hero.mp4" />

兩條路線：

路線一：自己存，外部 CDN 來送（Cloudflare R2

把影片傳到 R2，egress（流出流量）免費，只付儲存費（$0.015/GB/月）。一支 5MB 影片幾乎是 $0，部署平台那邊完全不計這筆流量。

路線二：讓別人的平台吸收（Vimeo/Youtube）

影片上傳到 Vimeo，你的伺服器完全不出流量，由 Vimeo 負責送給訪客。代價是多了第三方依賴，免費方案有上傳量限制。

形象站的滿版背景，通常不會用 YouTube，原因看下面。

YouTube 當「無播放器」背景？hack 與代價

YouTube 這麼主流，能不能拿來當乾淨背景？

沒有官方乾淨方案，主流做法都是 hack，而且 YouTube 近年反而把「藏品牌」收得更緊。

做法是 IFrame Player API + 參數 + CSS：

1

autoplay=1&mute=1&loop=1&playlist=VIDEO_ID&controls=0&playsinline=1&rel=0&disablekb=1&iv_load_policy=3

1
2
3
4
5
6
7
8

/* 把 iframe 放大超出視窗、置中裁切，藏掉黑邊與殘留 UI */
.bg-wrap { position: absolute; inset: 0; overflow: hidden; }
.bg-wrap iframe {
  position: absolute; top: 50%; left: 50%;
  width: 150vw; height: 150vh;        /* 刻意超出 */
  transform: translate(-50%, -50%);
  pointer-events: none;                /* 防止點到跳出控制列 */
}

代價很實際：

• modestbranding 已被 YouTube 淡化／移除，載入、暫停、結束仍可能閃一下 logo／標題。
• 單片循環要用 loop=1&playlist=ID 的 trick，接點會黑屏跳一下（要用 API seekTo(0) 才順）。
• 16:9 硬裁成滿版 → 邊緣被切掉。
• 比原生 <video> 重很多（要載播放器 JS、追蹤 cookie，除非用 youtube-nocookie）。
• 手機（尤其 iOS）自動播放不穩。
• 「完全藏品牌」本身遊走在 ToS 邊緣。

真正乾淨的主流解

1. Vimeo 背景模式

Vimeo 的嵌入支援 background=1 參數，這是官方為背景影片設計的模式：自動播放、循環、靜音、全程無控制列、無品牌。

1

https://player.vimeo.com/video/VIDEO_ID?background=1&muted=1&autoplay=1&loop=1

要 iframe 又要乾淨，這才是該選的，比 YouTube hack 乾淨太多。

2. 影音 CDN 的 mp4 + 原生 video

把影片放 Stream / Mux / R2，拿到真正的 mp4／HLS URL，用原生 <video> 播。

最乾淨、最可控，也最好做手機降級（poster、preload、小螢幕只給圖）。

架構建議：媒體以 URL 為主

把這些湊起來，得到一個簡單原則：渲染層不要綁死 host。

• 媒體只存一個 URL 字串（哪來的都行：自家 public/、R2、Mux、Vimeo iframe）。
• 範例／預設素材放 public/，跟使用者貼的網址走同一條路徑。
• 正式上線要換成 CDN？貼上新 URL 即可，不用改程式碼。
• 要支援 iframe 型（Vimeo／YouTube）就多開一種「媒體類型」，渲染分流到 iframe，原生影片仍走 <video>。

這樣早期可以自存 demo、之後無痛換成專業影音 CDN，決策成本最低。

參考

• 形象站滿版背景影片（一）：前端靜態資源放哪裡

小結

• 滿版自動播放背景影片最吃流量；CDN 加速 ≠ 免費流量，傳輸仍算額度。
• 省流量靠換 host：R2（egress 免費）/ Stream / Mux / Cloudinary。
• YouTube 無播放器背景只能 hack，缺點一堆；要 iframe 乾淨解請用 Vimeo background=1。
• 最乾淨：影音 CDN 的 mp4 + 原生 <video>。
• 架構上讓媒體「只認 URL」，換 host 就是換字串，不用動程式碼。

(fin)

前情提要

我有個 n8n workflow，每週自動抓 AI 新聞 → Gemini 生週報 → 發一篇 IG，順便生一張配圖、也產一篇 Blog 週報開 PR。

跑了一陣子，兩個毛病：

1. 每次發兩篇 IG，一篇正常、一篇是空的。
2. 配圖每週都是動物，跟當週主題八竿子打不著。

本來以為是兩個獨立問題，結果查下去——根因是同一條接錯的線。這篇記錄整個排查過程，還有後面為了「免費生圖」繞的一大圈。

流程長怎樣

出問題時的原始架構：

1
2
3
4

Schedule → RSS×4 → Filter → Edit Fields → Aggregate
  ├─ 文字生成(Gemini)        → IG 準備發文 → IG 發佈
  ├─ 生成圖片 Prompt(Gemini)  → IG 準備發文   ↑（兩條線都接這）
  └─ Blog 生成(Gemini)       → GitHub 建 branch → commit → 開 PR

配圖用 image.pollinations.ai 生成，圖片 URL 直接餵給 IG。

問題一：一次發兩篇 IG

根因

讀 workflow JSON 畫連線，發現 IG 準備發文 這個節點的同一個輸入埠（input 0）被兩條線餵：文字生成 和 生成圖片 Prompt 都接進去。

n8n（executionOrder v1）在「同一輸入埠收到多條來源連線」時，每條來源各觸發一次該節點 → IG 準備發文 跑兩次 → 發兩篇。這是 n8n 經典陷阱：該用 Merge 合併分支的地方，直接把兩條線併到同一個 input。

順便還抓到一個 bug：IG 那個 httpRequest 的 body 參數名是 " image_url"，開頭多一個空格，IG 收到的 key 變成 image_url 被忽略 → 圖片沒帶進去 → 空貼文。

修法

把「並聯」改成「串聯」：

1

Aggregate → 文字生成 → 生成圖片 Prompt → IG 準備發文

• IG 準備發文 只剩一條 input → 跑一次 → 發一篇
• 順手把 " image_url" 的空格拿掉

問題二：圖片每週都動物

根因（其實還是那條線）

Pollinations 要的是「視覺場景描述」（英文、具體畫面），餵新聞摘要長文它抓不到重點 → 退化成安全牌，而動物是文字生圖最常見的 fallback。

但更前面的根因是：workflow 裡其實已經有一個「生成圖片 Prompt」的 Gemini 節點，prompt 也寫得不錯（挑最有畫面感的一則、用英文描述場景）。問題是它接錯位置——從 Aggregate 進來，而 Aggregate 輸出的是 { data: [...] }，沒有 .text。節點模板寫 {{ $json.text }} → 拿到 undefined → 等於餵空內容 → 圖當然爛。

所以同一個接線錯誤：既讓 生成圖片 Prompt 拿不到週報內容，又跟 文字生成 併線造成重複發文。

修法

問題一的串接修法，順便就解了問題二——生成圖片 Prompt 接在 文字生成 之後，$json.text 真的拿得到週報全文了。再把它的 prompt 強化（固定畫風關鍵字 digital illustration, vibrant colors, no text, no logo、排除人名品牌、加 SFW 防護）。

教訓：兩個看起來無關的 bug，根因可能是同一個。先畫連線圖再動手。

插曲一：Blog 分支同天重跑撞名（422）

修完去重跑驗證，Blog 那條噴 422 Reference already exists。

根因：branch 名固定用 weekly/{{yyyyMMdd}}，同一天手動重跑就撞到自己上次建的 branch。正常每週排程日期不同不會撞，但測試時會。

修法：

• branch 名改成 weekly/{{yyyyMMdd-HHmmss}}，同天重跑不撞
• 後面 commit / 開 PR 的節點，branch 改成讀「建 branch」實際回傳的 ref（.ref.replace('refs/heads/','')），保證三個節點用同一個名字，不會各自用 $now 重算而漂移

插曲二：4 個 RSS 來源讓整條鏈跑多次

上線後跑了一次排程，GitHub 吐出 PR #65 和 PR #66——同一週跑出兩個週報 PR，IG 也連帶發了兩篇。

根因跟問題一其實是同一個模式：4 個 RSS 來源（Theverge、OpenAI、Google AI、Hackernews）各自直接連到 Filter 的 input 0，n8n 把每條來源視為獨立執行分支，Filter → Edit Fields → Aggregate 以下的整條鏈跑了 4 次，GitHub Create PR 就出現了 4 次（有的因 branch 撞名被 422 擋掉，但 IG 發文的那幾次成功了）。

修法：在 4 個 RSS Read 之後加一個 Merge RSS 節點（append mode），把 4 條分支匯聚成一條再進 Filter，確保下游只跑一次。

1

RSS×4 → Merge RSS（append）→ Filter → Edit Fields → Aggregate → ...

Merge 節點已加入，等下次排程（每週三）實際跑一次驗證。

大冒險：到底哪裡能免費生圖？

IG 兩個原始 bug 修好上線了，但配圖來源出事——這段繞最久。

關鍵限制：IG Graph API 是用「它自己的伺服器」去抓 image_url。所以不管我這邊怎麼生圖，只要那個 URL 被擋，IG 就抓不到。

繞一圈結論：「真正免費、不綁卡、又能讓第三方抓圖」的組合幾乎絕跡。

最終解：Cloudflare Workers AI + GitHub 托管 + 一圖共用

先講結論：用 Cloudflare Workers AI 的 flux-1-schnell 生圖（免費、不綁卡），把圖 commit 進 Hexo repo，文章嵌入它、IG 也用同一張的 raw URL。

為什麼是 Cloudflare Workers AI

• 免費層每天 10,000 neurons，不用綁信用卡，只要免費 Cloudflare 帳號
• 一週一張圖，額度永遠用不完 → 實質 $0
• 實測 OK：回合法 1024×1024 JPEG（base64）

為什麼一定要自己托管圖（這步躲不掉）

IG 發「照片」貼文時，是給它一個公開 URL、它自己伺服器去抓——不能直接上傳圖片 bytes（只有 Reels／影片能 binary 上傳）。而 flux 回的是 bytes 不是 URL。所以中間一定要有個「把 bytes 變成公開 URL」的托管處。

評估過 R2 / GCS / Imgur / 備份 repo，最後選 Hexo 的 public repo：

• GitHub 憑證早就接在 n8n 裡、repo 又是 public → 零新帳號、零成本、IG 抓 raw.githubusercontent.com 很穩
• 備份 repo 不能用（private + 內含明文 token，不能公開）
• 巧合：flux 回 base64、GitHub Contents API 剛好也吃 base64，中間免轉檔

一圖共用（這次的重點設計）

原本 Blog 與 IG 是兩條平行分支。為了「文章嵌圖 + IG 用同一張」，把它們串成一條：生一次圖 → commit 到該週分支 → 文章 md 嵌入 ![](/images/...) → IG 用同一張的 raw URL。一次生圖、零重複、圖也進了 blog。

1
2
3

Aggregate → Blog生成 → 文字生成 → 生成圖片Prompt → CF生圖(flux,base64)
→ 取main SHA → 建分支(weekly/<日期-時間>) → 上傳圖到GitHub
→ Blog建檔(嵌圖) → Blog Post → 開PR → IG準備發文(同一張raw URL) → Wait → IG發佈

代價：兩條從「獨立」變「耦合」（中間任一步失敗，後面不跑）。換來一圖共用。

接的時候又踩的坑

• n8n Header Auth 憑證填錯欄位 → 401：Name 要填 Authorization（不是憑證用途名），Value 要 Bearer <token>（不是只貼 token）。
• CLI import vs UI 編輯互相蓋：用 CLI 匯入改的是 DB，但若瀏覽器還開著舊畫布，一存就把匯入蓋掉。改之前先關掉所有編輯分頁、改完再 refresh。
• Gemini 503 過載：gemini-flash-latest 遇大尖峰整個 workflow 掛。加 retryOnFail（4 次／5 秒）擋小尖峰；大範圍過載只能換模型（換成 gemini-flash-lite-latest）。已記成 backlog，想做「多模型自動 fallback」。
• Blog CI 競態：repo 的 ci.yml 在 pull_request 也跑，會在 PR 的 detached HEAD 上把 ncu -u 結果推回 main → 必然 ! [rejected] (fetch first)，每開一個週報 PR 就失敗一次。修法：拿掉 pull_request 觸發 + 加 concurrency。

小結

• 兩個看似獨立的 bug（發兩篇、圖都動物），根因是同一條接錯的線。排查 n8n 先畫連線圖。
• n8n「同一輸入埠接多條線會重複觸發」，要合併分支用 Merge、別直接併線。
• 跨節點共用的值（branch 名）算一次、其他節點引用，別各自 $now 重算。
• 免費服務會退化：Pollinations 從「免簽免 key」變 402 + 加密付款；Gemini 圖片免費層 limit=0。架構別把命脈押在單一免費服務上。
• IG 發照片一定要公開圖床（它自己抓 URL），逼你先想清楚托管在哪。
• 動手前先驗證（列得出模型 ≠ 生得出圖、free tier 可能 limit=0），而且會花錢／動到別人系統的事先問過再做。

（Merge RSS 節點已加，等下次排程實際跑過驗證。之後補上實際成品圖。）

參考

• 個人自動化平台(一) 用 GCP 免費 VM 跑 n8n
• 個人自動化平台(二) Cloudflare Access & Cloudflare Tunnel
• 個人自動化平台(三) 收集、處理、輸出：三層可插拔管道設計
• 個人自動化平台(番外) 拆掉重建 GCP VM & Cloudflared Tunnel & Cloudflare Access
• 個人自動化平台(四) n8n 實作：收集層，RSS 資料來源
• 個人自動化平台(五) n8n 實作：處理層，Aggregate + Gemini 週報整理
• 個人自動化平台(六) n8n 實作：輸出層，Instagram API 取得 Token 全記錄
• 個人自動化平台(番外) Google OAuth redirect_uri_mismatch 除錯記錄
• 個人自動化平台(七) n8n 自動備份：CLI export + git
• 個人自動化平台(番外) 更新自架在 GCP VM 上的 n8n（Docker 版）

(fin)

本周要點

• OpenAI 前沿模型與 Codex 現已登陸 AWS：OpenAI 宣布其前沿模型與 Codex 系列正式整合至 AWS 平台，協助企業開發者更高效地構建 AI 應用。 more
• ChatGPT 的記憶優化計畫：Dreaming：OpenAI 推出「Dreaming」機制，旨在強化 ChatGPT 的記憶功能，使其能更精準且具備連貫性地提供使用者所需的協助。 more
• 為前沿 AI 建立民主化治理藍圖：OpenAI 提出一套關於前沿 AI 治理的藍圖，強調在發展尖端技術的同時，必須確保其安全性、透明度與全球性的民主參與。 more
• 在密西根州構建智慧時代的基礎設施：OpenAI 宣布將在密西根州建立大型數據中心項目 Stargate，為 AI 運算需求提供強大的硬體支持。 more
• Endava 如何圍繞 AI Agents 重塑軟體交付：Endava 透過引入 AI Agents 技術，徹底改變了傳統軟體開發與交付的流程，大幅提升了開發效率。 more
• 波士頓兒童醫院利用 AI 開啟新的診斷路徑：波士頓兒童醫院正應用 OpenAI 的技術輔助醫師進行複雜病例的診斷，為醫療領域帶來了新的突破。 more
• Travelers 保險公司在全國範圍部署 AI 理賠系統：保險巨頭 Travelers 與 OpenAI 合作，全面部署 AI 驅動的理賠處理流程，顯著縮短了客戶等待時間。 more

其他訊息

• 智慧時代的生物防禦
• 為 GPT-Rosalind 引入全新能力
• Wasmer 如何利用 Codex 建構 Edge 端的 Node.js 運行時
• OpenAI 公共政策議程
• Codex 適用於所有職位、工具與工作流
• 透過全球領導力推動青年安全與機遇
• Codex 正成為全民生產力工具
• 我們對 AI 政策與政治倡議的觀點
• Braintrust 如何利用 Codex 將客戶需求轉化為程式碼

(fin)

前情提要

這幾天整理 Cloudflare 的 DNS，看到幾筆我沒有記憶也不理解的記錄：

1

send.marsen.me   MX   feedback-smtp.ap-northeast-1.amazonses.com

Amazon SES？我什麼時候設過？還在用嗎？敢不敢刪？

不確定就不要亂刪 DNS——刪錯一筆，輕則信進垃圾桶，重則收不到信。所以乾脆把整個 marsen.me 上的 email 服務盤點一次，搞清楚每一筆 DNS 到底在幹嘛。

第一步，列出 DNS Record

把 DNS 裡跟 email 有關的記錄抓出來，對應到服務：

| 服務 | 相關 DNS 記錄 |
|　——　|————–|
| Cloudflare Email Routing | marsen.me MX（route1-3.mx.cloudflare.net） |
| Brevo（原 Sendinblue） | brevo1/2._domainkey CNAME |
| Resend | resend._domainkey TXT |
| Amazon SES | send.marsen.me MX + SPF |

四套服務、一堆 DKIM/SPF/MX，光看 DNS 根本分不出哪些還在使用，用途為何？

第二步，理解 DNS Record

可以參考文章最末的參考資料，這裡簡單說明 MX 與 SPF，以後有機會再進一步說明

MX: 告訴別人「寄到 @你的網域 的信，送去哪台伺服器，

你家的收件信箱地址，別人寄東西來才送得到。

SPF / DKIM = 你寄信時的防偽印章和授權書。

證明「這封信真的是你（或你授權的服務）寄的」，防止被當垃圾或冒名

所以一個純發信的服務（像 Brevo、Resend），只需要 DKIM 印章，根本不需要 MX。這個觀念是後面判讀的基礎。

補充：SPF 和 DKIM 的內容本體都是 TXT，但 DKIM 有兩種發布方式——
一種像 Resend 是把公鑰直接寫成 TXT 給你貼；
另一種像 Brevo 則是給你一筆 CNAME，把 brevoX._domainkey 委派指向它自家的 DNS，公鑰放在它那邊，方便它自己輪替金鑰。
所以上面表格裡 Brevo 是 CNAME、Resend 是 TXT，但做的是同一件事。

寄收信測試

我們可以查看郵件 header——它記錄了一封信實際走過的每一站。

方法很簡單：寄一封測試信給自己，打開「顯示原始郵件」看 header。

我用 [email protected] 寄一封信給自已

1
2
3
4
5

Message-Id: <[email protected]>
Received: from hb.d.sender-sib.com (...)
DKIM-Signature: ... d=marsen.me s=brevo2 ...   → PASS
Feedback-ID: ...:Sendinblue
Return-Path: <[email protected]>

sendinblue、sender-sib（SendInBlue 的縮寫）、s=brevo2 的 DKIM 簽章——這封信百分之百走 Brevo 發出。

s=brevo2 還正好對應到我 DNS 裡的 brevo2._domainkey。Brevo 確認在用。

同一封信，還證明了收信端

更妙的是，這封我寄給 [email protected] 的信，被轉發回我 Gmail，header 把收信路徑也記下來了：

1
2
3
4

Received: by cloudflare-email.net       → Cloudflare Email Routing 收到
X-Forwarded-To: [email protected]
X-Forwarded-For: [email protected] [email protected]
Delivered-To: [email protected]

一封信同時驗證了兩端：Brevo 發信 → Cloudflare Email Routing 收信並轉發 → 進 Gmail。

那「收信」到底是怎麼運作的？

順著 header 就看懂了，我的收信是 Cloudflare Email Routing：

1
2
3
4
5

別人寄到 [email protected]
  → marsen.me 的 MX 指向 Cloudflare（route1-3.mx.cloudflare.net）
  → Cloudflare Email Routing 收到
  → 依轉發規則（Routes）轉寄
  → 我的真實 Gmail

重點：Cloudflare Email Routing 是轉發，不是信箱。

它不存信，收到就立刻轉寄到你真正的 Gmail。所以 @marsen.me 沒有獨立的信箱空間，所有信最終都進同一個 Gmail。

整套自訂網域信箱長這樣：

1
2
3

            ┌─ 收信 → Cloudflare Email Routing（MX）→ 轉發 ┐
@marsen.me ─┤                                              ├→ Gmail
            └─ 寄信 ← Brevo SMTP relay ← Gmail「以 admin@ 寄」┘

用免費服務，把 Gmail 變成 @marsen.me 的網域信箱。

這就是我免費達成私有 domain 信件寄收的作法，但是要注意 Brevo 有每日 300 封信的使用上限

盤點結果

三重交叉查證（程式碼 grep、n8n 備份、郵件 header）之後：

| 服務 | 狀態 | 證據 |
|　——|——|——|
| Cloudflare Email Routing | ✅ 在用 | header 轉發路徑 |
| Brevo | ✅ 在用 | header 的 sendinblue / brevo2 簽章 |
| Resend | ✅ 在用 | 電商專案發訂單信，程式碼有引用 |
| Amazon SES | ❌ 殘留 | 任何地方都找不到使用，連 SES 驗證記錄都沒有 |

SES 是當初設定網域信箱時評估過的備選方案（按量計費、便宜但設定複雜），最後選了 Brevo，

但 AWS 用的　send.marsen.me 的 MAIL FROM 記錄留下來沒清。

為什麼在用的 Brevo 沒有 MX，沒用的 SES 反而有？

這題剛好回扣前面「收信才用 MX」的觀念，但有個例外：

• Brevo：純發信，靠 DKIM + SPF 驗證授權，不需要 MX。所以它在用，卻沒有 MX。
• SES：那個 send.marsen.me 的 MX 不是收一般信，而是 SES 的「custom MAIL FROM」機制要求的，用來接收退信/投訴回報（bounce/complaint）。

諷刺的是：沒在用的 SES 因為特殊機制留了 MX，在用的 Brevo 因為純發信反而沒有 MX。

光看「有沒有 MX」完全判斷不出哪個在用。

安全清理

確認 SES 是殘留後，要刪的只有兩筆（name 都是 send.marsen.me）。

刪之前先把完整內容記下來——理論上它一定沒用了，但留個底，萬一哪天要恢復可以照著重建：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

# ── 被刪除的 SES 殘留記錄（刪除日：2026-06-04，留供日後恢復）──

# 第一筆：SES custom MAIL FROM 的 bounce 接收
Type     = MX
Name     = send.marsen.me
Content  = feedback-smtp.ap-northeast-1.amazonses.com
Priority = 10
Proxy    = DNS only
TTL      = 1 hour

# 第二筆：SES 的 SPF
Type     = TXT
Name     = send.marsen.me
Content  = "v=spf1 include:amazonses.com ~all"
Proxy    = DNS only
TTL      = 1 hour

註：若真要復原 Amazon SES 寄信，光補這兩筆 DNS 不夠，還得回 AWS Console（ap-northeast-1 東京）重新驗證 identity 與 custom MAIL FROM。這兩筆只是當時設定留下的 DNS 半成品。

小結

盤點 email DNS 殘留，兩個心法：

1. 分清收信和發信——MX 是收信，SPF/DKIM 是發信驗證。看到一筆記錄先問它管的是收還是發。
2. 用郵件 header 當偵探——dashboard 會騙人，header 不會。寄封測試信，原始 header 裡寫得清清楚楚這封走了哪些服務。記得用網域地址寄，別用個人信箱，不然測了個寂寞。

殘留通常來自「評估過但沒採用的方案」——設定設了一半，淘汰後忘了清。盤點一次，把死記錄清掉，DNS 才乾淨。

補充：DNS 記錄類型速查

參考

• 怎麼建立一個網站？(四) - 自訂網域 EMail 收寄信（使用 Cloudflare 與 Brevo）

(fin)

前情提要

自架 n8n 跑在 GCP VM 的 Docker container，
某天備份 log 出現這行：

1

Error tracking disabled because this release is older than 6 weeks.

意思是 n8n 的 release 超過六週就會關掉錯誤追蹤，提醒你該更新了。
趁機整理一下 Docker 版 n8n 的更新流程。

更新前先確認現況

確認目前版本

1
2

docker exec n8n n8n --version
# 2.16.1

確認 container 設定

更新要重建 container，所以要先抓出原本的設定：

1
2
3
4
5
6
7
8
9

docker inspect n8n --format '{{json .HostConfig.PortBindings}}'
# {"5678/tcp":[{"HostIp":"","HostPort":"5678"}]}

docker inspect n8n --format '{{range .Mounts}}{{.Source}}:{{.Destination}}{{end}}'
# /home/user/.n8n:/home/node/.n8n

docker inspect n8n --format '{{range .Config.Env}}{{println .}}{{end}}'
# N8N_SECURE_COOKIE=false
# ...（其他是 image 預設的，不用帶）

重點是找出三個東西：port、bind mount 路徑、自己設的 env。

更新三步驟

Step 1：pull 最新 image

1

docker pull docker.n8n.io/n8nio/n8n

Step 2：停掉舊 container

1

docker stop n8n && docker rm n8n

這時候 n8n 停機，資料不會消失，因為資料在 VM 本地的 bind mount 目錄，
跟 container 的生命週期完全無關。

Step 3：用相同設定重新啟動

1
2
3
4
5
6
7

docker run -d \
  --name n8n \
  --restart unless-stopped \
  -p 5678:5678 \
  -v /home/user/.n8n:/home/node/.n8n \
  -e N8N_SECURE_COOKIE=false \
  docker.n8n.io/n8nio/n8n

把 -v 的路徑換成你自己的 bind mount 路徑，env 只帶你自己加的就好。

驗證

1
2

docker exec n8n n8n --version
docker ps | grep n8n

確認版本號，確認 container 狀態是 Up，完成。

補充：備份

更新前要不要備份？

如果你有設 bind mount，資料就在 VM 本地，container 停掉不影響。
但如果更新後 n8n 有 migration 問題，舊 DB 可能回不去。

保險做法是更新前先手動跑一次備份：

1
2
3
4
5
6
7

# 匯出所有 workflow
docker exec n8n n8n export:workflow --all --pretty \
  --output=/home/node/.n8n/exports/workflows/

# 匯出所有 credentials
docker exec n8n n8n export:credentials --all --pretty \
  --output=/home/node/.n8n/exports/credentials/

或者搭一個 cron job 每天自動備份、git push，就不用每次更新前手動跑：

1
2

# crontab -e
0 3 * * * /home/user/n8n-backup/backup.sh >> /var/log/n8n-backup.log 2>&1

參考

• 個人自動化平台(一) 用 GCP 免費 VM 跑 n8n
• 個人自動化平台(二) Cloudflare Access & Cloudflare Tunnel
• 個人自動化平台(三) 收集、處理、輸出：三層可插拔管道設計
• 個人自動化平台(番外) 拆掉重建 GCP VM & Cloudflared Tunnel & Cloudflare Access
• 個人自動化平台(四) n8n 實作：收集層，RSS 資料來源
• 個人自動化平台(五) n8n 實作：處理層，Aggregate + Gemini 週報整理
• 個人自動化平台(六) n8n 實作：輸出層，Instagram API 取得 Token 全記錄
• 個人自動化平台(番外) Google OAuth redirect_uri_mismatch 除錯記錄
• 個人自動化平台(七) n8n 備份自動化：workflow + credentials → GitHub
• 個人自動化平台(番外) n8n AI 週報踩坑記：一條接錯的線，與找免費生圖來源的旅程

小結

Docker 版 n8n 更新流程：

1. docker pull — 拉新 image
2. docker stop n8n && docker rm n8n — 移除舊 container
3. docker run — 用相同設定重建

停機時間大約 30 秒。
關鍵是 bind mount：資料住在 VM，不住在 container，container 砍掉重練資料不受影響。

(fin)

前情提要

最近在電商專案要把虛構金流換成真實串接，比較了 TapPay、綠界、藍新三家。

比著發現原來存在著兩種金流串接的模式。

• Prime Token 模式：TapPay、Stripe、Braintree
• MPG(Merchant Payment Gateway) 模式：綠界 ECPay、藍新 NewebPay

兩種模式選錯，後面整個訂單系統的設計都會錯。

本質差異就一個問題：卡號從哪走？

兩種模式的根本問題只有一個：敏感卡號（PAN + CVV）的傳遞路徑。

MPG 型金流（綠界、藍新跳轉）對消費者反而更透明——畫面明確跳到金流商的頁面，消費者看得出來自己在哪。

但是在使用者體驗上，會多一個斷點，以電商來說會有轉換率的問題

Prime 型（TapPay iframe）的取捨是體驗好但透明度低，信任靠的是商家品牌，不是技術可見性。

而這是一個取捨。

實作細節

Prime Token 的卡號欄位內嵌結帳頁（實際是 iframe，能改邊框字體但限制多）。

整個結帳流程在你自己的頁面，設計語言、外觀風格一致。

MPG 直接跳到金流方頁面，你的品牌設計到那一刻全部斷掉。

但好處也很實際：同一個金流頁面能直接接信用卡 + ATM + 超商代碼 + LINE Pay。

兩者的開發量比較

Prime Token 你寫的東西：

• 前端 SDK 載入 + mount 欄位
• 後端一支 charge API
• 一個結果頁

MPG 你多寫的東西：

• 表單產生器（含簽章演算法）
• 自動 submit 的轉址頁
• NotifyURL endpoint（驗章 + 冪等 + 更新訂單，這支是核心）
• ReturnURL endpoint（使用者回站只看結果，不可以當付款依據）
• 訂單狀態機要多 awaiting_payment
• 對帳邏輯（callback 沒到怎辦？要定時 query 嗎？）

MPG 看似簡單，實際工程量比 Prime Token 大，主要是 callback 的 edge case 多。

補充: PCI DSS 是什麼 ?

Payment Card Industry Data Security Standard，簡稱 PCI DSS。

信用卡組織（Visa、Mastercard 等）聯合制定的資安標準，規定任何「碰到卡號」的系統都要符合一堆安全要求。

核心概念：碰到卡號的範圍越小，你要過的關越少。

實務上只有金流商或大型電商會去取得這種認証，一般而言小型電商還是透過第三方金流來實現交易。

小結

• 兩種模式的本質差異是卡號的傳遞路徑：Prime Token 走 SDK iframe，MPG 走表單轉址
• 信任是最難的

(fin)

前情提要

想把個人 PBI 清單整合進 GitHub Projects，
同時設定 GitHub Actions 讓新 Issue 自動加進 Project 看板。
過程踩了幾個授權的坑，記錄一下。

授權流程

用 gh CLI 操作 GitHub Projects 和 Actions 需要分開授權，
預設的 token 不夠用。

Step 1：Project 讀寫權限

要新增 Issue 到 Project、建立 Project item，需要 project 和 read:project scope：

1

gh auth refresh -s project,read:project

執行後會跳出 device flow：

1
2
3

! First copy your one-time code: 70C4-9535
Press Enter to open https://github.com/login/device in your browser...
✓ Authentication complete.

Step 2：Workflow 修改權限

Push .github/workflows/ 目錄下的檔案需要額外的 workflow scope，
即使已有 repo 完整寫入權限也不夠：

1

gh auth refresh -s workflow

一樣走 device flow，完成後才能 push workflow 檔案。

為什麼要分開？

GitHub 的設計：CI/CD workflow 修改權限獨立出來，
防止 OAuth App 未經授權竄改 Actions。
錯誤訊息長這樣：

1

refusing to allow an OAuth App to create or update workflow

看到這個就知道要補 workflow scope。

GitHub Actions 自動加 Issue 進 Project

workflow 長這樣：

1
2
3
4
5
6
7
8
9
10
11
12
13
14

name: Add Issue to Project

on:
  issues:
    types: [opened]

jobs:
  add-to-project:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/[email protected]
        with:
          project-url: https://github.com/users/marsen/projects/2
          github-token: ${{ secrets.PROJECT_TOKEN }}

PROJECT_TOKEN 需要在 repo settings 裡設定 secret，
用一個有 project scope 的 PAT。

Fine-grained PAT 不適用

想用 fine-grained PAT 取代 classic PAT？這條路走不通。

actions/add-to-project 需要有 project scope 的 token。
Fine-grained PAT 的 Projects 權限在 Account permissions 區塊，
但 user-level project（/users/{user}/projects/N）目前不在支援範圍，
設定頁面根本找不到對應選項。

直接用 classic PAT，不要浪費時間。

私有 Repo 要加 repo scope

如果 Issue 所在的 repo 是私有的，光有 project scope 還不夠。
Action 需要讀取 Issue 的 node ID，而私有 repo 的 Issue 沒有 repo scope 就讀不到。

錯誤訊息長這樣：

1
2

Error: Request failed due to following response errors:
 - Could not resolve to a node with the global id of '...'

Classic PAT 沒有「只讀私有 repo」的細粒度選項，
repo:status、repo_deployment 這些子 scope 都不夠用，
只能勾最上層的 repo（Full control）。

小結

• gh project 操作要先 gh auth refresh -s project,read:project
• Push .github/workflows/ 要先 gh auth refresh -s workflow
• 兩個都是 device flow，不能在非互動環境下跑（例如 Claude Code 的 ! 指令）
• actions/add-to-project + user-level project → 只能用 classic PAT
• 私有 repo → classic PAT 需同時勾 project + repo

(fin)

前情提要

用 LINE Bot 做系統通知，結果某天發現通知完全停了，重啟也沒用。
查了一圈才發現根本原因不是程式問題，這篇記錄怎麼查用量、以及為什麼停的。

問題現象

LINE Bot 的 push 通知在某個時間點之後完全靜默。
程式沒報錯，因為程式碼裡的 push 用了 .catch(() => {}) 吃掉所有錯誤：

1
2
3

async function push(text: string) {
  await lineClient.pushMessage(ALLOWED_USER_ID, msg).catch(() => {})
}

靜默失敗，完全看不出來哪裡出問題。

怎麼查用量

LINE 的用量統計不在 Developers Console，要去 LINE Official Account Manager：

1. 打開 manager.line.biz
2. 選你的 Official Account
3. 左側 → 分析 → 訊息

可以看到：

可以選日期範圍，最長 60 天。

免費額度是多少

LINE Messaging API 免費方案每月有 500 則免費訊息（Push + Reply 合計）。

超過之後每則需要付費，或者訊息會被擋下來（依帳號設定而定）。

500 則聽起來很多，但如果 Bot 跑 AI 對話，Claude 回應很長，常常一次就切成好幾則 push（每則上限 5000 字），很快就會耗光。

這次的真正原因

查完用量才發現：5/1 用了 141 則，5/2 用了 59 則，5/3 之後全部是 0。

5/3 之後不是「發了但被擋」，是根本沒有觸發 webhook。

原因是 LINE Bot 用 Webhook 模式，需要一個對外的 HTTPS URL。
我的架構是：

1

LINE 伺服器 → HTTPS Webhook URL → Cloudflare Tunnel → 本機 Express server

Cloudflare Tunnel 的 launchd service 在 5/3 掛掉，LINE 打不到 webhook，所以什麼都沒發生。

Telegram 為什麼更穩

Telegram 用 Long Polling 模式，bot 主動去 Telegram 伺服器拉訊息，不需要對外開放任何 URL。

如果是用來做系統通知（不可中斷），Telegram 比 LINE 穩定很多。

小結

• LINE 用量在 LINE Official Account Manager → 分析 → 訊息
• 免費方案 200 則/月，用完靜默失敗
• Webhook 模式依賴 tunnel，tunnel 掛掉通知就停
• 對穩定性要求高的通知場景，Telegram Long Polling 更適合

(fin)