最近朋友问我最多的问题十个里有八个和“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 编程最值钱的认知窗口越大越要学会缩小注意力的范围。
