CCAR-F 备考手册 · Claude Certified Architect – Foundations
Chapter 05 · Domain 3（权重 20%）

CLAUDE.md 层级体系
user / project / directory、@import、.claude/rules/

Domain 3 有一半的题是「这段配置应该放在哪」。判断轴只有两条，ch01 的 P9 已经给过：要不要共享决定放哪一层，作用于哪些文件决定用什么形态。本章把这两条轴的全部形态列清楚，并标出考试爱用的捏造配置。

一、三层配置的位置与共享语义

~/.claude/CLAUDE.md              ✔ 真实存在 · user 级 · 只对该用户生效，不随版本库共享给队友
<repo>/CLAUDE.md                 ✔ 真实存在 · project 级 · 进版本库，clone/pull 即得
<repo>/.claude/CLAUDE.md         ✔ 真实存在 · project 级的另一位置
<repo>/packages/api/CLAUDE.md    ✔ 真实存在 · directory 级 · 绑定该子目录
<repo>/.claude/rules/*.md        ✔ 真实存在 · 主题化规则文件，可用 YAML frontmatter 的 paths 做 glob 条件加载
<repo>/.claude/config.json       ✘ 不存在 · 官方样题 Q4 的 D 选项（带 commands array 的配置文件）
层级位置随版本库共享？典型内容
user~/.claude/CLAUDE.md否 — 只对该用户生效个人快捷偏好、个人实验
project.claude/CLAUDE.md 或仓库根 CLAUDE.md是团队编码标准、测试约定、review 准则
directory子目录下的 CLAUDE.md是该目录特有的约定（仅当约定确实目录绑定时）
最常考的诊断题 — 「老成员一切正常，新成员克隆仓库后 Claude 完全不遵守团队约定」。 根因几乎总是：这些指令写在某个老成员的 ~/.claude/CLAUDE.md 里。user 级配置不随版本库分发，所以对老成员「一直有效」，对新成员「从来没有过」。修复是把它们移到 project 级。诊断工具是 /memory——查看当前实际加载了哪些 memory 文件，正是用来定位这类跨会话/跨成员的不一致。

二、@import：让 CLAUDE.md 保持模块化

单体 CLAUDE.md 会随项目膨胀，最后没人愿意维护。@import 语法允许引用外部文件，把标准拆出去按需组合——guide 给的用法是各 package 的 CLAUDE.md 按维护者的领域知识，选择性 import 与自己相关的标准文件。

# packages/api/CLAUDE.md

本包为对外 REST API。除下列标准外，遵循仓库根 CLAUDE.md。

@../../standards/error-handling.md
@../../standards/api-versioning.md

导入的实际写法是 @路径：考纲把这个功能叫「@import 语法」，本章沿用这个名字，考试也按这个叫法作答。官方文档给出的写法是 @path/to/import，不带 import 关键字，所以上面的示例直接写 @../../standards/…。相对路径按写这行导入的那个文件解析，不按工作目录解析。

来源：How Claude remembers your project · Import additional files。查阅于 2026-10-16。

注意 @import 与 .claude/rules/ 解决的不是同一个问题，这是本章最容易混的一组：

@import.claude/rules/
解决什么CLAUDE.md 文件本身太大、内容复用规则该不该加载——按当前编辑的文件路径条件生效
加载时机随宿主 CLAUDE.md 一起加载只在编辑匹配 glob 的文件时加载，省 token
关键机制文件引用YAML frontmatter 的 paths 数组

三、路径规则：横切约定的正解

--- .claude/rules/testing.md ---
---
paths: ["**/*.test.tsx", "**/*.test.ts"]     ✔ 真实存在 · frontmatter 的 paths 数组接受 glob
---
所有测试使用 table-driven 风格；mock 一律放在 __mocks__/ 下；
禁止在测试里直接读环境变量，用 fixtures/env.ts。

--- .claude/rules/terraform.md ---
---
paths: ["terraform/**/*"]                    ✔ 真实存在 · guide 原例
---
所有 module 必须声明 required_version；state 不入库。

三条要点，每条都被考过：

  1. 条件加载省 token——path-scoped 规则只在编辑匹配文件时加载，无关上下文不进 context。
  2. 横切文件必须用 glob，不能用 directory CLAUDE.md——测试文件散布在整个代码库里（Button.test.tsx 就躺在 Button.tsx 旁边），而 CLAUDE.md 是目录绑定的，覆盖不了散布的文件。这是官方样题 Q6 的正确答案。
  3. 「自动应用」的要求排除 skills——skill 需要被调用（或依赖 Claude 主动选择加载），题干一旦强调「automatically applies based on file paths」，skill 就出局了。
  1. 要团队共享 → 进版本库（project 级 / .claude/ 下）；要个人私有 → 家目录。
  2. 约定横跨多个目录 → .claude/rules/ + glob；约定确实绑定某个目录 → 该目录的 CLAUDE.md。
  3. 始终适用的普适标准 → CLAUDE.md；按需调用的任务流程 → skill（见 ch06）。
  4. 行为跨会话/跨成员不一致 → 先跑 /memory 看实际加载了什么。
实践中还有一个层级顺序问题：多层同时存在时，更具体的层通常补充而非整体覆盖上层。Exam Guide 没有给出优先级的形式化规则，只给了「层级 + 共享语义」这一层信息，所以考试不会考「project 与 directory 冲突时谁赢」这类细节。备考时把精力放在该放哪一层，不要花在推演覆盖顺序上。
外部课程 · CertSafari — 本章 2 个考点（展开查看）

用于补读和错题复盘；第三方 AI 生成练习材料，非官方题库。核验答案时以 Exam Guide 和官方文档为依据。复盘方法 · 链接核对：2026-10-16。

考点回链 — 本章覆盖：TS 3.1（user/project/directory 三层、user 级不随版本库共享、@import 模块化、.claude/rules/ 拆分主题化规则、/memory 诊断）、TS 3.3（frontmatter paths glob 条件加载、省 token、横切文件优于 directory CLAUDE.md）。相邻考点：commands / skills 见 ch06，MCP 作用域见 ch12。

本章题组

ch05 · Q1 · 准则 P9
Three engineers have used Claude Code on your repo for months and report that it reliably follows the team's commit-message format and error-handling conventions. Two engineers who joined last week report that Claude ignores both. All five are on the same repo, same branch, same Claude Code version. What is the most likely cause?
正确 DTS 3.1 点名的诊断场景：新成员收不到指令，因为它们在 user 级而非 project 级配置里。症状的形状是关键——按人分裂（老成员全对、新成员全错），而不是按文件或按任务分裂。修复是把它们移进版本库里的 project 级 CLAUDE.md。
D1 凭空捏造违反 P9A：/memory 是查看已加载 memory 文件的诊断命令（TS 3.1），不是加载命令。project 级配置不需要谁手动 load。它是很好的排查工具，但不是这里的原因。
D4 甩锅错位违反 P1B：若真是 glob 不匹配，症状应当按文件类型分裂——老成员编辑同类文件时也该失效。题干的分裂线是人员，不是路径。
D1 凭空捏造违反 P1C：编造了一个截断阈值机制。而且它同样解释不了人员维度的分裂——同一个仓库的 CLAUDE.md 对五个人是同一份。
ch05 · Q2 · 准则 P9
Your monorepo has React components, Go services, and Terraform modules. Test files sit next to the code they test in all three areas (*.test.tsx, *_test.go). You want one set of testing conventions applied automatically whenever any test file is edited, regardless of where it lives. What is the most maintainable configuration?
正确 ATS 3.3：约定横跨多个目录、按文件类型而非位置生效时，.claude/rules/ + frontmatter glob 是正解；同时它只在编辑匹配文件时加载，省 token。与官方样题 Q6 同构。
D6 概率当保证违反 P9B：依赖 Claude 从一大段 CLAUDE.md 里推断哪一节适用，题干却明确要求「automatically applied」。官方样题 Q6 的 B 选项被点名正是「依赖推断而非显式匹配」。
D3 治标不治本违反 P9C：CLAUDE.md 是目录绑定的，散布在整个 monorepo 的测试文件意味着要复制维护几十份同样内容——「most maintainable」直接排除它。
D3 治标不治本违反 P9D：skill 是按需调用的任务型工作流（TS 3.2），需要有人（或 Claude）主动触发；这与「编辑到测试文件就自动生效」的确定性要求不符。官方样题 Q6 的 C 选项同一工艺。
ch05 · Q3 · 准则 P9
Your root CLAUDE.md has grown to cover eight packages' conventions. Package maintainers complain that irrelevant standards clutter every session, and that they cannot tell which rules apply to their package. Each package already has its own CLAUDE.md for package-specific notes. What is the appropriate refactor?
正确 BTS 3.1 的原话级 skill：用 @import 按各 package 维护者的领域知识，选择性引入相关标准文件——这正是 @import 被设计出来解决的问题（保持 CLAUDE.md 模块化）。普适规则仍留在根级，因为它们确实普适。
D3 治标不治本违反 P9A：删掉根文件会让真正普适的标准无处安放，八个包各自复制一份——把「臃肿」换成了「重复」。共享语义没变，维护成本更高。
D2 过度工程违反 P9C：.claude/rules/ + glob 的适配轴是横切多个目录的约定（TS 3.3）。这里的标准是按 package 边界组织的——正好是目录绑定的形态，用 glob 把每条规则圈回单个包目录，是拿横切工具做绑定的事。「只在编辑该包时才加载」这个好处，各包已有的 CLAUDE.md 本来就具备；换来的代价是把标准搬离维护者自己那份文件，「哪些规则适用于我」反而更难看清。
D3 治标不治本违反 P1D：目录让人读得方便，但整份文件仍然全量进入每个会话的 context——「无关标准塞满会话」这个根因完全没动。
ch05 · Q4 · 准则 P9
You maintain a personal set of verbose debugging preferences ("always print intermediate state when investigating a failing test") that your teammates find noisy. You want them active for your own sessions on this repo without affecting anyone else. Where do they belong?
正确 CTS 3.1：user 级 ~/.claude/CLAUDE.md 的定义性质就是「只对该用户生效、不通过版本控制共享给队友」。P9 的第一条轴——不共享 → 家目录。
D3 治标不治本违反 P9A：放进版本库就是共享，标注「optional」不改变它会进入每个队友会话的事实。用注释约束加载行为，是拿文档当机制。
D3 治标不治本违反 P9B：.claude/rules/ 在项目目录下同样入库共享；glob 限定的是哪些文件触发，不是对谁生效。队友编辑同样的测试目录时照样会被影响。
D1 凭空捏造违反 P9D：.claude/config.json 这个配置机制在 Claude Code 中不存在——官方样题 Q4 的 D 选项就是它（带 commands array 的版本）。「按用户名分块」更是叠加了一层虚构。
ch05 · Q5 · 准则 P9
Your infrastructure team wants Terraform-specific conventions (required provider versions, state handling, module naming) to load only when Claude is editing Terraform files, so that application developers never see them. All Terraform lives under terraform/. Two proposals are on the table: a terraform/CLAUDE.md, or a .claude/rules/terraform.md with paths: ["terraform/**/*"]. Which consideration decides it?
正确 BTS 3.3 的选择规则是有条件的，不是「rules 永远更好」：glob 规则优于 directory CLAUDE.md 的场景是约定必须覆盖散布在多个目录的文件。这里约定确实目录绑定，两者都成立；决定性考量是未来是否会横切——这正是 guide 给出的那条判据的正向表述。
D3 治标不治本违反 P9A：用措辞前缀模拟条件加载——规则仍然全量进入每个会话的 context，题干「应用开发者永远看不到它们」的要求直接落空；而且它把生效与否交给模型推断，正是官方样题 Q6 的 B 选项被点名的工艺。
D1 凭空捏造违反 P9C：说反了。TS 3.3 明确 path-scoped 规则只在编辑匹配文件时加载，条件加载正是它的核心卖点（省 token）。
D1 凭空捏造违反 P9D：user-scoped 的是 ~/.claude/CLAUDE.md。子目录 CLAUDE.md 属于 project 侧、随仓库分发给所有人。
ch05 · Q6 · 准则 P2
A developer reports that Claude behaves differently between two of their own sessions on the same repo: in one it applies the API error-handling convention, in the other it does not. Nothing in the repo changed between sessions. What is the most efficient first diagnostic step?
正确 BTS 3.1 明确给了 /memory 的用途：核实哪些 memory 文件被实际加载，诊断跨会话的行为不一致。这道题的措辞几乎是原文——先看清事实（加载了什么），再谈修复。P2 的比例原则在诊断阶段同样适用：最便宜的观察先做。
D3 治标不治本违反 P1A：在 prompt 里显式提醒，等于绕过了「配置是否加载」这个待查问题——两次都会收敛，但你什么也没学到，下次照样不一致。
D2 过度工程违反 P2C：在还没查清是配置未加载还是模型未遵守之前就上 hook。若根因是 path glob 没匹配，hook 只会把一个配置问题伪装成一堆写入拒绝。
D4 甩锅错位违反 P1D：把差异归给模型档位，而题干说的是同一个人、同一个仓库的两个会话——最可能变化的是会话加载了什么，不是模型是谁。
ch05 · Q7 · 准则 P9
Your team wants two things: (1) a universal rule that all public functions carry doc comments, applied in every session; and (2) a multi-step release-checklist workflow (bump version, regenerate changelog, verify migrations, draft release notes) that engineers run a few times per month. How should these be configured?
正确 CTS 3.2 的分工判据：CLAUDE.md = 始终加载的普适标准，skills = 按需调用的任务型工作流。文档注释规则每次会话都要生效（普适），发布清单每月跑几次且是多步流程（任务型）——两者各归各位。
D3 治标不治本违反 P9A：把一个每月只用几次的多步流程塞进始终加载的文件，等于让它在其余 100% 的会话里白占 context。这正是 skill 存在的理由。
D3 治标不治本违反 P9B：把普适标准做成 skill，意味着它需要被显式调用才生效——「每次会话都适用」的要求随即落空。方向与 A 相反，错误性质相同。
D2 过度工程违反 P9D：两处都错位。paths: ["**/*"] 匹配一切，等于用条件加载机制实现无条件加载——徒增一层间接；而多步发布流程放进 CLAUDE.md 又回到了 A 的问题。