本文基于 Claude Code 源码，解析其上下文管理机制。重点介绍了由系统提示、工具定义、userContext、消息历史、Attachments 五层构成的复杂上下文结构，以及为应对上下文膨胀问题设计的压缩策略。包括工具结果超限时直接存磁盘、Prompt Cache 缓存优化、压缩带来的信息损失难题，以及分三层（MicroCompact、Session Memory Compact、AutoCompact）的存量清理机制。此外，还探讨了 AutoCompact 的工程保障体系、结构化摘要生成、Hook 机制等设计亮点，为程序员理解和优化大模型应用提供了宝贵参考。

基于 @anthropic-ai/claude-code@2.1.88[1] source map 还原的源码，拆解 Claude Code 的上下文管理机制。

要点速览

• 上下文不是一个对话框：每次请求由系统提示、工具定义、userContext、消息历史、Attachments 五层拼装，其中消息历史里的工具结果是 token 膨胀的主要来源
• 工具结果超限时直接存磁盘：单个结果超过 5 万字符、或一轮并行调用合计超过 20 万字符，超限部分持久化到本地文件，上下文只保留 2000 字节预览 + 文件路径，模型可按需读取完整内容
• Prompt Cache 是整个压缩设计的核心约束：系统提示 + 工具定义的缓存前缀命中后费用降至 1/10，但前缀一旦被修改就全部失效——所有压缩操作都必须绕开这个约束
• 压缩还面临信息损失难题：把工具调用历史压缩成摘要不可避免地丢失细节，模型可能"忘记"关键约束，在任务进行中压缩尤其危险
• 存量清理分三层，代价递进：MicroCompact 在每次请求前静默清理旧工具结果（零 API 调用）；Session Memory Compact 在上下文接近阈值时优先用已有记忆文件压缩（零额外 API 调用）；AutoCompact 在前两者都不适用时调用 Claude 生成摘要（一次额外 API 调用）
• AutoCompact 有完整的工程保障：结构化九章节摘要防止信息随意丢失、熔断器防止压缩失败时的无限循环、PreCompact Hook 允许注入项目特定的"重点保留"规则
• 压缩不等于遗忘：AutoCompact 后模型仍能通过状态恢复（最近 5 个文件）和完整转录文件按需找回细节，信息是"归档"而非"删除"

---

Claude Code 每次向 API 发起请求，发出去的不是一个简单的"对话历史"，而是一个由五个层次拼装而成的结构体。理解这个结构，是理解它为什么需要压缩、以及压缩机制为什么要设计成现在这个样子的前提。

---

上下文的构成

每次请求包含两个主要字段：system（系统提示）和 messages（消息列表）。但这两个字段的内部结构远比表面复杂。

系统提示的四个块

系统提示不是一段文字，而是一个数组，由最多四个块按顺序拼接而成。

归因头（Attribution Header）：内容类似 x-anthropic-billing-header: cc_version=1.2.3; cc_entrypoint=cli，用于服务端识别请求来源。包含版本号等会变化的信息，不参与缓存。

身份前缀（CLI Sysprompt Prefix）：固定文本，例如 You are Claude Code, Anthropic's official CLI for Claude.。所有请求共享，使用 org 级别缓存。

静态指令（Static Instructions）：系统提示的主体，包含任务指导、工具使用规范、代码风格要求、安全操作原则等。在一次会话中几乎不变，是缓存命中率最高的部分。启用 Global Cache 时使用 global 级别缓存，跨用户共享。

动态上下文（Dynamic Context）：包含会话特定信息：当前工作目录、Git 状态、CLAUDE.md 内容、今天的日期、语言偏好、MCP 服务器指令等。每次会话都可能不同，不参与跨会话缓存。

代码中有一个明确的边界标记 SYSTEM_PROMPT_DYNAMIC_BOUNDARY，将系统提示切分为"静态可缓存"和"动态不可缓存"两段：

// src/constants/prompts.ts
export const SYSTEM_PROMPT_DYNAMIC_BOUNDARY = '__SYSTEM_PROMPT_DYNAMIC_BOUNDARY__'

这个边界的意义在于：静态指令部分可能有数千 token，通过边界标记，Claude Code 告诉 API 边界之前的内容可以跨请求复用缓存，边界之后的内容每次重新处理。

工具定义

工具定义作为独立的 tools 字段传给 API，每个工具包含名称、描述和输入 schema。工具列表的最后一个工具会被标记 cache_control: { type: 'ephemeral' }，缓存点打在工具列表末尾，意味着系统提示 + 所有工具定义这整个前缀都可以被缓存。

userContext

CLAUDE.md 和当前日期不是放在系统提示里，而是作为消息历史的第一条消息注入：

<system-reminder>
As you answer the user&#x27;s questions, you can use the following context:
# claudeMd
...
# currentDate
Today&#x27;s date is 2025-04-04.
</system-reminder>

为什么不直接放在系统提示里？因为 CLAUDE.md 的内容可能在会话中途变化，而系统提示在会话开始后就被缓存了。把它放在消息历史开头，可以在不破坏系统提示缓存的情况下更新。

消息历史

消息历史是上下文中增长最快的部分。每一轮对话都会追加：用户消息、助手回复、工具调用（tool_use 块）、工具结果（tool_result 块）。文件内容本身会被完整地放入 tool_result 块，这是消息历史膨胀的主要原因。Claude Code 的默认上下文窗口是 200,000 tokens，一个中等规模的代码库，读取几十个文件后，消息历史就可能占满大半个窗口。

Attachments

Attachments 在每次请求前动态生成，注入到消息历史末尾。常见内容包括：用户 @ 提及的文件、当前 Todo 列表、Plan 文件、从 memdir 检索到的相关记忆片段、与当前任务相关的技能列表、新连接的 MCP 服务器使用说明。设计思路是"按需注入"——只在需要的时候把信息放进上下文。

上下文五层结构

---

上下文管理的必要性与难点

为什么必须压缩

200,000 tokens 听起来很大，但在实际编程任务中消耗极快。读取一个中等规模的源文件大约 1,000–3,000 tokens，执行命令的输出可能几千 tokens，一次完整的代码审查任务轻松消耗数万 tokens。更关键的是，上下文窗口是硬约束——超出就报错，任务中断。

但不是所有内容都值得保留。模型读取文件是为了理解代码，读完之后原始内容就不再需要了；执行命令是为了得到输出，输出被处理之后原始文本也不再需要了。这些"一次性消费"的工具结果占据了大量空间，却不再提供价值。压缩的本质，是把这些已经被消费的信息从上下文中清除，为新的信息腾出空间。

相比之下，有些内容绝对不能压缩：系统提示和工具定义参与 Prompt Cache，在会话中途修改会导致缓存失效，代价极高；用户消息代表任务的需求和约束，是整个任务的"需求文档"，一旦丢失，模型可能偏离方向。

Prompt Cache：压缩绕不开的约束

在讲压缩机制之前，有必要先理解 Prompt Cache，因为它是整个压缩设计的核心约束。

LLM 的推理有一个基本特性：每次请求，模型都要从头处理输入的所有 token，计算每个 token 的注意力权重，才能生成输出。这意味着即使你的系统提示一个字都没变，每次请求仍然要重新处理它。对于 Claude Code 这样的工具，系统提示 + 工具定义可能有数万 token，一次会话里要发送几十上百次请求，这部分重复计算的成本极高。

Prompt Cache 就是为了解决这个问题。它的原理是：API 在处理完一个请求后，把输入的 KV Cache（注意力计算的中间结果）保存下来。下次请求如果前缀完全一致，就直接复用这份 KV Cache，跳过重新计算，费用降低到正常处理的 10%。

缓存的粒度是"前缀"——必须从请求的开头开始，连续匹配。这意味着如果你在系统提示的中间插入了一个字符，整个系统提示之后的所有内容都无法命中缓存。缓存点通过 cache_control: { type: 'ephemeral' } 标记来指定，打在某个位置意味着"从请求开头到这里的所有内容都可以被缓存"。

Claude Code 的请求结构是这样的：

[系统提示静态部分] → [工具定义 ← cache_control 打在这里] → [userContext] → [消息历史] → [Attachments]

缓存点打在工具定义末尾，意味着"系统提示静态部分 + 工具定义"这整个前缀可以被缓存。这个前缀可能有数万 token，一旦命中缓存，每次请求节省的计算量非常可观。

Prompt Cache 的 TTL 是 5 分钟——如果超过 5 分钟没有发送新请求，缓存就会过期，下次请求需要重新处理整个前缀。这个 TTL 对压缩机制的设计有直接影响，后面会看到。

Prompt Cache 机制

压缩的两个核心难点

理解了 Prompt Cache，就能看清楚压缩面临的两个核心难点。

难点一：压缩操作本身可能破坏缓存。压缩需要修改消息历史，而消息历史紧跟在缓存前缀之后。如果压缩操作改变了消息历史的开头部分，就会影响缓存的匹配，导致下次请求无法命中缓存。省下的上下文空间，可能被增加的 token 处理成本抵消。

难点二：压缩会导致信息损失，影响推理质量。把一段详细的工具调用历史压缩成摘要，不可避免地会丢失细节。模型可能"忘记"某个关键约束，在后续推理中犯错。更棘手的是，如果压缩发生在任务进行中，模型需要在压缩后继续完成任务，它必须知道"现在文件是什么状态"，而不只是"我之前做了什么"。

这两个难点决定了压缩机制不能是一个简单的"截断历史"操作，而需要精心设计。

---

上下文管理机制

Claude Code 的上下文管理分为两类机制：入口管控和存量清理。入口管控在工具结果进入上下文之前就介入，阻止大内容进来；存量清理在上下文已经积累到一定程度后触发，对已有内容做清理或摘要。两类机制分工不同，共同构成完整的防线。

存量清理部分的核心逻辑是代价递进：用最低代价的方案处理最常见的情况，只在必要时升级到更高代价的方案。

入口管控与存量清理两类机制对比

入口管控：工具结果持久化

工具结果在入库时就会被检查大小，超限的直接持久化到磁盘，上下文里只保留预览和文件路径。这是最早发生的一道防线，代价也最低——只有磁盘写入，没有任何 API 调用。

// src/constants/toolLimits.ts
export const DEFAULT_MAX_RESULT_SIZE_CHARS = 50_000   // 单个工具结果上限：5 万字符
export const MAX_TOOL_RESULTS_PER_MESSAGE_CHARS = 200_000  // 单条消息内所有工具结果合计上限：20 万字符

触发持久化后，上下文里的工具结果会被替换成这样的消息：

<persisted-output>
Output too large (245 KB). Full output saved to: ~/.claude/projects/.../tool-results/abc123.txt

Preview (first 2000 B):
...前 2000 字节的内容...
...
</persisted-output>

这里有两层检查。第一层是单个工具结果超过 50,000 字符时触发，直接持久化。第二层是"消息级预算"：一轮对话里可能有多个并行工具调用，每个单独看都没超限，但合计可能超过 20 万字符——这时按大小排序，把最大的几个持久化，直到总量降到预算以内。

持久化机制有一个精心设计的细节：替换决策一旦做出就被冻结，后续每轮对话都用完全相同的预览字符串重新注入，而不是重新读文件生成。这保证了消息历史的前缀字节完全一致，Prompt Cache 不会因为"同一个工具结果每次预览略有不同"而失效。

模型如果需要完整内容，可以主动用 FileRead 工具读取持久化的文件路径——这是"按需恢复"而非"强制截断"的设计思路。

第一层：MicroCompact

工具结果持久化处理的是"刚产生的大结果"，MicroCompact 处理的是"已经在上下文里的旧结果"。最常见的情况是：某个工具结果很大（比如读取了一个几千行的文件），但模型已经处理完了，不再需要它的原始内容。这时候最理想的操作是把这条工具结果"缩小"，但不触动消息历史的其他部分，也不破坏 Prompt Cache。

MicroCompact 只针对特定工具的结果做清理，这些工具的输出都是"一次性消费"型的：

const COMPACTABLE_TOOLS = new Set<string>([
  FILE_READ_TOOL_NAME,   // 文件读取
  ...SHELL_TOOL_NAMES,   // Shell 命令（Bash 等）
  GREP_TOOL_NAME,        // 文件搜索
  GLOB_TOOL_NAME,        // 路径匹配
  WEB_SEARCH_TOOL_NAME,  // 网页搜索
  WEB_FETCH_TOOL_NAME,   // 网页抓取
  FILE_EDIT_TOOL_NAME,   // 文件编辑
  FILE_WRITE_TOOL_NAME,  // 文件写入
])

MicroCompact 的核心工具是 cache_edits API——Anthropic 提供的一个特殊接口，允许在不改变消息历史语义的情况下，用缓存版本替换消息内容。模型看到的是摘要或占位符，但 Prompt Cache 中保留了原始内容，缓存不会失效。这个接口直接解决了"压缩不能破坏缓存"的难点。

但 cache_edits 有一个前提：缓存必须还是热的。如果距离上次请求已经超过 5 分钟，Prompt Cache 的 TTL 到期，缓存已经失效，再用 cache_edits 维护缓存就是无用功。这时 MicroCompact 切换到另一条路径：直接把旧工具结果的内容清空，替换为占位符 [Old tool result content cleared]，不再尝试维护缓存。

// 时间触发路径：缓存已冷，直接清空内容
return { ...block, content: TIME_BASED_MC_CLEARED_MESSAGE }
// cache_edits 路径：缓存仍热，通过 API 层替换
pendingCacheEdits = cacheEdits

两条路径的选择逻辑很清晰：缓存热的时候保留缓存价值，缓存冷的时候不做无用功。MicroCompact 在每次发送请求前自动运行，不需要额外的 API 调用，几乎没有额外代价。

第二层：Session Memory Compact

当消息历史整体接近上限时，MicroCompact 就无能为力了。这时系统会先尝试 Session Memory Compact，再考虑代价更高的 AutoCompact。

Session Memory Compact 的核心思路是：Claude Code 在会话过程中会持续提取结构化的 Session Memory（10 段记忆），这份记忆文件本身就是对会话内容的高质量摘要。当需要压缩时，如果记忆文件已经有内容，就直接用它作为压缩摘要，完全跳过 AI 摘要 API 调用。

// autoCompact.ts — Session Memory Compact 排在 AutoCompact 之前被尝试
const sessionMemoryResult = await trySessionMemoryCompaction(
  messages,
  toolUseContext.agentId,
  recompactionInfo.autoCompactThreshold,
)
if (sessionMemoryResult) {
  // 成功：直接返回，不再调用 compactConversation
  return { wasCompacted: true, compactionResult: sessionMemoryResult }
}
// 失败或不适用：回退到 AutoCompact
const compactionResult = await compactConversation(...)

压缩后保留哪些消息由配置决定：

export const DEFAULT_SM_COMPACT_CONFIG = {
  minTokens: 10_000,          // 压缩后至少保留 10K tokens 的近期消息
  minTextBlockMessages: 5,    // 至少保留 5 条有文本内容的消息
  maxTokens: 40_000,          // 保留消息的硬上限
}

从上次记忆提取的位置之后开始，向前扩展直到满足最小 token 和最小消息数要求，但不超过 40K token 上限。这保证了压缩后的上下文既有完整的记忆摘要，又有足够的近期对话细节。

Session Memory Compact 还有一个安全检查：压缩后估算的 token 数如果仍然超过 AutoCompact 阈值，就放弃这条路径，回退到 AutoCompact。这防止了"压缩后立即再次触发压缩"的循环。

这一层的设计巧妙之处在于：它把"持续提取记忆"这个已有的功能，复用为"压缩时的摘要来源"，实现了零额外 API 成本的高质量压缩。

Session Memory 写入的 10 段结构化记忆，也会在下次会话开始时通过相关性检索注入到新会话的 Attachments 中，实现跨会话的知识传递。存储路径使用 git-root 作为 key（~/.claude/projects/<git-root>/memory/），同一项目的多次会话共享同一份记忆，不同项目相互隔离。

三层存量清理代价递进

第三层：AutoCompact

当 Session Memory Compact 不适用（记忆文件为空或不存在）时，AutoCompact 发起一次独立的 API 调用，把整个对话历史压缩成结构化摘要，然后用摘要替换原来的消息历史，重置到干净的起点。

触发阈值

AutoCompact 的触发阈值不是固定百分比，而是动态计算的：

export const AUTOCOMPACT_BUFFER_TOKENS = 13_000

export function getAutoCompactThreshold(model: string): number {
  const effectiveContextWindow = getEffectiveContextWindowSize(model)
  // 阈值 = 有效上下文窗口 - 13,000 tokens 缓冲
  return effectiveContextWindow - AUTOCOMPACT_BUFFER_TOKENS
}

effectiveContextWindow 等于模型上下文窗口减去为摘要输出预留的 token（最多 20,000），还可以通过 CLAUDE_CODE_AUTO_COMPACT_WINDOW 环境变量进一步限制。对于 200K 上下文的模型，实际触发阈值大约在 167K tokens 左右，但这个数字会随模型版本和配置变化。

结构化摘要

摘要不是让模型自由发挥，而是严格按照九个章节生成——主要请求和意图、关键技术概念、涉及的文件和代码、错误和修复、问题解决过程、所有用户消息、待完成任务、当前工作、可选的下一步。

其中"所有用户消息"这一节会逐条列出用户的每一条消息。这直接回应了"用户意图不能丢失"的约束——即使整个对话历史被压缩，用户说过的每一句话都会被保留下来。摘要生成还有一个两阶段过程：模型先在 <analysis> 标签内做草稿分析，确保覆盖所有要点，然后再生成最终的 <summary>。草稿分析在摘要完成后被丢弃，不进入上下文，但它提高了摘要的覆盖质量。

Hook 干预机制

AutoCompact 在执行前后各有一个 Hook 扩展点，允许外部脚本干预压缩过程：

PreCompact Hook 在生成摘要之前执行。Hook 脚本的标准输出会被作为自定义摘要指令，与用户指定的 customInstructions 合并（用户指令在前，Hook 指令追加在后）。这意味着你可以通过 Hook 脚本动态注入"压缩时重点保留 XXX 信息"的指令，而不需要每次手动指定。

// compact.ts
const hookResult = await executePreCompactHooks({
  trigger: isAutoCompact ? 'auto' : 'manual',
  custom_instructions: customInstructions ?? null,
})
// Hook 输出追加到用户指令之后
customInstructions = mergeHookInstructions(customInstructions, hookResult.newCustomInstructions)

PostCompact Hook 在摘要生成完成后执行，接收完整的压缩摘要文本（compact_summary）。可以用来记录压缩事件、同步摘要到外部系统，或者触发其他自动化流程。

两个 Hook 点的职责是不对称的：PreCompact 是"干预"（影响摘要内容），PostCompact 是"观测"（读取摘要结果）。

Hook 的配置格式（在 settings.json 中）：

{
  "hooks": {
    "PreCompact": [{ "hooks": [{ "type": "command", "command": "python3 /path/to/pre_compact.py" }] }],
    "PostCompact": [{ "hooks": [{ "type": "command", "command": "python3 /path/to/post_compact.py" }] }]
  }
}

压缩后的上下文重建

摘要只能保留"做了什么"，无法保留"文件现在是什么状态"。AutoCompact 完成后，会自动恢复最多 5 个最近修改的文件，预算上限是 50,000 tokens：

export const POST_COMPACT_MAX_FILES_TO_RESTORE = 5
export const POST_COMPACT_TOKEN_BUDGET = 50_000
export const POST_COMPACT_MAX_TOKENS_PER_FILE = 5_000

此外还会重新注入本次会话使用过的 Skills（每个最多 5,000 tokens，总预算 25,000 tokens）、重新执行 SessionStart Hook 加载 CLAUDE.md、重新注入工具和 MCP 指令。这个重建过程保证了压缩后的 Claude 能立即进入有效工作状态。

即使摘要和状态恢复都无法覆盖某个细节，还有最后一道保障：完整的会话转录文件。压缩后的摘要消息里包含一行提示：

If you need specific details from before compaction (like exact code snippets, 
error messages, or content you generated), read the full transcript at: /path/to/transcript

如果模型在后续推理中发现自己需要某个压缩前的具体细节，它可以主动读取转录文件，找回原始信息。这是"按需恢复"而非"全量重载"——不会在压缩时就把所有历史都重新加载进来，但也不会让信息永久丢失。

AutoCompact 工程保障体系

熔断器

AutoCompact 依赖 Claude API 生成摘要，但 API 调用失败的原因可能正是"上下文太长导致 413 错误"——这是一个逻辑死锁。熔断器通过计数打破这个循环：

const MAX_CONSECUTIVE_AUTOCOMPACT_FAILURES = 3

// 连续失败 3 次后，本次会话不再尝试 AutoCompact
if (tracking?.consecutiveFailures >= MAX_CONSECUTIVE_AUTOCOMPACT_FAILURES) {
  return { wasCompacted: false }
}

3 次的阈值是经验性参数：1 次失败可能是暂时性网络错误（值得重试），3 次连续失败说明问题可能是结构性的。熔断后用户仍然可以手动执行 /compact，手动路径有独立的 PTL（Prompt Too Long）重试逻辑，会逐步截断最旧的消息组直到压缩请求能够成功：

const MAX_PTL_RETRIES = 3

for (;;) {
  summaryResponse = await streamCompactSummary({ messages: messagesToSummarize, ... })
  if (!summary?.startsWith(PROMPT_TOO_LONG_ERROR_MESSAGE)) break
  messagesToSummarize = truncateHeadForPTLRetry(messagesToSummarize, summaryResponse)
}

---

总结

设计亮点

Claude Code 的上下文管理有几个值得记住的设计决策。

入口管控 + 三层存量清理。工具结果持久化在内容入库前就拦截超限数据，是代价最低的防线（仅磁盘写入）。存量清理部分代价递进：MicroCompact 零额外 API 调用，清理历史工具结果；Session Memory Compact 零额外 API 调用，复用已有记忆文件压缩整个会话；AutoCompact 需要一次额外调用，在前两者都不适用时兜底。每一层都在解决上一层解决不了的问题，同时接受上一层不愿意承担的代价。

缓存感知的压缩操作。MicroCompact 的两条路径（cache_edits vs 时间触发清空）体现了一个重要的工程意识：压缩操作本身不能破坏 Prompt Cache，否则省下的上下文空间会被增加的 token 处理成本抵消。这种"压缩操作必须对缓存友好"的约束，在很多系统中是被忽略的。

记忆提取的双重复用。Session Memory 既是跨会话知识传递的载体（下次会话通过相关性检索注入），又是当前会话压缩时的摘要来源（Session Memory Compact）。同一份数据服务两个目的，是"副产品转化为主产品"的工程复用。

结构化摘要 + 三道质量保障。AutoCompact 不依赖模型自由发挥，而是用九章节结构强制覆盖关键信息，再用状态恢复（最近 5 个文件）和完整转录兜底。摘要保留"做了什么"，状态恢复保留"现在是什么状态"，完整转录保留"原始细节按需可查"。三者分工明确，互不重叠。

Hook 机制是对"不确定性"的制度化应对。Anthropic 无法预知所有用户的压缩需求，PreCompact Hook 把"摘要指令"这个变量暴露给用户，让用户自己决定压缩时重点保留什么。这是"提供机制而非策略"的设计哲学——系统提供干预点，用户填充领域知识。

静态/动态边界的精确切分。SYSTEM_PROMPT_DYNAMIC_BOUNDARY 和 userContext 的设计，把"会变化的内容"和"不会变化的内容"精确分开，最大化 Prompt Cache 命中率。这不是一个显眼的设计，但它影响着每一次请求的成本。

普通用户需要关注什么

CLAUDE.md 要保持简洁。它通过 userContext 注入到消息历史开头，不参与系统提示的缓存，每次请求都会消耗 token。只放真正需要每次都提醒模型的内容，不要把它当成知识库来用。

AutoCompact 触发后，早期对话的细节会变成摘要。摘要会保留所有用户消息，但中间的工具调用细节会被压缩。对于长任务，在关键节点明确告诉模型"记住这个约束"，或者把重要约束写进 CLAUDE.md，比依赖模型的记忆更可靠。

压缩后模型会自动恢复最近 5 个文件。如果任务涉及很多文件，压缩后模型可能无法立即看到所有文件的当前状态。在压缩后的第一轮，可以明确告诉模型需要重新读取哪些文件。

可以用 PreCompact Hook 定制摘要重点。如果你的项目有特定的信息需要在压缩时重点保留（比如某个架构约束、某个正在进行的重构方向），可以写一个 PreCompact Hook 脚本，在每次压缩时自动注入这些指令，而不需要每次手动指定。

频繁切换 MCP 服务器会增加成本。连接和断开 MCP 服务器会改变工具定义，导致 Prompt Cache 失效。如果不需要某个 MCP 服务器，在会话开始前就断开，而不是在会话中途操作。

---

引用链接

[1] claude-code@2.1.88: mailto:claude-code@2.1.88

自动恢复最近 5 个文件。如果任务涉及很多文件，压缩后模型可能无法立即看到所有文件的当前状态。在压缩后的第一轮，可以明确告诉模型需要重新读取哪些文件。

可以用 PreCompact Hook 定制摘要重点。如果你的项目有特定的信息需要在压缩时重点保留（比如某个架构约束、某个正在进行的重构方向），可以写一个 PreCompact Hook 脚本，在每次压缩时自动注入这些指令，而不需要每次手动指定。

频繁切换 MCP 服务器会增加成本。连接和断开 MCP 服务器会改变工具定义，导致 Prompt Cache 失效。如果不需要某个 MCP 服务器，在会话开始前就断开，而不是在会话中途操作。

---

引用链接

[1] claude-code@2.1.88: mailto:claude-code@2.1.88

小白/程序员如何系统学习大模型LLM？

由于新岗位的生产效率，要优于被取代岗位的生产效率，所以实际上整个社会的生产效率是提升的。

但是具体到个人，只能说是：

“最先掌握AI的人，将会比较晚掌握AI的人有竞争优势”。

这句话，放在计算机、互联网、移动互联网的开局时期，都是一样的道理。

我在一线互联网企业工作十余年里，指导过不少同行后辈。帮助很多人得到了学习和成长。

我意识到有很多经验和知识值得分享给大家，也可以通过我们的能力和经验解答大家在人工智能学习中的很多困惑，所以在工作繁忙的情况下还是坚持各种整理和分享。但苦于知识传播途径有限，很多互联网行业朋友无法获得正确的资料得到学习提升，故此将并将重要的AI大模型资料包括AI大模型入门学习思维导图、精品AI大模型学习书籍手册、视频教程、实战学习等录播视频免费分享出来。

第一阶段（10天）：初阶应用

该阶段让大家对大模型 AI有一个最前沿的认识，对大模型 AI 的理解超过 95% 的人，可以在相关讨论时发表高级、不跟风、又接地气的见解，别人只会和 AI 聊天，而你能调教 AI，并能用代码将大模型和业务衔接。

• 大模型 AI 能干什么？
• 大模型是怎样获得「智能」的？
• 用好 AI 的核心心法
• 大模型应用业务架构
• 大模型应用技术架构
• 代码示例：向 GPT-3.5 灌入新知识
• 提示工程的意义和核心思想
• Prompt 典型构成
• 指令调优方法论
• 思维链和思维树
• Prompt 攻击和防范
• …

第二阶段（30天）：高阶应用

该阶段我们正式进入大模型 AI 进阶实战学习，学会构造私有知识库，扩展 AI 的能力。快速开发一个完整的基于 agent 对话机器人。掌握功能最强的大模型开发框架，抓住最新的技术进展，适合 Python 和 JavaScript 程序员。

• 为什么要做 RAG
• 搭建一个简单的 ChatPDF
• 检索的基础概念
• 什么是向量表示（Embeddings）
• 向量数据库与向量检索
• 基于向量检索的 RAG
• 搭建 RAG 系统的扩展知识
• 混合检索与 RAG-Fusion 简介
• 向量模型本地部署
• …

第三阶段（30天）：模型训练

恭喜你，如果学到这里，你基本可以找到一份大模型 AI相关的工作，自己也能训练 GPT 了！通过微调，训练自己的垂直大模型，能独立训练开源多模态大模型，掌握更多技术方案。

到此为止，大概2个月的时间。你已经成为了一名“AI小子”。那么你还想往下探索吗？

• 为什么要做 RAG
• 什么是模型
• 什么是模型训练
• 求解器 & 损失函数简介
• 小实验2：手写一个简单的神经网络并训练它
• 什么是训练/预训练/微调/轻量化微调
• Transformer结构简介
• 轻量化微调
• 实验数据集的构建
• …

第四阶段（20天）：商业闭环

对全球大模型从性能、吞吐量、成本等方面有一定的认知，可以在云端和本地等多种环境下部署大模型，找到适合自己的项目/创业方向，做一名被 AI 武装的产品经理。

• 硬件选型
• 带你了解全球大模型
• 使用国产大模型服务
• 搭建 OpenAI 代理
• 热身：基于阿里云 PAI 部署 Stable Diffusion
• 在本地计算机运行大模型
• 大模型的私有化部署
• 基于 vLLM 部署大模型
• 案例：如何优雅地在阿里云私有部署开源大模型
• 部署一套开源 LLM 项目
• 内容安全
• 互联网信息服务算法备案
• …

学习是一个过程，只要学习就会有挑战。天道酬勤，你越努力，就会成为越优秀的自己。

如果你能在15天内完成所有的任务，那你堪称天才。然而，如果你能完成 60-70% 的内容，你就已经开始具备成为一名大模型 AI 的正确特征了。

这份完整版的大模型 AI 学习资料已经上传CSDN，朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】