Claude Code 运行机制与工程优化：工程实践篇

分册导航： 当前是“工程实践篇”，聚焦上下文与运行时优化、仓库级故障修复、生产风险、竞品评测和面试训练；概念边界、Agent Loop、权限沙箱、上下文生命周期与项目文件见运行机制篇。

6. 关键工程优化

6.1 先看总表：优化的是端到端完成率

原始瓶颈	Claude Code 的公开机制	直接价值	代价与边界
每轮重复处理长历史	Exact-prefix Prompt Caching	降低稳定前缀的重复计算、延迟和费用	前缀必须精确一致；换模型、Effort、压缩或部分工具集合会失效
Context 被旧日志填满	先清旧 Tool Output，再自动 Compaction	延长单会话可工作时间	摘要有损，早期细节可能消失，压缩本身也要计算
大量工具 Schema 常驻	MCP ToolSearch 延迟 Schema，Skill 正文按需加载	降低基础 Token 和工具噪声	发现或触发可能失败；使用时仍要付上下文成本
大型探索污染主线程	非 Fork Subagent 使用独立 Context，只回传摘要	隔离日志、测试和研究噪声，可并行	启动与重新探索有成本，摘要会丢细节
广泛文本搜索低效	LSP 定义/引用/诊断与本地 CLI	用精确符号导航替代多次盲读	需要语言插件和正确环境，CLI 输出仍需裁剪
全部工具并发会竞态	只读并行、有状态工具顺序执行	加速探索并降低写冲突	长写操作仍会串行，工具只读注解必须准确
Prompt 强制规则不可靠	Permission、Hook、OS Sandbox、Managed Policy	把安全从“模型自觉”移到确定性控制面	配置复杂；Sandbox 主要覆盖 Bash，不等于业务授权
长任务过早宣布完成	Test/Build/Lint、Stop Hook、Goal Evaluator、验收 Agent	将“自述完成”转成外部证据	验收条件写错仍会得到错误结论，额外调用增加成本
修改出错不敢放权	Checkpoint、Resume/Fork、Worktree	降低试错和并行修改风险	不覆盖 Bash 写入和远程副作用，不能替代 Git 与备份
简单任务也使用最强推理	主模型、Effort、Subagent 模型和规划/执行路由	在质量、延迟和成本间分层	模型切换会影响缓存；弱模型可能造成返工

6.2 Prompt Caching：把请求组织成稳定前缀

每一轮 API 请求都包含此前上下文，但多数内容与上一轮相同。Claude API 的 Prompt Cache 按 Exact Prefix 匹配：

图：Prompt Cache 的稳定前缀、追加尾部与失效边界

替代文本： System Prompt 与工具定义、项目上下文和已有会话轮次按顺序组成精确前缀，新用户消息或 Tool Result 只追加在尾部；切换模型或 Effort、执行 Compaction、改变常驻工具集合等动作会改变前缀或缓存键，后续请求因此需要重新建立缓存。

图表加载中…

读图结论： Prompt Cache 复用的是完全一致的历史前缀，而不是永久记住文件；追加尾部通常能命中，改变模型、压缩历史或工具定义则可能让缓存失效。

图中上半部分表示正常会话只在尾部追加，下半部分表示会改变缓存键或前缀的典型事件。缓存失效影响延迟和输入成本，但不会自动证明模型能力退化。

只要前缀保持一致，服务端就能复用此前处理结果，只计算新增尾部。Claude Code 因此会尽量把动态内容追加在 Conversation 层，而不是频繁改 System Prompt 或 Tool Definitions。例如，权限模式改变通常不改 Prompt 文本，因此可保持缓存；切换模型或 Effort、执行 Compaction、首次切换某些速度模式，或改变非延迟加载的工具集合，则会产生新的缓存键或前缀。

这解释了一个反直觉实践：不要在长任务中频繁切换模型和工具配置；在会话开始时选好模型与 Effort，在自然任务边界压缩或清理。 Prompt Cache 优化的是相同前缀的重复计算，不是“模型只读一次文件后就永久记住”。文件历史仍作为上下文存在，文件发生变化时还需要重新读取关键部分。

来源定位： How Claude Code uses prompt caching（Exact Prefix、缓存层次和失效条件，访问日期：2026-07-10）。

6.3 Compaction：用有损摘要换取继续工作的空间

官方公开流程是先清理较旧 Tool Output，再在接近窗口上限时总结早期对话，保留近期交互和关键决策。项目根 CLAUDE.md 会在压缩后重新注入，用户也可用 /compact 指定保留重点，或通过 Compact Hooks 在边界处存档。

Compaction 解决“窗口装不下”，却不自动解决“摘要是否正确”：

验收标准只在早期聊天里出现，可能被摘要弱化；
精确错误文本、文件行号和失败实验可能丢失；
模型生成的摘要可能把推断写成结论；
一个超大文件或超长工具结果会在压缩后立刻重新填满，形成 Thrashing。

所以长期任务还需要外部可验证 Artifact：需求清单、测试、计划文件、进度记录、Git 历史和未解决问题。Anthropic 的长任务工程文章也明确指出，Compaction 本身不足以让 Agent 跨多个窗口可靠完成复杂应用；增量交付和清晰交接仍是必要 Harness 设计。

6.4 Progressive Disclosure：只在需要时付 Token

Claude Code 对不同上下文采用渐进式披露（Progressive Disclosure）：

CLAUDE.md 只保留每个会话都需要的核心规则；
Path Rules 在读取匹配目录或文件时加载；
Skill 启动时主要暴露名字和描述，完整正文调用后加载；
MCP 默认先暴露工具名，完整 JSON Schema 通过 ToolSearch 按需获得；
Auto Memory 的入口保持简短，详细主题文件按需读取；
Subagent 的完整执行轨迹留在独立窗口，主 Agent 只接收结果摘要；
Hook 自身在模型外完成格式化、过滤、审计或阻断；只有需要模型看到的返回内容、拒绝原因或 Additional Context 才注入主上下文。

优化目标不仅是节省 Token，还包括降低“注意力稀释”。即使模型上下文窗口足够大，把 500 个无关工具和几十份规范全部放进去，也会让工具选择、规则遵循和事实定位更困难。

来源定位： Extend Claude Code；Manage costs（Skill、MCP、Hook、Subagent 与 Context 成本，访问日期：2026-07-10）。

6.5 Context Isolation：Subagent 既是并行机制，也是压缩机制

非 Fork Subagent 接收专门的委派消息，通常从独立 Context 和自己的 System Prompt 开始，完成后把结果摘要交回父 Agent；模型、Effort、工具、权限、预载 Skill 和 Memory 可以按 Agent 配置，但仍受父会话与组织策略上限约束。Fork 模式则会继承父对话，不属于“Fresh Context”路径。Subagent 的典型适用场景包括：

运行产生海量输出的测试或日志分析；
并行研究互不依赖的模块；
用只读权限做安全、性能或代码审查；
让不同假设分别取证，再由主 Agent 综合；
通过 Worktree 隔离并行写入。

截至本文快照，Claude Code 还提供后台 Subagent、研究预览（Research Preview）的 Agent View、实验性 Agent Teams 和脚本化 Dynamic Workflows。它们不是同一概念：Subagent 向父线程回报，Agent View 管多个独立 Session，Agent Teams 有共享任务表和 Agent 间消息，Worktree 只负责文件隔离。

它们的失败模式同样清晰：委派信息不足会导致重复探索；详细摘要会重新污染主上下文；多个 Writer 没有 Worktree 会冲突；Agent Teams 的 Token 大致随实例数增长；并行任务存在强依赖时，等待和返工会抵消加速。

来源定位： Subagents；Parallel agents；Worktrees（访问日期：2026-07-10）。

6.6 把确定性工作移出模型

能用程序可靠完成的事情，不应每轮都让模型阅读和判断：

Hook 负责固定格式化、阻断敏感路径、记录审计和压缩日志；
LSP 负责精确符号、引用和类型诊断；
Shell/CLI 负责 Git、编译、测试、包管理和云平台查询；
CI 负责最终一致的隐藏测试与发布门禁；
Permission/Sandbox 负责动作边界；
模型负责开放式定位、方案选择和根据 Observation 修正。

官方成本指南甚至建议，在有成熟 CLI 时优先让 Bash 使用 gh、aws、gcloud 等，而不是为每个命令常驻一组 MCP Tool Schema。MCP 的优势是结构化接口、连接和鉴权；CLI 的优势是模型只需要生成命令，不增加每轮工具定义成本。选型关键是安全、可观测、Schema 可靠性和 Context 成本，而不是统一偏好某一种扩展。

6.7 模型和推理分层：把“最强”用在决策点

Claude Code 允许选择模型和推理 Effort，Subagent 还可单独配置。工程上可以把任务分成：

文件列表、简单查询、格式检查：低成本模型或较低 Effort；
常规修改与测试：平衡模型；
架构决策、复杂调试、跨模块重构：更强模型和更高 Effort；
规划与执行使用不同模型；
主 Agent 日常推进，关键决策再咨询更强 Advisor 或验证 Agent。

这是典型的 Model Routing。它减少高能力模型在机械步骤上的浪费，但路由错误会产生新成本：弱模型漏掉关键证据、不同模型理解不一致、切换导致 Prompt Cache Miss、委派摘要造成信息损失。因此应以任务评测而不是模型品牌决定路由。

6.8 完成条件外置：防止“说完成了”代替“真的完成了”

模型的停止信号只是一个候选条件。可靠 Harness 还应检查：

目标测试是否运行且退出码为 0；
构建、Lint、类型检查和安全扫描是否通过；
git diff 是否只包含授权范围；
UI 是否用浏览器或截图验证；
是否仍有未解决任务、重复失败或被拒绝工具；
费用、时间、步骤和权限预算是否超限。

当前 Claude Code 的 /goal、Stop Hook、验证 Subagent 和任务跟踪都体现“执行者与验收者分离”的思路。但验收器仍可能配置错误；最强的证据依然是项目自身的确定性测试、独立 Review 和人工业务验收。

来源定位： Goals；Hooks；Tools reference（访问日期：2026-07-10）。

6.9 恢复性设计：把错误成本限制在可承受范围

Claude Code 在文件修改前建立快照，并把 Session 保存为可 Resume/Fork 的 JSONL；并行 Session 或 Subagent 可放入 Worktree。三种恢复手段分别应对：

失败	首选恢复手段	原因
模型方向错误但文件未改	中断、Conversation Rewind、重新提示	回到错误决策之前
Edit/Write 造成错误文件变更	File Checkpoint 或 Git Restore	恢复本地文件内容
两个 Agent 的修改冲突	Worktree + 独立分支 + 人工整合	隔离 Writer
进程退出或稍后继续	Session Resume / Fork	恢复消息和工具历史
数据库/API/部署结果不确定	外部幂等键、对账、补偿和人工确认	Claude Checkpoint 不覆盖外部系统

恢复能力让用户更敢授权长任务，却不能成为放宽远程权限的理由。真正不可逆的动作必须在工具服务端重新鉴权，并设计幂等和对账。

6.10 Release 级运行时优化：不只是 Prompt 技巧

Claude Code Changelog 还能看到一组更底层的优化方向。它们是特定版本的公开记录，不应当成永不变化的 API 契约：

精简 System Prompt，直接减少每一轮基础输入；
将大 Tool Result 落盘、处理后释放，并为文件历史快照设置上限；
把大型 SSE Frame 处理和长 SDK Transcript 写入从二次复杂度改为线性；
Headless 模式延迟加载 UI/WASM 依赖，降低非交互启动成本；
发行平台原生二进制，并在部分平台内嵌搜索工具，以降低外部依赖并提高跨平台搜索可用性；
并行加载 Resume 列表、并发连接 MCP、延迟加载资源模板；
对 Read 输出采用更紧凑表示并避免不变内容重复进入上下文；
稳定 Tool Description 中的动态内容，提高跨云提供商的 Prompt Cache 命中。

这些例子说明 Claude Code 的优化对象横跨 Token、CPU、内存、I/O、进程启动、网络连接和缓存稳定性。把它只解释为“Anthropic 写了一个很长的 System Prompt”，会漏掉真正的系统工程。

来源定位： Claude Code changelog（本文快照最新公开版本 2.1.202，访问日期：2026-07-10；条目属于具体版本，不是永久 API 契约）。

6.11 一个公开行为级伪代码

下面是根据官方行为抽象的伪代码，用于理解控制流；它不是 Claude Code 源码，也没有还原私有 Prompt、Classifier 或调度算法：

python

def run_agent(user_goal, session, policy, budget):
    context = load_stable_prefix(
        system_prompt="claude_code preset",
        project_rules=load_claude_md_and_memory(),
        tool_metadata=discover_tools_lazily(),
    )
    context += session.history
    context.append(user_goal)

    while budget.remaining():
        if near_context_limit(context):
            context = prune_old_tool_results_then_compact(context)
            context = reinject_project_root_rules(context)

        response = model.generate(context, tools=current_tool_schemas())
        session.persist(response)

        if not response.tool_calls:
            completion_gate = optional_goal_stop_hook_or_orchestrator()
            if completion_gate is None:
                return response.final_text  # 默认 Agent Loop 在此结束
            if completion_gate.accepts(response, session):
                return response.final_text
            context.append("可选外部验收未通过，请依据证据继续")
            continue

        readonly, mutating = classify_by_side_effect(response.tool_calls)
        results = run_readonly_concurrently(readonly, policy)
        results += run_mutations_sequentially(
            mutating,
            permission_check=policy.decide,
            sandbox_bash=policy.sandbox_if_enabled,
            checkpoint_direct_edits=True,
        )
        context.extend(results)
        session.persist(results)

    raise BudgetExceeded(session.id)

生产实现还需要错误分类、超时、用户批准、Hook、敏感信息处理、Trace、模型切换和会话进程管理。默认 Agent Loop 在模型输出不含 Tool Call 时结束；只有显式配置 /goal、Stop Hook 或自定义外部编排时，独立验收才会覆盖该停止信号并启动下一 Turn。模型产生动作，运行时决定动作能否执行；外置验收是可选增强，不是默认核心循环。

7. 示例项目：一次仓库级故障修复

证据说明： 本节是用于解释机制的示例项目，不是当前仓库发生过的真实 Claude Code 运行记录，也没有延迟、成功率或业务收益实测。

7.1 背景、目标与约束

假设一个中型服务仓库出现“登录刷新 Token 后偶发 401”，要求：

只修改认证模块及相关测试；
不访问生产数据库，不推送远程分支；
先复现，再修复；
单元测试、集成测试和静态检查通过；
解释根因、修改边界和剩余风险。

7.2 Claude Code 可采用的调用链

启动时读取仓库 CLAUDE.md 中的构建命令、目录和禁止事项；
查看 Git Status，确认用户已有修改，避免覆盖；
用 Explore Subagent 并行检索刷新 Token、缓存和中间件路径，只返回候选调用链；
主 Agent 读取最相关文件和测试，不把整个仓库塞入 Context；
运行最小复现测试，保留错误、退出码和关键日志；
形成“过期时间单位错误”和“缓存并发覆盖”两个假设，分别取证；
在 Plan Mode 中给出拟修改文件、风险和验证项，等待确认；
Edit 前建立 Checkpoint，做最小修改；
LSP 立即检查类型和引用，随后运行目标测试；
若目标测试通过，再运行认证模块测试和静态检查；
用 git diff 检查范围，独立 Review Subagent 只读审查 Patch；
最终报告根因证据、验证命令、未运行项和无法回滚的外部动作；本例没有外部动作。

7.3 真正的技术难点

这个任务最难的不是生成一段 Token 代码，而是在上下文有限、仓库已有修改且故障偶发的约束下，同时保证根因证据、修改范围和回归验证。难点应拆成“复现是否稳定、两个假设如何区分、并发问题是否被测试覆盖、既有改动是否保留、验收是否针对真实失败”。失败信号包括只改了异常分支却无法复现、测试跑错目录、Review 发现超范围修改或 Compaction 后遗失验收条件。

7.4 可验证亮点与边界

亮点不应写“Claude 很聪明”，而应写：

用独立 Explore Context 隔离搜索噪声；
先复现再修改，使根因与 Patch 可关联；
只读并行、写入串行并保留 Checkpoint；
用确定性测试和只读 Review Agent 双重验收；
用 git diff 证明范围，而不是依赖最终自述。

这些亮点只有在 Transcript、Diff 和测试输出可定位时才成立。没有真实运行就只能说“设计了验证协议”，不能说“修复成功率提升”或“已用于生产”。

8. 为什么很多人觉得它更强

8.1 先拆掉错误前提：有效能力是乘法，不是单项冠军

可以用一个非统计、仅用于工程分析的启发式表达：

Q_{e f f e c t i v e} \propto Q_{m o d e l} \times D_{c o n t e x t} \times P_{t o o l} \times P_{v e r i f i c a t i o n} \times T_{s a f e_a u t o n o m y} \times P_{r e c o v e r y}

其中：

$Q_{m o d e l}$ ：模型理解代码、规划和工具使用能力；
$D_{c o n t e x t}$ ：上下文中有效证据的密度，而非原始长度；
$P_{t o o l}$ ：选对工具、参数正确且工具可靠返回的概率；
$P_{v e r i f i c a t i o n}$ ：能用外部测试识别错误完成的能力；
$T_{s a f e_a u t o n o m y}$ ：在不越权前提下连续工作的时长；
$P_{r e c o v e r y}$ ：出错后恢复到可信状态并继续的能力。

这些量并不独立，公式也不是官方 Benchmark；它强调木桶效应：模型再强，如果拿不到正确文件、不能执行测试或没有权限完成动作，端到端结果仍然失败。

8.2 Claude Code 容易形成优势的七个原因

模型与 Harness 协同迭代。 官方 claude_code Preset、工具语义、模型 Effort 和 Claude 的 Tool Use 能力围绕相同工作流演进。这里的“协同优势”是合理架构推断，Anthropic 未公开完整训练和 A/B 细节。
把终端当通用执行总线。 它不需要为每个构建系统重新开发 UI，只要人能从命令行完成，Agent 通常就能调用并观察结果。
Context 被当作稀缺工作内存。 Cache、Compaction、ToolSearch、Skill、Rules 和 Subagent 共同控制信息何时进入、何时退出。
验证进入主循环。 Test、Build、Lint、LSP、Browser 和 Review 不只是结束后的建议，而是下一轮决策的 Observation。
自治与安全一起设计。 Permission、Sandbox、Hook、Checkpoint 和 Worktree 降低了每一步询问与完全放权之间的张力。
用户始终可以 Steering。 中断、追加消息、Plan、Resume、Fork 和 Rewind 让人能在长任务中低成本纠偏，而不是等错误 Patch 完成后重来。
扩展原语职责清晰。 CLAUDE.md、Skill、MCP、Hook、Subagent 和 Plugin 各有加载时机和主要职责，便于团队把隐性经验固化。

8.3 与主要竞品的当前对比

快照日期：2026-07-10。 产品变化非常快；本表比较公开产品机制，不比较未控制变量的主观“代码智商”。Codex 一列明确覆盖 CLI/App/Cloud 产品族，并非每项都由 CLI 单独提供；Copilot Cloud Agent 是异步 GitHub PR 工人，和三个本地 CLI 也并非完全同类。

维度	Claude Code	OpenAI Codex 产品族	Google Gemini CLI	GitHub Copilot Cloud Agent	条件性结论
核心循环	Gather/Act/Verify，支持实时中断和追加 Steering	同样是开放源码 Agent Loop，支持本地与云端执行	Core 执行工具并回灌模型，支持本地 Agent	在临时环境研究、改码、测试并发 PR	基础 Loop 已趋同，Claude 不独占迭代验证
上下文	`/context`、Cache、Compaction、Rules、Skill/MCP 延迟加载、Auto Memory、独立 Subagent	AGENTS、Memory、Compaction、Tool Search、Subagent	长上下文、GEMINI.md、Memory、压缩、JIT Context、Subagent	仓库/路径指令、Custom Agent、可验证 Memory	Claude 的优势更像“上下文治理组合和可见性”，不是唯一有记忆
并行与协作	Subagent、Agent View、Worktree、实验性 Agent Teams 与共享任务/消息	Subagent、多 Agent App/Cloud、可单独 Steering	Subagent、并行调用与 A2A Remote Agent	多个独立 Cloud Session 并发	Claude 的 Peer Team 组合有差异，但实验性、昂贵且不自动隔离写入
安全	细粒度 Permission + 可选 OS Sandbox + Checkpoint + Managed Policy	OS Sandbox、Approval、默认工作区写边界和网络限制，源码可审计	多种 Sandbox、Folder Trust、Approval、Checkpoint	临时 GitHub Actions 驱动环境、受限网络、仅能向单一分支 Push 的受限凭据、人工 PR Review 与安全扫描	不能说 Claude 默认最安全；Copilot 更适合 GitHub 治理，Codex 默认隔离和透明度突出
扩展	CLAUDE.md、Skill、MCP、Hook、Subagent、Plugin、LSP	AGENTS、Skill、MCP、Hook、Plugin、Apps	GEMINI.md、Skill、MCP、Hook、Extension、A2A、ACP	Instruction、Skill、MCP、Hook、Custom Agent	能力高度对齐；差别主要在组合、生态和成熟度
恢复	JSONL Resume/Fork，代码与对话 Rewind，Checkpoint，Worktree	Resume/Fork、Git/Worktree、客户端恢复能力	Session Resume、Checkpoint、Rewind/Restore	Git Commit、受限分支、PR 和 Session Log	Claude/Gemini 交互回退细，Copilot 审计链清晰；远程副作用都需另行治理
透明度	核心运行时非开源，公共仓库保留所有权利	Apache-2.0 Rust CLI，可读 Agent Loop	Apache-2.0 TypeScript CLI/Core	托管 Cloud Runtime	需要审计或二次开发时，Codex/Gemini 明显占优
基于公开机制更可能适合	复杂本地工程、长调试、频繁 Steering、上下文隔离与细粒度恢复	开源 Runtime、默认隔离、Codex App/Cloud 组合	Google/多模态/搜索生态、长上下文、开放扩展与 A2A	Issue 到 PR、企业 GitHub 治理、异步任务	仍需在目标任务同条件实测，不能只数功能

竞品来源定位： Claude 列来自 How Claude Code works、Parallel agents 与 Permissions；Codex 列覆盖 CLI/App/Cloud 产品族，来自 Codex CLI、Codex agent loop 与 openai/codex；Gemini CLI 列来自 Core、Subagents 与 Remote Agents/A2A；Copilot 列仅指 Cloud Agent，来自 About Cloud Agent 与 Risks and mitigations。均访问于 2026-07-10。

这张表最重要的结论是：MCP、Skill、Hook、Subagent、Memory、Sandbox 和 Checkpoint 已不是 Claude Code 的独占功能。 Claude Code 的差异主要来自这些原语在同一交互式工作流中的组合密度、上下文纪律和可接管性；Codex/Gemini 的开源透明度、Codex 的默认隔离、Gemini 的开放互操作、Copilot 的 PR 治理都是真实反向优势。

主技术点横向选型

下表与机制分册中的技术清单使用同一组 ID。它比较的是 Claude Code 内部可采用的工程策略，不把不同产品未控制变量的 Benchmark 当作通用选型结论。

技术点 ID	候选方案	优点	缺点/代价	适用场景	不适用场景	选择结论与依据
TP-CLAUDE-CONTEXT	分层 `CLAUDE.md` + Skill/MCP 按需加载 + Cache/Compaction	稳定规则可复用，高噪声资料按需进入，长任务能继续	需要维护触发描述、层级边界和压缩后的验收一致性	大仓库、长调试、工具多且规则相对稳定	一次性小问题或没有可复用仓库规则	默认策略；用 `/context`、读取轨迹和强制压缩后回归验证
TP-CLAUDE-CONTEXT	全部规则、资料和工具说明常驻长 Prompt	初始行为直接，早期无需设计加载层级	Token 成本高、重点稀释、Exact-prefix Cache 易失效	很小且短命的上下文实验	长会话、大仓库和频繁切换工具的任务	仅作小规模备选，达到窗口或缓存压力前应迁移到分层上下文
TP-CLAUDE-EXECUTION	Permission + OS Sandbox + Hook + 服务端授权	权限、执行环境和确定性检查分层，拒绝原因可回灌模型	策略配置、审批和平台差异增加维护成本	读写仓库、联网、执行命令和接入 MCP 的真实工程任务	纯文本问答或完全无副作用的离线生成	默认生产候选；用允许、请求批准、拒绝和越界对照测试验收
TP-CLAUDE-EXECUTION	无限制本地 Shell + 事后人工检查	摩擦低，原型执行速度快	Prompt Injection、误删、外传和不可逆副作用影响面大	隔离且可丢弃的个人实验容器	共享仓库、敏感数据、生产凭据和部署动作	不用于正式交付，只能在可销毁环境中短时探索
TP-CLAUDE-RECOVERY	JSONL Resume/Fork + Checkpoint + Git/Worktree + 外部对账	会话、文件和并行写入分别恢复，证据边界清楚	需要管理历史、工作树、外部幂等和存储清理	长任务、频繁 Steering、并行 Writer 和高成本修改	只有一次只读查询或无需保留轨迹的草稿	默认策略；以中断恢复、文件回退和外部成功但响应丢失演练验收
TP-CLAUDE-RECOVERY	只依赖 Git Commit 或手工复制文件	工具通用，团队已有版本控制心智	未提交修改、对话状态和数据库/部署副作用无法完整恢复	小型串行改动且每步及时提交	长会话、未提交 Patch、外部工具和并行工作	作为最后文件恢复层保留，但不能单独满足 Agent 恢复契约

8.4 什么场景更可能选 Claude Code

本地复杂仓库，需要长时间搜索、修改、测试并随时插话纠偏；
多个高噪声调查希望用独立 Context 隔离，再由主线程综合；
团队愿意维护 CLAUDE.md、Rules、Skills、Hooks 和权限策略；
需要在 Terminal、IDE、Web、Remote Control、Headless/SDK 之间延续相近工作模式；
修改风险较高，希望细粒度 Rewind、Checkpoint 和 Worktree 降低试错成本。

8.5 什么场景它未必更合适

只要毫秒级 Inline Completion 或小范围补全，IDE 原生助手摩擦更低；
需要完全审计、修改或自托管 Agent Runtime，Codex CLI 或 Gemini CLI 的开源实现更合适；
主要工作是 GitHub Issue 自动变成受治理 PR，Copilot Cloud Agent 的原生分支、Actions、扫描和审计链更直接；
固定、规则明确、高风险的流程，应优先确定性 Workflow，而不是开放 Agent；
成本高度敏感或任务很小，多 Agent、长思考和完整 Harness 可能得不偿失；
必须处理不可逆生产动作时，Claude Checkpoint 不能替代业务系统的授权、幂等、对账和补偿。

8.6 关键技术难点与可验证亮点

类型	约束与难点	Claude Code 的设计	如何验证	代价与边界
难点：相关上下文	仓库大、窗口有限、工具结果长	Search/LSP、延迟加载、Compaction、Subagent	`/context`、文件读取轨迹、压缩前后验收一致性	摘要有损，延迟加载可能漏触发
难点：长任务连续性	多窗口、进程退出、Agent 过早完成	JSONL、Resume/Fork、Goal/Stop、进度 Artifact	中断恢复演练、跨压缩验收、隐藏测试	持久历史不等于可信长期记忆
亮点：真实反馈闭环	第一次 Patch 很难全对	测试、Shell、LSP、Browser Tool Result 回灌	故障注入后能否根据失败继续修正	测试本身可能不完整或跑错范围
亮点：可控自治	每步审批慢，完全放权危险	Permission + Sandbox + Hook + Auto Classifier	恶意仓库、越权命令和允许命令对照测试	厂商指标非独立基准，仍存在漏判
亮点：低风险并行	并行可加速，也会冲突	只读并发、写入顺序、Subagent、Worktree	并行/串行墙钟时间、冲突率和 Token	Agent Team 成本与协调开销高
亮点：恢复	Agent 可能误改或用户改变方向	Checkpoint、Rewind、Resume、Git/Worktree	文件与对话分别回退后重跑测试	Bash 和远程副作用不可自动恢复

8.7 生产风险与排障闭环

以下是生产风险或故障演练，不是本文声称发生过的真实 Claude Code 事故。

| 风险 | 现象与影响 | 定位证据 | 根因 | 临时止损 | 长期修复 | 回归验证与防复发 | | --- | --- | --- | --- | --- | --- | --- | --- | | Compaction 丢验收条件 | Agent 重复工作、扩大范围或错误结束 | Compact Boundary、Transcript、/context、计划与 Diff | 关键约束只存在早期对话，摘要未保留 | 中断，重述验收，恢复或重新读取证据 | 根规则进 CLAUDE.md，任务标准写外部清单，设置 Compact 指令 | 人工触发压缩后继续同任务，隐藏测试与 Diff Scope 必须一致 | | 仓库 Prompt Injection | 读取文件后尝试外传秘密或执行无关命令 | Tool Call、来源文件、Permission/Auto 日志、网络拒绝 | 不可信文本被模型当指令，权限过宽 | 拒绝动作、断网、停止 Session、轮换已暴露凭据 | 最小权限、文件/网络 Sandbox、Deny/Hook、秘密不进 Context | 恶意 README/Issue Fixture，确认不越权且正常任务仍可完成 | | 错误宣称测试通过 | 最终消息说完成，但 CI 或真实路径失败 | 实际命令、退出码、测试目录、CI、未运行项 | 验收目标模糊、命令被拒、只跑局部或模型误读输出 | 运行权威测试，撤销发布，报告未验证项 | CLAUDE.md 固定命令，Stop/Goal/CI 检查，输出过滤保留退出码 | 注入失败用例和错误工作目录，禁止无证据完成 | | Cache Miss 导致延迟/成本突增 | 深会话某一轮突然慢且输入费用高 | Usage、Cache Read/Write、模型/Effort/MCP/Compaction 事件 | Exact Prefix 变化或新模型缓存键 | 冻结配置，避免继续切换，必要时在任务边界新会话 | 会话开始选模型/工具，减少常驻 Schema，监控命中率 | 重放固定脚本，对比正常与强制失效的延迟和 Token | | 多 Agent 写冲突 | Patch 相互覆盖、测试基于过期状态 | Agent 任务、Git Status、Worktree、文件修改时间和 Diff | 共享工作树、任务边界重叠、缺主整合者 | 停止 Writer，保存各自 Diff，回到可信基线 | Worktree 隔离、文件 Ownership、依赖任务串行、主 Agent 整合 | 两 Agent 故意修改同文件，验证能阻止或显式解决冲突 | | 远程副作用无法回滚 | 本地 Rewind 后数据库、部署或消息仍已改变 | 外部请求 ID、审计日志、服务端状态、Checkpoint 范围 | 把文件恢复误当业务事务 | 冻结自动重试，外部对账，人工止损 | 服务端授权、幂等键、确认指纹、补偿和 Dry Run | 模拟“外部成功但本地超时”，必须先对账而非盲目重做 | | Memory/规则陈旧 | Agent 持续用过时命令或架构 | /memory、InstructionsLoaded、文件版本和失败日志 | Auto Memory 长期保留且未清理，或缺少失效治理、规则冲突和范围错误 | 删除/修正条目，清会话，使用 Safe Mode 排查 | 记录来源、更新时间、路径范围和维护人，定期审计 | 修改构建命令后启动新会话，确认旧规则不再影响 |

建议排障顺序统一为：

图：Claude Code 异常的证据优先诊断树

替代文本： 出现错误修改、重复工作或无证据完成时，先核对真实仓库、依赖和权威测试；基线无误后再检查 Tool Call 是否发生以及 Permission/Sandbox 是否拒绝；随后核对加载的规则和 Memory，再检查 Context、Compaction 与 Prompt Cache 事件；只有前述证据均正常时，才进入模型理解或产品回归分析。

图表加载中…

读图结论： 诊断必须从可复现的仓库和执行证据向上排查；把环境、权限、规则或上下文问题过早归因于“模型变笨”，会绕过最容易验证和修复的根因。

四个判断节点分别覆盖执行基线、工具控制面、持久规则和上下文生命周期；每条修复分支都要回到原现象复测，只有证据链排除这些层后，模型或产品回归才成为合理主假设。

很多“模型突然变笨”其实是文件未读、工具被拒、测试命令错误、上下文被污染、缓存重建或产品版本回归；没有证据时不要把所有失败归因于模型。

8.8 如何公平验证“比其他工具强”

建立版本化评测集，而不是凭一次演示下结论：

固定仓库 Commit、依赖镜像和冷启动状态；
给各工具同一需求、验收测试和时间上限；
明确模型、版本、推理强度、Context、联网、MCP、Sandbox 和权限；
至少覆盖定位 Bug、跨模块功能、重构、测试补齐、安全修复和 UI 验证；
隐藏测试不进入 Prompt，防止“按答案改代码”；
记录成功率、首次有效 Patch、墙钟时间、Token/费用、工具错误、人工干预、越权尝试和回滚时间；
失败按模型理解、Context、Tool、环境、权限、验证、恢复和用户 Prompt 分类；
重复多次并报告方差，因为 Agent 结果有随机性；
单独报告模型与 Harness 组合，不把某个产品的模型优势误写成 Harness 独占能力。

可以优先使用三个核心指标：

Verified Task Success Rate：隐藏测试和人工范围审查都通过的任务比例；
Human Intervention per Success：每个成功任务需要多少次澄清、批准和纠偏；
Total Cost to Verified Change：从开始到验证变更的 Token、费用和人时，而不是只看首 Token 延迟。

8.9 可复用选型清单

[ ] 主要任务是 Inline Completion、交互式本地 Agent，还是异步 Issue-to-PR？
[ ] 是否能给工具相同的模型、权限、网络、依赖和上下文？
[ ] 是否有确定性测试、Diff Scope 和人工 Review，而不是模型自评？
[ ] 长任务如何压缩、恢复、交接和防止过早停止？
[ ] 多 Agent 是否真正可并行，是否用 Worktree 隔离 Writer？
[ ] Prompt、Memory、Skill、Hook 和 Permission 是否各司其职？
[ ] 远程副作用是否有服务端授权、幂等、对账和补偿？
[ ] 是否记录版本、模型、Effort、Cache、Token、费用和工具失败？
[ ] 是否愿意接受闭源 Runtime，还是必须审计和二次开发？
[ ] 结论是否限定了仓库、任务、版本、预算和日期？

8.10 面试时怎么说难点与亮点

难点表达：

Claude Code 最难的不是把 Claude 接上 Bash，而是在有限 Context 和真实副作用约束下，同时保证证据相关性、持续验证和可恢复执行。我会把它拆成上下文生命周期、工具语义、权限沙箱、验收与恢复五个控制面，通过 Transcript、隐藏测试、恶意输入、Compaction 和中断恢复演练验证；公开结论只覆盖产品行为，闭源调度细节不能确认。

亮点表达：

普通基线是模型根据一次 Prompt 直接给 Patch，主要问题是看不到真实仓库状态、失败后不能自修正，也难限制副作用。Claude Code 选择 Agent Loop、渐进式上下文、真实工具反馈和分层安全，把生成变成“取证—行动—验证—恢复”的闭环；价值应由验证成功率、人工干预和总成本证明，代价是 Token、配置复杂度、摘要丢失和闭源透明度。

9. 面试题与参考答案

问题 1：Claude Code 和 Claude 模型是什么关系？

参考回答｜30 秒专业短答：

Claude 模型负责理解代码、推理和提出工具动作，Claude Code 是承载它的软件工程 Harness，负责装配 System Prompt 与项目上下文、执行工具、回灌结果、控制权限、保存会话和恢复文件。实际效果是模型与 Harness 的组合，不能用 Claude Code 的一次成功证明模型单项更强，也不能把工具拒绝或环境缺失误判为模型失败。

生活化解释： 小林负责判断设备怎么修，工位则提供手册、终端、门禁、测试台和工作记录。小林的判断对应 Claude 模型，整套工位对应 Claude Code Harness；专业上是模型提出候选动作、Harness 管理上下文与执行反馈。类比只解释职责分工：模型不是脱离 API 独立行动的人，Harness 中也仍包含概率性决策。

考察点：模型与运行时职责、闭源证据边界；
常见错误：把 Claude Code 说成一个独立新模型，或说全部能力都来自 System Prompt；
可继续追问：同一模型换成不同 Harness，为什么完成率会变化？

问题 2：Claude Code 的主要项目文件如何分工，为什么不能全部塞进 `CLAUDE.md`？

参考回答｜60～90 秒：

CLAUDE.md 放每个相关会话都需要的项目事实和验收命令；Rules 拆分长期规则并可按路径加载；Skills 保存按需流程；Agents 定义独立工作者；settings.json 承担权限、Hook、Sandbox 等客户端配置；.mcp.json 声明外部工具；Session JSONL、Auto Memory 和 Checkpoint 分别保存轨迹、跨会话笔记和本地文件恢复。全部塞进 CLAUDE.md 会让偶用内容永久消耗 Context，还会把“行为提示、确定性配置、运行数据”混成一层。团队文件应提交 Git，Local 文件与 ~/.claude 数据留在本机，秘密通过环境变量或安全凭证注入。

生活化解释： 支付项目的总手册对应 CLAUDE.md，支付目录 SOP 对应 Rules，临时诊断手册对应 Skill，独立专家对应 Agent，门禁对应 Settings，外部服务目录对应 .mcp.json，工作录像对应 Session。专业上，这些载体分别进入 Context、约束客户端、扩展工具或保存状态，不能互相替代。类比只解释职责分层：模型仍可能忽略自然语言手册，真正的权限必须由 Settings、Sandbox 和外部服务授权执行。

考察点：项目配置、Context 生命周期、Git 与安全边界；
常见错误：把 AGENTS.md 说成 Claude Code 原生入口，把 .claude/hooks/ 说成自动发现目录，或把 Session/Memory 提交为团队规范；
可继续追问：路径规则和 Skill 都能减少常驻 Context，二者的选择标准是什么？

问题 3：为什么 Prompt Cache、Compaction 和 Subagent 要一起用？

参考回答｜60～90 秒：

Prompt Cache 降低相同前缀的重复计算，但不会减少 Context 中的信息量；Compaction 用有损摘要缩短历史，却可能丢失早期细节；Subagent 把高噪声任务放到独立窗口，从源头避免主 Context 膨胀。三者分别解决重复计算、窗口容量和信息隔离，不能互相替代。工程上还要把永久规则写进 CLAUDE.md、偶用知识放 Skill、确定性处理放 Hook，并用外部测试和计划 Artifact 防止压缩丢失验收标准。

生活化解释： 编辑部把不变的前几页保留排版结果，把旧会议记录写成摘要，再让调查员去另一间房看海量资料后只带结论回来。保留排版对应 Prompt Cache，会议摘要对应 Compaction，独立调查对应 Subagent；专业上分别优化重复计算、窗口容量和信息隔离。类比边界是：Cache 不会删除历史，摘要可能丢细节，调查员带回的结论也可能遗漏证据。

考察点：Context Engineering 和各机制边界；
常见错误：认为 1M Context 可以取消上下文治理，或认为 Cache 会自动删除旧内容；
可继续追问：压缩后 Agent 忘记验收标准怎么排查？

问题 4：为什么不能直接说 Claude Code 比 Codex、Gemini CLI 和 Copilot 强？

参考回答｜60～90 秒：

因为当前产品原语已经高度重叠，且模型、Harness、版本、权限和任务类型是混杂变量。基于公开机制，Claude Code 在复杂本地长会话、上下文隔离、Steering 和细粒度恢复上值得优先进入候选；Codex/Gemini 的开源透明度、Codex 的默认隔离、Gemini 的开放互操作、Copilot 的 GitHub PR 治理又各有优势。我会固定仓库、模型设置、工具权限、预算和隐藏测试，比较 Verified Success、人工干预和总成本；没有这种控制实验，只能说“更值得在某类工作流中实测”，不能说已经证明更强。

生活化解释： 车队同时面对山路抢修、赛道竞速和工厂运输，负责人必须先确定道路、载重、安全规则和终点。不同车辆对应不同 Coding Agent Surface，隐藏验收与预算对应统一赛道；专业上要固定仓库、模型、权限和测试后再比较完成率。类比不能证明 Claude Code 在所有道路都更快，产品能力也会随版本变化。

考察点：竞品分析、评测设计、事实纪律；
常见错误：用厂商 Demo、一次成功或过时功能表下绝对结论；
可继续追问：怎样把模型能力和 Harness 能力尽量拆开评测？

完整的 L1～L7 训练见 Claude Code 运行机制与工程优化专项面试题。

10. 递进追问

CLAUDE.md、Rules、Skills、Settings 和 Session 分别属于什么生命周期，为什么不能全部塞进 CLAUDE.md？
Exact-prefix Prompt Cache 为什么会被模型切换和工具定义变化破坏？
Compaction、Auto Memory 和 Session Resume 分别保存什么，哪些信息仍可能丢失？
为什么只读工具适合并行，而 Edit、Write 和 Bash 默认应顺序执行？
如何证明 Subagent 降低了主 Context 污染，而不是只增加了 Token？
设计一次仓库 Prompt Injection 演练，应观察哪些日志、拒绝和副作用？
如果要求自建“类 Claude Code”平台，你会把哪些能力交给模型，哪些放进确定性运行时？

11. 实践任务

[ ] 画出你当前 Coding Agent 的 System Prompt、项目上下文、历史、工具和 Memory 加载顺序；
[ ] 为一个测试仓库设计最小 CLAUDE.md、rules/、skills/、agents/、settings.json 与 .mcp.json 结构，并逐项判断是否应提交 Git、是否可能含秘密、何时进入 Context；
[ ] 用同一仓库任务分别执行“单 Agent 全量探索”和“Subagent 隔离探索”，比较主 Context、Token、墙钟时间与结果；
[ ] 构造一次 Compaction 前后实验，检查验收条件、文件路径、失败测试和未解决项是否保留；
[ ] 编写一个只读 Hook 过滤万行测试日志，只返回失败用例、退出码和前后文；
[ ] 用两个 Worktree 让两个 Agent 修改独立模块，再设计一个同文件冲突实验；
[ ] 在测试仓库放入恶意 README 指令，验证 Permission、Sandbox 和 Deny Rule 是否阻止越权；
[ ] 选 Claude Code、Codex 或 Gemini CLI 中两个工具，按第 8.8 节协议完成至少 10 个重复任务，不使用主观“感觉”评分；
[ ] 练习 30 秒说明“Claude 模型、Claude Code 和 Agent SDK 的区别”，并主动说明未知内部实现。

12. 相关知识与参考资料

12.1 相关知识

12.2 Anthropic 一手资料

下列机制、竞品和 Changelog 资料最初核验于 2026-07-10；第 16 项的项目文件目录与配置边界于 2026-07-11再次核验。本文以官方 Changelog 最新公开版本 **2.1.202（2026-07-06）**为主要产品快照；Claude Code 迭代很快，实验功能、默认模型、上下文上限、定价与权限模式应在使用时重新核对。

How Claude Code works：产品定位、工具、Session、Context、Checkpoint 与权限；
How the agent loop works：消息流、工具回灌、并发策略、权限与 Compaction；
Modifying system prompts：claude_code Preset 的构成与公开边界；
Prompt caching：Exact-prefix、缓存层次、失效条件和观测；
Memory：CLAUDE.md、Rules、Auto Memory 和加载范围；
Extend Claude Code：Skill、MCP、Subagent、Hook、Plugin 和 Context 成本；
Subagents、Parallel agents、Worktrees：上下文隔离、并行与文件隔离；
Permissions、Sandboxing、Checkpointing：权限、OS 边界和恢复范围；
Tools reference、Costs：内置工具、LSP 与 Context/成本优化；
Claude Code changelog：Release 级 Token、内存、I/O、启动和并发优化；
Effective context engineering for AI agents：Compaction、结构化笔记和 Subagent 的工程解释；
Effective harnesses for long-running agents：为什么压缩不足以支持长任务，以及增量与交接设计；
Claude Code sandboxing、Auto mode：OS 隔离、分层安全和厂商内部评测边界；
Headless mode、Agent SDK hosting、Goals：程序化运行、Session 进程和外置验收；
Claude Code official repository、LICENSE：公共仓库内容和非开源许可边界。
Explore the .claude directory、Settings、Skills、MCP、Hooks：项目文件、作用域、加载时机、Git 共享和运行数据边界（访问日期：2026-07-11）。

12.3 竞品一手资料

以下均访问于 2026-07-10，用于确认当前产品已经高度功能对齐，而不是证明任一产品的模型质量：

OpenAI：Codex CLI、Unrolling the Codex agent loop、Codex open-source repository；
Google：Gemini CLI Core、Subagents、Remote Agents/A2A、Gemini CLI repository；
GitHub：About Copilot cloud agent、Risks and mitigations、Custom agents configuration。

12.4 当前无法确认

当前完整 System Prompt、不同模型的逐字变体和 Lean Prompt 具体内容；
Compaction 的精确 Prompt、摘要 Schema、信息打分和全部阈值；
主 Agent 的 Tool、Delegation、Replanning 和 Termination 私有启发式；
Checkpoint 的内部 Delta、去重和存储算法；
Fast/Auto Mode 后端调度、Classifier 训练数据和全部判定阈值；
Claude 针对 Claude Code 的训练、RL、合成 Tool Trace 与内部评测集；
同版本、同模型、同任务、同权限和同预算下对竞品的可复现优势。

13. 简明总结

一句话记忆： Claude Code 工程实践的核心，是用上下文优化、确定性验证、恢复机制和同条件评测，把 Coding Agent 的能力转化为可验证、可排障且有边界的交付结果。

核心 Loop 是“获取证据 → 提议动作 → 权限裁决 → 工具执行 → Observation 回灌 → 外部验证 → 继续或结束”；
Prompt Cache、Compaction、延迟加载、Subagent 和 Hook 分别优化重复计算、窗口容量、信息噪声和确定性处理，不能互相替代；
项目文件按生命周期分工：CLAUDE.md 与 Rules 管上下文，Settings 管客户端控制，Skills、Agents 与 MCP 管扩展，Session、Memory 与 Checkpoint 管轨迹、经验和恢复；这套组合而不是某个独占文件构成工程优势；
Codex、Gemini CLI 和 Copilot 已具备大量相同原语；Claude Code 基于公开机制更值得在复杂本地长任务中作为候选，但是否形成优势仍需同条件实测，在开源透明度、默认隔离和 GitHub 治理上也未必占优；
面试和选型时必须说明证据等级，并用固定仓库、隐藏测试、人工干预和总成本验证，不能把闭源推断或一次 Demo 写成普遍事实。

Claude Code 运行机制与工程优化：工程实践篇 ​

目录 ​

6. 关键工程优化 ​

6.1 先看总表：优化的是端到端完成率 ​

6.2 Prompt Caching：把请求组织成稳定前缀 ​

6.3 Compaction：用有损摘要换取继续工作的空间 ​

6.4 Progressive Disclosure：只在需要时付 Token ​

6.5 Context Isolation：Subagent 既是并行机制，也是压缩机制 ​

6.6 把确定性工作移出模型 ​

6.7 模型和推理分层：把“最强”用在决策点 ​

6.8 完成条件外置：防止“说完成了”代替“真的完成了” ​

6.9 恢复性设计：把错误成本限制在可承受范围 ​

6.10 Release 级运行时优化：不只是 Prompt 技巧 ​

6.11 一个公开行为级伪代码 ​

7. 示例项目：一次仓库级故障修复 ​

7.1 背景、目标与约束 ​

7.2 Claude Code 可采用的调用链 ​

7.3 真正的技术难点 ​

7.4 可验证亮点与边界 ​

8. 为什么很多人觉得它更强 ​

8.1 先拆掉错误前提：有效能力是乘法，不是单项冠军 ​

8.2 Claude Code 容易形成优势的七个原因 ​

8.3 与主要竞品的当前对比 ​

主技术点横向选型 ​

8.4 什么场景更可能选 Claude Code ​

8.5 什么场景它未必更合适 ​

8.6 关键技术难点与可验证亮点 ​

8.7 生产风险与排障闭环 ​

8.8 如何公平验证“比其他工具强” ​

8.9 可复用选型清单 ​

8.10 面试时怎么说难点与亮点 ​

9. 面试题与参考答案 ​

问题 1：Claude Code 和 Claude 模型是什么关系？ ​

问题 2：Claude Code 的主要项目文件如何分工，为什么不能全部塞进 CLAUDE.md？ ​

问题 3：为什么 Prompt Cache、Compaction 和 Subagent 要一起用？ ​

问题 4：为什么不能直接说 Claude Code 比 Codex、Gemini CLI 和 Copilot 强？ ​

10. 递进追问 ​

11. 实践任务 ​

12. 相关知识与参考资料 ​

12.1 相关知识 ​

12.2 Anthropic 一手资料 ​

12.3 竞品一手资料 ​

12.4 当前无法确认 ​

13. 简明总结 ​

Claude Code 运行机制与工程优化：工程实践篇

目录

6. 关键工程优化

6.1 先看总表：优化的是端到端完成率

6.2 Prompt Caching：把请求组织成稳定前缀

6.3 Compaction：用有损摘要换取继续工作的空间

6.4 Progressive Disclosure：只在需要时付 Token

6.5 Context Isolation：Subagent 既是并行机制，也是压缩机制

6.6 把确定性工作移出模型

6.7 模型和推理分层：把“最强”用在决策点

6.8 完成条件外置：防止“说完成了”代替“真的完成了”

6.9 恢复性设计：把错误成本限制在可承受范围

6.10 Release 级运行时优化：不只是 Prompt 技巧

6.11 一个公开行为级伪代码

7. 示例项目：一次仓库级故障修复

7.1 背景、目标与约束

7.2 Claude Code 可采用的调用链

7.3 真正的技术难点

7.4 可验证亮点与边界

8. 为什么很多人觉得它更强

8.1 先拆掉错误前提：有效能力是乘法，不是单项冠军

8.2 Claude Code 容易形成优势的七个原因

8.3 与主要竞品的当前对比

主技术点横向选型

8.4 什么场景更可能选 Claude Code

8.5 什么场景它未必更合适

8.6 关键技术难点与可验证亮点

8.7 生产风险与排障闭环

8.8 如何公平验证“比其他工具强”

8.9 可复用选型清单

8.10 面试时怎么说难点与亮点

9. 面试题与参考答案

问题 1：Claude Code 和 Claude 模型是什么关系？

问题 2：Claude Code 的主要项目文件如何分工，为什么不能全部塞进 `CLAUDE.md`？

问题 3：为什么 Prompt Cache、Compaction 和 Subagent 要一起用？

问题 4：为什么不能直接说 Claude Code 比 Codex、Gemini CLI 和 Copilot 强？

10. 递进追问

11. 实践任务

12. 相关知识与参考资料

12.1 相关知识

12.2 Anthropic 一手资料

12.3 竞品一手资料

12.4 当前无法确认

13. 简明总结