最近朋友问我最多的问题，十个里有八个和“AI编程”有关。大家被“Claude Code 的 200K 上下文”这个卖点吊足了胃口，觉得只要窗口够大，AI 就能一口气把整个项目都吞下去，然后像高级工程师一样精准地帮我改代码、迁移模块、重构祖宗级老项目。可真正上手的人，大概率会遇到和我一样的场面：对话刚开始二十轮，AI 就开始前言不搭后语；你让它改完了 A 文件，回头再动 B 文件，它把之前说好的约定忘得一干二净；有时候你只是想让它看一下某个报错，它反而被上下文里一堆无关文件带偏，给你一个自洽但完全错误的方案。
问题到底出在哪？我把这段时间的实操经历整理成一篇长文，核心结论一句话：200K 上下文是“理论饭量”，不是“实际战斗力”。它救不了你的 AI，真正能救你的，是你怎么管理这段极其昂贵的窗口资源。
1. 200K 上下文的“隐形账单”：大食堂里真正的空位没那么多
先说一个很多人忽略的前提：上下文窗口 200K，指的是模型一次最多能“注视”的 token 总数，但这些 token 并不是全都留给你塞对话和代码的。Claude Code 运行时本身就要吃掉一大块固定开销。
1.1 系统提示、工具定义和输出预留：还没开工就少了十几万？
我第一次被惊到，是发现 Claude Code 在不做任何事的情况下，上下文里就躺着十几万 token 吗？其实没那么夸张，但也绝不少。Claude Code 有一套复杂的系统提示，里面包含工具使用的规则、安全约束、操作规范、以及模型需要理解的“怎么调用 bash、怎么读写文件、怎么用 grep”等说明。这一部分的 token 数通常在一两万左右浮动，具体视版本而定。
更重要的是：模型每次回复之前，API 会为“即将生成的输出”预留 token。这是很多人的知识盲区——上下文窗口的计算方式是“输入 token + 输出 token 预填充”。比如你给模型 32K 的输出上限，那么在输入侧统计时，这 32K 就已经被“锁”住了，窗口可用容量瞬间少掉 32K。也就是说，200K 窗口，先扣掉系统提示，再扣掉输出预留，真正能装对话历史的空间可能只剩 150K 上下。如果你还把 max_tokens 调得很大，可用输入空间会更小。
这里有笔账值得算一算：假设系统提示占 15K，输出预留 32K，那么有效输入空间大约是 153K。看着还是很大对吧？但代码文件非常吃 token。一个 500 行的 TypeScript 文件，含缩进、注释、泛型声明，大概要吃 5K 到 8K token。你让 Claude Code 给你“看一下整个项目的结构”，它得用 bash 的 tree 命令——几百行目录树，1K 到 2K token；它再打开三个关键文件，一个 10K，一个 8K，一个 5K；再加上你描述需求的 2K，一轮“仔细看代码”之后，你已经消耗掉 30K 左右 token。而这仅仅是开始，后面的每一轮修改、每一次运行测试、每一次报错分析，都在持续累加。
1.2 工具调用的输入输出全部计费：每执行一条命令，都在烧窗口
Claude Code 和普通聊天最大的区别，是它会主动调用工具。每调用一次 bash 或读取一个文件，命令内容、输出结果、甚至报错信息都会完整写回上下文。这个设计让 AI 具备“动手能力”，但也让上下文消耗速度比普通聊天快一个量级。
我在实际项目里观察到的现象：一次简单的“运行测试并告诉我失败原因”，Claude Code 会执行 npm test，如果测试框架输出特别啰嗦，一次就能产生 10K 到 20K token 的日志。如果项目里有好几个失败的用例，每修一个就重新跑一遍全家桶测试，连续三轮之后，你的 200K 窗口基本就见底了。这时候模型表现明显下降，因为它需要在比之前多数倍的信息里找到那条真正关键的报错。这就引出一个更核心的问题——窗口大不等于注意力准。
2. 上下文越长，注意力越“撒胡椒面”：模型不是数据库，是个精力有限的实习生
Transformer 架构有一个被研究了很多年的现象，通俗讲叫“lost in the middle”：当输入序列很长时，模型对开头和结尾的内容注意力最强，对中间部分的记忆和利用效率明显下降。你把 200K 塞满，不代表模型能均匀地“看见”每一行代码。它更像一个精力有限的实习生，你把 200 页资料拍在他桌上，他只会认真读第一页和最后一页，中间全靠扫。
2.1 中间遗忘效应：你放在第 80K token 处的关键修改要求，它可能压根没“看见”
我踩过一个非常典型的坑：有一次让 Claude Code 重构一个模块，我把需求写在了对话的中间位置——前面是几次无关的调试记录，后面是另一个文件的内容。结果模型在生成新代码时，完全忽略了我中途给出的“不允许改动对外接口签名”的硬性要求，直接按照自己理解把接口改了。事后排查，我把那条要求翻出来，它确实清清楚楚躺在上下文里，但模型就是没“往心里去”。
这提醒我一件事：重要的指令，要么放在对话最开头，要么放在最结尾，或者在每次关键任务前重新强调一遍。千万别指望模型从 200K 的历史里自动检索你两小时前说过的一句话。它没这个能力，至少现在没有。
2.2 幻觉放大器：上下文越多，模型越容易“编”出一套自洽但错误的方案
长上下文的另一个副作用是幻觉更容易出现。模型在生成代码时，要同时对齐的约束条件越多，就越倾向于“填补空白”来让输出显得合理。比如在一个老旧项目里，模型看到上下文里有 5 个不同的配置文件，它可能会自动“脑补”出一个并不存在的依赖关系，然后给你生成一段理直气壮的代码，注释还写得特别完整。你如果不逐个验证，很容易被这种自信误导。
我和用 Cursor 的朋友交流过，大家有共同感受：小上下文时模型像“精确制导”，你喂什么它就吃什么；大上下文时模型变成了“大范围轰炸”，覆盖面广但精度下降。对编程这种容错率极低的任务来说，精度下降的代价是不可接受的。
3. 真实项目场景：200K 是怎么被“吃干抹净”的
理论上 200K 已经能装下一本不薄的小说，为什么实际开发中还是不够用？因为真实项目的复杂度不是线性的，而是指数膨胀的。
3.1 多文件修改的需求链路：改一个功能要读 20 个文件
假设你要给一个 Web 应用加一个新的权限校验中间件。这个任务听起来不大，但在真实工程里，它涉及路由注册文件、鉴权工具函数、用户模型、数据库查询、前端接口定义、环境变量配置、现有中间件的写法约定……Claude Code 为了做出正确修改，会不断用 Read 工具去打开相关文件。每打开一个，上下文就多一份。再加上中途还要查看 package.json 了解依赖、看看 README 了解项目约定，只完成这一个中小型需求，上下文就轻松用掉 80K 到 120K token。
更麻烦的是，改完代码后，Claude Code 会自己运行 lint、测试或者类型检查，然后用Claude（旧版叫claude-code，现在就是claude）尝试修复错误。每次失败信息加上代码尝试，又是一大块消耗。真实场景里，一个包含 20 个文件的模块级重构，根本不是一个 200K 上下文能装完的，3 倍都不够。
3.2 上下文污染：无关代码会把模型带偏
比不够用更隐蔽的问题，是“塞了太多不该塞的东西”。我见过有人为了让 AI 全面理解项目，直接把整个目录结构、所有配置文件、甚至 node_modules 的 part 文件都丢进去。结果模型被大量无关细节淹没，反而没法分辨哪些信息对你的当前任务有用。
尤其在排查 bug 时，上下文里的“噪音”是致命的。模型看到一堆不确定的日志和错误猜测，它会倾向于给出一个“可能”的修复方向，而不是真正定位问题。我在实际使用中发现，越是把上下文控制得精准——只放关键文件、关键报错、明确期望——AI 的修复成功率越高。这也是为什么我不建议把项目的全部代码一次性塞进去，哪怕 200K 装得下，也不该这么干。
3.3 费用失控：长上下文是隐形的“烧钱机”
API 计费按输入 token 数量计算，Claude 的输入价格对长上下文相当敏感。如果你每天高频使用 Claude Code，动不动就让上下文堆到 150K，那么一个下午的对话就可能烧掉几十万的 token 量。费用账单会告诉你一个扎心的事实：大上下文不是馈赠，是另一种形式的开销。相比之下，把上下文精打细算到 20K 以内，不仅模型表现更好，成本也能压到一个数量级以下。
这里多提一句：很多团队开始给 Claude Code 配置第三方模型，比如通过修改ANTHROPIC_BASE_URL环境变量，让它接入别的模型服务，用参数更小的模型承接部分简单任务。这样做确实能降本，但要注意上下文窗口、输出上限、工具调用能力都有差异。同样一段 100K 的上下文，在不同模型身上表现出的效果天差地别，别把 Claude Code 的能力默认等同于所有接入模型的能力。
4. 自救方法论：把 200K 当稀缺资源，而不是无限仓库
说了这么多问题，总得给解药。这一节是我在项目里反复验证过、现在仍然每天在用的工作流。核心原则一句话：把上下文当成你手里的战略资源，每一分 token 都要花在刀刃上。
4.1 一个会话只干一件事：分割任务，别让历史变成垃圾场
我见过太多人把 Claude Code 当成一个“跨天的结对编程伙伴”，从早上写到晚上，同一个会话里既写接口又改样式还查 bug。这是最耗上下文、也最容易让模型精神分裂的用法。我现在强制的规矩是：一个会话只对应一个原子任务。要写新功能，就开新会话；要排查线上问题，再开一个新会话；哪怕是同一个模块的两次重构，也尽量分开。
这样做的逻辑很简单：任务越单一，模型需要关注的上下文边界越清晰。会话一短，模型从开头就能明确理解“我这次进来是干嘛的”，不需要从上百轮历史里猜你的意图。配合CLAUDE.md文件把项目技术栈、目录结构、约定规则写清楚，每次新会话模型都可以通过读取这个文件快速进入状态，比让它从长篇大论的历史里找线索高效得多。
4.2 用检索代替投喂：让模型自己找，而不是你把整个世界塞给它
很多人的习惯是把文件内容复制粘贴或者拖动进对话。在小项目里这没问题，但项目一变大，你就要学会“让 Claude Code 自己去找”。Claude Code 内置了Grep、Glob、Read等工具，你应该先让它Grep出关键词，再定位到具体文件，最后用Read读取文件的具体片段，而不是一次性把整个大文件完整读入。
举个例子，假设我要让 AI 改某个表单验证逻辑。我不会直接把整个表单组件文件丢给它，而是先让它搜索validate函数在哪些文件出现，用Glob看目录结构，然后定位到核心函数所在的几十行代码。这样上下文里只保留最相关的片段，模型注意力不会被无关代码稀释。你甚至可以主动用git diff来查看改动，而不是让 AI 从头到尾读一遍工作区文件。这种方式能让上下文使用量下降 50% 以上，同时准确率反而提升。
4.3 善用压缩与清理指令：关键时刻主动断舍离
Claude Code 提供了几个管理上下文的内置命令，很多人没用熟。一个是/compact，它会把当前对话的可压缩部分打包成摘要，释放出大量上下文空间。我一般会在对话超过 60K token 或者感觉模型开始“犯傻”时主动执行一次。但注意，压缩是把双刃剑——摘要会丢失细节，模型后续可能忘掉一些具体约束。所以用/compact之前，最好在CLAUDE.md或者对话的开头部分用显式文字记录关键决定。
另一个更狠的命令是/clear，直接清空当前对话历史，相当于“重开一局”。如果你的任务已经完成，或者你发现当前对话已经乱到无法修补，别犹豫，直接清。很多开发者舍不得清空，怕之前的努力白费。但你要意识到，AI 的上下文不是工作的“存档”，而是它的“短期记忆”。记忆坏了，继续硬撑只会让错误滚雪球。该清就清，干净的记忆远比冗长的历史有价值。
在这里我摸索出一个实用习惯：在有复杂多步骤任务时，每完成一个阶段性目标，就把结论复制到项目根目录下的一个DECISIONS.md文件里。然后/clear新开会话的时候，先让 AI 读这个文件。这样虽然短期记忆清空了，但长期“工作记忆”还在，而且是通过更稳定的外部文件形式存在——这比堆在 200K 上下文里可靠得多。
5. 踩坑实录与排查思路：遇到问题别只怪“上下文不够”
最后分享几个我在实际使用中遇到的典型问题。很多时候模型表现差，不一定是上下文窗口不够大，而是工作方式不对。以下排查思路可以帮你快速定位到底是哪一环出了问题。
5.1 症状一：AI 改东忘西，修改代码前后矛盾
排查方向：先看当前上下文是否达到 80% 以上的容量。如果是，优先执行/compact或者/clear，把关键决策写进外部文档。如果不是容量问题，很大概率是你给的指令缺少明确的“边界描述”。我给模型下达任务时会强制它回答三个问题：哪些文件可以改、哪些文件绝对不能碰、改动的验收标准是什么。模型对边界的理解越清晰，前后矛盾的概率就越低。之前提到的中间遗忘效应，很多时候可以通过把验收标准放在对话最开头来缓解。
5.2 症状二：模型完全走偏，给出的方案和你的预期南辕北辙
排查方向：先停下手头操作，重新读一遍它生成代码之前的上下文里有没有无关内容。比如你在让它写 Python 后端之前，刚刚聊过前端 CSS 的细节，这些信息残留会影响它的思维倾向。我试过最夸张的一次，模型在生成一个数据迁移脚本时，居然用了 CSS 里的变量命名风格，就是因为前面 30K token 全是样式相关的内容。解决办法是重要任务前主动用/clear清空无关记忆，不给它产生联想的背景。
5.3 症状三：接入其他模型后效果明显变差
很多教程让你通过环境变量配置去接入更便宜的模型来降本，但请记住：Claude Code 负责调度和工具调用，模型负责“思考”。不同模型在长上下文、代码理解、指令遵循上差异极大。如果你把默认模型换成参数更小的模型，并且照搬之前的 80K 长对话，效果八成是灾难。我的经验是，接入替代模型时要把任务拆得更细、上下文控制得更短，并且适当降低单轮输出预期。别指望平替模型直接继承 Claude 的满血表现。
5.4 我的“上下文管理清单”：每次开会话前的 10 秒
现在，我每次用 Claude Code 干活之前，都会在心里过一遍这个清单：
- 这个会话的目标是什么？能不能用一句话说清楚？
- 哪些文件是必要的？哪些文件虽然在相关，但现在不用看？
- 有没有把当前项目最重要的约束写进
CLAUDE.md？ - 我准备让 AI 用什么命令去定位信息，而不是自己复制粘贴大段代码？
- 完成当前小任务后，要不要把结论记录下来并准备
/clear？
这套流程听起来平淡，但效果非常显著。从测试结果看，同样一个功能开发任务，优化上下文管理之前平均要和大模型纠缠 200K 上下的 token，反复修正三四次；优化之后平均不到 60K token 就能做到一次通过，而且返工率大幅降低。
说到底，200K 上下文是一个非常好的“安全垫”，它让你在偶尔偷懒多喂一些内容时不至于立刻崩溃。但把它当作解决一切问题的万能钥匙，最后一定会失望。AI 能力的上限，一半在模型，另一半在你如何约束和引导它。我的真实感受是：每一次把上下文精简干净的尝试，一次只让 AI 专注做一件小事的克制，比单纯追更高的窗口数字有用的多。这也许就是 2025 年这个阶段，AI 编程最值钱的认知：窗口越大，越要学会缩小注意力的范围。
