Obsidian to Blog：n8n + Git 的最小發布流程

問題在哪

我有幾百則 Obsidian 筆記。想法、靈感、工作紀錄、技術筆記，全部堆在裡面。

問題是：它們從來沒有變成文章。

不是沒時間寫，是發布流程太長。要開 CMS、要排版、要想標題、要找圖、要按發布。每一步都是一個可以放棄的出口。

所以我決定砍掉所有中間步驟，把發布流程壓縮到最短路徑：在 Obsidian 打一個 tag，剩下的交給系統。

架構：四個節點

整個流程只有四個節點，每個節點做一件事：

節點一：Obsidian — 觸發點

在 Obsidian vault 裡建一個 publish-queue/ 資料夾。把寫好的筆記移進去，Obsidian Git 外掛會自動 push 到 GitHub。

這一步的關鍵設計：不是直接搬筆記上線，而是建立一個 publish brief。

Brief 包含：工作標題、SEO 描述、目標讀者、編輯角度、原始素材。它是寫給 AI 的指令，不是寫給讀者的文章。

節點二：n8n — 中樞神經

GitHub webhook 偵測到 publish-queue/ 有新檔案 → 觸發 n8n workflow。

n8n 做三件事：

1. 抓取 brief 的 markdown 原文
2. 把原文丟進 Claude API 擴寫
3. 把 AI 生成的完整文章 commit 回 blog repo

節點三：Claude API — 擴寫引擎

AI 不是隨便寫。System prompt 裡有嚴格規則：

• 分類規則：商業模式 / AI 工具 → 升級紀錄；人格 / MBTI → MBTI 生活；甜點 / 情緒 → 甜點情緒
• 輸出格式：必須包含完整 frontmatter（title、description、pubDate、category、tags）
• 語氣規則：保留 PENSO editorial 語氣，先整理問題再給框架，不灌雞湯

AI 的角色是 editorial writing partner，不是內容農場。它負責把零碎素材擴寫成可讀的長文，但不發明事實、不編數字、不加沒有的個人經驗。

節點四：GitHub → Vercel → 上線

AI 完成的 .md 檔案被 commit 到 src/content/blog/，GitHub 推到 Vercel，Vercel 自動 build + deploy。

整個流程裡，人類只做了一件事：把筆記移到 publish-queue 資料夾。

為什麼不用 Notion CMS

之前試過 Notion 當 CMS。問題：

1. API 限速：Notion API 有 3 req/sec 限制，當文章量大時會卡
2. 多一層抽象：Notion → API → 解析 → Markdown → Git → Vercel，鏈條太長
3. 與現有系統不對齊：我的所有知識管理都在 Obsidian，多一個 Notion 就是多一個要維護的地方

遷移到 Obsidian + Git 直發後，少了一整層中間商。Obsidian 裡的 .md 就是最終格式，不需要轉換。

費用

自架 n8n 的話，整套系統的邊際成本趨近於零。

限制與誠實話

1. AI 擴寫不等於免審：每篇文章 AI 寫完後，我還是會人工審一遍。AI 偶爾會加不存在的過渡句。
2. Brief 品質決定輸出品質：垃圾 brief 進去，垃圾文章出來。寫 brief 的時間省不掉。
3. Obsidian Git 有時會 conflict：多裝置同步時偶爾要手動解衝突，但頻率低到可以接受。

下一步

• Telegram Bot 整合 — 在手機上 /approve slug 就能讓文章從 draft 變 published
• 電子報自動發送 — Vercel deploy 成功後，n8n 呼叫 Resend API 通知訂閱者
• 排程發布 — brief 裡設定 pubDate，n8n 到時間才觸發

系統的價值不在於它今天能做什麼，而在於每次加一個節點，整條鏈都變強。