模块 09 — 架构师问答题

用法：先自己口述作答，再对照参考答案要点。每题标注考点与官方来源（均访问于 2026-08-30）。术语保留英文。

Q1. CLAUDE.md 的四个层级是什么？加载顺序与设计意图？

🎯 学习重点：按 managed、user、project、local 顺序回答，并解释越具体越后加载。

考点：项目记忆 (CLAUDE.md) 的分层设计（来源: https://code.claude.com/docs/en/memory）

参考答案要点：

• 四层（从宽到窄）：Managed policy（组织级，如 macOS /Library/Application Support/ClaudeCode/CLAUDE.md、Linux /etc/claude-code/CLAUDE.md，IT/DevOps 管）→ User（~/.claude/CLAUDE.md，个人跨项目偏好）→ Project（./CLAUDE.md 或 ./.claude/CLAUDE.md，团队共享、入版本控制）→ Local（./CLAUDE.local.md，个人本地补充、不入库）。
• 越具体的层越后加载、越有针对性；组织策略放最顶层保证全员一致。
• 架构师意图：这是「策略分层」的经典模式——组织管红线、团队管约定、个人管偏好，互不覆盖彼此的职责。

Q2. 为什么官方说 CLAUDE.md 是 context 而不是 enforced configuration？强制该用什么？

🎯 学习重点：必须指出提示上下文可被模型解释，强制阻断应落到 deny 或 PreToolUse。

考点：LLM 指令 ≠ 应用层强制（来源: https://code.claude.com/docs/en/memory；对照模块 11）

参考答案要点：

• 官方原话：Claude 把 CLAUDE.md「treats them as context, not enforced configuration. To block an action regardless of what Claude decides, use a PreToolUse hook instead」。
• CLAUDE.md 只是提高模型「按约定行事」的概率：长文件反而降低遵从度（官方建议每文件 ≤200 行）；它无法阻挡 prompt injection 或模型偏离。
• 强制点有三层：deny 权限规则（所有模式生效）、PreToolUse hook（无论模型怎么决定都执行、可返回 block）、managed settings（组织锁定）。
• 架构判断：把「希望模型通常这样做」写进 CLAUDE.md；把「绝对不允许发生」写进 deny/hook/managed settings。

Q3. 企业环境如何设计最小化 permissions？

🎯 学习重点：从最小 allow、明确 deny、团队配置、managed policy 与 sandbox 形成纵深防御。

考点：permissions 最小化（来源: https://code.claude.com/docs/en/permissions 、https://code.claude.com/docs/en/settings）

参考答案要点：

• 分层落盘：团队共享规则进项目 .claude/settings.json（入库）；个人例外进 settings.local.json（不入库）；组织强制项进 managed settings（优先级最高，可锁定）。优先级（高→低）：managed → 命令行 → project local → project shared → user。
• allow 用最小粒度规则（如 Bash(pnpm test:*)、Read(./**)），绝不用 Bash(*)) 一劳永逸；同时维护非空 deny 列表（危险命令、secrets 目录、任意 WebFetch）。
• deny 规则在所有 permission modes 下生效（含 bypassPermissions）；受保护路径任何模式都不自动批准。
• CI/脚本用 dontAsk 只放预批准工具；bypassPermissions 仅限不可逃逸的容器/VM。
• 审计视角：规则入库 = 可 code review、可回滚；.local 只放个人便利项。

Q4. 六种 permission modes 各自的免询问范围与适用场景？auto 模式的 classifier 解决什么问题？

🎯 学习重点：六种模式要完整，并权衡人工审批疲劳与 classifier 自动审查。

考点：permission modes（来源: https://code.claude.com/docs/en/permission-modes）

参考答案要点：

• default（CLI 显示 Manual）：仅只读免批——审查每个动作、敏感工作；acceptEdits：+文件编辑与常见文件系统命令——迭代加速；plan：只读+规划——先探索后动手；auto：全部动作由后台 classifier 审查代替人工——长任务；dontAsk：仅预批准工具——锁定 CI；bypassPermissions：全部——仅隔离环境。
• classifier 针对的问题是提示疲劳：Manual 模式下人被问麻了会机械式点允许，反而更危险；auto 用第二个模型审动作换效率（Pro/Max/Team 默认 auto）。
• 架构权衡：auto 不是「无 oversight」，而是把 oversight 从「每动作人审」变为「模型审 + 事后可审计」；高风险变更仍应走 plan → 人审 → 执行。

Q5. 什么时候用 plan mode？它把 human approval 插在 agent loop 的哪个位置？

🎯 学习重点：高风险、低可逆任务先只读探索，审批点位于计划与实际行动之间。

考点：planning 与 human approval（来源: https://code.claude.com/docs/en/permission-modes、https://code.claude.com/docs/en/sub-agents）

参考答案要点：

• plan 现在是一种 permission mode（config 值 plan），CLI 用 Shift+Tab 或 /plan 进入；探索由只读 Plan subagent 承担，产出计划供人审。
• 位置：在 take action 之前插入一道人审闸门——gather context（只读）→ 产出计划 → 人批准 → 才允许行动。对应模块 4/8 的原则：高破坏性、低可逆性操作前必须 human approval。
• 何时值得：大范围重构、跨模块变更、不熟悉的代码库。何时不值得：一行小改（多一轮往返纯增延迟）。
• 术语注意：官方文档已无独立 "plan-mode" 页面，能力分散在 permission modes + Plan subagent + /plan 命令。

Q6. Hooks 的事件节奏分几种？设计「Edit 后自动 lint」和「禁止危险 Bash」分别挂在哪个事件？

🎯 学习重点：区分会话、轮次、工具调用三种节奏，并正确选择 PostToolUse 与 PreToolUse。

考点：钩子 (Hooks)（来源: https://code.claude.com/docs/en/hooks）

参考答案要点：

• 三种节奏：每会话一次（SessionStart/SessionEnd）；每轮一次（UserPromptSubmit/Stop/StopFailure）；agent loop 内每次工具调用（PreToolUse/PostToolUse；另有 PermissionRequest、PreCompact/PostCompact、Notification 等）。
• Edit 后 lint → PostToolUse（matcher Edit|Write）；禁止危险 Bash → PreToolUse（matcher Bash），检查 tool_input.command，命中策略返回 block（exit code 2 或 JSON decision）。
• hook 的形态不限于 shell：可以是 shell 命令、HTTP 请求、MCP 工具调用、LLM prompt 或 subagent。
• 关键定位：PreToolUse 是「无论模型怎么决定都会执行」的强制层——CLAUDE.md 里的安全规则只是建议，hook 才是执行点。

Q7. 什么时候该拆 subagent？拆分的收益与代价？

🎯 学习重点：用上下文隔离、专门化、工具限制和摘要细节损失解释拆分边界。

考点：subagents 拆分（来源: https://code.claude.com/docs/en/sub-agents）

参考答案要点：

• 触发信号：侧任务（大探索、日志分析、批量搜索）会淹没主对话；重复出现同类 worker；需要硬约束（只读）或成本路由（低价值任务跑便宜模型如 Haiku）。
• 收益：主上下文只回收摘要（context 保护）；独立上下文窗口可并行；frontmatter tools 限制 + 独立权限 = 最小权限的实例化；model 可指定更便宜的模型（内置 Explore 继承主会话模型且不超主会话档位）。
• 代价：结果只有摘要、细节丢失；主会话失去交互连续性（不能中途追问子任务内部）；description 合计超 15,000 tokens 会启动告警（细节应移入各 subagent 的 system prompt）。
• 内置：Explore（只读探索，禁 Write/Edit）与 Plan（plan 模式研究）；自定义放 .claude/agents/<name>.md。

Q8. 会话启动时 200K 窗口按什么顺序自动加载？上下文预算的三大手段 /context、/compact、/clear 怎么选？

🎯 学习重点：回答加载顺序，并区分诊断、压缩与重开三种动作的副作用。

考点：context 管理（来源: https://code.claude.com/docs/en/context-window）

参考答案要点：

• 加载顺序：system prompt → auto memory（MEMORY.md 前 200 行或 25 KB，先到为准）→ 环境信息 → MCP 工具名（延迟）→ skill 一行描述（正文用时才载）→ user CLAUDE.md → project CLAUDE.md（rules 按路径触发）。
• 文件读取是上下文的主要消耗者：提示越具体、读的文件越少；研究型任务交 subagent。
• /context 诊断（什么占满窗口）；/compact 有损压缩历史（skill 描述列表不重新注入，只有用过的保留）；/clear 换新任务但保留项目记忆。选择：先诊断 → 侧任务泛滥用 subagent/新会话，主线太长才 compact。
• 成本细节：Claude Code 自动管理 prompt caching；切换模型触发一次无缓存慢轮次；CLAUDE.md 修改不会在会话中途生效。/rewind（checkpointing）可回滚代码与对话。

Q9. Skills 与 CLAUDE.md、rules、MCP、subagent、plugins 的边界怎么划？

🎯 学习重点：按常驻事实、路径上下文、按需流程、外部工具、委派和分发逐层归位。

考点：扩展机制选型（来源: https://code.claude.com/docs/en/skills、https://code.claude.com/docs/en/features-overview）

参考答案要点：

• 官方「随时间搭建」信号表：同一约定错第二次 → 写进 CLAUDE.md；重复粘贴同一段提示/多步 playbook → 存成 skill；一直从别的工具复制数据 → 接 MCP server；读很多文件只为找符号定义 → 装 code intelligence 插件；侧任务淹没主对话 → subagent。
• Skills：SKILL.md 装知识/流程，/skill-name 显式调用或自动按需加载，正文只在用时进上下文；遵循 Agent Skills 开放标准；custom commands 已并入 skills（.claude/commands/deploy.md 与 .claude/skills/deploy/SKILL.md 等价）；disable-model-invocation: true 可限制为仅用户手动调用；最多可链式调用 6 个。
• Rules：带 paths: 的目录级局部规则，路径匹配才加载——把大 CLAUDE.md 拆小的官方机制。
• Plugins：把 skills+hooks+subagents+MCP 打包成可安装单元（.claude-plugin/plugin.json），经 marketplace 分发——跨仓库复用时才值得打包，先用 .claude/ standalone 快速迭代。

Q10. MCP 集成的治理要点？tool search 解决什么问题？

🎯 学习重点：说明 tool search 只省 schema 上下文，不解决认证、权限和 prompt injection。

考点：MCP 集成（来源: https://code.claude.com/docs/en/mcp；对照模块 6/11）

参考答案要点：

• 接入：claude mcp add --transport http <name> <url>（远程推荐 HTTP transport）；项目级 .mcp.json 入库保证团队/CI 一致；token 走环境变量，绝不入库。
• tool search / deferred tools：MCP 工具默认延迟加载——上下文常驻只有工具名列表，schema 按需载入（ENABLE_TOOL_SEARCH 可调）；解决「几十个 server 的工具 schema 挤爆上下文」。
• 治理：组织可对 connector 工具设 allow/ask 控制；单工具可标 requiresUserInteraction 强制人工确认；信任边界——会抓取外部内容的服务器可能带回 prompt injection，连接前必须信任该服务器（模型读到的外部内容不可当指令）。
• 选型（对照模块 6）：只是调一个已知 API → 直接集成/Bash 即可；需要让模型自助发现并操作外部系统/数据 → MCP。

Q11. headless/CI 场景（claude -p）应如何配置权限与安全？

🎯 学习重点：使用 dontAsk 与预批准最小工具，并定义超时、失败、sandbox 和审计边界。

考点：非交互模式（来源: https://code.claude.com/docs/en/overview、https://code.claude.com/docs/en/permission-modes）

参考答案要点：

• claude -p "..." 非交互 print 模式用于 CI/脚本；无人值守时选 dontAsk 模式：只放预批准工具，其余一律不跑（而不是全放行）。
• 组合拳：最小 allow 白名单 + deny 列表 + PreToolUse hook 兜底 + /sandbox 定义的文件系统/网络隔离边界；输出进日志可审计。
• bypassPermissions 只属于一次性容器/VM；在开发者本机用它等于把 shell 交给概率系统。
• 失败处理：CI 中给明确退出码与 --max-turns 类上限（对照模块 3/4 的超时与停止条件思维），防止 loop 空转烧钱。

Q12. 把 Claude Code 当作「参考 agent harness」，自建 agent 系统时应抄走哪四条设计？

🎯 学习重点：从循环验证、权限强制、上下文分层和扩展隔离提炼可迁移设计。

考点：agentic harness 抽象（来源: https://www.anthropic.com/engineering/demystifying-evals-for-ai-agents；模块 8）

参考答案要点：

1. 循环骨架：gather context → take action → verify results，每次工具结果回喂影响下一步；停止条件 = 任务完成 / 用户打断 / 步数与预算上限。
2. 权限即分层：读/写/执行/网络分档审批 + 规则可持久化 + deny 优先于一切模式——把 human oversight 做成产品化机制而不是口头约定。
3. 上下文即预算：常驻内容（系统提示、记忆、工具名）与按需内容（skill 正文、MCP schema、subagent 结果）分离；压缩是有损手段，隔离（subagent）优先于压缩。
4. 强制点独立于模型：模型决定「做什么」，harness 用 hook/权限层决定「什么绝不允许」——LLM 指令不是授权机制。

场景决策题 A：企业安全加固

🎯 学习重点：先识别不可接受的权限失效半径，再组合确定性强制层而非只改提示词。

Scenario：某公司要在开发者笔记本上推广 Claude Code。安全团队三条硬要求：(1) secrets/ 目录绝不可读；(2) 任何情况下不得对 origin/main force push；(3) 个人不得自行放宽权限。

Constraints：开发者日常要跑测试与 lint；不允许逐动作审批拖垮效率；已有组织 MDM 通道。

Options：

• A. 在每个仓库的 CLAUDE.md 写明三条禁令，并要求开发者自觉遵守
• B. 项目 .claude/settings.json 加 allow（测试/lint）+ deny（secrets 读、force push）；managed settings 锁定权限配置与危险功能；敏感模式默认 auto
• C. 全员 bypassPermissions 提升效率，靠事后 git 历史追责
• D. 只用 PreToolUse hook 检查所有 Bash 命令与文件读取，不给任何 allow 规则

Best choice：B。

Why：分层落盘与官方企业路径一致——managed settings 优先级最高、可强制锁定（个人无法放宽）；deny 规则在所有模式下生效；allow 最小化（pnpm test:* 级别）保效率；auto 模式用 classifier 审动作避免提示疲劳。可再叠加 D 的 PreToolUse hook 做纵深防御（如解析命令语义），但主骨架是 B。

Why others are weaker：A 把强制寄望于模型遵从——CLAUDE.md 是 context 不是 enforcement，注入或偏离即可绕过；C 在非隔离环境裸奔，违反官方「bypassPermissions 仅限不可逃逸容器」的红线；D 单打独斗——hook 解析 shell 命令易漏（编码/别名/管道），且不给 allow 白名单意味着要么全问（疲劳）要么放空（低效）。

Tradeoffs：B 引入配置分层治理成本（managed settings 的变更流程）；auto 模式的 classifier 是概率审查，高风险动作仍建议 plan/人审；hook 纵深防御增加维护面。

What would change the answer：若运行环境是 CI 容器（一次性、无 secrets 挂载），C 的效率取向在容器内可接受（换成 bypassPermissions 仅限该容器）；若团队极小且互信，可省 managed settings、只用项目 settings + hook。

场景决策题 B：大型仓库的 context 预算

🎯 学习重点：先测上下文构成，再用 rules、skills、subagents 和 compaction 分层减载。

Scenario：单体大仓（约 50 万行）。架构师用 Claude Code 做「梳理认证链路并写一页架构说明」。会话 40 分钟后 /context 显示 90% 占用，历史里塞满文件内容，模型开始忘事。

Constraints：任务还要继续约 1 小时；产出必须引用具体文件与行号；中途不能重开丢掉已确认的结论。

Options：

• A. 立即 /compact 压缩历史继续干
• B. /clear 重开，把已知结论手写进新会话首条消息
• C. 剩余梳理委派给只读 Explore 型 subagent（或自定义 code-explorer，tools 限 Read/Grep/Glob），主会话只接收「结论 + 文件:行号」摘要；把关键结论沉淀进 CLAUDE.md/rules 供后续会话复用
• D. 换更大上下文的模型硬扛

Best choice：C。

Why：根因是「文件读取主导上下文消耗」且探索发生在主会话。subagent 在独立窗口做重探索、只回摘要（保留文件:行号引用），主上下文立刻减压；已确认结论写进 CLAUDE.md 使跨会话也不丢——这是官方对大规模探索的标准建议（README 9.3/9.10/9.13）。

Why others are weaker：A 压缩是有损的——继续探索会继续吃上下文，且细节（行号、片段）恰是本任务产出所需，越压越丢；B 丢掉交互连续性与部分结论，重开成本高（且新会话若仍主会话直读文件，会重演同一问题）；D 治标不治本：窗口更大只是延后占满，成本更高，模型切换还会触发一次无缓存慢轮次。

Tradeoffs：subagent 结果只有摘要，中途无法追问子任务内部细节（必要时可再派一个带具体问题的 subagent）；CLAUDE.md 沉淀要花整理时间、且每会话都占固定预算（应保持精简）。

What would change the answer：若剩余工作是写文档而非继续探索（不再大量读文件），A 的 /compact 就够用且最省事；若任务其实已基本完成、只差收尾，B 重开更干净。

配套练习：exam-style.md（考题型）、labs/lab.md（动手）。