Kimi K3 的 100 万上下文到底能干什么：整本 PDF、整个仓库一次读完
「100 万 token 上下文」这种参数很容易被当成跑分数字划过去。但它和大部分参数不一样——它不是让模型答得更准，而是让一整类以前做不了的事变成可以做。
换算一下：100 万 token 大约相当于 150 万汉字，或者一本 300 页的书 + 还有富余。DeepSeek 的 128K 大约是 20 万字，够读一份标书，不够读一摞。
分块检索（RAG）解决不了的那类问题
主流做法是把长文档切片、做向量检索、只把相关片段喂给模型。这套在「这份合同的付款条件是什么」这类问题上工作得很好——答案就在某一段里，检索出来就行。
它解决不了的是需要通篇视野的问题：
- 「这份文件里有没有自相矛盾的地方？」
- 「第 12 页的口径和第 240 页的附件对得上吗？」
- 「整份材料里，对乙方不利的条款一共有几条？」
- 「这半年的会议纪要里，哪个决定被推翻过、推翻了几次？」
这些问题的共同点是：你事先不知道答案藏在哪几段。检索按相似度取 top-k，天然会漏掉那些「单独看毫不起眼、只有放在一起才矛盾」的片段。
一次性全读进去就不会漏。这是 K3 百万上下文最实在的价值——不是读得更快，是读得全。
三个真实场景
1. 整本 PDF 不切片
招标文件、年报、论文、产品手册，几百页直接拖进对话框，然后问通篇性的问题。
比 RAG 方案强的地方在于，你可以连续追问：先让它列出所有风险条款，再指着第 3 条问「这条在附件里有没有被豁免」——模型手上一直握着全文，不用再检索一轮。
2. 整个代码仓库一次读完
中型项目的全部源码通常在几十万 token 量级，K3 装得下。这让「跨文件」的问题第一次变得可问：
- 「这个函数被哪些地方调用了，有没有漏改的？」
- 「配置项 X 在整个项目里的读取路径是什么？」
- 「这次重构有没有留下没清理的死代码？」
只喂单个文件的模型回答不了这些，因为答案本身就分布在文件之间。
3. 一堆零散材料的交叉比对
半年的周报、一整个项目的聊天记录、十几份供应商方案。把它们一起扔进去，问「这些方案里报价口径不一致的有哪些」——这种活人工做要一整天，而且人比模型更容易漏。
几个可以直接抄的提问模板
长文档提问有个常见失误：扔进去就问「总结一下」。模型给你一段四平八稳的摘要，等于白读。下面几个模板的共同点是指定视角：
找矛盾：通读全文，列出内容上互相矛盾或口径不一致的地方，每条标出出现在哪一部分、分别是怎么说的。
找风险：站在乙方角度通读这份合同，列出所有对乙方不利的条款，按严重程度排序，每条说明不利在哪。
找遗漏：这是我们项目的全部文档，对照需求列表检查有哪些需求在实现里找不到对应，列成表格。
找演变：按时间顺序梳理「XX 方案」这个议题的讨论过程，标出每次结论的变化和变化原因。
交叉比对：这里有 N 份方案，按报价、交付周期、付款条件三个维度做成对比表，口径不一致的地方单独标注。
什么时候别用 K3
百万上下文是有代价的：慢。K3 的生成速度约 35 tokens/s，首字延迟 4 秒上下；相比之下 DeepSeek V4.1 Flash 约 213 tokens/s、首字 1.3 秒，差着接近六倍。
所以：
- 随手问一句话、改个函数、解释一行报错 —— 用快模型，别用 K3。
- 文档就几页 —— 用快模型，百万窗口对你没有任何收益，只有等待。
- 需要连续来回几十轮的快速迭代 —— 快模型。
K3 是重型装备，不是日用工具。 一天当中真正该叫它出场的可能就一两次，但那一两次别人替不了。
实际的用法：和快模型配合
最顺手的流程是两者接力，而且在同一个对话窗口里完成：
- 用 K3 把长文档读完，让它输出结构化的结论（风险清单、对比表、问题列表）。
- 切到 DeepSeek 这类快模型，针对结论里的具体条目快速追问、改写、生成邮件或方案。
关键是第 2 步不需要重新交代背景——在不墨 AI 助手里换模型，上下文跟着走，前面 K3 读出来的结论下一个模型直接看得见。如果是在两个不同平台之间切换，这一步就得把结论复制粘贴一遍，长文档场景下这个动作本身就很痛。
站内的 Kimi K3 是官方满血版，国内直连访问，不需要自备 API Key，登录即送免费额度，日常签到可持续领取。文件解析支持 PDF、Word、Excel 和图片。