在处理大型代码库时，上下文窗口管理是决定 Claude Code 效能的核心工程问题。Karpathy 技能库强调「思考优先」与「目标驱动执行」两大原则，而将这些原则落到实处的技术前提是：你必须清晰地知道当前会话消耗了多少 Token、以及如何在有限的上下文空间内最大化信息价值。本文将从 Token 预算分配、会话分段策略、上下文压缩技术三个维度，提供可直接应用于工程实践的参数与监控方案。
Token 预算分配模型
Claude Code 支持约一百万 Token 的上下文窗口，但这并不意味着你应该持续填充整个空间。Token 成本随上下文累积线性增长，每次 API 调用都会包含历史会话的所有 Token，因此预先规划预算分配至关重要。
一个实用的预算分配建议如下：将总预算划分为三个层次。第一层为核心任务层，占用 40% 至 50%，专门用于当前正在处理的文件内容、相关的测试代码以及即时的工具输出结果。第二层为上下文参考层，占用 30% 至 35%，用于存放项目架构文档、关键模块的接口定义以及近期的设计决策记录。第三层为思考与推理层，占用 15% 至 25%，这是 Claude Code 进行内部推理和计划生成的专属空间。
对于中等规模的代码库（单个仓库约数万至十余万行代码），建议将单次任务的 Token 预算控制在 8 万至 15 万之间。这个区间既能保证足够的信息密度，又留有缓冲空间避免频繁触发上下文压缩。具体参数可参考以下阈值：当会话 Token 总量超过 12 万时，应当主动触发上下文摘要；当超过 18 万时，必须进行会话分段。
在 karpathy-skills 框架下，Think Before Coding 原则与 Token 预算管理形成了天然配合。每次进入新的推理阶段时，明确声明可用预算可以迫使模型做出更聚焦的决策，而非在过于宽泛的上下文中产生冗余推理。例如，在实现一个复杂功能前，可以明确告知「此阶段预算为 4000 思考 Token，请先列出三种可行方案及其权衡」。
会话分段与长期项目上下文保持
长期项目是上下文管理的最大挑战。当一个功能开发周期跨越数天甚至数周时，如何在多次会话之间保持项目连续性，同时避免上下文无限膨胀，是工程化落地的关键。
会话分段的核心原则是以里程碑为单位切割任务。每个里程碑应当是一个可独立验证的子目标，对应独立的会话上下文。完成一个里程碑后，需要生成一份紧凑的交接文档，包含已完成的关键决策、待解决的技术债务、下一步的具体步骤以及任何需要传递的隐性知识。这份文档应当控制在 500 至 1500 Token 之间，使用结构化格式便于后续会话快速重建上下文。
建议的会话分段策略遵循「三阶段循环」模型。第一阶段为调研与设计阶段，在此阶段应当集中消耗 Token 于理解现有代码结构、分析依赖关系、制定技术方案，输出物为设计文档和实现计划。第二阶段为实现与验证阶段，此阶段专注于编写代码、运行测试、修复问题，上下文应当聚焦于当前实现的具体文件和相关的测试用例。第三阶段为审查与优化阶段，此阶段需要回顾整体变更、检查代码质量、更新文档，上下文可以适度扩展以包含全局视角的审视。
在每次会话开始时，用 1000 至 2000 Token 重建上下文是一个有效的实践。具体做法是读取上次会话留下的交接文档、项目根目录的 README、最近的提交记录以及关键的配置文件。这种轻量级的上下文预热能够让 Claude Code 快速进入状态，同时避免将整个历史会话完整加载。
上下文压缩技术与监控阈值
当会话 Token 接近预算上限时，被动的上下文压缩往往导致信息丢失。更好的做法是主动实施压缩策略，在关键节点有选择性地保留高价值信息，丢弃可重建的低价值信息。
上下文压缩的第一层是工具输出精简。Claude Code 在执行搜索、读取文件、运行测试等操作时会产生大量输出。建议为每类工具设置输出保留策略：文件系统搜索仅保留匹配的文件路径列表而非完整内容；代码审查工具的输出保留问题描述和行号，去除完整的代码片段；测试运行结果保留失败用例的摘要和错误堆栈，移除通过测试的详细输出。
第二层是历史消息压缩。当会话长度超过 40 轮交互时，应当对早期的对话历史进行摘要压缩。具体操作是将每 10 轮对话压缩为一段 200 至 300 Token 的摘要，保留核心决策、关键问题和最终结论，丢弃中间的过程性讨论。这种压缩可以在会话中自动触发，也可以手动执行以保证信息完整性。
第三层是项目知识外部化。将项目的架构决策、技术选型理由、代码规范要点从会话上下文迁移到项目根目录的 CLAUDE.md 或专门的文档文件中。Claude Code 在每次会话开始时可以快速读取这些文件，比从历史会话中检索要高效得多。karpathy-skills 本身就是一个典型的外部化知识库，它将 Andrej Karpathy 的最佳实践沉淀为可复用的指令集，避免在每次编码任务中重复解释相同的原则。
监控阈值的设置需要结合具体项目规模和团队习惯。以下是一组经过实践验证的参考值：黄色预警线设为总预算的 70%，此时应当开始关注并准备压缩；橙色警戒线设为 85%，触发强制压缩并暂停新的大规模读取；红色警戒线设为 95%，此时应当立即保存交接文档并结束当前会话。这些阈值可以根据模型版本和具体场景进行调整，但核心原则不变：永远在失控之前主动干预。
工程化落地的关键要点
将上下文窗口管理转化为可执行的工程实践，需要在工具链和流程两个层面建立约束。在工具链层面，建议在项目中配置 Token 使用量监控脚本，每次重要操作后输出当前会话的 Token 统计；同时建立 CLAUDE.md 模板，包含预设的预算分配说明和会话分段指引，确保每次使用 Claude Code 时都有明确的上下文管理策略。
在流程层面，将任务分解为独立会话应当成为团队的开发规范。每个冲刺周期或功能开发都应当有明确的里程碑定义，会话交接文档作为完成的必要条件。这种做法不仅优化了 Token 使用，还间接实现了任务的可追溯性和可审查性，与 karpathy-skills 强调的目标驱动执行形成了方法论上的呼应。
上下文窗口管理本质上是一种信息性价比的权衡艺术。理解何时该充分利用完整的上下文、何时该主动精简并重新聚焦，比单纯追求更大的窗口容量更能体现工程决策的质量。将这种权衡内化为可量化的参数和可复用的流程，是团队在大型代码库场景下充分发挥 Claude Code 能力的关键路径。
参考资料