最近有人丟給我一個 Dropbox 資料夾，裡面是 21 份 PDF、共 154 頁，主題是「給設計師的 Claude Code」。內容是 UX Planet 主編 Nick Babich 一系列英文文章的繁中重點摘要，加上筆記作者自己的補充，從 Plan Mode、CLAUDE.md、Skills、Plugins 一路排到 Figma 整合，分成 10 章。
我讀完的第一反應是：這份寫得巨好。
好在哪，我想拆清楚。因為我自己也在寫 Claude Code 的文章，也被自己訂的寫作規則打回過：資訊都對，但讀者要讀到第三個逗號才知道重點。這份筆記剛好示範了相反的狀態：資訊密度不低，讀起來卻很順。下面是我拆出來的 7 個寫法，每一個都附上我在 21 份 PDF 裡數到的證據，最後也列出它不準的地方。
懶人包
| 寫法 | 在筆記裡長什麼樣 | 出現範圍 |
|---|---|---|
| 1. 固定骨架 | 出處 → 一句話 → 為什麼 → 怎麼做 → 補充 → 延伸閱讀 | 21/21 篇 |
| 2. 先講沒有它會怎樣 | 先列痛點，範本放後面 | 主要概念篇 |
| 3. 原文和自己的話分開標 | 「— Nick」引用 25 處，「補充」49 處 | 21/21 篇有補充 |
| 4. 用熟悉的東西類比 | MCP＝USB、Skill＝食譜、Plugin＝廚房電器 | 概念篇 |
| 5. 範例貼完再拆結構 | 把一段 prompt 拆成 6 個區塊 | Plan Mode 篇 |
| 6. 正反對照、可照做的指令 | ❌／✅ 對照、claude --debug | 6 篇有 ❌／✅ |
| 7. 收尾表＋章節互連 | 一頁總結表、「詳見 4.1」 | 8 篇有一頁總結，21 篇有延伸閱讀 |
這份筆記是什麼？
- 形式：21 份 Notion 匯出的 PDF，頁尾有篇名和頁碼，每篇 3 到 16 頁。
- 來源：每篇開頭標原文標題與作者，並寫明「繁中重點摘要＋個人補充說明，僅供學習使用」。21 篇全部都有這段。
- 讀者：設計師。範例情境是使用者研究、啟發式評估、landing page redesign，而不是後端 API。
- 製作方式：筆記裡提到它是用 Notion MCP 寫進 Notion、用 Firecrawl MCP 抓原文。教的工具，作者自己就在用。
寫法 1：每篇都用同一副骨架
21 篇的順序幾乎一樣：
讀到第三篇，我已經知道「為什麼」會在哪、「怎麼做」會在哪、作者自己的意見會在哪。讀者不用每篇重新適應版面，注意力全留給內容。
這等於是內容版的設計系統。設計師做 UI 會先定元件，這份筆記把同樣的事用在文章上。
寫法 2：先講「沒有它會怎樣」，再給範本
CLAUDE.md 那篇不是一開頭就貼範本。它先列出沒有 CLAUDE.md 時 Claude 會怎樣：不知道你用什麼框架、可能引入錯的套件；不知道你的命名規則、寫出風格不一致的 code；不知道指令、不會跑 build 和 test；不知道商業限制、可能違反規則。
讀者先看到這四個具體後果，後面那份最小範本才有理由存在。反過來先列步驟的話，讀者照做完可能還是不知道為什麼要做。
寫法 3：原文和自己的話，分開標清楚
這是我覺得最值錢的一點。
- 原文的話一律掛「— Nick」，21 篇裡有 17 篇用到，共 25 處。
- 作者自己的意見一律標「我的補充」或「💡補充」，21 篇都有，共 49 處。
- Plan Mode 的價值不在「先想再做」的儀式感，而是逼 Claude 在動手前把它對問題的理解講出來，你在這一步抓誤解最便宜。
- Plan 產出的「驗收流程」和「風險評估」兩段，新手常跳過，老手最先看。
- Skill 和 Plugin 怎麼選：只是要 Claude 換一種思考方式，就寫 Skill；要拿另一個軟體裡的東西（Figma、GitHub、Notion），就裝 Plugin。
寫法 4：用讀者已經熟悉的東西類比
筆記沿用了原作者幾個好記的類比：
| 概念 | 類比 | 讀者因此知道的事 |
|---|---|---|
| MCP | USB | 一個標準接口，接上就能用外部工具 |
| Skill | 食譜 | 教 Claude「怎麼做一件事」的步驟 |
| Plugin | 廚房電器 | 給 Claude 本來沒有的能力 |
| CLAUDE.md | 新同事第一天的 onboarding 文件 | 每次開工都會先讀一遍 |
寫法 5：範例貼完，順手拆它的結構
Plan Mode 篇貼了 Nick 用來規劃 landing page redesign 的完整 prompt。貼完沒有直接往下講，而是多做了一張表，把 prompt 拆成 6 個區塊：
| 區塊 | 作用 |
|---|---|
| 意圖 | 說明這次要做什麼 |
| 防護 | 明講「改任何東西之前先停」 |
| 目標 | 往哪個方向想 |
| 流程 | 一步一步怎麼走 |
| 包含 | 計畫裡一定要有的段落 |
| 限制 | 硬性規則，例如盡量重用既有元件 |
只貼範例，讀者帶走的是一段別人的 prompt。拆完結構，讀者帶走的是一個能重複用的模板。
寫法 6：給 ❌／✅ 對照，給能直接跑的指令
有 6 篇用了 ❌／✅ 對照，例如 prompt 可以「廣」但不能「空」：「幫我規劃這頁的 redesign」可以，「幫我改一下這個東西」不行。
疑難排解篇則直接給目錄結構的正確和錯誤寫法，以及能馬上執行的檢查，例如：
# 用 debug 模式看 skill 載入時的錯誤
claude --debug讀者讀完就能動手，不用再去別處查。
寫法 7：一頁總結表收尾，章節之間互相指路
21 篇最後都有「延伸閱讀」，連回原文，也連到筆記裡的其他章節，例如 CLAUDE.md 篇寫「超過 200 行怎麼辦，詳見 4.1」。21 篇因此串成一張網，不是 21 份散落的單篇。
其中 8 篇在最後放了「一頁總結」或「一頁速記」表，把整篇壓成「習慣／為什麼重要／怎麼做」三欄。讀完當複習卡，三個月後回來查也只要看這一頁。
這份筆記有哪些地方不準？
寫得好不代表每句都對。我拿 2026-10-16 的 Claude Code 官方文件對了三處，都跟筆記寫的不一樣：
| 筆記寫法 | 官方文件現況 | 出處 |
|---|---|---|
MCP server 可以加在 ~/.claude/settings.json | MCP 定義存在 ~/.claude.json（local／user scope）或專案根目錄的 .mcp.json（project scope）；settings.json 只放啟用與核准設定 | Claude Code MCP 文件 |
| Skill 的 description 是跟 prompt 做字面比對 | Claude 讀每個 skill 的 description，自己判斷相不相關；關鍵字重疊有幫助，但不是字串比對 | Claude Code Skills 文件 |
| 裝完 Plugin、新增 Skill 都要重啟 | Skill 目錄有即時偵測，不用重啟；Plugin 裝完多半立即生效，需要時用 /reload-plugins | Skills 文件、Plugin 安裝文件 |
還有一條是觀點不同：筆記建議「Skill 和 Plugin 都能做時選 Plugin，因為有人維護」。我不完全同意。Plugin 會帶進 hooks、MCP server 和外部依賴，筆記自己下一段也在提醒權限風險。我的做法是先看那件事要不要碰外部服務，不用碰就寫成 Skill。
這也是一個寫法上的提醒：AI 工具的筆記，保存期限大概只有幾個月。如果是我來寫，會在每篇開頭加一行「依 Claude Code 某版本、某日期查證」，讓三個月後的讀者知道要不要再對一次。
哪些寫法可以直接搬到自己的筆記？
如果只能帶走三個，我會選：
- 固定骨架。先決定每篇的段落順序，再開始寫。骨架定好，寫作時只要填內容。
- 把「我的補充」標出來。翻譯和摘要誰都能做，你自己的判斷才是讀者找不到別處替代的部分。
- 貼了範例就拆結構。讀者要的是能套到自己情境的模板，不是你的那一段 prompt。
想看「拆結構」這招用在別人的 Skill 庫上長什麼樣，可以接著讀我拆 Matt Pocock 的 Skill 庫那篇。
FAQ
整理英文技術文章成中文筆記，可以公開分享嗎？
要看原文授權。這份筆記的做法是每篇標出處、寫明「僅供學習使用」、只摘重點不全文翻譯，並附原文連結。就算這樣，公開發表前還是應該確認原作者的授權條款；Medium 上的會員文章尤其要注意。
學習筆記一定要做一頁總結表嗎？
不一定。21 篇裡只有 8 篇有。適合放的是「有幾個平行概念要比較」的篇章，例如四個習慣、Skill 和 Plugin 的差別。只講一個工具怎麼用的短篇，用延伸閱讀收尾就夠了。
用 Notion 寫技術筆記，匯出 PDF 好用嗎？
這份筆記的程式碼區塊、表格、emoji 標題在 PDF 裡都保留下來，頁尾自動帶篇名和頁碼，當成交付物很整齊。我用程式抽 PDF 文字時，表格會變成一格一行，要整理成可複製的內容得自己重排；如果讀者需要複製指令，同時留一份線上版比較方便。