CLAUDE.md 一旦設計好，Claude Code 的生產力真的會差很多，我把自己實際在用的設定方式和工作流整理給你看:
剛開始用 Claude Code 的時候，真的很容易有一種「哇，也太神了吧」的感覺。你用自然語言跟它講，它就能幫你寫程式、跑測試，連重構都能一起做，整個很像多了一個很能幹的搭檔。可是差不多用了一陣子之後，很多人都會開始卡住。像是：
- 明明之前講過一樣的要求，它這次又用不同風格寫
- 每個專案的規則都要重講一次，講到有點煩
- 想用 sub-agent，卻不知道到底要怎麼拆、怎麼設計才合理
我自己後來很有感的一件事是，這些問題很多其實不是模型不夠強，而是 CLAUDE.md 沒有設計好。
我平常同時在跑本業、副業，還有一些自己的 side project，所以 Claude Code 幾乎已經變成我每天工作的固定夥伴。最一開始，我的 CLAUDE.md 也是寫得很隨便，有什麼想到就塞什麼。可是後來重新整理結構之後，最大的變化就是：重講需求的次數變少很多，輸出也穩定很多。
這篇就想直接把我現在實際在用的 CLAUDE.md 設計方式，還有我是怎麼把它串進日常 workflow 的，完整分享出來。
這篇內容是以 2026 年 3 月時點的 Claude Code 功能 為基礎，預設你已經會用 sub-agent、Agent Teams、Memory、Hooks 這些功能。
如果你想先補基本功，像是 Claude Code 的基本使用方式，或是怎麼整理 context，比較建議先看基礎教學；這篇比較偏實戰，重點是「怎麼設計，才真的能長期用得順」。
CLAUDE.md 最重要的，不是寫很多，而是分層
Claude Code 其實會分層讀取多份 CLAUDE.md。所以重點不是把所有規則都塞進同一份，而是你要先想清楚：什麼資訊該放哪一層。
大概可以這樣分：
~/.claude/CLAUDE.md ← 全域設定（每個專案都共用）<project>/.claude/rules/*.md ← 條件式規則（依情境套用）<project>/CLAUDE.md ← 專案專屬設定
官方的 memory hierarchy 比較接近這樣：
- Enterprise policy
- Project memory（
./CLAUDE.md或./.claude/CLAUDE.md） - User memory（
~/.claude/CLAUDE.md）
至於 .claude/rules/*.md 這種拆法，不是官方硬性規格，比較像是我自己實務上用得很順的一種整理方式。老實說，這層真的很有用，因為可以把一些「只在特定情境才需要」的規則獨立出來，不會讓主檔案變得超肥。
全域設定：寫你自己的工作風格，不要寫專案細節
放在 ~/.claude/CLAUDE.md 的內容，我建議你把它想成：
這是 AI 要怎麼跟你一起工作的說明書。
像我自己的全域設定，大概會包含這幾類：
1. 基本資訊
例如：
- 我的名字 / GitHub ID
- 回答要先講重點，不要一大堆前言
- 語氣統一或固定風格
2. 角色設定
我通常會定義它要像什麼樣的搭檔，例如：
- 經營與策略夥伴
- 行政助理 / 秘書
- Tech lead / reviewer
這樣它在不同任務裡，比較容易切到我要的思考方式。
3. 常用工具
像是：
- Gmail / Calendar / Drive 的操作工具
- GitHub CLI
- 編輯器或 Smart Edit 類工具
- 拿來做 second opinion 的其他模型工具
4. 行動原則
這一段其實很關鍵，因為它會影響整體輸出品質。像我自己會放：
核心原則
- 先求簡單，不要為了炫技把事情做複雜
- 盡量只改必要的地方，降低影響面
- 不要用「先能動再說」那種很臨時的修法交差
工作流程
- 只要任務超過 3 個步驟，就先進 Plan mode
- 研究型工作盡量丟給 sub-agent
- 一個 sub-agent 只做一件事
驗證
- 沒有驗證，不算完成
- 要跑測試、看 log、確認結果
這裡有一個很重要的觀念：
不是寫「AI 可以幫我做什麼」，而是寫「我平常怎麼做事」。
因為 Claude Code 讀到這些之後，才比較能模仿你的工作習慣，而不是每次都用它自己的預設方式亂發揮。
還有一點很重要：
不要把專案專屬資訊寫進全域設定。
像是資料夾結構、build 指令、測試命令，這種都不該放這裡。因為一放進全域，它就會污染所有專案，之後很容易出現奇怪的誤判。
專案設定：寫這個專案自己的規則和脈絡
接下來是 <project>/CLAUDE.md。
這份就不是在寫「你這個人怎麼工作」，而是在寫：
這個專案本身是什麼、怎麼運作、什麼東西在哪裡。
我自己在一些工作管理型 repo 裡，通常會放這些資訊：
1. 目錄結構
例如哪些資料夾分別在放什麼：
00_context/：個人背景、AI memory、脈絡資料01_strategy/：策略、方向、決策文件output/：AI 產出的報告、草稿、成果物
這樣它在搜尋或生成內容時，不會亂存亂放。
2. workflow 與 skill 觸發條件
這個我自己超常用，而且很好用。
我會直接寫一張對照表，讓某些自然語言觸發固定 skill。例如：
- 說「早安」→ 啟動
/daily-schedule - 說「幫我查」→ 啟動
/deep-research - 說「幫我寫文章」→ 啟動
/write-article
好處是什麼？
就是你平常講話可以很自然，不用每次都手動下那種很制式的命令。只要 mapping 寫得清楚，Claude Code 讀久了之後就比較能穩定辨識。
3. 專案內部的 AI memory
像我通常會把 memory 再拆幾種：
preferences.md：文風偏好、工具習慣decisions.md：過去做過的決策和理由context-log.md：最近正在跑什麼事- 其他判斷框架或 case 類型整理
這樣的好處是，AI 不是只記住零碎資訊，而是記得比較像「工作上下文」。
條件式規則：把情境限定清楚，真的比較不會亂
我自己很推薦把某些規則拆到 .claude/rules/*.md。
像是：
.claude/rules/├── codex-guidelines.md└── plan-template.md
這些檔案就很適合放那種：
- 只有某些任務會用到的規範
- 固定格式模板
- 某種工具的使用原則
例如 plan-template.md，我會規定只要進 Plan mode，就要照固定格式輸出，像是：
- 為什麼要做
- 要改什麼
- 怎麼做
- 怎麼驗證
- 風險和注意事項
這樣有個很大好處：
每次計畫長得都差不多，自己 review 會快很多，也比較容易看出有沒有漏。
不然有時候 AI 今天用條列、明天用散文、後天又換一種結構，看久真的會有點煩。
我的整體 workflow，大概是這樣串起來的
如果把整個使用方式講白一點，我平常其實不是在「跟一個會寫程式的聊天機器人互動」，而比較像是在管理一個有規則的 AI 工作系統。
它的核心大概有幾個部分：
- CLAUDE.md 管規則和行為
- sub-agents 負責拆工
- memory 系統負責記錄上下文
- review 流程負責把關品質
這幾個東西一旦串起來之後，整體穩定度真的會差很多。
Sub-agent 的設計，重點不是多，而是角色要乾淨
sub-agent 我通常會定義在 .claude/agents/*.md，用 Markdown 檔去描述。
前面可以放 YAML frontmatter，後面正文就當成 system prompt。
這邊我自己踩過很多雷，後來發現最重要的一件事其實很簡單：
一個 agent 就做一件事。
真的，不要貪心。
以 research team 為例
我有一個 /deep-research skill，裡面大概會有 6 個 agent。
它不是每個都在做同樣的研究，而是分工很清楚。
像第一階段，我會讓幾個 researcher 並行：
- A：抓論點與主張
- B：查事實資料
- C：做批判性思考，找漏洞或反例
接著第二階段再交給整合的人去 synthesize。
後面還會有 reviewer 看架構和最後報告，品質不夠就退回去。
這樣設計的原因很實際：
1. 第一階段要並行
如果全部直線式地一個 agent 做到底，很容易被前面的思路帶偏。
並行做 research，視角會比較廣，不容易只剩單一路線。
2. reviewer 一定要能退件
我以前覺得 review 好像可以省，後來發現真的不能省。
沒有 reviewer，常常就是結構還沒站穩就開始寫，最後返工更多。
3. 一個 agent 不要身兼太多職務
你叫同一個 agent 同時研究、分析、寫作、檢查，最後通常每一項都做得不夠深。
拆開之後，品質通常反而更穩。
文章寫作 team 其實也可以用同樣邏輯
寫文章這件事，我也是用類似的 team workflow。
大概像這樣：
Phase 1：平行 research
三個 agent 同時跑：
- 一個看論述主軸
- 一個查事實與資料
- 一個專門負責批判與補強
Phase 2：規劃結構
把前面的 research 統整成一版有邏輯的架構。
Phase 3～5：review → 寫作 → 最終 review
先審大綱，再寫正文，最後再做一次總 review。
這樣的好處是，會比較不容易出現那種：
- research 還不夠就急著下筆
- 架構還很鬆就直接寫長文
- 寫完才發現核心論點其實沒有站穩
我自己覺得，這種 pipeline 對長文、報告、企劃都很有用。
AI memory 最好也自己做結構，不要只靠內建記憶
除了 Claude Code 本身的 memory 功能以外，我還會在專案裡另外做一套比較可控的 memory 系統。
像我通常會有這些：
00_context/memories/├── preferences.md├── decisions.md├── context-log.md└── case-judgment-framework.md
每一份都有不同用途：
preferences.md：記文風、格式、習慣decisions.md：記「為什麼最後選這個方案」context-log.md：記目前進度、卡點、下一步case-judgment-framework.md：記判斷模式、常用準則
這樣做的好處是什麼？
就是當你跟 AI 說「這件事記一下」，它不是亂記，而是可以根據內容分類。
而且我通常還會加兩個邏輯：
1. 重複檢查
如果已經有同樣內容，就不要再重存一次。
2. 衝突檢查
如果新資訊跟舊記錄矛盾，就先提示，不要默默覆蓋。
這兩個其實很重要，不然 memory 用久了，很容易自己打自己臉。
另外，如果某些 sub-agent 有長期固定任務，也可以讓它們有自己的 persistent memory。
這樣它們跨 session 之後，還是能累積各自的知識脈絡，滿方便的。
Context 管理要寫進規則裡，不然 AI 越忙越容易偷懶
這個我真的很有感。
Claude Code 用久了之後，context window 壓力一定會來。
一旦 context 快滿，模型有時候就會開始走捷徑，例如：
- 還沒看清楚程式就直接改
- 少做驗證
- 想跳過 plan
- 明明不確定還硬做下去
所以我後來乾脆在 CLAUDE.md 裡面直接寫一段規範，類似：
當你開始慌的時候，先停下來
- 沒看過原始碼就不要亂寫
- 不要省略驗證
- 不要跳過 Plan mode
- context 緊的時候，多用 sub-agent 分擔
- 如果做不到完整品質，就誠實中止，不要硬湊
- 一旦察覺自己在趕，直接明講
這段規範的效果比我原本想像中還好。
因為你等於是先跟 AI 約法三章：品質比假裝完成更重要。
加入之後，它真的比較會明確說出現在的限制，而不是吐一個看起來好像完成、但其實很多地方沒驗證過的結果。
老實說，這種誠實比亂做可靠太多了。
我很推薦加一個 second opinion 機制
我自己平常會把其他模型工具接進 workflow，當成 second opinion。
用途通常是這幾種：
必用情境
- 做完重要文件或成果物之後，請另一個模型 review
- 要做重大決策之前，先聽另一個觀點
很值得用的情境
- 同一條路試了兩次都失敗
- 幾個選項看起來都合理，選不出來
- 踩到自己不熟的領域
這樣做最實際的價值就是：
降低單一模型的盲點。
如果 Claude 跟另一個模型看法不同，我通常不會直接聽其中一個，而是要求它們各自把理由講清楚，最後再自己判斷。
這樣整體決策品質會穩很多。
我平常是怎麼用的？
早上的 routine
我有設定一種很輕鬆的觸發方式。
例如只要打一聲「早安」，整套流程就會開始跑：
- 從 Google Calendar 抓今天行程
- 從 GitHub Issue 抓目前進度
- 看專案 milestone
- 把任務用「緊急度 × 重要度 × 認知負荷」分類
- 生成 15 分鐘粒度的今日排程
我通常會把高認知負荷的事情排在上午，像是設計、開發、寫關鍵內容。
下午就放會議、整理、routine 類工作。每個任務中間再故意塞 5 分鐘 buffer，這樣整天的節奏會舒服很多。
做 research
只要說「幫我查某某主題」，research team 就能起來跑。
最後把整理好的結果輸出到固定資料夾。
這種方式的最大優點是，它不是只有幫你搜資料，而是可以從：
- 最新資訊
- 技術背景
- 反方觀點 / 批判角度
一起併進來，所以常常會比自己手動開一堆分頁還更完整。
寫文章
這篇文章其實也很適合用一樣的流程處理。
先 research，再規劃結構，再 review，最後才進正文。 整個 pipeline 跑起來之後，文章品質通常會穩很多，不太會出現中段開始散掉的狀況。
我踩過的幾個坑，真的很值得先避開
失敗 1：把所有東西都塞進 CLAUDE.md
我一開始的 CLAUDE.md 超長，超過 200 行。
資料夾結構、coding style、commit rule、各種備註，什麼都塞。
結果就是：
重要的東西反而不重要了。
因為資訊一多，權重就會變得很平。AI 看起來像都有讀到，但實際上會更容易忽略真正關鍵的指令。
後來我改成一個原則：
CLAUDE.md 只放會影響決策的內容。
至於可以用 linter、formatter、test、自動化工具處理的機械性規則，就交給工具，不要全部丟給 prompt。
這個改法非常有感。
失敗 2：一個 sub-agent 什麼都做
我以前也有想過，研究、分析、整理、寫作都交給同一個 agent，感覺比較快。
結果完全不是。
它會變得每件事都碰一點，但沒有一件真的做深。
後來我就強迫自己遵守：
一個 agent 只做一件事。
拆開之後，整體品質反而變好很多。
失敗 3：省掉 review 流程
一開始我覺得 review 很花時間，所以曾經用過這種流程：
research → 大綱 → 直接寫
結果就是，前面如果大綱有問題，後面整篇都會一起歪掉。
返工的成本比多一道 review 還高很多。
後來我加了一個 editor / reviewer agent，讓它在：
- 大綱完成時 review 一次
- 全文完成時再 review 一次
從那之後，手感真的差很多。因為品質管理變成前置，而不是最後才補救。
最後整理一下：我自己目前最有感的設計原則
如果要濃縮成幾句話，大概就是這些：
1. 一定要分層
把全域、專案、情境規則分開，不要混在一起。
2. CLAUDE.md 只放高價值的決策資訊
可以被工具驗證的規則，就交給工具。
3. skill 的觸發條件要寫清楚
自然語言 mapping 一旦設好，日常用起來會順超多。
4. 一個 agent 一個任務
不要什麼都想塞給同一個 agent。
5. review 不能省
一定要有可以退件的品質關卡。
6. context 管理要明文化
不要等模型亂掉才補救，先把規則寫好。
7. memory 要有結構
不是只記「有沒有記住」，而是要記在對的位置。
總結
我現在最大的感想是：
CLAUDE.md 不是專案說明書而已，它比較像是你和 AI 一起工作的設計圖。
當你開始有意識地去設計它，而不是想到什麼寫什麼，你會很明顯感受到 Claude Code 的表現變穩：
- 規則比較不會跑掉
- 重複解釋需求的次數變少
- sub-agent 的分工更清楚
- 輸出品質更可控
- 跨 session 的延續性也更好
簡單講就是，從「感覺很厲害但有點飄」的工具，慢慢變成一個真的能長期合作的工作系統。
所以如果你現在的 CLAUDE.md 還是很隨手、很零碎，我會很推薦你花點時間重新整理一次。
不用一口氣做到很完整，但只要先把層次、角色、workflow、memory 這幾件事理清楚，之後你真的會越用越順。
