用 Claude Code 寫技術文章：AI 輔助內容創作的真實流程
你現在讀的這篇文章，就是用 Claude Code 寫的。 事實上，這個部落格的每一篇文章都是。
🎯 前言
「用 AI 寫文章」聽起來像是把主題丟進去就自動生出一篇。實際上不是這樣。
如果你直接對 Claude 說「幫我寫一篇 Claude Code Hooks 的教學」，你會得到一篇結構完整但毫無個人特色的文章——沒有真實經驗、沒有踩過的坑、用詞也不像是你寫的。
我摸索出一套流程，讓 Claude Code 寫出來的文章接近我自己寫的品質，同時把一篇文章的產出時間從幾小時壓縮到十幾分鐘。
這篇文章分享這個流程。
📂 流程總覽
你的工作 Claude 的工作
───────── ──────────────
第一步：主題選擇 決定寫什麼 建議主題清單
第二步：素材準備 提供經驗片段 （等待）
第三步：風格校準 回饋「不像我寫的」 學習你的風格
第四步：初稿產出 審閱 寫完整文章
第五步：修改迭代 指出要改的地方 修改關鍵差異：你負責「說什麼」，Claude 負責「怎麼說」。
🔧 第一步：用 CLAUDE.md 定義寫作規範
在你開始寫第一篇文章之前，先在 CLAUDE.md 中定義好寫作規範。這樣 Claude 每次寫文章時都會自動遵守，不需要每次重複提醒。
我的 CLAUDE.md 中和寫作相關的設定：
## 內容撰寫規範
所有文章以**繁體中文（zh-TW）**撰寫。
### 去識別化要求
**重要**：文章不得包含真實內部資訊。
所有真實名稱與數值必須依照 `docs/CLAUDE_ANONYMIZATION_MAP.md` 中的對照表進行替換。
### 文章 Frontmatter
以下四個欄位應完整填寫：
title: '文章標題'
description: '文章描述'
pubDate: YYYY-MM-DD
heroImage: '../../assets/blog-placeholder-N.jpg'這段設定解決了幾個問題：
| 規範 | 解決什麼 |
|---|---|
| 繁體中文 | Claude 預設會用簡體中文或英文 |
| 去識別化 | 自動使用對照表中的替換值 |
| Frontmatter 格式 | 不用每次手動加 |
🔧 第二步：讓 Claude 讀你的舊文章
這是最重要的一步。在請 Claude 寫新文章之前，先讓它讀幾篇你已經寫好的文章：
你：讀一下 src/content/blog/claude-code-permissions-settings.md
和 src/content/blog/claude-code-custom-slash-commands.md，
了解我寫文章的風格Claude 會學到：
- 你用 emoji 做章節標題（🎯、📂、⚙️、🛡️、💡、🎉）
- 你喜歡用表格做比較
- 你會在前言說明「為什麼要寫這篇」
- 你習慣在結尾放相關文章連結
- 你的語氣是務實的、不說廢話的
不需要明確告訴 Claude 這些規則——讓它讀兩三篇文章，它就會自動模仿。
🔧 第三步：提供素材，不是提供指令
最常見的錯誤是這樣下指令：
❌：幫我寫一篇 Claude Code Hooks 的教學文章
✅：幫我寫一篇 Claude Code Hooks 的文章。
我在 AppSystem 專案中用了 PreToolUse hook 來阻擋 rm -rf，
用了 PostToolUse 來自動跑 prettier。
我覺得最有價值的是桌面通知——Claude 需要我確認時會彈通知。
文章要延續之前權限控管和 Slash Commands 的脈絡。差別在哪？
| 做法 | 結果 |
|---|---|
| 只給主題 | Claude 寫出一篇「教科書式」的通用教學 |
| 給素材 + 脈絡 | Claude 寫出一篇「有你的經驗在裡面」的文章 |
素材不需要很完整。幾句話就夠：
- 「我踩過一個坑：Stop hook 會無窮迴圈」
- 「我覺得最實用的是 xxx」
- 「讀者是已經看過我前幾篇的人」
Claude 會把這些片段編織成完整的文章。
🔧 第四步：批次產出
如果你一次要寫多篇文章，不需要一篇一篇來。
我的實際做法是一次給主題清單：
你：幫我寫 #4（去識別化）、#8（MCP Server）、#9（Git Hooks）這三篇Claude 會同時產出三篇，每篇都符合你的風格和 CLAUDE.md 規範。我在一次對話中產出了四篇完整文章，每篇 300-500 行，全程不到一小時。
適合批次產出的條件：
- 主題之間有系列關係（例如 Claude Code 系列）
- Claude 已經讀過你的舊文章
- CLAUDE.md 中有明確的寫作規範
💡 讓文章更像「你寫的」的技巧
技巧 1：給 Claude 你的口頭禪
如果你有特定的用詞習慣，直接告訴它：
我寫文章時會用「簡單說」「換句話說」「我的經驗是」這些過渡詞。
不要用「讓我們」「在本文中」「眾所周知」這種教科書用語。技巧 2：指定文章結構
不要讓 Claude 自己決定結構。給它你習慣的結構：
結構要和我之前的文章一致：
- 前言（為什麼寫這篇）
- 基本概念
- 設定語法
- 實戰範例（至少 3 個）
- 注意事項
- 結語
- 相關文章連結技巧 3：先寫大綱再寫全文
對於複雜的主題，先讓 Claude 列大綱：
你：先列出 MCP Server 這篇的大綱，不要開始寫
Claude：（列出大綱）
你：第三節拿掉，第五節往前移，加一個安全考量的章節
Claude：（更新大綱）
你：好，開始寫技巧 4：用 /interview 寫文章
如果你有設定 自訂 Slash Commands，/interview 也能用在寫文章上：
你：/interview 我想寫一篇 MCP Server 的教學文章
Claude：🎤 Interview
1. Why：為什麼要寫這篇？
2. What：要涵蓋哪些內容？
3. How：讀者的程度？
4. Edge cases：有什麼不想寫的？強迫自己先想清楚再動筆，文章品質會好很多。
⚠️ AI 寫文章的限制
缺乏真實經驗
Claude 能寫出「正確」的技術文章，但寫不出「我上週在 production 遇到這個問題，花了三小時才找到原因」這種內容。
你的真實經驗是 AI 無法取代的部分。 哪怕只是一兩句，加進去之後文章的可信度完全不同。
容易落入模板化
如果你不干預，Claude 寫出來的每篇文章結構都很像。讀者看三篇就會發現「這些文章長得好像」。
解法：偶爾刻意改變結構。有些文章用 Q&A 格式，有些用 timeline 格式，有些從一個故事開始。
需要事實查核
Claude 對技術細節的描述大多正確但偶爾有誤。特別是：
- API 的參數名稱和行為
- 特定版本的功能差異
- 新功能的發布時間
寫完之後，至少對關鍵技術細節做一次查核。
📋 我的實際工作流
完整流程大概是這樣：
1. 我決定要寫什麼主題（1 分鐘）
2. 告訴 Claude 讀我的舊文章（Claude 花 30 秒）
3. 給 Claude 素材和脈絡（我花 3 分鐘打幾句話）
4. Claude 寫出初稿（3-5 分鐘）
5. 我讀一遍，指出要改的地方（5 分鐘）
6. Claude 修改（1 分鐘）
7. 用 npm run dev 預覽確認（1 分鐘）總時間：大約 15 分鐘一篇。
如果同一主題自己從零寫，大概要 3-4 小時。
🎉 結語
用 AI 寫文章不是「讓 AI 替你寫」，而是「讓 AI 幫你把想法整理成文章」。
你的角色從「寫作者」變成「編輯」——你決定方向、提供素材、把關品質，Claude 負責組織結構和打字。
這個流程最大的價值不是「省時間」，而是降低了寫文章的門檻。很多技術經驗你知道、你做過，但就是懶得花時間寫成文章。現在你只需要說幾句話，Claude 就幫你寫好了。
如果你一直想寫技術部落格但遲遲沒開始，試試這個流程。你會發現最難的部分不再是「寫」，而是「決定寫什麼」。
📎 相關文章：