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 考試要求你診斷損壞設定、正確引導新隊友，以及避免個人偏好洩漏到共用倉庫的架構視角。

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

CLAUDE.md 階層架構的每個層級服務特定的對象，並存放於特定的檔案系統位置。將檔案放錯一個層級，是 Domain 3.1 最常見的考試陷阱，因此請將這些位置練習到反射性記憶的程度。

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

使用者層級 CLAUDE.md 位於 ~/.claude/CLAUDE.md（波浪號展開為使用者的家目錄——macOS 上是 /Users/<name>/，Linux 上是 /home/<name>/，Windows 上是 C:\Users\<name>\）。這個檔案專屬於擁有它的作業系統帳號，不提交至任何共用倉庫，隊友看不到，且每次使用者開啟工作階段時，無論在哪個專案，Claude Code 都會載入它。

適合放在使用者層級 CLAUDE.md 的內容：

• 「請稱呼我 Jaric，不要叫我『使用者』。」
• 「個人腳本偏好 pnpm，不用 npm 或 yarn。」
• 「對話回覆使用正體中文，程式碼注釋保持英文。」
• 「終端機文字輸出預設使用適合深色模式的 ANSI 色彩。」

不適合放在此處（應放在專案層級）：

• 「這個倉庫使用 Astro 4 和 Cloudflare Pages adapter。」
• 「所有資料庫 migration 透過 pnpm run migrate:new 執行。」

判斷原則：如果一個隊友 clone 倉庫後需要這條指示才能正確工作，它就屬於專案層級，而不是使用者層級。如果這條指示只反映個人習慣或環境，就留在使用者層級。

專案層級 — .claude/CLAUDE.md 或根目錄 CLAUDE.md

專案層級 CLAUDE.md 是共用的倉庫記憶。Claude Code 接受兩個標準的專案層級檔案位置：

• <repo-root>/CLAUDE.md — 位於倉庫頂層的裸檔案。
• <repo-root>/.claude/CLAUDE.md — 位於 .claude/ 設定目錄內。

兩個位置都有效；裸根目錄檔案更容易被發現，也是開源 Claude Code 倉庫最常見的模式。若你想把相關設定資產（slash command、skills、rules、settings）集中在一起，則偏好使用 .claude/ 目錄。

專案層級檔案提交至版本控制。每位 clone 倉庫並在其中執行 claude 的隊友，都會自動載入這些指示。適合放在此處的內容：

• 技術棧聲明（「本倉庫為 Astro 4 + TypeScript + Cloudflare Pages」）。
• 編碼慣例（「使用帶有 hooks 的函式式 React 元件；不用 class 元件」）。
• 架構約束（「所有資料庫存取透過 db/ 套件；路由 handler 中不得直接 import @prisma/client」）。
• 禁止模式（「TypeScript 中不得使用 any；不得提交包含 TODO 或 FIXME 的檔案」）。
• Claude 應執行或建議的測試、建置與部署指令。

目錄層級 — 巢狀 CLAUDE.md

目錄層級 CLAUDE.md 位於倉庫的子目錄中，僅在 Claude Code 的工作上下文位於該子樹內時才生效。例如，在包含 packages/api/、packages/web/ 和 docs/ 的 monorepo 中，每個子目錄都可以有自己的 CLAUDE.md，其中載明該模組專屬的規則：

• packages/api/CLAUDE.md — 「這是後端 API。使用 Hono 做路由。所有 handler 必須以 Zod 驗證輸入。」
• packages/web/CLAUDE.md — 「這是 Astro 前端。頁面使用 .astro 元件；只在需要互動性時才使用 React island。」
• docs/CLAUDE.md — 「這是文件目錄。檔案為 Markdown。標題與 frontmatter 遵循 docs/STYLE.md 指南。」

當 Claude Code 在 packages/api/ 中運作時，會載入使用者層級、專案層級與 packages/api/CLAUDE.md 並合併它們。移動到 packages/web/ 時，API 目錄的檔案會被 web 目錄的檔案取代。在任意時刻，只有從當前工作目錄往上走到倉庫根目錄的路徑上，最近的那個目錄層級檔案會被載入——這個細節經常出現在情境題中。

階層優先順序與合併語義

CLAUDE.md 階層架構不採用「贏家通吃」模型。Claude Code 會依特殊性由低到高的順序讀取每個適用的檔案並串接指示，最具針對性的指示排在最後，這樣當 Claude 處理衝突時，自然會賦予它們較高的權重。

載入順序

當工作階段在 <repo>/packages/web/src/routes/login/ 啟動時，載入順序為：

1. ~/.claude/CLAUDE.md（使用者層級）
2. <repo>/CLAUDE.md 或 <repo>/.claude/CLAUDE.md（專案層級）
3. <repo>/packages/web/CLAUDE.md（目錄層級——從樹狀結構往上找到的最近一個）

若 <repo>/packages/web/src/routes/CLAUDE.md 也存在目錄層級檔案，它也會被載入；Claude Code 從當前工作目錄往上遍歷目錄樹，沿途拾取每個 CLAUDE.md，直到到達專案根目錄為止。

何謂衝突

自然語言指示不像結構化 key 那樣產生明確碰撞——「偏好 pnpm」和「永遠用 yarn」都會注入到上下文中，Claude 會透過賦予更具針對性來源（目錄 > 專案 > 使用者）較高權重來解決這個表面矛盾。但在實踐中，設計良好的 CLAUDE.md 檔案會避免衝突，讓每個層級聚焦在不重疊的關注點上：使用者層級處理個人習慣，專案層級處理共用慣例，目錄層級處理模組專屬的覆寫。

合併是累加，不是替換

CCA-F 考試常見的陷阱是誤以為目錄層級檔案會取代專案層級檔案——並不會。若專案層級 CLAUDE.md 說「永遠用 Vitest 撰寫單元測試」，而 docs/CLAUDE.md 對測試隻字未提，當 Claude 在 docs/ 內工作時，Vitest 的指示仍然有效。目錄層級檔案只會新增指示；它永遠不會刪除任何指示。

@import 語法與模組化組織

隨著倉庫成長，單體式 CLAUDE.md 會愈來愈難維護——它不斷累積測試、部署、樣式指南、架構決策、資料庫規則、API 契約等章節。Anthropic 的解決方案是 @import 語法，讓 CLAUDE.md 可以參照其他 Markdown 檔案，使每個主題都能存放在自己專屬的文件中。

語法與路徑解析

@import 指令接受相對於包含該指令的檔案的路徑。例如，根目錄的 CLAUDE.md 可能長這樣：

# 倉庫記憶

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

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

工作階段啟動時，Claude Code 讀取根目錄的 CLAUDE.md，遇到每個 @import，相對於根目錄解析路徑，載入目標 Markdown 檔案，並將其內容內聯展開，彷彿它從一開始就是主檔案的一部分。

相對路徑規則

@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 保存倉庫的高層背景，並將細節委派給規則檔案：

# ExamHub 倉庫記憶

這是一個以 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/examhub/CLAUDE.md
  [project]   /Users/jaric/work/examhub/.claude/rules/typescript.md  (imported)
  [project]   /Users/jaric/work/examhub/.claude/rules/testing.md     (imported)
  [directory] /Users/jaric/work/examhub/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，什麼不該放

把階層架構設定正確，也意味著要在正確的範疇放入正確的內容。有兩條經驗法則可以指引決策。

應包含

• 跨工作階段持續存在的上下文 — 技術棧、架構約束、編碼慣例、禁止模式。
• 穩定的規則 — 依照架構決策的步調更新，而非依照個別任務的步調。
• 橫切慣例 — 適用於 agent 會碰觸的許多檔案的安全規則、記錄需求、錯誤處理模式。
• 探索輔助 — 指向關鍵檔案的指引（「路由表在 src/router.ts」）和關鍵指令（「測試套件以 pnpm test 執行」）。

不應包含

• 密鑰、憑證、API key、連線字串 — CLAUDE.md 檔案以提示上下文的形式讀取，可能被記錄；把它當作已提交到 git 的文件看待（通常確實如此），永遠不要放憑證。
• 單次任務指示 — 「這張票要重構結帳流程」屬於對話提示，不屬於 CLAUDE.md。
• 易變資料 — 版本發布說明、有日期的 TODO 清單、衝刺目標；這些東西老化很快，會汙染上下文。
• 長篇教學 — 改為連結到外部文件；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 要求架構師內化的具體診斷模式。附有完整解析的詳細版本存放在 ExamHub 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 ExamHub topics: 自定義 Slash Command 與 Skills, 路徑專屬規則與條件式慣例載入, Plan Mode vs 直接執行, MCP Server 整合至 Claude Code, 內建工具的選擇與應用.