Scenario 2 · 主考 Domain 3 / 5
S2 · Code Generation with Claude Code
把一个人的用法变成一个团队的配置
官方设定：用 Claude Code 加速软件开发，团队用它做代码生成、重构、调试与文档；需要把它接进开发流程——自定义 slash commands、CLAUDE.md 配置，并理解什么时候用 plan mode、什么时候直接执行。 这个场景几乎全是「配置放哪」和「先想还是先做」两类判断，官方样题里有三道（Q4、Q5、Q6）出自这里。
场景的隐含前提 — 设定里的关键词是 team。所有配置题的第一问都是「这东西要不要给队友」。P9 的第一条轴（共享进版本库、个人进家目录）在这个场景里的命中率高得离谱。
一、从零设计：四层配置
一个团队把 Claude Code 用起来，配置分四层，每层解决一个不同的问题：
| 层 | 放什么 | 加载时机 |
|---|---|---|
| 项目 CLAUDE.md | 始终适用的普适标准：编码规范、错误处理约定、测试标准 | 每次会话 |
.claude/rules/*.md | 按文件路径条件生效的约定（frontmatter paths glob） | 编辑匹配文件时 |
.claude/commands/ | 团队共享的 slash command | 被调用时 |
.claude/skills/ | 按需调用的多步任务流（SKILL.md frontmatter） | 被调用时 |
再加一层不进版本库的：~/.claude/CLAUDE.md、~/.claude/commands/、~/.claude/skills/——个人偏好与个人变体的去处。
二、上线：三个官方样题就是三次踩坑
踩坑 ①：想让所有人都能用 /review
官方样题 Q4：一个跑团队标准 code review 清单的 /review 命令，要求每个开发者 clone 或 pull 仓库就能用。答案是放 .claude/commands/——version-controlled，clone 即得。三个错法各有代表性：放 ~/.claude/commands/（个人命令，不随版本库共享）、写进 CLAUDE.md（那是项目指令与上下文，不是命令定义）、以及一个根本不存在的 .claude/config.json + commands array（官方解析原话：describes a configuration mechanism that doesn't exist）。
踩坑 ②：单体应用要拆微服务
官方样题 Q5：涉及数十个文件，且需要就服务边界与模块依赖做决策。答案是 plan mode——它正是为大规模变更、多个可行方案、架构决策设计的，让你在提交变更前安全地探索并设计，避免昂贵返工。三个错法：直接开干让实现「自然揭示」服务边界（依赖发现太晚，返工成本最高）、直接执行但给一份详尽的前置指令（假设你已经知道正确结构，而你还没读代码）、以及最值得记住的那个——先直接执行，遇到意外复杂度再切 plan，官方解析点名它「忽视了复杂性已经写在需求里，而不是可能才出现」。
踩坑 ③：测试文件散落各处
官方样题 Q6：代码库分区有不同约定（React 用 hooks、API 用 async/await、DB 用 repository pattern），而测试文件与被测代码并排放（Button.test.tsx 挨着 Button.tsx），要求所有测试无论位置都遵循同一套约定。答案是 .claude/rules/ + frontmatter glob（如 **/*.test.tsx）。三个错法：全部塞进根 CLAUDE.md 靠 Claude 推断该用哪节（依赖推断而非显式匹配）、做成 skills（需要调用或依赖 Claude 主动加载，与「自动」要求矛盾）、每个子目录放一个 CLAUDE.md（目录绑定，覆盖不了散布的文件）。
三、修复之后：长任务里的 context
这个场景的第二主考 domain 是 Context Management。三条最相关的：
- Explore subagent 隔离冗长的发现输出，只把摘要带回主会话，防止多阶段任务耗尽 context。
- 长会话退化的识别信号：答案开始不一致、引用「典型模式」而非先前发现的具体类 → scratchpad 文件持久化关键发现。
- 会话续接的选择：上下文大体有效用
--resume；tool results 已过期（代码被队友改了）则新开会话 + 结构化摘要注入；要 resume 时必须告知具体哪些文件变了做定向重新分析。
迭代精化：说不清就给例子
生成结果「不太对但说不清哪不对」时，TS 3.5 的四个手段按触发条件选：散文被反复误解 → 2–3 个具体 I/O 示例；需求可测 → 先写测试再分享失败；自己不熟这个领域 → interview pattern（让 Claude 先提问）；多个问题要反馈 → 按耦合性分组，相互作用的一次给全、独立的顺序修。
四、坑位地图
| 决策点 | 正确直觉 | 常见干扰项工艺 |
|---|---|---|
| 1. 团队共享的命令放哪 | .claude/commands/（入版本库） | D1 .claude/config.json；D3 写进 CLAUDE.md |
| 2. 新成员收不到约定 | 配置在 user 级，移到 project 级；先用 /memory 看实际加载了什么 | D1 编造「需要手动加载」；D4 归咎模型档位 |
| 3. 横切约定（测试文件） | .claude/rules/ + glob，不用 directory CLAUDE.md | D3 靠 Claude 推断章节；D3 做成 skill 却要求「自动」 |
| 4. plan vs direct | 看复杂度与方案多样性：多文件/多方案/架构决策 → plan；单文件明确修复 → direct | D3「先 direct 遇到复杂再切」；D2 为两行守卫开 plan |
| 5. 冗长探索阶段 | Explore subagent 隔离，只回摘要 | D3 换更大 context window；D6「让它输出简短些」 |
| 6. 隔天续接会话 | 文件已变 → 新会话 + 摘要注入；要 resume 则告知具体变更 | D6 直接 resume（"才两天"）；D2 要求全量重读 |
| 7. 反复说不清的转换需求 | 2–3 个具体 I/O 示例 | D3 第三遍重写散文；D2 直接上验证-重试基础设施 |
| 8. 个人定制不想影响队友 | 放 ~/.claude/ 且改名 | D1 同名「shadow」；D3 改团队文件加注释 |
外部课程 · CertSafari — 本章 7 个考点（展开查看）
用于补读和错题复盘；第三方 AI 生成练习材料，非官方题库。核验答案时以 Exam Guide 和官方文档为依据。复盘方法 · 链接核对：2026-10-16。
- TS 1.7 · Resuming Claude Sessions by Name and ID
- TS 3.1 · CLAUDE.md Hierarchy: User, Project and Directory Scopes
- TS 3.2 · Slash Commands and Skills: Project vs Personal Scope
- TS 3.3 · Path-Scoped Rules in .claude/rules/: paths Frontmatter and Glob Patterns
- TS 3.4 · Plan Mode vs Direct Execution: Choosing by Task Scope
- TS 3.5 · Examples, Tests First and the Interview Pattern
- TS 5.4 · Context Rot, /compact and Scratchpad Files in Long Codebase Sessions
考点回链 — 本场景覆盖：TS 1.7、TS 3.1、TS 3.2、TS 3.3、TS 3.4、TS 3.5、TS 5.4。官方样题精讲：Q4（
.claude/commands/）、Q5（plan mode）、Q6（.claude/rules/ glob）。场景题组
ch16 · Q1 · 准则 P9
Your team wants a
/migrate-check slash command that runs the standard pre-migration checklist. Every developer should get it automatically when they clone or pull the repository, with no setup steps. Where does the command file belong?正确 BTS 3.2 与官方样题 Q4：project-scoped slash command 放仓库内的
.claude/commands/——随版本控制分发，clone 或 pull 即自动可用。「无需任何设置步骤」这个要求把它锁死了。D3 治标不治本违反 P9A：
~/.claude/commands/ 是个人作用域。用 dotfiles 仓库分发意味着每个人要额外做一次同步——恰恰是「no setup steps」排除的东西，而且与项目版本会漂移。D3 治标不治本违反 P9C：CLAUDE.md 装的是项目指令与上下文，不是命令定义（官方样题 Q4 的 C 选项原判）。写在那里不会产生一个可调用的
/migrate-check。D1 凭空捏造违反 P9D：
.claude/config.json 加 commands array 这个机制在 Claude Code 里不存在——官方样题 Q4 的 D 选项，解析原话是「描述了一个不存在的配置机制」。ch16 · Q2 · 准则 P5
You must replace the team's ORM across a service: 60+ files import it, several wrap it with custom transaction helpers, and there are two viable strategies (a compatibility shim versus a full rewrite) with different testing and rollout implications. Which approach fits?
正确 CTS 3.4 的三个触发条件在题干里全部出现：大规模变更（60+ 文件）、多个可行方案（shim vs 重写）、需要先摸清依赖（自定义事务包装）。同时体现官方推荐的组合形态——plan 做调查与决策、direct 做实施。与官方样题 Q5 同构。
D4 甩锅错位违反 P5A：「详尽的前置指令」假装你已经知道正确结构，而两种策略的取舍尚未做出。官方样题 Q5 的 C 选项原判：在没有探索代码的前提下假设已有答案。
D3 治标不治本违反 P5B：官方样题 Q5 的 D 选项形态。复杂性已经写在需求里（60+ 文件、两种策略），不是「可能出现」的东西；等它显形时返工成本已经发生。
D3 治标不治本违反 P5D：逐文件跑测试保证的是实施期正确性，管不了「该选哪种策略」这个先决问题。策略选错时每个文件的测试都能过，而整体架构是错的。
ch16 · Q3 · 准则 P9
Your repo has React components, Go services, and SQL migrations, each with distinct conventions. Migration files live under
db/migrations/, but test files sit beside the code they test throughout the repo. You want conventions applied automatically by file type. What configuration best fits both cases?正确 ATS 3.3：glob 规则按文件类型生效而不受目录位置约束，既覆盖目录绑定的迁移文件，也覆盖散布全库的测试文件——一套机制解决两种形态。官方样题 Q6 的正确答案。
D6 概率当保证违反 P9B：依赖推断而非显式匹配，与「automatically applied」的确定性要求冲突（官方样题 Q6 的 B 选项原判）；而且整份内容每次会话全量进 context。
D3 治标不治本违反 P9C：skill 是按需调用的任务流（TS 3.2），需要有人或 Claude 主动触发——题干要的是编辑到文件就自动生效（官方样题 Q6 的 C 选项原判）。
D3 治标不治本违反 P9D：迁移那半可行，测试那半不行——CLAUDE.md 是目录绑定的，散布全库的测试文件意味着要复制维护几十份同样内容（官方样题 Q6 的 D 选项原判）。
ch16 · Q4 · 准则 P5
Yesterday a session analyzed a payments service and produced a refactoring plan. Overnight, three teammates merged changes to eight of the analyzed files, including the two the plan depends on most. You want to continue today. What should you do?
正确 BTS 1.7 的明确排序：既往 tool results 陈旧时，新开会话 + 结构化摘要注入比 resume 更可靠。resume 会把八个文件的过期快照一并带回，模型无从判断哪些还作数。
D6 概率当保证违反 P5A：resume 的前提是「既往上下文大体仍然有效」，而题干说变更命中了计划最依赖的两个文件。用时间长短（一天）代替内容有效性判断，是错的代理指标。
D2 过度工程违反 P2C：全量重读昂贵，而且旧的过期内容仍留在上下文里与新内容并存。TS 1.7 的做法是告知具体变更做定向重新分析，不是全量重来。
D3 治标不治本违反 P5D：
fork_session 用于从有效基线探索分歧方案。从一个已失效的基线分叉，只会得到两条都基于旧快照的分支。ch16 · Q5 · 准则 P2
You have asked Claude three times to normalize your legacy config files into a new format, describing the rules in prose each time. Results keep differing: sometimes boolean strings are converted, sometimes not; nested keys are flattened inconsistently. Your rules are clear to any human reader. What is the most effective next step?
正确 CTS 3.5 的第一条：当散文描述被反复不一致地理解时，具体的输入/输出示例是传达期望转换最有效的手段，剂量 2–3 个。题干把前提铺满了——写了三遍散文仍不一致，而规则对人类读者清晰。
D3 治标不治本违反 P2A：第四遍散文仍是散文。前三次已经证明这条路径失效，同一手段的更详细版本不构成升级。
D3 治标不治本违反 P5B：interview pattern 的触发条件是你自己不清楚该考虑什么。这里你非常清楚要什么，只是没能传达清楚——用错手段的适配轴。
D2 过度工程违反 P2D：验证-重试循环每次失败都要多跑一轮，而「给两个例子」这个近乎零成本的手段还没试过。比例倒置。
ch16 · Q6 · 准则 P7
A task has two phases: first understand how feature flags propagate through a 300-file service, then add a new flag type. Phase one generates hundreds of file reads and search results. By phase two the agent gives inconsistent answers and describes "the usual flag pattern" instead of the specific evaluator classes it found. What should you change?
正确 DTS 3.4 的 Explore subagent（隔离冗长发现输出、只回摘要）+ TS 5.4 的 scratchpad（关键发现跨上下文边界持久化）。题干的症状「引用典型模式而非先前发现的具体类」是 TS 5.4 对上下文退化的原话级描述。
D3 治标不治本违反 P1A：
--resume 会把同样臃肿的上下文原样带回，退化照旧发生。跨天与否和 context 占用无关。D4 甩锅错位违反 P1B：放弃理解阶段，在一个 300 文件的服务里用测试失败当地图。它取消了阶段一的目标，而不是解决阶段一的成本。
D3 治标不治本违反 P7C：更大的 context window 解决「装不下」，而这里是注意力质量与上下文退化问题（官方样题 Q12 的 C 选项被点名的正是这个混淆）。它只把耗尽时点推后。
ch16 · Q7 · 准则 P9
Three engineers who have worked on the repo for a year report Claude reliably follows the team's error-wrapping convention. Two engineers who joined this week report it ignores the convention entirely. Same repo, same branch, same tool version. What is the most likely cause, and what is the fastest way to confirm it?
正确 CTS 3.1 的诊断场景：新成员收不到指令，因为它们在 user 级而非 project 级配置里；而
/memory 的定义用途正是核实哪些 memory 文件被实际加载、诊断跨会话不一致。症状按人分裂（老成员全对、新成员全错）是这个根因的签名。D4 甩锅错位违反 P1A：glob 不匹配会让症状按文件类型分裂——老成员编辑同类文件时也该失效。题干说三位老成员「reliably」follows，即跨文件一致；分裂线是人员，不是路径。
D1 凭空捏造违反 P1B：编造了一个与资历相关的 context 限制。而且
/compact 是压缩当前上下文的手段，不是诊断配置加载的工具。D1 凭空捏造违反 P1D：Claude Code 不会从个人的历史会话里「学会」团队约定——约定来自被加载的配置文件。这个选项把一个确定性的配置分发问题说成了适应期。
ch16 · Q8 · 准则 P5
A crash report gives a clear stack trace:
parseDuration in config/loader.go panics on an empty string. The fix is a guard clause. The function is used in three places, all of which want the same fallback behavior. Which approach is appropriate?正确 DTS 3.4 对 direct execution 的定义几乎逐字命中：范围明确、单文件、有清晰的 stack trace。plan mode 的四个触发条件（大规模变更、多方案、架构决策、多文件）一个都不成立——题干还明说三个调用点想要同样的回退行为。
D2 过度工程违反 P2A：把「影响面大」误当成 plan mode 的触发条件。影响面提高的是对测试与 review 的要求；plan mode 的判据是复杂度与方案多样性。
D2 过度工程违反 P2B：「多个可行方案」确实是 plan mode 的触发条件之一，但题干已经排除了它——三个调用点想要相同的回退行为，取舍问题不存在。为一个已被回答的问题启动探索。
D4 甩锅错位违反 P2C：题干已经确认三个调用点想要同样的回退行为——去征询一个已知答案的问题，把一个两分钟的修复变成一轮跨团队等待，负担转嫁给了他人。
ch16 · Q9 · 准则 P9
Your team ships a
codebase-audit skill in .claude/skills/. It emits several hundred lines of intermediate findings that crowd the main conversation, and during one run it executed a cleanup command that deleted generated files a developer still needed. What two frontmatter changes address these?正确 ATS 3.2 的两个 frontmatter 各解决一个症状：
context: fork 让 skill 在隔离的 sub-agent 上下文中运行，防止冗长输出污染主会话（guide 的原例正是代码库分析）；allowed-tools 限制执行期间的工具访问以防破坏性动作。D1 凭空捏造违反 P4B：
argument-hint 是缺参时提示开发者补参数的提示串，不是校验器，也不构成执行前的权限闸门——它对误删文件毫无作用。D3 治标不治本违反 P9C：权限那半对了，但把团队 skill 挪进个人目录会让它不再随版本库分发（
~/.claude/skills/ 的正当用途是改名后的个人变体），而且完全没有解决输出污染。D1 凭空捏造违反 P4D：前半句对——隔离输出正是 TS 3.2 给
context: fork 的职责；后半句给它安上了 guide 没有分派给它的第二个职责。限制执行期的工具访问归 allowed-tools 管，两个症状要两个字段（这正是 A 的做法）。用一个真实字段冒领另一个字段的语义，是 ch01 点名的 D1 子型。allowed-tools 只让所列工具免确认，不限制可用工具；实际收窄要用 disallowed-tools 或权限 deny 规则。本题按考纲作答，详见 ch06 的说明。来源：Skills · Pre-approve tools for a skill，查阅于 2026-09-27。