上下文工程实战：为什么AI编程助手越用越笨？如何用上下文管理解决

1. 你眼里的变笨其实是模型在工作记忆里翻车1.1 先还原一个越用越笨的完整现场我前阵子用Cursor帮同事review一个微服务项目刚开始的两轮对话几乎可以用惊艳来形容——需求理解精准、代码建议靠谱、还主动指出了我都没注意到的边界条件。但等我们聊到第二十几轮情况开始不对劲了它把之前已经明确放弃的旧方案重新捡了回来反复修改同一个早已改好的bug甚至在我已经确认就这样别再动了之后又自作主张给代码加了一层多余的抽象。同事脱口而出这AI是不是越用越笨了我告诉他模型没变笨它还是那个它。真正出问题的是它的上下文窗口里堆满了垃圾。这个现象在AI编程助手的使用中太普遍了。你回想一下自己是不是也遇到过类似的场景新开会话时它灵得吓人聊得越久反而越迟钝。开始时让你惊喜后期让你血压升高。大多数人会归结为AI能力不行或者模型抽风但真相是——大语言模型的推理能力来自训练阶段学到的参数这些参数在你使用过程中是固定不变的。变的不是模型的智力而是它每轮问答时眼前能看到的信息。1.2 模型没变变的是它能看到的纸条堆我习惯用一个比喻来理解上下文机制你面前坐着一个资深程序员他能力很强但记性不太好桌上堆满了便利贴。这些便利贴就是上下文窗口里的内容——包括你们聊过的每一句话、你贴过的每一段代码、工具自动抓取的每一个文件。他厉害归厉害但每次做决策时只能扫一眼桌上最显眼的那些纸条。当桌面上堆满了20轮前早已废弃的代码版本、5次重复确认的同一条需求、随手粘贴的与任务无关的配置文件这位资深程序员再聪明也只能按纸条堆里权重最高的信息来办事。这就是所谓的信息密度下降上下文窗口是有限的无效内容越多有效信息被稀释得越厉害。从工程角度说这叫做上下文污染。它不是模型推理能力退化而是关键信息在窗口内被大量噪音淹没。我实测过很多次同一个问题在干净的上下文里模型能给出精准答案在塞了3万行日志和10轮闲聊的上下文里同一个模型可能给出完全相反的建议。2. 上下文里的三大噪音源浪费token最多的地方2.1 对话历史滚雪球每一轮都在降低信噪比对话历史的增长是上下文污染最隐蔽、也最致命的一条路径。你每多聊一轮AI编程助手都会把上一轮的内容继续留在上下文里——包括你的确认、追问、甚至好的谢谢这种毫无信息量的口水话。多轮修改同一段代码时旧版本、新版本、中间的各种讨论版本全部堆叠在一起。模型需要自己去判断哪一个是最终版本而现实是它经常判断错。我遇到过一个很典型的案例有个朋友在改前端样式跟AI助手聊了15轮一会儿改颜色一会儿改间距最后AI给出的方案竟然回到了第3轮的状态。朋友气得不行我一看他的会话记录就明白了——早先那几轮明确的用这个颜色这个间距可以这些关键决策已经被后面十几轮的新内容挤到了上下文的边缘位置。模型看到的内容里最终答案的信息权重反而被稀释了。我的建议很简单改到一定程度就果断开新会话。把当前状态目标用一段话描述清楚在新的上下文里继续工作而不是让它在堆满历史垃圾的基础上猜你要什么。2.2 大文件与超长日志一次性投喂的代价另一个常见的噪音源是一次性投喂。很多新手喜欢把整个项目目录、整份README、几千行的日志文件直接扔给AI觉得信息越全它越聪明。这个思路大方向没错但完全忽略了上下文窗口的物理极限。以Claude Sonnet 4.5为例1M token的上下文窗口大约能容纳70万到80万个英文字符——差不多是《三体》三部曲的总字数。听起来非常大对吧但注意装得下和读得懂是两回事。模型在1M token里做决策时注意力是均匀分布的吗不是。它对开头和结尾部分的内容关注度会明显更高对中间部分的信息容易忽略。这就导致你把一个巨大的代码文件塞进去之后它真正看清楚的可能是开头几百行和结尾几十行中间的核心业务逻辑反而被忽略了。日志分析场景更夸张。我见过有人把几万行的服务端日志全部粘贴给AI助手想让它找出报错根因。结果模型被高频出现的普通警告信息带偏了方向反而漏掉了真正关键的那条异常。正确做法是先让AI设计排查策略告诉它错误发生的模块、时间范围、已知症状然后用grep自己先过滤掉明显无关的行只把可疑片段交给它。这就像你去看医生得先自己说清楚哪儿不舒服而不是把一整年的血常规报告全拍医生脸上。2.3 用户自己的口水话和重复指令还有一类噪音源来自用户自己可惜很多人意识不到。有些人习惯每轮都把自己的完整需求重复一遍觉得这样AI不会忘。但上下文机制下你每重复一次需求那些关键词的权重就会被再次强化。结果模型可能误以为你在强调这个功能很重要要重点处理反而偏离了你原本想做的事。还有一种更隐蔽的坑指令冲突。如果你在前几轮说不要用事件委托实现到了后几轮又说用事件委托处理一下模型就会面临不确定性——它有时会听从最近的指令有时会倾向于遵循更长的、被重复更多的指令完全没有规律可循。我在Claude Code里踩过好多次这个坑最后的解决方案是所有关键决策写进一个项目文档在对话开头用按docs/decision.md执行来锁定状态而不是反复在对话里追加口头指令。3. 1M上下文不是万能药长不等于记得住3.1 上下文变大的代价最近行业里刮起了一股上下文军备竞赛。从早期的4K、8K到后来GPT的128K再到Claude的200K现在已经卷到了1M。热搜词里Claude Code 1M上下文1M上下文已经全量可用请启用1M上下文后重试这些说法频频出现说明大家确实在把上下文窗口当作产品竞争力的核心指标。1M token确实很有吸引力。理论上你可以把整个中型项目的核心代码全部塞进去让AI助手拥有全局视野再也不用担心它忘记哪块逻辑。但你需要理解一个底层事实模型在每个token上的注意力是有限预算。窗口变得更大注意力被分摊到更多的信息上模型反而更难锁定最关键的少数几条信息。学术界有一个著名的Lost in the middle现象在处理长文本任务时大语言模型对上下文开头和结尾部分的内容记忆显著好于中间部分。也就是说你把一个大型代码库的中间某个模块塞进上下文它很可能看是看到了但没往心里去。这就像人听一场两小时的演讲记住的往往是开场和结尾中间部分再重要也会模糊。3.2 当1M窗口遇到真实工程场景再说一个更实际的观察当工具提示上下文已使用满请启用1M上下文后重试或者上下文已满请清理时很多人第一反应是换更大的窗口。但你有没有想过真正该做的是清理而不是扩容真实工程场景远比你想象的复杂。一个项目里除了源代码还有Dockerfile、配置文件、构建脚本、README、node_modules、测试夹具、数据库迁移脚本……即使1M窗口全给你也塞不下一个中大型仓库的全部内容。所以工具实际做的是检索式投喂——根据你的当前任务从仓库里抓取相关文件拼装进上下文。这个检索环节的质量参差不齐经常抓进来一堆不相关的文件反而占用了大量窗口空间。我的观点很明确大窗口有用但它降低的是忘记重要内容的概率不是推理质量的保证。你如果在1M窗口里塞了50个文件其中5个是真正关键的、45个是不相关的模型依然会被那45个文件带偏。上下文管理的核心始终是让关键信息占据窗口内更大的权重而不是让窗口尽量装下更多内容。4. 上下文工程比提示词工程更底层的一层4.1 提示词工程与上下文工程是两码事现在很多人都在学提示词工程教你怎么把一句指令写得清晰、具体、带上角色设定和输出格式。但我想说提示词工程只是最后一公里它解决的是模型如何理解你的话上下文工程解决的是模型基于什么信息思考。基础信息错了提示词再漂亮也是空中楼阁。你可以把这两个概念放在一起对比提示词工程决定模型如何理解指令上下文工程决定模型看见哪些事实。假设你要让AI重构一个支付模块提示词你写得多花哨都不重要关键是上下文里必须包含当前支付模块的完整代码、依赖关系和业务约束。如果这些信息没有进入上下文——或者进入的是过时的版本——那么再好的提示词也只能在一个错误的基础上做优化。4.2 上下文工程四要素选、排、量、清做了这么多年的AI编程助手使用和团队推广我把上下文工程总结成四个要素选、排、量、清。选决定哪些内容进入上下文。用工具提供的文件引用功能精确指定Cursor的File、Copilot的#file而不是把整个仓库交给它自动检索。我见过很多人喜欢把当前打开的所有文件自动加入上下文看起来方便实际上副作用很大——你打开的文件不一定都和当前任务相关。排决定内容在上下文中的顺序。还记得Lost in the middle吗关键信息尽量放在对话的开头或结尾。我的习惯是任务描述放最开头具体的参考代码放后面把你最终要输出什么再放一段在提问之前。这样模型在注意力分配上更容易抓住重点。量控制总token的使用率。我给自己立了一个规矩一个会话里让上下文使用率尽量维持在70%以下。超过这个阈值检索工具就不能可靠地把新内容拼进窗口AI的行为会变得极其不稳定。遇到WorkBuddy上下文已使用满了这类提示时立即清理或新开会话而不是硬着头皮继续。清定期清理和压缩。AI编程助手普遍提供的/compact、自动摘要、会话重置功能本质上都是对上下文的有损压缩。压缩之后必然丢失一些细节所以压缩前把关键决策记录到自己的笔记里别指望AI帮你记住。4.3 上下文数据流一个会话的生命周期讨论上下文工程得清楚上下文在工具里是怎么流动的。我画过一张自己的理解图这里用文字描述给你你的指令先进入系统工具根据指令去检索相关文件和索引检索结果与对话历史组装成完整上下文模型基于这份上下文做推理生成回答回答又作为下一轮对话的历史重新进入上下文。如此循环直到会话结束。这个链条上每一个环节都可能引入噪音。检索环节可能抓到无关文件组装环节可能因窗口空间不足而截断旧内容对话历史环节可能累积重复指令。之前有同行提出了上下文harness第四层的概念——大意是上下文工程像层层叠加的装备底层是模型能力往上依次是检索策略、提示词封装、最外层是用户的使用习惯。工具能帮你封装前几层但最后一层始终掌握在你自己手里。5. 把变笨的AI救回来的实操清单5.1 会话管理新任务必须开新会话这句话我在团队里说了无数遍但一直到今天还是有人做不到。很多人有一种一个会话用到底的心理觉得新开会话重新沟通浪费时间。但他们没有意识到在同一个会话里持续对话时间成本并没有消失只是转移到了纠正AI因为上下文污染犯下的错上面。我的建议是每开始一个独立任务——不管它看起来和之前的任务有多接近——都新建一个会话。可能你需要花30秒把关键信息重新描述一遍但与花5分钟纠正AI的错误决策相比这30秒非常划算。会话切换时怎么把关键信息迁移过去我的做法是写一份交接文档包含三项内容目标、约束、当前进度。目标用一句话说清楚要做什么约束列出不能踩的坑当前进度说明已经改了哪些文件、总体思路是什么。这份文档本身也可以沉淀成项目的参考资料。5.2 精准投喂用diff、索引进工具代替整个文件精准投喂是我最想让你记住的实操技巧。AI编程助手有很强的代码分析能力但它并不知道你当前的关注点在哪里。你需要通过投喂的内容告诉它看这里别管其他。具体操作上我有几个固定套路。第一能用git diff就不用完整文件。改了几行代码就把这几行的diff贴给它而不是把整个三百行的文件丢过去。第二项目级任务先让AI读文件列表和README等它提出我需要看xxx文件之后再把那个文件具体的内容给它。这个过程模拟的是你带一个新人入职先给他看部门组织架构再按需打开具体文档而不是第一天就把整柜子档案全摊在他面前。第三利用工具自带的引用语法Cursor用FileCopilot用#fileClaude Code直接给路径让AI自己去读需要的内容。5.3 主动压缩与摘要让工具帮你瘦身现在主流AI编程助手都提供了压缩上下文的功能。Claude Code里有/compact可以自动把长对话压缩成摘要Cursor有对话压缩Copilot可以重启主题。但我提醒你这类压缩是有损的——它可能丢掉细粒度的代码细节、一些你当时没明确强调但实际很重要的上下文信息。所以我的建议是压缩前先备份关键信息。如果你正在进行一次重要的架构调整把当前状态、已经改动的文件清单、下一步计划单独用一段文字记录下来再执行压缩。否则压缩之后AI记不清你改到了哪里又要重新问一遍反而浪费更多时间。另外如果工具提示上下文已满之类的警告优先考虑新开会话交接文档而不是依赖压缩因为压缩的摘要质量直接取决于模型对对话的理解程度聊得太乱的时候压缩出来的摘要也很乱。5.4 用结构化指令对冲上下文漂移最后一条是关于矛盾指令的处理。AI编程助手的上下文越长越容易发生早期指令和后期指令的冲突。防止冲突的办法不是少说而是把关键决策做成可引用的存档。我现在做项目时的固定动作是在项目根目录放一个DECISIONS.md文件每次和AI助手确认一个重要决策就把它写进去。然后跟AI约定对话开始时先读这个文件后续所有建议必须符合里面的决策。这样一来即使上下文里出现了矛盾指令模型也会优先遵循这个权威文件。这个方法帮我解决了很多次上下文漂移问题比在对话里反复强调我之前不是说了...高效得多。6. 主流编程助手的上下文管理差异对比6.1 几大工具的上下文策略既然聊的是AI编程助手市面上主流工具各自怎么处理上下文自然要拉出来对比一下。我实际用过Cursor、GitHub Copilot、Windsurf、Trae和Claude Code谈一下它们各自的脾气。Cursor交互式对话做得最好可以用File精确控制哪些文件进入上下文。它的优点是灵活缺点是灵活意味着你得自己负责上下文卫生。如果你不手动管理它会持续把当前打开的文件和最近对话一起堆积进窗口。GitHub Copilot和编辑器深度绑定可以用workspace检索整个仓库。有自动索引能力适合回答这个项目哪里用了xxx这类横跨多个文件的问题。但它在多轮对话中的上下文管理相对不透明经常出现你只问一个函数它却检索了一大堆相关文件的情况。Windsurf主打Cascade上下文感知能力强在代码补全和局部修改场景下体验很流畅。但我个人感觉它的上下文窗口信息展示不够透明你很难判断它当前看见了哪些文件出问题时排查成本较高。Trae国产AI IDE对中文需求理解友好适合国内团队快速上手。它在上下文管理上相对简化项目级上下文的效果尚可但如果你和它进行非常长几十轮的对话同样会遇到注意力稀释的问题。Claude Code终端CLI工具最大的卖点是1M上下文窗口和强大的会话管理命令/clear、/compact、--resume。我自己在Claude Code里的使用体验是长会话能力确实强但它更偏技术极客的工具对命令行不熟悉的用户门槛略高。6.2 工具特性与使用习惯的匹配做完了工具对比我想强调一点工具之间没有绝对的优劣关键是使用习惯要适配工具的设计逻辑。如果你习惯了打开一个会话聊到底的用法那么任何工具最终都会在你手里变得越用越笨——不是工具变笨而是你始终没有给它一个干净的上下文。反过来如果你养成了新任务新会话、关键信息文件化、检索优先于堆量这三个习惯即使工具本身的上下文管理不是最先进的那档也一样能跑出稳定的效果。说到底AI编程助手是一个放大器你的工程素养高它帮你放大效率你的使用习惯差它帮你放大混乱。我现在日常的工作流已经固定为Claude Code处理大型代码库分析和批量重构Cursor做交互式代码编辑和模块设计Copilot补全日常小改动。每个任务的开头30秒一定是想清楚这次我要让它看见什么然后才开始对话。这个习惯帮我省下了大量踩坑的时间也让我真正体会到了上下文工程这四个字的分量。