CLAUDE.md 內容篩選原則
寫 CLAUDE.md（專案手冊） 不是「把所有事都塞進去」——每次對話開頭 AI 都要讀一遍，寫太多就是浪費 token。核心判準：「不寫的話 AI 一定會搞錯的事」才寫。
該寫 vs 不該寫對照表
| ✅ 該寫進 CLAUDE.md | ❌ 不該寫進 CLAUDE.md |
|---|---|
| 你的身份和 AI 的角色定位 | 程式碼的架構細節（AI 會自己讀） |
| 硬規則（絕對不能做的事） | Git history（用 git log 查就好） |
| 工作流程和驗證步驟 | 暫時性的 debug 筆記 |
| 語言偏好（如：回覆用中文） | 已經寫在 README 裡的東西 |
| 常用的 API endpoint 和環境資訊 | 每次都會變的動態資料 |
五大常見區塊
科技翰林院 Hans 的 CLAUDE.md 結構：
- 身份定位 — 我是誰、AI 的角色是什麼
- 工作流程 — 先規格再開發、改完要驗證
- 硬規則 — 絕對不能做的事（不要用 em dash、不要 force push）
- 常用專案資訊 — API endpoint、部署流程
- （視專案而定）領域特定規則
反面教材：寫太多會怎樣
- 每次對話多耗幾千 token → 留給實際工作的 context 變少
- AI 注意力被稀釋 → 真正重要的硬規則被忽略
- 維護負擔上升 → 過時規則沒人清
→ 對應 Context Window Token 衛生 pattern：定期體檢 CLAUDE.md。
黃金啟發
「重點是寫『不寫的話 AI 一定會搞錯的事』」
繁中：「重點是寫『不寫的話 AI 一定會搞錯的事』。」（原文即繁中）
→ 倒過來想：每條規則寫進去前先問「不寫的話 AI 會做錯嗎？」答 No 就刪掉。
與其他概念的關係
強連結
- CLAUDE.md（專案手冊） — 本 pattern 的承載 artifact
- CLAUDE.md 4 層機制 — 4 層各層該放什麼
- Context Window Token 衛生 — 同方向的 token 節流原則
- Compounding Engineering — CLAUDE.md 飛輪是 compounding 的具體實踐
推斷連結
- Auto-compaction 規則衰減 ?? — CLAUDE.md 寫越多 → compaction 時越容易丟（被打散），所以更該精簡