我一直觉得很多人用AI大模型应用时遇到的很多“翻车现场”其实都不是模型不行而是不会管理上下文。这一期我想认真聊聊这个话题上下文的规划、压缩和交接。适用的人很广——用AI做长文档分析、项目策划、代码重构、论文润色或者说任何需要AI“记住”大量背景再做输出的场景都会从里面受益。如果你只是偶尔问一句“今天天气怎么样”那这篇对你的意义不大但只要你的对话超过十几轮或者涉及上万字的素材上下文管理就是决定你效率上限的关键。我先说个反直觉的结论AI大模型的上下文窗口再大也是不够用的。它不是你手机里那个越堆越满、但总能翻到的聊天记录它更像一块每次回复都要重新擦写的白板。白板就这么大你往上面写的东西越多真正被模型“看清楚”的内容反而越少。很多人觉得“窗口越大越好”但真实情况要复杂得多这也是为什么你会遇到越聊越笨、越聊越跑偏、AI突然像失忆了的大模型应用。1. 为什么对话一长AI就开始“装疯卖傻”1.1 先搞清楚“上下文”是什么AI每轮都在重新读一遍我知道“上下文窗口”这个词已经被说烂了但大部分人是真没理解它到底意味着什么。简单来说你每次给AI发消息它并不是在你上一轮回答的基础上“接话”——它是把你和它的所有历史对话加上你这一轮新问的问题全部拼接成一段超长文本然后一次性“吞”进去再生成回答。这个过程可以类比成一个速记员每次你要他发言他都要把前面几小时会议记录从头到尾飞快扫一遍再组织语言。如果把记录都摆在桌上一次能扫完那没问题可记录越堆越多、桌子放不下他就只能把最旧的那部分推到地上或者从中间草草跳着看。大模型应用的运作方式基本就是这个样子。所以“上下文”不是AI的“记忆”而是每轮对话时临时加载的数据。上下文窗口就是这张白板的大小。像市面上主流的模型窗口有128K、200K甚至更大的看起来很大但你丢一篇几百页的技术文档进去就占掉大半了根本没有你想象的那么从容。1.2 窗口溢出的真实过程不是突然断片是被“挤”出窗外很多人以为上下文溢出会弹个“内存不足”的提示——不好意思多半不会。大多数大模型应用在窗口被填满时会静默地丢掉最早的内容或者做非常粗放的压缩。你感觉不到它丢了只有结果变差了。我自己实测过一段很长的产品需求迭代对话。前10轮AI对需求的把握很准能准确引用我最初提的约束条件到第15轮它开始偶尔忘记某个小众但关键的规则到了第28轮它干脆开始凭空编造一种“符合逻辑但完全不在原需求里”的技术方案。我不是换模型也不是改提示词就是同一个会话一直聊。后来我把整个过程记录下来做对比才确定问题就出在对话长度上——这个现象在技术圈叫“中段遗忘”或“长上下文退化”本质有两层第一层是硬溢出早期内容被踢出窗口模型是真的读不到了。第二层是注意力稀释窗口还没满但内容太多太杂模型处理不过来了等于一张白板上写了密密麻麻几千个小字你让谁来找关键信息都要花好几倍精力还容易看错。这也是为什么你会发现同样一句“请严格按照开头说的XX规则执行”放在对话第一轮非常管用到了第30轮再说AI就当耳旁风。不是它叛逆是那条规则早就被挤到白板边缘甚至已经被擦掉了。1.3 常见的“上下文浪费”习惯排名想解决上下文空间被浪费的问题先得知道自己是怎么浪费的。我根据实际观察和身边朋友的案例整理了一个“浪费榜”浪费行为具体表现典型损失重复粘贴每轮都把完整需求原样再发一遍生怕AI忘了几千token被同一份内容反复占用围绕无关信息反复确认“这句话对吗”“那上句话呢”翻来覆去大量无效指令挤占关键位置不分割任务一会在写文案一会要它读PDF一会让它写代码不同任务的素材互相干扰注意力稀碎从不清理历史一个会话从早聊到晚什么都在里面早期重要背景被静默挤出窗口用AI当复读机已经聊完的结论隔几轮又让它重述一遍对话越来越长效率越来越低我并不是说这些行为绝对不能有而是说要分清轻重。真正高效的大模型应用使用者都会在“输入前”就把上下文当成一种昂贵的资源来规划。注意不是节省——是规划。对话省钱省不出效率关键是把每一寸白板都留给真正重要的内容。2. 输入侧管理在让AI读之前先把内容“洗”干净2.1 给每一次任务定边界一个会话只专注一件事我观察到的第一类高手操作是拆会话。普通人喜欢把所有事情塞进同一个对话里“帮我写个方案顺便把里面提到的数据整理成表再帮我起个标题”——这三个任务的素材各不相同混合在一个上下文里AI难以兼顾互相干扰。我的做法是动手之前先问自己一句“这个任务依赖哪些素材输出什么成果”。然后按这个标准拆会话。举个实际例子。假设我要用AI协助整理一份行业调研报告。拆分会话之前我可能是这样做的在同一个对话里先让它总结PDF里的内容又让它列举三家竞品再让它写一页PPT大纲。结果是什么呢三个任务的关键信息在同一个窗口里挤成一团后面的输出总感觉“两边都沾一点”。拆完之后是这样的会话A“从PDF里提取市场规模、增长率、主要玩家” —— 输出是结构化数据会话B“基于会话A的数据列出三家竞品的差异化对比” —— 输入是数据表不是PDF会话C“基于前两个会话的产物写PPT大纲” —— 输入是结构化资料输出是骨架每个会话只处理一个任务上下文干净AI能用在正事上的“注意力”就多得多。多花一分钟拆任务能省下大半个小时在混乱上下文里来回纠错。2.2 制作“项目资料卡”把背景信息做成结构化片段第二个习惯是我个人强烈推荐的项目资料卡。大多数人跟AI合作时背景信息都是散落在对话里的——这次想起来提一句下次又补充一点。这会让AI始终处在一个“用半套信息做判断”的状态而且它自己不知道缺了多少信息只能瞎猜。资料卡长什么样我每次的新会话开头都会放一个标准模板类似这样【项目背景】我们在做一个面向中小团队的项目管理工具当前阶段是MVP验证。 【核心目标】本周要生成一份给投资人看的原型演示说明。 【已知约束】不能使用SaaS服务需要在本地运行团队只有5人没有专职运维。 【术语表】MVP最小可行产品本地运行用户在自己机器上部署不考虑云端。 【当前状态】已经完成了需求调研但还没有确定最终的信息架构。 【待解决问题】希望AI帮我梳理原型演示的讲述主线。你发现没有这份资料卡本质上就是一次“上下文预加载”。它把AI需要用到的背景知识在对话开始之前就整整齐齐地放进白板里AI不用问东问西也不会基于错误的假设乱发挥。实测下来放资料卡和不放资料卡效果差距非常大。不放的时候AI开头几步经常反问一些你早就知道答案的基础问题你还得停下来纠正放了之后AI的第一次输出就进入正题而且越到后面越稳定。资料卡还可以复用——项目不结束这一套卡就能在多轮会话之间来回贴。这就是所谓的“上下文复用”比每次重新口述背景高好几个段位。2.3 预设输出模板把AI的“发挥空间”关小第三个输入侧技巧是给AI限定输出骨架。很多人只关注怎么把背景喂进去忽略了输出本身也在占用上下文——AI输出越多下一轮它的上下文就越臃肿而且它自己生成的不相关内容反过来会污染接下来的判断。我常用的一种做法是在指令里直接给出输出模板。请按下面的结构输出 1. 结论不超过3句话 2. 关键依据列出3-5个要点每个要点用一句话说明来自哪份资料 3. 待确认事项如果没有写“无”别小看这个模板它的作用有三个第一压缩输出长度省下宝贵的token空间第二逼AI把信息密度提上来而不是用一堆“首先……其次……最后……”的套话填充第三让AI知道“我需要的只是这些其他别啰嗦”大幅减少无关内容对上下文的污染。这个技巧说白了就是给AI关小一点“发挥”的空间。它不是什么魔法但它配合资料卡一起用很多长任务的完成质量会明显上一个台阶。3. 对话进行中动态维护上下文的三个动作3.1 摘要接力法当对话超过一定轮数先把旧的“蒸干”再继续就算你在输入侧做得再好对话总会有拉长的时候。比如要AI帮你逐段评审一份长方案或者把一个逻辑链条一环节一环节地推演下去。这种场景下会话长度很难降下来这时候我们就需要“摘要接力”。这个方法其实特别朴素当对话到一个里程碑节点时先让AI把已经讨论过的内容压缩成一份简短摘要然后以这份摘要为起点开启新会话。操作分三步在当前会话里对AI说“请把我们刚才讨论中已经确定的结论、你给出的建议、还悬而未决的事项整理成一份不超过500字的交接摘要用要点形式。”把这份摘要复制出来另存到一个临时文档里顺手把明显冗余的修饰词删掉只保留干货。注意这一步最好人工过一眼因为AI在总结自产内容时也会偶尔漏掉关键点。打开新会话贴上摘要再加上下一步任务比如“基于这份摘要我们继续讨论XX环节。”这就像开了一个新的工作台——白板是干净的上面只有最核心的结论和新任务。AI不用再背着几十轮的历史包衭干活注意力全部集中在你真正需要它处理的部分。如果一次“蒸干”还不够再来一次多蒸几次上下文始终能保持在一个非常高效的长度。我自己用AI写长文的时候几乎每写完一个大章节就做一次“摘要接力”也因此很少遇到长对话越聊越笨的情况。拿“蒸干”这个词来形容是因为你留下的不是水是浓缩后的精华。3.2 引用锚点法让AI只改某块内容而不是全篇重读很多时候我们并没有在“对话”只是在有一搭没一搭地修同一份材料。“第三段那个说法我觉得有点问题”“第五点里的数据再查查”“开头那里帮我换个语气”——这种诉求如果不加控制地一股脑发出去AI会为了响应你反复扫描整份材料上下文压力瞬间飙升。我建议的做法是给材料的内容块编号让AI做“定点修订”。比如材料输出之后你自己加上段落编号或者要求AI在输出时就自带编号【段落1】项目背景与痛点 【段落2】现有方案对比 【段落3】我们的差异化优势然后在后续指令里永远使用编号指路“请只修订【段落3】其他段落保持不动。修订方向把‘优势’的描述从3点扩展到5点。”这样做有两个好处。第一AI不需要一遍遍地重读整份材料上下文里反复出现的全文扫描少了很多第二AI的注意力被强制聚焦在你指定的位置上它就不容易把那些已经定稿的段落顺手改得面目全非。你体验过那种“我只是让它改第三段结果它把第五段也重写了”的现场后就会知道引用锚点这个动作有多关键。顺便说一句如果材料特别长比如超过几十页我更推荐把每个章节的内容单独拆开分别开不同的会话去处理最后再合并。因为到了这种规模就算AI硬撑着把全部内容读进去注意力稀释也足以影响输出质量。3.3 主动“换页”什么时候必须开新会话而不是硬撑很多人的使用习惯是一个对话尽量不打断从头聊到尾觉得“断了”就浪费了。但实际上适时开新会话不是浪费是在给下一段工作腾一张干净的白板。我自己判断“要不要开新会话”主要看三个信号任务阶段已经完成比如方案已经写完初稿接下来是全新的修订任务那就开新会话带上初稿作为附件或贴入要点即可。对话轮数超过25到30轮不管我觉得聊得有多顺都要考虑做一次摘要交接因为注意力稀释大概率已经在悄悄发生了。感觉AI开始“偷懒”比如它反复说“正如之前提到的”却又没有真正引用上下文里的关键信息或者答非所问开始泛泛而谈。这种情况下硬聊下去只会越来越差赶紧开新会话反而能救回来。我把这个动作比作“换页”——你有再长的笔记本也不能永远写在一页上。该翻页就翻页上一页的内容用摘要或链接的方式带到下一页保持每一页的信息密度和清晰度。开新会话之前强烈建议顺手做一份“交接单”。交接单是我的习惯叫法它不复杂任务进度、已确定事项、待解决事项、下一步计划最多几百个字。把交接单贴进新会话的第一条消息然后开始新任务。就是这几分钟的整理时间能让每个新会话都从“高起点”出发而不是从“我记得……”这种模糊记忆里重新开始。4. 进阶用法用多AI协作把上下文压力分散掉4.1 为什么单模型全程一个人干活不如分工配合前面讲的都是“一个AI、一个会话”内部的上下文管理。到了进阶阶段我开始建议大家换一种思路别指望一个AI从头到尾全包让多个AI各管一段。这也是现在AI Agent类应用比较核心的底层逻辑。关于“多AI协作”这件事我是怎么理解的其实和团队管理是一样的道理。你让一个团队成员既当产品经理又当UI设计又当测试又要负责写代码他的工作台会被各种上下文塞满很快就开始丢三落四、决策打折。但如果分工开规划模型的上下文里只有目标和约束执行模型的上下文里只有手头素材审查模型的上下文里只有交付标准那么每个模型的负担都很轻反而能做得更稳。落实到实际操作哪怕你不用任何Agent编排框架靠人工也能做出“轻量版多AI协作”规划AI只用来把大任务拆解成小任务、定优先级、写验收标准。它的上下文干干净净专注做思想工作。执行AI拿到规划AI拆好的任务清单一次只做其中一个子任务。审查AI把执行AI的产出拿过来用一套固定的检查标准去揪毛病。我身边有人可能觉得这样“绕了远路”但从整体效果看两个AI各自在自己的小上下文里干活比一个AI在一个大上下文里包揽所有质量要稳得多出错率也明显下降。4.2 上下文外置让文档当“共享硬盘”AI只当“计算单元”多AI协作之后有一个非常关键的配套动作把上下文外置到文件系统里。换句话说别让信息只存在单个AI的对话记录里要让它“落盘”变成可以随时取用的文档。为什么强调这个因为对话是线性的、私有的换会话就消失而文件是结构化的、可共享的。你把中间产物需求说明、数据表、方案初稿、检查清单单独存成文档哪个AI需要就对它说“请读取这个文件”它的上下文立刻被精准填充而不是把整个聊天历史一股脑带过去。我在碰到需要搭个轻量多Agent流程的场景时会考虑用Dify这类编排工具。它的思路其实和我上面说的“文档轴心”完全一致你设计每个节点的输入来自哪个文件或哪个前置模型输出节点之间通过清晰的产物流转而不是靠模型硬记。哪怕你不想上工具纯手动复制粘贴只要你坚持“把中间产物落在文档里而不是落在对方的记忆里”效果也会好很多。领会到这一步你就会明白上下文不一定是非要塞给AI的它可以“外包”给文件和流程。AI只是计算单元文档才是共享硬盘。4.3 提示词片段化做一个“补丁库”随取随用最后再分享一个我自己非常依赖的习惯把反复使用的提示词片段沉淀成“补丁库”。所谓片段不是那种花里胡哨的大段模板而是高价值的小指令贴进上下文就能立刻生效。比如我常用的几类“请指出你回答中所有仍然存疑的假设不要自己默默补全。”“每次引用原文时标注来源段落编号无法标注时明确说是你自己的推断。”“如果信息前后矛盾直接列出矛盾点并问我不要自行选择一边。”“输出时删除所有客套话、过渡句只保留实质内容。”这些片段每一条都很短但它们的价值在于你不需要每次都重新组织语言只要从自己的“补丁库”里抽一条贴进去就能有效引导AI的注意力减少它在无意义内容上的开销。久而久之你就会发现自己对同一个模型的应用能力比别人高出一截——因为你的上下文里每一寸都被你用更高质量的指令占据了。5. 一次真实的“AI变笨”排查全过程5.1 完整复现那个长对话是怎么一步步崩掉的理论讲了不少我拿一个自己踩过的真实案例来复盘整个过程。上个月我要用AI整理一份访谈素材大概来自十个受访者的记录合计两三万字。我当时的做法就是“典型反面教材”把所有素材一次性贴进同一个对话里然后开始连续提问比如“受访者A对预算的主要顾虑是什么”“受访者B提到的团队协作问题和A有哪些异同”“把所有人都提到的共性问题汇总成表”。前10轮工作得挺顺利到了第18轮我要求“把受访者C和D对某个功能的态度做个对比”AI给的回答里把受访者C明确反对过的东西写成了“比较认可”。我当时以为是自己的提问方式有问题又重问了一遍结果它给出了另一个错误的答案。我又把这个错误答案复制回去纠正它它倒是道歉了紧接着在下一个问题里忘记了更多细节。整个会话走到第25轮左右AI已经表现得像个连基础信息都记不住的实习生大量输出模糊的“可能”“大概”“根据不同受访者的描述”甚至开始自己脑补一个受访者根本没提过的观点。5.2 逐步排查链路从提示词到token用量再到上下文重置遇到这种情况我的排查顺序是固定的分享给你参考第一步检查提示词本身。我把最近几轮的指令重新审了一遍确定问题不是出在我表达了错误的需求上。有些时候AI变笨其实是需求没讲清不能急于怪上下文。第二步尝试精简指令再问一次。我把问题改成极度口语化且带上原文引用的格式“请找受访者C原话看他怎么评价XX功能。”结果它给的回答还是有问题甚至引出来一句根本不存在的“原话”。这一刻我基本确定这已经超出单纯指令理解的问题了。第三步验证是不是上下文问题。我开了一个新会话只贴入受访者C和D那两段素材问完全一样的问题它秒答且正确。然后我又开了另一个新会话把全部素材以“文件 简短任务”的方式提交它也答对了。这就能确认出问题的不是模型能力也不是素材本身恰恰是那个又长又乱的历史会话把模型拖垮了。第四步看工具里的token情况。我用的工具能看到上下文使用量那会儿已经接近窗口上限了。早先的内容被塞在最边缘模型实际上已经“读不清”它们了。这进一步印证了判断。5.3 修复方案与可复用SOP修复方法其实没什么黑科技就是把前面章节说的那套东西反向用一遍分块把十份访谈素材按受访者分成十个独立任务每个任务单独开一个会话。结构化每个会话都以“资料卡”开头标注这份素材的核心主题、我需要提取的五类信息。合并每个会话的产物都是固定的“要点表”最后我拿这些要点表汇总再做一次总分析。处理完的结果非常理想——正确率一下就回来了而且每个会话都很短处理速度也快了很多。把这次经验沉淀成流程我现在处理任何长文档类任务都会走这套标准作业程序判断素材总量超过5000字的基本都建议分块别一股脑全塞。每个子任务定一个明确的输出物要点表、结论清单、摘要不做模糊的“帮我看看”。子任务产出的文档要及时落盘作为下一个任务输入而不是靠对话历史传递。遇到AI开始“睁眼说瞎话”的情况别在原对话框里反复纠正先重置上下文再检查是否恢复。我个人的习惯是碰到一个会话让我产生“是不是我蠢”的念头时第一反应先开个新会话试一遍。很多时候问题真的不在你而是在那个已经臃肿得无法消化的上下文里。踩过几次坑之后我现在宁可多花两分钟做一份交接单、拆一个会话也绝不在已经变长的对话里硬撑。这大概就是所谓“高效使用AI大模型应用”这件事里最值得养成的几个习惯之一吧。