文心一言的 128K 上下文：哪些长文档任务会被挡在门外

128K token，中文约合十万字量级。单份合同、单篇论文、单个模块的代码够用；整套投标文件、多篇文献综述、中型代码库不够，而且不是「勉强够」和「不够」的差别，是差一个数量级。

先把 128K 换算成能看懂的字数

token 和汉字的比例跟分词器有关，不同模型不能直接套。按常见的中文分词效率估：

实际能装多少，取决于你的文档长什么样。纯文字的小说最省 token；带大量表格、公式、代码的文件，一页占的 token 是纯文字的好几倍。同样是百页量级的 PDF，排版松的和密的，token 数能拉开明显差距。

还有一个常被忽略的点：上下文窗口要装的是「输入 + 输出 + 历史对话」。你留 12 万字喂文档，输出空间就被压到很小，长报告会写到一半断掉。

合同与招投标：单份够，整套不够

一份 50 页的工程合同，中文大约 3 万到 5 万字，128K 装得下，还能留出足够的输出空间做逐条风险标注。这类任务是 128K 最舒服的区间。

会卡住的是两件事。

一是「中间遗忘」。长上下文模型对开头和结尾的信息利用率高，中间部分容易被略过。审一份 5 万字的合同，如果关键条款在第三十几页，它的回答质量会明显下降。做法是把合同按章节切开，每段单独问，最后再让它汇总——切分比一次性喂更准。

二是多文件比对。招标文件 + 投标文件 + 评分办法三份放一起，很容易顶到上限。这类任务需要的是检索而不是长上下文：先把评分条款抽出来，再定向查找投标文件里的对应章节。

论文与研究报告：卡在参考文献

一篇硕士论文正文 3 万到 5 万字，加参考文献和附录能到 8 万到 10 万字。这个体量在 128K 的边缘，能做全文摘要，做不了精细的引用核对。

博士论文常见 10 万字以上，加上附录直接超。多篇论文做文献综述更不可能——五篇论文就是 25 万字起。

可以做的：单篇精读、章节改写、把方法和结论抽成结构化字段。 做不了的：跨文献对比、全库检索、需要引用页码的核对。

如果你要做的是文献管理而不是单篇理解，这属于检索增强的活，不是上下文窗口的活。硬塞进上下文，效果不如老老实实做分块索引。

代码库：差一个数量级

这是差距最明显的一类。

一个中型项目 10 万行代码，按每行 4 到 6 个 token 算，约 40 万到 60 万 token。128K 只够放两三千行，大概是一个模块或者几个文件的量。

所以「把整个仓库丢进去让它改 bug」在 128K 下不可能。可行的做法是：报错栈 + 相关文件 + 接口定义，控制在几百行内提问。这也是所有编程助手实际采用的策略——先检索，再喂给模型。

文心 5.5 Flash Preview 在 2026 年 11 月上线千帆时把上下文提到了 100 万 token，这个量级才接近「整仓理解」的门槛。但注意这是 API 侧的模型，C 端网页用的不是它。

不够用时的三条路

切片加工。 把文档按语义单元切开，逐块处理，再用一次汇总调用合并结论。成本可控，准确率通常比一次性长上下文更高，代价是要写切分逻辑。

检索增强。 文档量超过十份就上这条路。建索引、召回相关段落、再喂给模型。工程量大一些，但对「从一百份文件里找三条」这类任务，是唯一可行的方式。

换更长的窗口。 5.5 Flash 的 100 万 token 是一档，其他厂商也有同量级的产品。窗口翻八倍，价格通常不会同比例上涨，需要按实际用量核算。横向价格可以看 11 月大模型 API 价格表。

判断

一句话标准：要处理的总字数在十万以内，128K 够；超过十万，先想切分，别想窗口。

具体到你的场景，先数一下三样东西：文档总字数、需要它输出的字数、历史对话累积的长度。三个加起来超过十万字，就准备好切分方案再动手。

本地部署场景的显存与上下文关系是另一套算法，可以参考 Qwen3.8-27B 本地部署那篇里的容量估算方式，逻辑是通的：上下文越长，KV 缓存占用越大，跟参数量是两笔账。