Chapter 01 · 全书之魂
出题人思维九条判断准则与干扰项分类学
CCAR-F 不考记忆，考工程判断。60 道题里的大多数，题干都是一份「生产环境诊断报告」——日志、错误率、延迟数据——而四个选项是四种工程反应。本章把官方样题背后反复出现的判断准则提炼成九条，先建立这套思维，再进入知识层，每个知识点都会自动挂到某条准则上。
为什么先读这一章
观察官方 12 道样题会发现一个规律：正确选项几乎从不依赖你记住某个冷僻 API 参数 ，而是依赖你在两三个「都说得通」的方案之间做出符合生产工程直觉的取舍。反过来，错误选项也不是随机凑数——它们是按固定套路制造的（治标不治本、过度工程、凭空捏造的 feature……）。
这意味着两件事：第一，遇到没复习到的知识点，你仍然可以靠准则排除掉两到三个选项；第二，识别干扰项的「制造工艺」，比认出正确答案更快。本书后续每一道题的解析，都会标注错误选项属于哪类干扰项、违反了哪条准则——编号即出自本章。
这九条从哪来
九条不是九个知识点，而是从官方样题反复出现的判断轴上归纳出来的。归纳到这一层已经够用来做题，但其中四条还能再往下追一层：它们不是考试技巧，是 LLM 固有性质的直接推论 。把这层映射点破，你要记住的东西就从九句口诀变成了「四条性质 + 从性质推准则」的能力——遇到 Exam Guide 没覆盖的新题型，也能自己把该有的判断推出来。
准则 底层性质
P3 关键规则用模型的每个 token 都是采样出来的。prompt 里写 "mandatory" / "always" 改变的是分布，不是保证；单次遵守率再高，失败率也随调用次数累积。所以 guide 把 hooks 归为 deterministic guarantee、把 prompt 归为 probabilistic compliance——这不是两种风格偏好，是两个不同量级的东西。
P7 注意力有限，长输入上的注意力稀释是架构性的，不是「不够努力」——所以 lost-in-the-middle 是可预期的失效模式，而不是偶发 bug。同一 session 里的 self-review 则带着生成时的推理惯性，而那份惯性本身就是上下文的一部分，这才是独立实例强于「让它再自查一遍」的原因。两句话推向同一个动作：多拆一次 pass、多换一个实例。
P6 信息保全，模型没有隐式记忆。下一轮它能看到什么，完全等于你往 messages 里放了什么——tool results 是被追加进对话历史才存在的，subagent 也不自动继承父上下文。被压掉的那条错误上下文，对它来说等于没发生过。所以「吞」不是表达风格问题，是把信息从系统里删掉。
P8 显式准则自报 confidence 未经校准时，它反映的是表述的流畅度而非正确的概率，恰恰在难题上会错误地自信。所以 guide 要求 field-level confidence 先用 labeled validation set 校准才可作路由依据，而「be conservative」这类模糊指令并不改变模型用的判据，改判据要靠分类式的具体准则。
剩下的不在这一层，说清楚同样重要：P1 根因优先、P2 比例原则、P5 机制匹配、P9 配置分层属于通用工程判断 ——把 Claude 换成任何一个分布式系统、任何一套配置框架，这四条照样成立，跟对面是不是语言模型无关。考试考它们，是因为它考架构师。P4 最小权限介于两者之间 ：「只给该给的权限」是安全工程的老规矩，但「工具从 4–5 个涨到 18 个会降低选择可靠性」是模型性质——P4 的上半句是工程，下半句是模型。
用法很直接：碰到一道 guide 没明写答案的题，先问「这道题在赌模型的哪条性质」。赌它每次都会遵守 → 查 P3 那一栏；赌它在长输入里不漏 → P7；赌它还记得上一轮 → P6；赌它知道自己错了 → P8。四问过完，通常只剩一个选项没在赌。
上表右栏里「逐 token 采样」「注意力稀释是架构性的」「没有隐式记忆」这三句属于机制层 解释：Exam Guide 只给结论（hooks = deterministic guarantee / prompt = probabilistic compliance、lost-in-the-middle 现象存在、上下文要显式传递），不给机制。机制帮你记住结论，但考场上该引用的是结论——写理由时用「prompt 是概率性合规」，不用「因为解码是采样」。另外，本节不新增任何考试事实：四条性质对应的考试面已经写在各自的准则卡正文里，这里只是把它们收进同一个解释。
九条判断准则
题干给出的日志和数据不是背景装饰，而是诊断材料。正确选项直指数据揭示的根因；错误选项要么修补症状，要么把责任推给运转正常的下游组件。读题时先问：「这份数据证明坏掉的是哪一环？」 再看选项。
样题证据 — Q2：两个工具描述都只有一句话（"Retrieves customer information"），选错工具的根因是描述无法区分，第一步就该扩写 description（tool descriptions 是 LLM 选择工具的首要机制），而不是叠 few-shot 或加 routing layer。Q7：报告只覆盖视觉艺术，coordinator 日志显示它把 "creative industries" 只分解成了三个视觉子题——根因在 coordinator 的 task decomposition，怪 synthesis / search / analysis agent 的选项全是甩锅。
边界 — 根因级方案也可能因成本被否。Q2 里合并成单个 lookup_entity 工具同样触及根因，但作为 "first step" 过重，败给了改描述。根因优先要与准则 2 联用：多个根因级方案并存时，选最轻的那个。
口诀：先验尸，再开药；数据指向谁，就修谁。
2
比例原则
Proportionate First Response
干预手段有一条从轻到重的阶梯：改写 description / 明确 criteria → few-shot examples → 结构化机制（schema、hooks）→ 独立基础设施（classifier、routing layer、额外模型）。没有走完轻量级手段之前，任何要求「训练一个模型」「加一层路由」的选项都是 over-engineering 干扰项。
样题证据 — Q3：escalation 判断失准，正确做法是在 system prompt 里加显式 escalation criteria + few-shot，而不是部署 classifier（需要标注数据和 ML 基础设施）或 sentiment analysis（解决的是另一个问题）。官方解析原话的判断轴就是 "proportionate first response"。
边界 — 比例原则不等于「永远从 prompt 开始」。当失败后果触及资金、合规、身份验证（见准则 3），直接上程序化强制不算过度工程——判断轴是后果严重性 ，不是手段轻重本身。
口诀：能改提示词，不动基础设施；但钱的事除外。
3
关键规则用确定性强制
Deterministic Enforcement for Critical Rules
Prompt 指令是概率性合规 ——哪怕写上 "mandatory"、"always"、"never"，失败率也非零。当某条规则要求 100% 遵守（身份验证先于退款、金额超阈值必须转人工、外发内容先过审），必须用程序化机制：prerequisite gate 阻断未验证的下游调用，tool call interception hook 拦截违规操作并重定向到替代流程。
样题证据 — Q1：12% 的案例跳过 get_customer 直接退款，正确答案是程序化前置条件（blocks process_refund until get_customer has returned a verified customer ID）；强化 system prompt 和 few-shot 的选项因「概率性合规不足以承担资金后果」被排除。对应 TS 1.4 / 1.5：hooks 提供 deterministic guarantees，prompt 提供 probabilistic compliance。
边界 — 反向陷阱同样存在：并非所有规则都值得上 hook。风格偏好、软性流程用 prompt 引导即可；把一切都程序化会回到准则 2 的 over-engineering。识别信号：题干出现资金数额、合规、误操作已造成损失 的字样时，才切换到确定性强制。
口诀：钱和合规不赌概率。
4
最小权限与专用工具
Least Privilege, Scoped Tools
工具集按角色收敛：subagent 只拿本职工具，工具太多（18 个 vs 4–5 个）会直接降低选择可靠性；拿到专业外工具的 agent 倾向于误用它。对高频且简单 的跨角色需求，给一个 scoped 专用工具（如 synthesis agent 的 verify_fact）；低频复杂需求仍走 coordinator。泛化工具换成受约束的替代品（fetch_url → load_document）。
样题证据 — Q9：85% 的验证是简单 fact-check，正确答案是给 synthesis agent 一个 scoped verify_fact，复杂的 15% 继续经 coordinator 委派；「给它全部 web search 工具」违反关注点分离，被点名 over-provisions。对应 TS 2.3。
边界 — 拆分不是越细越好。拆分的标准是「描述能否清晰区分」：如果拆出的两个工具描述高度相似（analyze_content vs analyze_document），反而制造新的误选（准则 1 的 Q2 场景）。拆到描述可区分为止。
口诀：八成场景给小刀，两成场景走大门。
5
机制匹配负载
Match Mechanism to Workload
每种机制都有一个「适配轴」，题目会构造两个负载让你二选一或分流：Batch API （省 50%，up to 24h，无 latency SLA）只配 latency-tolerant 的非阻塞任务，blocking pre-merge check 一律用同步 API；plan mode 配架构级、多方案、多文件的变更，单文件明确修复直接 direct execution；session resume 配上下文仍然有效的场景，tool results 已过期就 fresh session + 结构化摘要注入。
样题证据 — Q11：技术债报告（overnight）转 batch、pre-merge check 保持实时，「都转 batch + 轮询/超时回退」的选项因为把阻塞流程押注在无 SLA 的机制上被排除。Q5：monolith → microservices 重构直指 plan mode，「先 direct 遇到复杂再切」被点名忽视了复杂性已在需求中写明。对应 TS 4.5 / 3.4 / 1.7。
边界 — 「混合方案」选项（如 batch + timeout fallback to real-time）看似周全，实际是复杂度干扰项：当简单的「各配各的」方案存在时，混合机制因引入不必要的复杂度被判错。
口诀：阻塞走同步，过夜走批量；架构进 plan，小修直接干。
6
信息保全，不吞不炸
Preserve Information — Don't Suppress, Don't Explode
错误、冲突、空缺都是信息，处理方式只有一种：结构化地保留并上交 。错误上报要带 failure type、attempted query、partial results、可选替代方案，让 coordinator 能做智能恢复；两个可信来源数字冲突时，双值保留并标注来源，不擅自二选一；access failure（超时）与 valid empty result（查询成功但无匹配）必须区分。两个对称的反模式：吞 （把失败标记为成功的空结果）和炸 （单点失败终止整个 workflow）。
样题证据 — Q8：subagent 超时，正确答案是结构化错误上下文四件套；generic "search unavailable" 隐藏了上下文、空结果标成功阻断一切恢复、直接终止全流程放弃了可行的恢复策略——三个错误选项恰好是「模糊化、吞、炸」。对应 TS 5.3 / 5.6 / 2.2。
边界 — 保全不等于全量上抛。Transient 错误应先在 subagent 内部局部重试（local recovery），只把无法局部解决的 错误连同 partial results 上交。「所有错误立刻上抛」同样是可被出题的反模式。
口诀：错误带简历上报，冲突带出处并存。
7
注意力有限，独立性有价
Attention Is Finite; Independence Has Value
两个相关事实：其一 ，长输入存在 lost-in-the-middle 效应，一次性处理 14 个文件会注意力稀释（有的文件详评、有的敷衍、同一模式两处结论矛盾），解法是拆遍——per-file local pass + 独立的 cross-file integration pass，而不是换更大 context window 的模型。其二 ，同一 session 里模型带着生成时的推理惯性，self-review 弱于无先验上下文的独立实例；重要审查用第二个独立 Claude instance。
样题证据 — Q12：单遍审 14 文件结果不一致，正确答案是拆成 per-file + integration 两类 pass；「更大 context window」被点名不解决 attention quality，「三遍投票取交集」反而会压掉只被间歇性发现的真 bug。对应 TS 4.6 / 5.1 / 1.6。
边界 — 拆遍有成本（多次调用、跨遍信息要显式传递）。单文件小 PR 拆遍属于过度工程；触发拆遍的信号是题干出现不一致、矛盾结论、深浅不一 这类注意力稀释症状。
口诀：稀释就拆遍，自审不如换人审。
8
显式准则胜过模糊置信
Explicit Criteria Beat Vague Confidence
「be conservative」「only report high-confidence findings」这类模糊指令不会提升 precision；自报 confidence score 未经校准时不可作为路由依据（模型恰恰在难题上错误地自信）。有效做法是分类式显式准则 ：明确列出报什么（bugs、security）、跳过什么（minor style），每个 severity 级别配具体代码示例，边界案例用 few-shot 示范推理过程。
样题证据 — Q3 的 B 选项（self-report confidence 1–10 低于阈值就转人工）被点名 "poorly calibrated"。对应 TS 4.1：general instructions fail compared to specific categorical criteria。
边界 — Confidence 并非一无是处：用 labeled validation set 校准后的 field-level confidence 是 human review routing 的正规手段（TS 5.5），配合 stratified sampling 持续测错误率。区分的关键字是「calibrated / labeled validation set」——有它是正确选项，没它是干扰项。
口诀：没校准的置信度是感觉，校准过的才是数据。
9
配置放对层级
Right Scope, Right Place
「要不要共享」决定放哪层：团队共享的进版本库——project-scoped .claude/commands/、.mcp.json、项目级 CLAUDE.md；个人实验的放用户目录——~/.claude/commands/、~/.claude.json。「作用于哪些文件」决定形态：横切整个代码库的约定（如所有 **/*.test.tsx）用 .claude/rules/ + glob frontmatter，目录绑定的才用 subdirectory CLAUDE.md；始终加载的普适标准进 CLAUDE.md，按需调用的任务型工作流做成 skill。
样题证据 — Q4：团队共享 /review 命令 → .claude/commands/（version-controlled，clone 即得）。Q6：测试文件散布全库 → glob rules 而非每目录一个 CLAUDE.md（directory-bound 覆盖不了散布文件）。对应 TS 3.1–3.3。
边界 — 该轴上的干扰项常伴随捏造机制（如 Q4 的 .claude/config.json commands array 并不存在）。层级题答不出来时，先删掉「没见过的机制」，再按共享/私有二分。
口诀：共享进版本库，个人进家目录；横切用 glob，绑定目录才用目录。
干扰项分类学
错误选项是按工艺批量制造的。识别工艺，就能在读完题干后先删掉两个选项。全书题库的每个错误选项都会标注以下类型编号：
类型 制造工艺 识别信号 样题实例
D1 凭空捏造Nonexistent Feature 发明一个听起来合理但不存在的 flag、环境变量或配置机制；或给一个真实存在的机制安上它没有的语义 （后者是全书更常见的子型）
你在官方文档里从没见过它；名字过于「顺理成章」。子型信号 ：机制眼熟、但那句话不像你见过的行为 → 回想它的官方职责是什么，对不上就是 D1。别用「我见过这个名字」当放行理由
CLAUDE_HEADLESS=true、--batch flag、.claude/config.json 的 commands array（真实存在的是 -p / --print 与 .claude/commands/）。子型实例见本章自测第 4 题的 B / C（/compact 被安上「跨边界持久化」、Explore 被安上「存储」）；官方样题 Q11 的 C 是它的镜像——抹掉 custom_id 本来就有的关联语义，两个方向都算 D1
D2 过度工程Over-engineering 在轻量手段未穷尽时引入 classifier、routing layer、投机缓存、混合回退
选项里出现「训练」「部署一个独立的」「fallback」而题干未证明轻量手段已失败
Q3 的 classifier、Q2 的 routing layer、Q9 的 speculative caching、Q11 的 timeout fallback
D3 治标不治本Symptom Patch 用叠加手段掩盖根因（数据已指明根因在别处）
方案「有帮助」但没碰题干数据指向的那一环。边界 ：D3 的前提是题干数据已经 指明根因在别处；若没有这样的数据指认，先考虑 D2（手段过重）或 D4（对象错位）——D3 不是「说不清属于哪类」的兜底类
Q2 用 few-shot 掩盖描述缺失；Q12 换大 context window 掩盖注意力稀释
D4 甩锅错位Wrong Component 把修复对象指向运转正常的组件，或把负担转嫁给用户/开发者
日志已证明该组件在其职责内工作正常
Q7 怪 synthesis / search / analysis（根因在 coordinator）；Q12 要求开发者拆小 PR
D5 吞错或炸链Suppress or Explode 把失败伪装成成功（空结果、generic status），或单点失败终止全流程
「返回空结果并标记成功」「终止整个 workflow」「仅返回通用状态」
Q8 的 C（吞）与 D（炸）、B（模糊化 generic status）
D6 概率当保证Probabilistic as Guarantee 在需要 100% 合规的场景里，用 prompt 措辞（"mandatory"）冒充确定性机制
题干涉及资金/合规/已发生损失，选项却只是「强化 system prompt」
Q1 的 B 与 C（prompt 与 few-shot 均为 probabilistic compliance）
使用方法 — 考场三步：① 从题干数据定位坏掉的环节（准则 1）；② 扫一遍选项，先删 D1（捏造）与 D5（吞/炸），它们最机械；③ 剩下两个选项用准则 2–9 的适配轴裁决。多数题在第②步后只剩两个候选。
自测：用准则做题
以下五题为本书自编，覆盖不同准则组合。点击你认为正确的选项，解析会按「干扰项类型 + 违反准则」标注每个错误选项。其中第 4 题专门演示 D1 的「真实机制 + 虚构语义」子型——按「我见过这个名字」放行，是漏判 D1 的头号原因。
SELF-TEST 01 · 准则 6
Your document analysis subagent processes two market reports for the synthesis stage. Both are credible sources, but they state different figures for 2025 enterprise AI adoption: one reports 61%, the other 74%. The subagent must now return its findings to the coordinator. What should it do?
A Return the figure from the more recently published report, since newer data supersedes older data and one number per field spares synthesis from arbitrating. B Return the average (67.5%) with a note that sources varied, so synthesis gets one usable number and the disagreement stays on the record. C Return both figures with explicit source attribution and an annotation flagging the conflict, letting the coordinator decide how to reconcile before synthesis. D Omit the adoption-rate field and return null, since an arbitrary pick would be worse than an acknowledged gap the coordinator can fill in later.
正确 C 对应 TS 5.6：conflicting statistics from credible sources 的标准处理是 annotate conflicts with source attribution，保留双值上交，由 coordinator 决定如何调和。信息保全（准则 6）。
D4 甩锅错位 违反 P6 A ：「更新的胜出」是 heuristic selection——两份都是可信来源，时间差可能只是统计口径不同；擅自二选一即丢失信息。注意与 temporal data 规则的区别：正确做法是附上 发布日期让下游正确解读，而不是用日期裁决。至于「别让 synthesis 为难」——调和权本来就该交回 coordinator，这条辩护把 TS 5.6 的要求当成了要规避的麻烦。
D5 吞错 违反 P6 B ：取平均制造了一个两个来源都没说过的数字，是最彻底的信息销毁——冲突被伪装成了共识。附一句 "sources varied" 也救不回来：进入下游计算的仍然只有 67.5% 这一个数，note 不参与运算，两个真实值已经消失了。
D5 吞错 违反 P6 D ：返回 null 把「有两个候选值」伪装成「没有数据」。null 的正确用途是信息在源文档中确实不存在（防 fabrication），不是冲突处理手段。「乱选不如留白」这个二选一本身是假的——第三条路（两个都上交并标注）就在选项里。
SELF-TEST 02 · 准则 5 + 2
Your team runs two Claude-powered workflows: (1) nightly generation of compliance summaries for 800 documents, which must be ready by 9:00 AM the next day, and (2) an interactive assistant where analysts wait for answers in real time. Finance asks you to cut API costs. What's the right move?
A Move both workflows to the Message Batches API and add a polling layer with a real-time fallback if a batch runs long, so the whole platform earns the batch discount while analysts still get answers on the spot. B Move the nightly summaries to the Message Batches API, submitting the batch early enough that the up-to-24-hour window still meets the 9:00 AM deadline; keep the interactive assistant on the synchronous API. C Keep both on the synchronous API but add a caching proxy in front of Claude to deduplicate similar requests across both workflows, cutting spend on repeated prompts without changing either workload's latency profile. D Move both to the Message Batches API, since batches usually complete in under an hour in practice and the 9:00 AM deadline leaves plenty of headroom on either workflow.
正确 B 机制匹配负载（准则 5）：nightly summaries 是 latency-tolerant 非阻塞任务，吃下 50% 成本节省；但 "up to 24-hour window, no SLA" 意味着提交时间要向前推足窗口（TS 4.5 的 SLA 计算技能）。交互式助手是 blocking 负载，保持同步。
D2 过度工程 违反 P5 A ：混合回退在「各配各的」简单方案存在时引入不必要复杂度；且 blocking 负载即使有 fallback 也不该押注无 SLA 机制（同 Q11 的 D 选项工艺）。「全平台都吃到折扣」这笔账也算错了：回退一旦触发，那份请求要重跑一遍，交互负载的实际单价高于一开始就走同步。
D2 过度工程 违反 P2 C ：放着现成的 50% 批量折扣不用，先造一层缓存代理——轻量手段未用尽就上基础设施，比例原则倒置。「不动延迟」这半句确实成立，但夜间汇总本来就不在乎延迟——它保住的，恰恰是这条负载唯一可以拿去换钱的东西。
D6 概率当保证 违反 P5 D ："usually under an hour" 是把无 SLA 的经验分布当成保证。9:00 AM 是硬约束，blocking 语义同理——不能建立在 "often faster" 之上（Q11 官方解析原话）。
SELF-TEST 03 · 准则 8 + 1
Your extraction pipeline reports 97% overall accuracy, and leadership wants to cut the human review team's workload by 80%. Before automating away most review, what should you do first?
A Proceed with the reduction: 97% overall accuracy exceeds the 95% bar set for the project, so review capacity is being wasted on correct extractions and the freed reviewers can be redeployed to work the pipeline cannot do. B Have the model output a 1–10 confidence score per document and route only low-scoring documents to the remaining reviewers, so the shrunken review budget follows the model's own uncertainty rather than a fixed sampling rate. C Break accuracy down by document type and field, calibrate field-level confidence scores against a labeled validation set, then route review by calibrated confidence with stratified random sampling of high-confidence extractions for ongoing error measurement. D Run every extraction twice with different prompts and only send documents to human review when the two runs disagree, using disagreement as an automated proxy for the documents a reviewer would have caught.
正确 C TS 5.5 全套：aggregate accuracy 可能掩盖特定 document type / field 上的塌方，先分段验证；confidence 必须用 labeled validation set 校准后才可作路由依据；高置信区间保留 stratified sampling 持续测错并捕捉 novel error patterns。
D3 治标不治本 违反 P1 A ：97% 是聚合数字，可能是「常见类型 99.5% + 某类合同 70%」的混合。未分段验证就削减复核，正是 TS 5.5 点名的风险。「复核在做无用功」这个前提一旦不成立，「腾出人去干别的」这个收益也一起垮掉——它不是一条独立的理由。
D6 概率当保证 违反 P8 B ：未校准的自报 confidence 不可作路由依据——模型在难样本上恰恰错误地自信。缺少的关键词：calibrated、labeled validation set。
D2 过度工程 违反 P2 D ：双跑一致性检验把每份文档的成本翻倍，且「两次都错得一样」的系统性错误（最危险的一类）恰好检不出来；轻量且正规的分段验证 + 校准方案尚未尝试。
SELF-TEST 04 · 准则 6 + 1
A four-day investigation of an unfamiliar 300-module service is under way. On day one the agent identified the three adapter classes that wrap the payment gateway and named the module that owns retry logic. By day three its answers describe "typical adapter patterns" instead of those classes, and two consecutive answers disagree about which module owns retries. The remaining phases still need those concrete findings. What should you do?
A Persist each finding to a scratchpad file as it is established, delegate the lengthy exploration passes to subagents so raw output stays out of the main session, and summarize a phase's key findings before injecting that summary into the next phase's prompt. B Run /compact at the end of each working day so the findings established so far are preserved past the context boundary and reloaded when the investigation continues; compaction is built for exactly this case, where a long exploration session has filled up with verbose discovery output. C Route every exploration pass through the Explore subagent, which retains the structure it discovers so later phases can query it instead of rediscovering the modules, keeping raw file listings out of the main session entirely. D Add a standing instruction to every prompt requiring answers to cite concrete class names and file paths rather than general patterns, so a drifting answer fails the rule visibly instead of passing as plausible prose.
正确 A TS 5.4 的三件套：scratchpad 文件把关键发现持久化、跨越上下文边界；冗长探索输出交给 subagent 隔离，主 agent 只做高层协调；一个探索阶段结束先做 key findings 小结，再把小结注入下一阶段的初始上下文。三步合起来保证「下一轮它能看到的」正是你显式放进去的（准则 6）。次轴是准则 7：两个连续答案互相矛盾，是注意力稀释的签名症状，解法同样是拆遍而不是把一切塞进同一条会话。
D1 凭空捏造 违反 P6 B ：/compact 是真实机制，也确实被 guide 正面背书（长探索会话被冗长发现输出塞满时用它压缩上下文）——但它压缩的是当前会话的上下文 ，既不落盘也没有「跨边界重新加载」这回事。给真实机制安上它没有的语义，是 D1 最常见的子型；更糟的是压缩恰恰是具体类名被丢掉的地方。
D1 凭空捏造 违反 P6 C ：Explore subagent 真实存在，作用是隔离冗长的发现输出、只把摘要返回给调用方。它不是一个可供后续阶段查询的存储——委派本身不产生持久化，要持久化得你自己写下来（这就是 A 的第一步）。「把冗长列表挡在主会话之外」这半句它做得没错，那也正是 A 的第二步；错在把「隔离」当成了「存储」。
D3 治标不治本 违反 P1 D ：题干数据已指明根因——day-1 的发现不在上下文里了，所以它是「引用不出来」而不是「不肯引用」。要求它引用具体类名，只会把不在上下文里的名字编出来，把丢信息变成造信息。所谓「可见地失败」也不会发生——编造出来的类名同样满足这条格式要求，规则照样通过。
SELF-TEST 05 · 准则 9 + 3
Terraform files live under services/*/infra/ across some forty services, and your repo has two needs. First, a set of naming and tagging conventions that should be in context only while those .tf files are being edited. Second, a hard requirement: last quarter an agent-run apply against the production workspace destroyed a live resource, and management now requires that no apply reach production unless the plan-review artifact for that change exists. How should the two be configured?
A Put both in the project root CLAUDE.md — the conventions as a Terraform section, and the apply requirement in bold as a mandatory rule that must never be bypassed, so one reviewed file governs all forty services and nothing depends on per-directory copies. B Put a directory-scoped CLAUDE.md in each service's infra/ directory carrying both the conventions and the apply requirement, so the rules sit next to the files they govern and enter context only when someone is working inside that service. C Put the conventions in a .claude/rules/ file with paths: ["services/*/infra/**/*.tf"], and add an enforce: block key to the same frontmatter so a matching edit cannot proceed without the plan-review artifact, keeping scoping and enforcement in one reviewable file. D Put the conventions in a .claude/rules/ file with paths: ["services/*/infra/**/*.tf"] so they load only for those edits, and enforce the production gate with a tool call interception hook that blocks the apply and returns the missing-artifact reason.
正确 D 两个需求走两条不同的轴。「只在编辑这些文件时加载」是 .claude/rules/ + frontmatter paths glob 的定义用途，散布在各服务目录下的横切文件用 glob 优于 directory-bound CLAUDE.md（准则 9）。「production apply 必须先有 plan review」是 100% 合规需求，只有出站 tool call 拦截 hook 能给确定性保证，且拦截后要把原因回给 agent 而不是只抛一个失败（准则 3）。
D6 概率当保证 违反 P3 A ：加粗和 "mandatory" 不改变机制层级，prompt 仍然是 probabilistic compliance。题干已经记了一次生产资源被摧毁，这正是准则 3 的触发信号。附带的第二个错：只在编辑 .tf 时才需要的约定塞进始终加载的文件，其余每个会话都要为它付 token。「一个文件管全部」省下的是维护成本，赌上的是执行力——题干要的正是执行力。
D4 甩锅错位 违反 P9 B ：directory-bound CLAUDE.md 要求每加一个服务就再复制一份，把维护负担转嫁给每个开发者，漏一份就静默失效——这正是 glob 规则存在的理由。而且它对 production gate 依然只提供文字约束。
D1 凭空捏造 违反 P3 C ：paths 是真实的 frontmatter 字段，enforce: block 不是。.claude/rules/ 决定的是「哪些上下文被加载」，不是「哪些操作被允许」。给真实机制安上一个它没有的执行语义，后果是团队以为自己装了闸门，实际什么都没拦——本章开头那条子型信号（机制眼熟、行为不眼熟）就是为这种选项准备的。
速记卡
根因优先 — 先验尸，再开药；数据指向谁，就修谁。比例原则 — 能改提示词，不动基础设施；但钱的事除外。确定性强制 — 钱和合规不赌概率。最小权限 — 八成场景给小刀，两成场景走大门。机制匹配 — 阻塞走同步，过夜走批量；架构进 plan，小修直接干。信息保全 — 错误带简历上报，冲突带出处并存。注意力有限 — 稀释就拆遍，自审不如换人审。显式准则 — 没校准的置信度是感觉，校准过的才是数据。层级正确 — 共享进版本库，个人进家目录；横切用 glob。
考场三步：定位坏环 → 删 D1/D5 → 用适配轴裁决剩余两项。本卡将在 ch22「考前 48 小时速查页」中与全书对照表合并。