对话内容/文件长度超出了当前模型允许的最大上下文长度

你在长对话里贴了一份合同、一段代码或一整份日志，回车之后界面弹出一行字：对话内容或文件长度超出了当前模型允许的最大上下文长度。这篇不重复讲「上下文窗口是什么」，而是按「先判断卡在哪一层、再选对应动作」的顺序，把能立刻试的几种解法、各自的代价，以及什么情况下这些办法都不适用讲清楚。

你在一个已经聊了很久的窗口里，贴了一份合同、一段代码或者一整份日志，回车之后界面只回你一行字：对话内容或文件长度超出了当前模型允许的最大上下文长度。多数人第一反应是「模型太弱，换一个」，但报错原因经常跟换不换模型没关系。

这篇不讲上下文窗口的定义，按「先判断卡在哪一层、再选对应动作」的顺序，把能立刻试的几种解法、各自的代价，以及什么情况下这些办法根本不管用讲清楚。全程只给判断标准和可执行动作，具体数字请到站内页面核对你当下的情况。

先分清是三层里的哪一层被撑爆

报错文案往往只说「上下文超限」，但实际被撑爆的可能是三个不同的地方：单次提问的输入长度、整段对话累积的历史长度、以及附件被解析成 token 之后的量级。这三层的解法完全不同，先定位再动手，能省掉一半的无效尝试。

单次输入

这一条消息本身的正文加附件解析结果，跟聊了多久无关

历史累积

之前每一轮的提问和回答都被带上，越聊越重，最后连一句「继续」都发不出去

附件解析量

同一个文件，PDF、扫描图、纯文本被解析出的 token 量差别很大，格式本身也占位置

最容易被忽略的是历史累积这一类。很多人觉得自己只是问了一个很短的问题，为什么也报错，因为平台默认把整段历史一起发给了模型，你看到的短问题背后拖着几万字的旧对话。定位方法很简单：新开一个会话，只贴那一份文件或那一句长输入。如果还是报错，问题在单次输入或附件；如果顺利通过，问题就在历史累积。

动手前先估个量级，别盲试

判断够不够用，不需要精确到个位数。中文大致按一个字接近一个 token 来估，英文按词更低一些，这个粗估的误差不影响你做决策：如果粗估下来输入已经占掉上限的一大半，那基本就是超了或者快要超了。

需要更准的数字时，用站内的换算工具把字数换成 token，再和你在用的模型规格对一遍。模型参数、上下文规格这些信息不要靠记忆，容易记成隔壁家的，直接到 /models 查当时登记的数值。另外看一个信号：输入占掉上限大半时，留给模型输出的空间会很小，表现是答一半断掉、结论没写完，这种也算变相超限，别等它明确报错才处理。

解法一：把输入压小，而不是急着换模型

换模型是成本最高的一步，先试试把输入本身压小。压缩不是随便删字，是有优先级的：删无关段落最省事，其次是摘要化，最后是结构化抽取——只保留你要的字段和结论，丢掉叙事和铺垫。

1. 先删把跟问题无关的章节、免责声明、页眉页脚、重复段落整段去掉，这一步经常就够用了；验证方式是删完重发一次，看还报不报错。
2. 再摘要让模型或你自己把长文压成要点清单，只保留事实和结论；验证方式是拿摘要再问同一个问题，看答案质量有没有明显下滑。
3. 最后抽取长表格转成只留需要的几列几行，日志只留报错栈和关键函数，整仓代码用检索取相关片段而不是全量喂；验证方式是核对抽取结果是否覆盖了你真正要问的那部分。

多文件场景还有一招：按主题拆成多轮，每轮只问一件事，把这一轮的结论随手记到本地笔记里，下一轮只带结论不带原文。长代码贴报错栈加关键函数通常就够定位，整份工程上下文应该走检索，而不是靠一次性塞进去。

解法二：分段处理 + 结论串联

如果输入确实没法再压，就把它切开来做。标准流程是切片、逐片抽取要点、最后汇总。关键在切片方式：要按语义边界切，比如章节、函数、表格行，而不是按固定字数硬切，硬切最常见的后果是答案正好卡在切口上，两边各拿一半，谁都答不全。

• 切片之间留一点重叠，防止关键信息正好落在切口被截断
• 串联阶段只带上一轮的结论，不带原始正文，否则历史又会把上下文撑爆
• 每片都记下它对应的原文位置，汇总时方便回去核对
• 最终汇总可以再让模型把各片结论合并去重，但不要把原文重新拼回去
• 需要引用原文的场合，让结论带上片段编号，别贴整段原文

这套办法有一个明确的失效边界：需要跨全文做全局比较、去重或对齐的任务，分段会丢掉片与片之间的关联。合同条款前后引用、整本书里同一个概念的不同说法、多份文件之间的差异对齐，都属于这类，只能走长上下文模型或者检索方案，硬切反而更容易得出错结论。

解法三：换承载方式——换模型、换入口、换参数

压缩和分段都试过还不行，再考虑换承载方式。换模型之前先去 /models 核对目标模型的上下文规格，注意同一家不同档位的规格并不一致，名称相近的两个型号容量可能差一截。别凭印象选，去站内看当时登记的参数。

在线对话入口通常比 API 更早截断，同一模型换个调用方式可能就过得去。本地部署还要另看显存：上下文拉长不是免费的，它同时吃显存和速度，长上下文跑在显存吃紧的机器上很容易直接失败或者慢到不可用。调参方向上，把输出上限调小能给输入腾出空间，关掉那些会自动带上历史的功能也能立刻见效。

解法四：把历史管理当习惯，而不是等报错

上下文超限大部分时候是攒出来的，不是一次贴出来的。把历史管理变成习惯，比每次报错再救火省事得多。节奏上有个简单的判断标准：话题一换就新建会话，别在同一个窗口里从写代码聊到改文案再聊到查资料。

• 话题切换、任务阶段切换时新建会话，别指望窗口能一直撑
• 一段长任务做到一半，让模型先把已确认的结论固化成一页小结
• 新会话开头只贴这页小结加新问题，把旧原文留在旧会话里
• 重要中间结论存成本地文件，比在聊天记录里往上翻更可靠
• 团队协作时把小结放进共享文档，不要靠转述聊天内容

这里有个容易踩的坑：别指望「清空对话」按钮。很多界面只清显示、不清上下文，你以为清干净了，实际历史还在被带上，于是同一个报错反复出现。真正有效的是新建会话，从零开始。如果确认历史已经清空、输入也不长还是报错，那问题多半不在你这边，可以考虑附件解析或平台侧限制，换个文件格式试一次，比如用纯文本替换 PDF。

排查顺序清单：从最省事试到最费事

按固定顺序排查，能避免来回改了两个变量还不知道是谁解决的。每做完一步记下是否复现，这个记录本身就是证据。

1. 第一步：新开会话重试只带必要内容重发，判断是不是历史累积；这是成本最低的一步，别跳过。
2. 第二步：删附件和长历史去掉无关附件、免责声明、重复段落；验证方式是删完重发。
3. 第三步：摘要化或按语义切片把长文压成要点，或按章节、函数切片处理；记下每片的结论。
4. 第四步：换入口或换模型先去 /models 核对规格，再换对话入口或调用方式；这一步之后还没解决，就不是选择问题了。
5. 第五步：改架构上检索、做分片流水线，把「一次喂完」改成「按需取用」。

如果前四步都无效，而且你确认输入本身没有超，那大概率不是模型容量问题，而是附件解析出问题或平台侧限制。换文件格式再试一次，纯文本替换 PDF、去掉扫描图、把表格导出成文本，经常能绕过。这种情况下去站内的排查工具页面走一遍检测流程，比反复重发更高效。

这些办法什么时候不适用

上面所有技巧都有一个共同前提：你的任务允许对原文做加工。一旦这个前提不成立，技巧就都失效了，这不是方法问题，是容量门槛问题。

• 任务本身要求跨全文一致性，比如合同比对、全局去重、整本书问答；压缩和分段都会伤结论，正确动作是选够大的模型或上检索方案
• 合规或审计场景不允许对原文做摘要加工，只能整份喂，这时容量是硬门槛，不存在技巧解
• 需要严格可复现的批处理任务，人工切片的随机性会带来批次差异，应该把切片规则写成固定脚本并纳入版本管理
• 数据不能出内网、只能本地跑的场景，换模型这条路本身就受限，得先看本地硬件能不能支撑目标上下文

分不清是输入太大还是历史太重，后面的所有努力都是在猜。