2026 年的某個週末下午，窩在家裡的我看著自己好一陣子沒更新的部落格，心裡又生出了那股熟悉的愧疚感。其實想分享的東西一直都有，但每次想到要手動處理 frontmatter、調整格式、確認 nuxt-content 的各種自訂組件，那股動力就瞬間消失了（大概就和打開健身 App 看了一眼又關掉的感覺差不多吧）。

於是我做了一件工程師最擅長的事情——把問題自動化。

緣起

我的部落格是用 Nuxt 加上 nuxt-content 搭建的，文章都是 Markdown 格式。而我平時用 Obsidian 來管理自己的各種筆記和想法，裡面早就累積了不少可以寫成文章的素材。但這兩個系統之間一直是斷開的——Obsidian 裡的想法要變成部落格文章，中間隔著一道格式轉換和風格調整的牆。

而且說實話，我的部落格用了不少自訂組件，像是 ::epilogue、::note-img、::footnote-block 之類的。每次寫新文章都要回頭翻舊文章確認格式，實在是有些麻煩。

所以我的目標很明確：讓 AI 幫我把 Obsidian 裡的草稿，轉換成符合我寫作風格的部落格文章，然後自動發布。

聲音 DNA

整個專案中最有意思的部分，是讓 Claude 分析我所有已發布的 40 多篇文章，從中提取出一份完整的「寫作風格指南」。

這份指南涵蓋了 22 個維度的寫作特徵。其中有些是我自己完全沒有意識到的習慣，像是：

• 我的驚嘆號和句號的比例是 1:11——也就是說我其實很少用驚嘆號，遠比我自己以為的還要少
• 波浪號「～」在 40 多篇文章中只出現了 3 次，而且都只在對話或隨性的第一人稱想法中使用
• 我最常用的轉折詞是「而」（95 次）和「但」（79 次），而不是更正式的「但是」（只有 15 次）
• 每篇敘事類文章的結尾都有一個固定的四層結構：故事收束 → 哲學反思 → 給讀者的問題 → ::epilogue 簽名

Claude 還幫我整理出了六種不同的文章類型，每一種都有各自的語氣、結構和組件使用規則。從創業故事系列到技術教學、從面試心得到自我成長，每一類的「聲音」其實都不太一樣。

簡而言之，這份風格指南就像是我寫作風格的 DNA——有了它，AI 在生成文章時就有了一份精確的參考依據。

架構設計

在考慮了幾種方案後，我選擇了最乾淨的做法：兩個獨立的系統，用一個 AI 技能作為橋梁。

Obsidian（思考）→ Claude 技能（轉換）→ 部落格 Repo（發布）

Obsidian 那邊新增了一個 Blog/ 資料夾，裡面分成 ideas/ 和 drafts/。草稿可以用任何語言、任何格式來寫——英文、中文、混合都行。而部落格 Repo 這邊完全不需要改動，現有的 content/ 結構保持原樣。

這個決定其實比想像中重要。一開始我有考慮過把部落格內容也搬進 Obsidian，但後來想想，Obsidian 是用來「想事情」的，部落格是用來「發布成果」的。硬是要讓 Obsidian 去渲染 nuxt-content 的自訂組件，等於是在逼兩個工具做它們不擅長的事（大概就像是叫 Monroe 去學握手，理論上可以但何必呢）。

發布技能

整個系統的核心是一個 Claude Code 的技能檔案。當我寫好草稿後，只需要下一個指令，技能就會：

1. 讀取 Obsidian 草稿和風格指南
2. 分析內容並推斷文章類型（敘事、技術教學、面試心得等）
3. 生成符合我風格的完整部落格文章——包括 frontmatter、自訂組件、正確的中英文混用
4. 在部落格 Repo 建立一個分支並開 Pull Request
5. Netlify 自動生成預覽連結
6. GitHub Action 把預覽連結寄到我的信箱

所以最後的流程變成：我在 Obsidian 寫個草稿，下個指令，然後就會收到一封帶有預覽連結的 Email。點開看看滿不滿意，滿意的話合併 PR 就上線了。

而最讓我驚喜的是，因為有了那份詳盡的風格指南，生成出來的文章在語氣和用詞上其實相當接近我平時的寫法。

學到了什麼

AI 的風格分析比想像中準確

那些我從未刻意追蹤的寫作習慣——驚嘆號比例、波浪號使用頻率、轉折詞偏好——AI 都精準地提取出來了。有了這些數據化的描述，風格就變得可複製了。

關注點分離很重要

Obsidian 是用來思考的，部落格是用來發布的。把這兩件事混在一起只會讓兩邊都變得更難用。用技能當作橋梁，讓每個工具專注做自己最擅長的事。

風格指南才是真正的成果

自動化的管線固然方便，但真正讓整套系統能用的是那份風格指南。沒有它，AI 生成的文章就只是通用的文字。有了它，技能對每一個寫作決定都有 22 個維度的參考依據。

基礎建設其實很簡單

Netlify Deploy Preview = 一個 toml 檔案加上後台的一個開關。Email 通知 = 一個 GitHub Action。整個專案中最困難的部分是風格分析，而不是那些管線和設定。

結語

回頭看看這個下午的成果，其實讓我最有感觸的不是自動化本身，而是在分析的過程中重新認識了自己的寫作。那些無意識的習慣被一條一條列出來的時候，就像是照鏡子看到了平時沒注意到的表情。

也許未來 AI 工具會變得更加強大，而我們作為工程師能做的，就是找到讓這些工具和自己的工作流程自然融合的方式。不是用 AI 來取代自己的聲音，而是用它來放大自己的聲音。

你有想過用 AI 來自動化你日常工作中那些「想做但一直擱置」的事情嗎？