CLAUDE.md 階層架構

CLAUDE.md 階層架構是 Claude Certified Architect — Foundations（CCA-F）考試 Domain 3.1 的核心主題，也是整場 60 題、120 分鐘考試中情境題最密集的主題之一。任務說明 3.1——「設定具有適當階層、範疇與模組化組織的 CLAUDE.md 檔案」——同時出現在 Code Generation with Claude Code 情境叢集和 Claude Code for Continuous Integration 叢集，因此每位考生至少會遇到一、兩道題目，其答案取決於理解 CLAUDE.md 檔案的存放位置、誰能看見它，以及它的指示如何與其他層級的指示合併。

這份學習筆記涵蓋 CCA-F 架構師在基礎認證層級需要掌握的 CLAUDE.md 階層架構全貌：三個範疇層級（使用者、專案、目錄）、各層級之間的優先順序與合併規則、用於模組化檔案組合的 @import 語法、作為單體式 CLAUDE.md 替代方案的 .claude/rules/ 目錄慣例、用於驗證已載入記憶體檔案的 /memory 指令、新隊友未收到預期指示時的診斷模式，以及將 720 分及格分與 893 分頂尖成績區隔開來的具體考試陷阱。文末也清楚說明 CCA-F 的考察重點（架構層級判斷、辨識範疇陷阱）與超出基礎範疇、屬於實作深度的內容之間的差異。

CLAUDE.md 是什麼，為什麼階層架構很重要？

CLAUDE.md 是 Claude Code 在工作階段啟動時讀取的主要設定檔，用來建立跨對話持續生效的行為指示、編碼慣例、專案背景與記憶。一次性的使用者提示只影響單一輪次，而 CLAUDE.md 的指示則會在每次工作階段於相關目錄中開啟時注入 Claude 的工作記憶——這也是為什麼這個檔案有時被稱為「專案記憶」或「倉庫記憶」檔案。

CLAUDE.md 階層架構之所以存在，是因為 Claude Code 同時在至少三種不同情境下被使用：個別工程師有個人習慣（「永遠用 pnpm，不用 npm」）、團隊共用倉庫並遵循集體慣例（「所有 React 元件使用帶有 hooks 的函式式風格」），以及倉庫內部的子系統需要局部覆寫（/docs 目錄應遵循 Markdown 規則，而非 TypeScript 規則）。單一的扁平設定檔無法同時服務這三種對象而不產生衝突，因此 Anthropic 將 CLAUDE.md 階層架構設計為三個可合併的範疇層級。

理解 CLAUDE.md 階層架構不只是詞彙測驗。它是 CCA-F 考試要求你診斷損壞設定、正確引導新隊友，以及避免個人偏好洩漏到共用倉庫的架構視角。

三個範疇層級 — 使用者、專案、目錄

每個層級服務特定對象，存放於特定路徑。把檔案放錯一個層級是 Domain 3.1 最常見的陷阱。

使用者層級 — ~/.claude/CLAUDE.md

專屬於 OS 帳號、不提交、每次 session 啟動都載入（不管在哪個專案）。放個人偏好 / 環境設定：「叫我 Jaric」、「個人腳本偏好 pnpm」、「對話用正體中文」。

判斷原則：隊友 clone repo 後需要這條指示才能正確工作 → project-level；只反映個人習慣或環境 → 留 user-level。

專案層級 — CLAUDE.md 或 .claude/CLAUDE.md

共用的 repo 記憶，提交至版本控制。兩個標準位置都有效；裸根目錄較好發現，.claude/ 目錄則便於把 commands/skills/rules/settings 集中。適合放：技術棧聲明、coding 慣例、架構約束、禁止模式、tooling 指令。

目錄層級 — 巢狀 CLAUDE.md

位於子目錄、僅在 working context 進入該子樹時生效。Monorepo 中每個 packages/*/CLAUDE.md 載明該模組專屬規則。只有從 CWD 往 repo root 路徑上最近的那個目錄層級檔案會被載入 — 這個細節常被考。

階層優先順序與合併語義

階層不是贏家通吃。Claude Code 依特殊性由低到高串接指示，最具針對性的排在最後，Claude 自然賦予它們較高權重。

載入順序

Session 在 <repo>/packages/web/src/routes/login/ 啟動時：

1. ~/.claude/CLAUDE.md（user）
2. <repo>/CLAUDE.md 或 <repo>/.claude/CLAUDE.md（project）
3. 從 CWD 往 repo root 路徑上遇到的每個 CLAUDE.md（所有 directory-level 檔案）

合併是累加，不是替換

常見陷阱：誤以為 directory-level 會取代 project-level。並不會。若 project 說「用 Vitest」，而 docs/CLAUDE.md 對測試隻字未提，Claude 在 docs/ 內工作時，Vitest 規則仍生效。Directory 檔案只新增指示，從不刪除。

@import 語法與模組化組織

Repo 變大時單體式 CLAUDE.md 難維護。Anthropic 的解決方案是 @import，讓 CLAUDE.md 可以參照其他 Markdown 檔案，每個主題各自一份。

語法與路徑解析

根目錄 CLAUDE.md 可以長這樣：

# Repository Memory

這個 repo 是基於 Cloudflare Pages 的 Astro 4 monorepo。

@import ./.claude/rules/typescript.md
@import ./.claude/rules/testing.md
@import ./.claude/rules/api-conventions.md

啟動時 Claude Code 讀根目錄、遇到每個 @import、抓目標、內聯展開，彷彿一開始就是主檔案的一部分。

相對路徑規則

@import 中的路徑永遠相對於包含該指令的檔案，而非當前工作目錄，也不是倉庫根目錄。若 packages/web/CLAUDE.md 包含 @import ./rules/components.md，解析器會尋找 packages/web/rules/components.md，而非 <repo-root>/rules/components.md。

為何使用 @import？

• 可讀性 — 每個規則檔案可以有 50–200 行，專注於單一主題，而非一個 2000 行的超級大檔。
• 可審查性 — 只觸及測試規則的 pull request 只需修改 testing.md，diff 清晰易讀。
• 可重用性 — 一個規則檔案可被多個 CLAUDE.md 條目 import（例如專案根目錄與特定套件），無需重複。
• 團隊所有權 — 不同團隊可以各自擁有不同的 import 檔案（平台團隊擁有 database.md，設計系統團隊擁有 components.md）。

.claude/rules/ — 模組化規則目錄慣例

.claude/rules/ 目錄是個別規則檔案的慣用存放位置，這些規則檔案由根目錄的 CLAUDE.md 透過 @import 引入。它並不是 Claude Code 的內建功能（不是會被自動載入的魔法路徑），而是社群與 Anthropic 官方文件推薦的命名慣例，讓團隊能在各個倉庫中一致地找到規則檔案。

典型的目錄結構

<repo-root>/
├── CLAUDE.md                           # 包含 @import 指令的協調者
└── .claude/
    ├── CLAUDE.md                        # （可選的替代專案層級檔案）
    ├── rules/
    │   ├── typescript.md
    │   ├── testing.md
    │   ├── api-conventions.md
    │   ├── database.md
    │   ├── deployment.md
    │   └── security.md
    ├── commands/                        # 自定義 slash command（見 3.2）
    └── skills/                          # 自定義 skills（見 3.2）

協調者 CLAUDE.md 保存倉庫的高層背景，並將細節委派給規則檔案：

# ExamLab 倉庫記憶

這是一個以 Cloudflare 為核心的 monorepo，服務一個備考平台。
Phase 1 MVP 目標是 6 張認證、12 種語言。

## 核心規則

@import ./.claude/rules/typescript.md
@import ./.claude/rules/testing.md
@import ./.claude/rules/api-conventions.md
@import ./.claude/rules/database.md
@import ./.claude/rules/deployment.md
@import ./.claude/rules/security.md

## 專案特定慣例

- 永遠以正體中文回應作者。
- 不得提交包含 `TODO` 且未附 GitHub issue 連結的檔案。

單體式 vs 模組化 — 架構師的抉擇

小型倉庫（單一應用、一兩位工程師）可以只用一個 100 行的 CLAUDE.md 而不需要任何 import。大型倉庫（擁有多個套件與團隊的 monorepo）幾乎立刻就需要模組化模式，因為單體式檔案很快就會變得無法審查也無法瀏覽。CCA-F 考試經常測試這個判斷：當情境描述一個成長中的團隊、重疊的慣例或跨團隊衝突時，預期答案是把單體式檔案拆分為 .claude/rules/ 下的多個檔案，並透過 @import 串接起來。

/memory 指令 — 驗證已載入的記憶體檔案

Claude Code 提供一個 slash command /memory，會列出當前工作階段記憶體中已載入的所有 CLAUDE.md 檔案，包含它們的路徑，以及每個檔案所屬的範疇。當答案或行為與倉庫的 CLAUDE.md 檔案所預期的不符時，這是架構師首先使用的診斷工具。

/memory 顯示的內容

在活躍的 Claude Code 工作階段中執行 /memory，會產生類似這樣的輸出：

Loaded memory files:
  [user]      /Users/jaric/.claude/CLAUDE.md
  [project]   /Users/jaric/work/examlab/CLAUDE.md
  [project]   /Users/jaric/work/examlab/.claude/rules/typescript.md  (imported)
  [project]   /Users/jaric/work/examlab/.claude/rules/testing.md     (imported)
  [directory] /Users/jaric/work/examlab/packages/web/CLAUDE.md

架構師可以立刻確認：

• 預期的使用者層級檔案是否有被載入（可能因缺失或路徑錯誤而未載入）。
• 專案層級檔案是否有被找到（若 Claude Code 是在倉庫外啟動的，就不會載入）。
• 哪些 @import 目標有被解析（缺失的檔案不會出現在清單中）。
• 當前工作目錄是否有活躍的目錄層級檔案。

/memory 作為第一線診斷工具

當情境題描述 Claude 行為異常——「Claude 沒有遵循我們記錄的測試慣例」——架構師的第一個動作是執行 /memory，確認測試規則檔案是否真的有被載入。問題的修正方法往往不是「加更多指示」，而是「確保現有指示已在範疇內」。

白話文解釋 CLAUDE.md 階層架構

抽象的範疇規則一旦錨定在熟悉的日常情境上，就會變得直觀。以下四個類比涵蓋 CLAUDE.md 階層架構的完整面貌。

類比一：辦桌廚房 — 個人口味、店家食譜、工作站規則

想像一個忙碌的辦桌廚房，三層指示在其中並行而不衝突。

每位師傅口袋裡帶著的個人筆記本，就是使用者層級 CLAUDE.md。裡面記著個人口味偏好（「我的滷汁永遠比標準食譜再多燉半小時」）和個人習慣（「切肉我偏好剔骨刀，不用厚刀」）。別人看不到這本筆記本。它跟著師傅走，換了哪家辦桌都帶著。

釘在出菜台旁的店家食譜總冊，就是專案層級 CLAUDE.md。它定義這家辦桌店的慣例——「豬肉要燉到筷子一插即透」、「所有菜色出台前用乾淨的布抹盤邊」、「辦桌菜色依四季時令輪替」。廚房裡每個人都遵守這本冊子。新師傅第一天就會拿到一份。

貼在各工作站上方的護貝小卡，就是目錄層級 CLAUDE.md。白切雞工作站的卡寫著「雞隻下鍋前務必確認冰水備好以便冰鎮定型」；糕點工作站的卡寫著「發糕麵糊調好後至少靜置 30 分鐘再入爐」。這些卡片在店家食譜之上疊加工作站專屬規則——不會取代食譜。若白切雞師傅被調去幫忙熱炒，他仍遵守滷肉的店家規定。

對應回來：CLAUDE.md 階層架構在每次師傅（Claude Code）開始在某個工作站（目錄）工作時，會合併三個層級。個人筆記本（使用者）、店家食譜（專案）、工作站小卡（目錄）同時攤開在面前。

類比二：服裝規定 — 個人衣橱、公司政策、場地告示

想像某個普通工作日抵達辦公室。

你在家裡的衣橱決定今天穿什麼——藍色襯衫、卡其褲、棕色皮鞋。這是使用者層級，別人看不見，套用在你工作過的每個辦公室。

公司的人資政策再加一層：「上班時間 09:00 至 18:00 商務休閒裝」、「生產區域不得穿露趾鞋」、「客戶會議穿公司品牌外套」。這適用於公司每位員工，明訂在員工手冊中——相當於專案層級 CLAUDE.md。

最後，某個房間門口的告示再加最後一層：「無塵室——進入本區域請穿鞋套」。你仍遵守人資政策的品牌外套規定，仍穿著家裡選的藍色襯衫，並額外套上鞋套。無塵室告示不會取代服裝規定；它只是在上面疊加一條特定規則。這就是目錄層級 CLAUDE.md。

CCA-F 常見的錯誤，就是誤以為無塵室告示取代了人資政策。並不會。合併永遠是累加的。

類比三：開卷考 — 你帶進考場的參考資料

你坐在一場開卷考試的桌前，桌上有三疊資料。

• 你的個人讀書筆記（使用者層級 CLAUDE.md）每場考試都帶著你。它反映你的學習風格——螢光筆、頁邊塗鴉、記憶口訣表。
• 這門課指定的教科書（專案層級 CLAUDE.md）是全班共用的標準參考；它定義了共同的詞彙。
• 這個特定題組的補充講義（目錄層級 CLAUDE.md）給出局部規則——「本題組請用簡化的尤拉法，不用 Runge-Kutta」。

答題時，你同時從三疊資料中取用。每疊資料疊加在前一疊之上，最具針對性的（講義）在直接衝突時優先。這正是 CLAUDE.md 階層架構在工作階段啟動時合併的方式。

類比四：工具箱 — 個人工具、廠房規定、現場告示

師傅的個人工具箱走到哪帶到哪——這是使用者層級。廠房每個工位牆上貼著的標準作業程序——這是專案層級。今天貼在客戶車引擎蓋上的現場告示「此車安全氣囊有效，未依公告 24-A 程序前不得切斷電源」——這是目錄層級。

師傅三樣東西同時參照。CLAUDE.md 階層架構對 Claude Code 就是這樣運作的。

什麼內容該放進 CLAUDE.md，什麼不該放

把內容放在正確的 scope 是一半的功夫。

該放

• 跨 session 持續存在的上下文 — 技術棧、架構約束、coding 慣例、禁止模式。
• 穩定規則 — 依架構決策的步調，不依個別任務。
• 橫切慣例 — Security、logging、error handling 等跨多檔案的規則。
• 探索輔助 — 關鍵檔案（src/router.ts）與關鍵指令（pnpm test）的指引。

不該放

• API key / secrets — CLAUDE.md 以 prompt context 讀取，可能被記錄。
• 單次任務指示 — 「重構 checkout」屬於 prompt，不屬於規則。
• 易變資料 — Release notes、sprint TODO；老化快、汙染 context。
• 長篇教學 — 連結到外部文件；CLAUDE.md 該精簡。

隊友上線 — 經典診斷模式

Domain 3.1 最具代表性的 CCA-F 考試模式之一，是新隊友沒有收到指示的情境。每當題目引入一位加入團隊的新工程師，並表示他們「沒有看到預期的 Claude Code 行為」，請仔細閱讀。

情境範本

情境通常長這樣：

一位架構師已設定 Claude Code 遵循團隊的 React 慣例。架構師自己的工作階段正確遵循這些慣例。一位新工程師加入團隊，clone 倉庫，執行 claude。新工程師回報 Claude 忽略了這些慣例。倉庫中沒有其他任何改變。最可能的原因是什麼？

干擾答案通常包括：

• （A）新工程師需要升級 Claude Code 客戶端。
• （B）慣例的寫法讓 Claude 無法解析。
• （C）慣例設定在原始架構師的機器上的使用者層級（~/.claude/CLAUDE.md），因此未透過版本控制共用。
• （D）新工程師需要執行 /memory 來重新載入規則。

正確答案是（C）。診斷邏輯是：若架構師的機器行為正確而新工程師的不正確，且其他什麼都沒變，那麼指示一定在跟著架構師走、而非跟著倉庫走的位置。唯一符合這個描述的位置是使用者層級 CLAUDE.md。

架構師的修正方法

修正方法是把指示從使用者層級移動到專案層級：

1. 從 ~/.claude/CLAUDE.md 複製（或剪下）相關章節。
2. 貼到 <repo-root>/CLAUDE.md（或 .claude/rules/ 下的專屬檔案並從根目錄 import）。
3. 提交到版本控制。
4. 請新工程師 git pull 並重新開啟 Claude Code。

修正後，兩位工程師的 /memory 輸出都應顯示慣例檔案從專案範疇載入。

CI/CD 中的 CLAUDE.md — 非互動式情境

CCA-F 考試的 Claude Code for Continuous Integration 情境叢集，經常將 Domain 3.1（CLAUDE.md 階層架構）與 Domain 3.6（CI/CD 整合）結合在一起。在 CI 情境中，Claude Code 以非互動式方式執行——通常透過 -p 旗標——並與互動式工作階段相同地讀取 CLAUDE.md 檔案。

CI 中有什麼不同

• 執行 CI 工作的 OS 使用者通常是像 github-actions 這樣的機器人帳號，因此 ~/.claude/CLAUDE.md 的使用者層級 CLAUDE.md 並非架構師的個人檔案——而是存在於 CI runner 家目錄的任何檔案（大多數情況下什麼都沒有）。
• 專案層級 CLAUDE.md 與本機開發完全相同地被找到，因為 CI runner 會 checkout 倉庫並從其內部執行 Claude Code。
• 目錄層級檔案的運作方式相同，範疇限定在 CI 步驟的工作目錄。

什麼維持不變

• 互動式與非互動式工作階段的階層優先順序與合併規則不會改變。
• @import 解析方式相同。
• /memory 的運作方式相同，但由於 CI 是非互動式的，若需要診斷 CI 執行，必須透過腳本輸出記憶體狀態。

為什麼這對考試很重要

CCA-F 的題目可能描述一個「CI 中的 Claude Code 沒有遵循架構師本機工作階段相同慣例」的 CI pipeline。診斷邏輯與隊友上線模式一致：本機規則很可能在架構師機器的使用者層級。將它們移到專案層級，一次修正同時解決了隊友上線問題和 CI 不符問題。

常見考試陷阱 — Domain 3.1 CLAUDE.md 階層架構

CCA-F 考試針對 CLAUDE.md 階層架構利用四種反覆出現的陷阱模式。將每個陷阱及其對應的反制方法牢記於心。

陷阱一：目錄層級取代專案層級

最常見的陷阱。答案選項暗示目錄層級 CLAUDE.md 會取代專案層級檔案。並不會。合併永遠是累加的。目錄層級檔案補充較高層級；它無法讓它們靜音。

陷阱二：使用者層級檔案與隊友共用

干擾答案聲稱在使用者層級 CLAUDE.md 中寫入慣例就已足夠，「因為團隊所有人都在用 Claude Code」。這是錯誤的：使用者層級的檔案存在於每個 OS 使用者的家目錄，永遠不會透過 git 傳遞。隊友看不到它們。需要傳達給隊友的指示，屬於專案層級。

陷阱三：@import 路徑是絕對路徑或相對於倉庫根目錄

干擾答案聲稱 @import 相對於倉庫根目錄解析路徑。並不是——@import 相對於包含該指令的檔案進行解析。若你移動了規則檔案，所有指向它的 @import 都必須重新審查。

陷阱四：.claude/rules/ 自動載入

干擾答案聲稱 .claude/rules/ 下的檔案會被 Claude Code 自動載入。並不會。.claude/rules/ 是存放規則檔案的位置慣例；這些檔案只有在有效 CLAUDE.md 鏈中的某個地方透過 @import 引入它們時才會生效。若一個團隊把規則檔案丟進 .claude/rules/ 卻沒有設定 @import，會發現 /memory 顯示這些檔案根本沒有被載入。

考前必背重點

CLAUDE.md 階層架構主題獎勵記憶一小組關鍵事實。

練習錨點 — 任務 3.1 情境題類型

CLAUDE.md 階層架構的練習題聚集在四種可辨識的題型上。每種題型對應一個 CCA-F 要求架構師內化的具體診斷模式。附有完整解析的詳細版本存放在 ExamLab CCA-F 題庫中。

類型 A — 隊友上線失敗

一位新工程師加入團隊、clone 倉庫、執行 Claude Code，回報慣例沒有被遵守，但撰寫這些慣例的架構師看到的行為是正確的。預期答案：慣例存在於 ~/.claude/CLAUDE.md（使用者層級），需要搬移到專案層級檔案，讓版本控制負責傳遞它們。這是 Code Generation with Claude Code 情境的標準陷阱。

類型 B — 單體式 CLAUDE.md 變得無法審查

一個成長中的團隊回報他們那個 2500 行的單體 CLAUDE.md 在 pull request 中痛苦難審，而且一個團隊的修改經常與另一個團隊的修改衝突。預期答案：重構為 .claude/rules/*.md 檔案，從協調者 CLAUDE.md 用 @import 指令串接，並依規則檔案指派 CODEOWNERS。「把檔案縮短，移除一些規則」的干擾選項是錯的，因為規則本身是正確的——組織結構才是問題所在。

類型 C — CI Pipeline 未遵循本機慣例

一個以 -p 旗標執行 Claude Code 的 CI pipeline 產出的結果忽略了架構師在本機套用的慣例。預期答案：慣例存在於架構師機器的使用者層級，在 CI runner 上不存在；移到專案層級，同時修正 CI 不符和隊友上線問題，一次搞定。

類型 D — @import 目標沒有被載入

開發者在專案層級 CLAUDE.md 的頂端加入 @import ./rules/testing.md，但 /memory 沒有顯示該檔案已載入，測試慣例也被忽略。預期答案：路徑相對於包含該指令的檔案；該檔案不存在於 <repo>/rules/testing.md，或者架構師原本的意圖是 ./.claude/rules/testing.md。執行 /memory 確認哪些檔案已載入，有助於找出損壞的路徑。

CCA-F 認知深度 vs CCP-P 建構深度

CCA-F 定位為基礎、架構層級認證。它測試你能否辨識某條規則的正確範疇、從情境描述診斷一個放錯位置的檔案，以及判斷某個情境是否應使用使用者、專案或目錄層級。

更高階的 Claude Certified Professional 和 Claude Certified Practitioner 計畫（待日後推出）將測試建構層級的深度——撰寫包含 @import 鏈的複雜 .claude/rules/ 階層、將 CLAUDE.md 合併與自定義 skills 及 slash command 整合，以及為記憶體檔案正確性撰寫 CI 驗證。

對 CCA-F 而言，停留在認知與判斷層：

• 精確記住三個路徑。
• 知道合併是累加的。
• 熟悉使用者 vs 專案的診斷模式。
• 知道 /memory、@import 和 .claude/rules/ 各自做什麼、不做什麼。

若你開始撰寫自定義驗證腳本或手動追蹤十個檔案的 @import 解析鏈，你已經偏入 CCA-F 不需要的實作深度了。

CLAUDE.md 階層架構常見問題（FAQ）

對 CCA-F 考試而言，使用者層級、專案層級和目錄層級 CLAUDE.md 有什麼差別？

使用者層級 CLAUDE.md 位於 ~/.claude/CLAUDE.md，適用於該 OS 使用者執行的每個工作階段，且不透過版本控制共用——它是個人機器的私有設定。專案層級 CLAUDE.md 位於倉庫根目錄（或 .claude/ 內），提交至 git，適用於每位隊友在倉庫內開啟的每個工作階段。目錄層級 CLAUDE.md 位於子目錄內，提交至 git，僅在 Claude Code 在該子樹內運作時生效。CCA-F 要求反射性地辨識給定規則屬於哪個層級。

為什麼新隊友沒有收到我設定的 Claude Code 指示？

幾乎可以確定是因為指示存在於你在 ~/.claude/CLAUDE.md 的使用者層級 CLAUDE.md，它存放在你的個人機器上，永遠不會透過 git 倉庫傳遞。修正方法是將指示移到倉庫根目錄的專案層級 CLAUDE.md（或 .claude/rules/ 下的檔案並從根目錄 import），提交更改，並請隊友 git pull。這是 Domain 3.1 考試中測試最頻繁的模式——若 CCA-F 情境對比「在我的機器上可以」與「在隊友機器上不行」，答案就是範疇不符。

目錄層級 CLAUDE.md 會取代專案層級 CLAUDE.md 嗎？

不會。CLAUDE.md 階層架構的合併是累加的，而非取代。目錄層級檔案補充專案層級檔案；兩者都在工作階段啟動時載入並合併。若專案層級檔案說「用 Vitest 做測試」，而某個子目錄的檔案對測試隻字未提，Vitest 規則在那個子目錄內仍然有效。這個累加合併語義是考試測試最多的陷阱之一——描述較低層級「取代」較高層級的答案選項是錯的。

CLAUDE.md 中的 @import 如何解析路徑？

@import <path> 相對於包含該指令的檔案解析路徑，而非相對於倉庫根目錄，也不是相對於當前工作目錄。若 packages/web/CLAUDE.md 包含 @import ./rules/components.md，Claude Code 會尋找 packages/web/rules/components.md。這個規則容易記錯——CCA-F 經常包含聲稱 @import 從倉庫根目錄解析的干擾選項。請記住「相對於 import 它的那個檔案」。

.claude/rules/ 目錄是什麼，Claude Code 會自動載入其中的檔案嗎？

.claude/rules/ 是根目錄 CLAUDE.md 透過 @import 引入的焦點 Markdown 規則檔案的社群慣用存放位置。Claude Code 不會自動載入 .claude/rules/ 中的檔案——只有在有效 CLAUDE.md 鏈中的某個地方引入了它們，才會生效。若你把檔案丟進 .claude/rules/ 但沒有加入對應的 @import，這個檔案什麼都不做。這是一個 CCA-F 陷阱模式：描述 .claude/rules/ 為「自動載入」的干擾選項是錯的。

/memory 指令是做什麼的，什麼時候應該用它？

/memory 是一個 Claude Code slash command，列出目前工作階段中載入的每個 CLAUDE.md 檔案，以及範疇（使用者、專案或目錄）和透過 @import 引入的任何檔案。當 Claude 的行為與你的 CLAUDE.md 檔案所說的不符時，把它當作第一線診斷工具使用——根本原因往往是某個檔案根本沒有被載入（路徑錯誤、缺少 @import 目標，或 Claude Code 在倉庫外啟動），而非規則措辭有問題。在 CCA-F 中，任何說「規則被忽略」的情境，都應該先讓你想到規則是否有被載入。

什麼內容應該放進 CLAUDE.md，什麼不應該放？

放入跨工作階段持續存在的永久性上下文——技術棧聲明、編碼慣例、架構約束、禁止模式、關鍵檔案與指令的指引。密鑰與憑證不要放（這個檔案是提示上下文，且通常提交至 git）。單次任務指示不要放——那屬於對話提示或自定義 slash command。易變資料不要放——版本發布說明、衝刺目標、任務描述老化太快。CCA-F 經常測試這個判斷：若情境提到短期任務備註，正確的範疇是提示，而非 CLAUDE.md。

延伸閱讀

• CLAUDE.md configuration — Claude Code Docs: https://docs.anthropic.com/en/docs/claude-code/claude-md
• Claude Code features overview: https://docs.anthropic.com/en/docs/claude-code/overview
• Claude Code settings reference: https://docs.anthropic.com/en/docs/claude-code/settings
• Integrate Claude Code into CI/CD pipelines: https://docs.anthropic.com/en/docs/claude-code/ci-cd
• Custom slash commands and skills: https://docs.anthropic.com/en/docs/claude-code/slash-commands
• Claude Certified Architect Foundations — launch announcement: https://www.anthropic.com/news/claude-certified-architect
• CCA-F Exam Guide PDF: https://everpath-course-content.s3-accelerate.amazonaws.com/instructor/8lsy243ftffjjy1cx9lm3o2bw/public/1773274827/Claude+Certified+Architect+%E2%80%93+Foundations+Certification+Exam+Guide.pdf

Related ExamLab topics: 自定義 Slash Command 與 Skills, 路徑專屬規則與條件式慣例載入, Plan Mode vs 直接執行, MCP Server 整合至 Claude Code, 內建工具的選擇與應用.