用 Claude Code Skill Creator 打造技術部落格寫作 Skill

我們團隊用 Claude Code 寫程式已經一段時間了，最近開始研究它的 Skill 機制——可以把特定的工作流程封裝成一份指令文件，之後只要觸發對應的 Skill，Claude 就會依照預設的規範執行任務。

我們第一個想做的 Skill 是「技術部落格寫作」。原因很直接：公司的技術文章產出頻率不高，每次寫都要重新跟 AI 溝通語氣、格式、禁用詞彙，效率不好。如果能把這些規範寫成 Skill，以後只要丟素材進去就能產出符合風格的初稿，應該能省下不少時間。

這篇記錄我們從零開始設計這個 Skill 的完整過程，包含中間踩的坑和迭代修正。

我們想要的效果

• 丟入技術主題和背景素材，產出一篇符合公司風格的繁體中文技術文章
• 文章語氣專業但不僵硬，有真實經驗的支撐
• 自動遵守格式規範：正確的 frontmatter、檔案命名、圖片路徑
• 避免 AI 味的寫法：「隨著…的發展」「賦能」「讓我們拭目以待」這類用語一律不出現

第一步：分析現有文章的風格

設計 Skill 之前，我們先分析了自己網站上幾篇文章的寫作模式。抓了三篇不同類型的文章來讀：

1. Cloudflare Pages 預覽環境設定教學 — 踩坑紀錄型
2. 與 AI 合作開發的四種方式 — 工具比較型
3. 多巴胺開發 Dopamine Coding — 個人反思型

從這三篇歸納出幾個共同特徵：

• 開場直接交代「我們要做什麼」或「發生了什麼事」
• 用「我們」或「我」當主語，不用被動語態
• 踩坑的描述帶有排查脈絡，不只是列出問題和答案
• 結尾用具體清單或成果收束，沒有感性結語
• 程式碼區塊只放讀者需要複製的部分

同時也讀了 content config 和 category 設定，確認 frontmatter 的格式要求。

第二步：參考 humanizer-tw

除了分析自己的文章，我們還參考了 GitHub 上的 humanizer-tw 這個 Skill。它專門處理中文 AI 寫作的去痕跡問題，把常見的 AI 味寫法分成八大類、19 個具體問題，每個都附上替換表和改寫範例。

這個 Skill 有幾個設計值得借鑑：

• 系統化分類：不只是列一堆「禁用詞」，而是按類別整理（開場套話、互聯網黑話、翻譯腔、書面語過重等），方便 AI 逐項檢查
• 「個性與靈魂」的概念：它指出「乾淨但無靈魂」的文字跟 AI 味重的文字一樣有問題。光是去除壞模式不夠，還要主動注入真實感
• 品質評分機制：用五個維度各 10 分的方式自評，給 AI 一個具體的品質標準

不過 humanizer-tw 的語氣定位偏口語，像是「我覺得」「得想想」「聊一下」，這對個人部落格合適，但我們是公司技術部落格，需要再正式一些。

第一個坑：語氣太像個人部落格

第一版 Skill 寫完後，我們用三個測試案例跑了一輪：

1. wp-env Docker 開發環境的踩坑紀錄
2. Cursor vs Claude Code 的工具比較
3. AI 時代接案公司轉型的反思

三篇都順利產出，格式正確、沒有 AI 套話。但讀完之後有個明顯問題：語氣太隨性了。

踩坑紀錄那篇出現了「光看那個 crash log 真的完全猜不到原因」，反思那篇寫了「玻璃心碎了一地」「快崩潰」。這些表達放在個人部落格完全沒問題，但放在公司的技術部落格就顯得不夠專業。

問題出在 Skill 裡的語氣指引。第一版寫的是「讓人覺得是一個真的工程師在跟你聊天」，這個定位太偏聊天了。

修正方式

我們重新定義了語氣定位：「專業技術文章，但讀起來不會想睡。」並且加了一張三欄語氣校準表，明確標出「太正式」「適當」「太隨便」的分界：

太正式	適當	太隨便
經由詳細的調查分析	排查之後發現	隨便 google 一下
予以高度重視	我們很重視這個問題	超在意的

還特別標注了一點：「我認為」在本部落格是適當的用語，不需要降到「我覺得」。這是跟 humanizer-tw 不同的地方。

修正後重跑三篇測試，語氣明顯改善。「光看那個 crash log 真的完全猜不到原因」變成了「一開始我們沒有馬上聯想到是架構相容的問題」，「玻璃心碎了一地」變成了「這個問題困擾了我好一段時間」。專業但不死板。

第二個坑：AI 寫作問題沒有系統化分類

第一版 Skill 有列禁用清單，但只是把所有禁用詞和句型混在一起。AI 在執行時容易遺漏，因為沒有分類就沒有逐項檢查的依據。

參考 humanizer-tw 的做法後，我們把 AI 寫作問題整理成八大類、19 個具體問題：

1. 開場白與連接詞（3 個）：時代開場白、共識開場白、連接詞濫用
2. 互聯網黑話（2 個）：商業術語、動詞術語
3. 翻譯腔（3 個）：「這是一個…」結構、「的」字堆疊、被動語態
4. 書面語過重（2 個）：書面代詞、介詞結構
5. 公式化結構（2 個）：三段式公式、否定式排比
6. 結尾套話（2 個）：展望類、反思類
7. 語氣問題（3 個）：過度正式、缺乏觀點、絕對詞
8. 節奏問題（2 個）：句子長度單一、過渡詞依賴

每個類別都附上替換表或改寫範例，讓 AI 有明確的對照可以參考。

第三個坑：光去除 AI 味不夠

這個問題是從 humanizer-tw 的「個性與靈魂」段落得到的啟發。即使文字通過了所有 AI 味檢查，如果每句話都正確但沒有觀點、沒有轉折、沒有真實經驗的痕跡，讀起來還是像機器寫的。

我們在 Skill 裡加了「缺乏靈魂的警訊」清單：

• 每個句子長度和結構都相同
• 沒有觀點，只有中立描述
• 不承認不確定性或取捨
• 全文沒有第一人稱
• 讀起來像產品文件或新聞稿

以及七個「增添人味的技巧」：交代決策脈絡、加入具體數字、寫出轉折、帶入觀點、變化節奏、承認不確定性、對感受要具體。

最終成果

經過兩輪迭代，最終產出的 Skill 是一份約 300 行的 SKILL.md，包含以下模組：

• 文章格式規範：frontmatter 格式、檔案命名規則、圖片路徑
• 三種文章結構模板：踩坑紀錄、工具比較、觀點反思
• 語氣定位：語氣校準表、開場和結尾的寫法指引
• 人味注入指南：靈魂警訊清單、七個增添人味的技巧
• 19 個 AI 寫作問題：八大類分類，附替換表和改寫範例
• 品質評分：直接性、節奏、信任度、真實性、精煉度五個維度，各 10 分
• 快速檢查清單：交付前的 11 項逐項確認

實際使用時，只要告訴 Claude Code「幫我寫一篇關於 X 的文章」，它就會自動載入這份 Skill，按照規範產出初稿。如果素材不足，它會主動詢問缺少的資訊，不會自己編造技術細節。

設計 Skill 的幾個心得

先分析再動手。 我們一開始就讀了自己的文章和別人的 Skill，這讓第一版的品質有一個不錯的起點。如果直接憑感覺寫，可能要多迭代好幾輪。

測試案例要涵蓋不同類型。 如果我們只測了踩坑紀錄，可能不會發現語氣在反思型文章中過於隨性的問題。三種模式各跑一篇，問題很快就浮現了。

語氣校準需要明確的邊界。 光說「專業但不僵硬」太模糊，AI 不知道邊界在哪。三欄對照表（太正式 / 適當 / 太隨便）比抽象描述有效得多。

去除 AI 味和注入人味是兩件事。 前者是刪掉壞的，後者是加入好的。只做前者會得到乾淨但無聊的文字。兩者都做，才能產出讀起來像真人寫的文章。