一句话总结
上传文档，先要结构大纲，再逐节深入、要页码引用，接着检查”少了什么”，手工验证 3-5 条引语，最后才让它写执行摘要。200 页文档整圈跑下来 30-60 分钟，得到一份你能拿到会上撑得住的摘要。最大的坑就是第一句话直接问”这份 200 页 PDF 给我 5 条总结”：你会拿到一篇自信、像样、却悄悄漏掉关键那节的答案。
这篇讲什么
一套可复用的工作流，用 Claude 处理大约 100-500 页的长文档，不拆分、不误转述、不编出根本不存在的章节。Claude 的长 context 在这类文档上确实很强——但要靠结构化提问。这篇把结构和具体 prompt 都给你。
本文涉及的工具 / 概念：
- Claude（Opus 4.7 / Sonnet 4.6）：Anthropic 的模型。在 claude.ai 聊天界面，付费 plan 用这两个模型是 500K token 上下文窗口；完整的 1M token 窗口要走 Claude Code 或 API（截至 2026 年 6 月）。Sonnet 4.6 是更快的主力；Opus 4.7 更稳，适合读高风险文档。
- 结构大纲 pass：任何内容解读之前先要文档结构。这是让答案落地最关键的一步。
- 逐节深入：一次问一节并要页码引用，而不是对全文一个大问题。这能对抗 2026 年仍困扰所有长上下文模型的”中段丢信息”问题。
这篇适合谁看
研究、分析、法律从业者、学生，以及任何以读长 PDF 为生的人。如果你被 LLM “总结”漏掉最关键那段坑过，这篇尤其值。
什么时候适合用
读报告、合同、论文、笔录、技术规范、监管申报，或任何超过 50 页的东西。多文档比对、且每份本身就长时，也很有用。
你实际是在哪些限制里干活（2026 年 6 月）
先搞清楚盒子有多大，再往里装。下面是截至 2026 年 6 月 claude.ai 消费端的限制；API 端更宽。
| 项目 | claude.ai 聊天（Pro/Max） | Claude Code / API |
|---|---|---|
| 上下文窗口（Sonnet 4.6 / Opus 4.7） | 500K token | 1M token |
| 单文件最大体积 | 30 MB | 单请求 32 MB / 更大走 Files API |
| 单次对话文件数 | 20 | 不适用（Project：存储几乎无上限） |
| 单份 PDF 页数（完整视觉解析） | 最好控制在约 100 页内 | 单请求最多 600 页 |
| 每页 PDF 的 token | 约 1,500-3,000（每页同时按文本和图像解析） | 同上 |
两个实际后果。第一，一份密集的 100 页 PDF，一旦每页都渲染成图像，可能吃掉 15 万到 30 万 token，所以一份大合同加几份参考文件，会比页数看起来更快地塞满 500K 窗口。第二，Project 不会把整个知识库一次塞进上下文——Claude 是在你提问时按需检索相关片段，所以钉页码的问题永远比”把全部总结一遍”更靠谱。（来源：Anthropic PDF 支持文档。）
开始前准备
- 确认文档有真正的文本层（PDF reader 里能选中文字）。重扫描靠 OCR，会带噪声。
- 旁边另开一份独立副本核查。第一遍什么都别信。
- 决定输出目标：执行摘要、分节表、引语清单，还是合规缺口分析。不同目标要不同 prompt。
- 留出 30-60 分钟。长文档不是 90 秒的活，别挤。
具体步骤
- 上传并改名。 把文件改成好记的名字（
acme-vendor-msa-2026.pdf），方便后续消息里 Claude 按名引用。要反复用的文档，放进 Project，别用一次性对话。 - 先要结构大纲——先不要内容：
列出本文每个一级和二级章节及对应页码区间。先不要总结内容。强制先盘点再解读，给你一张可以逐节钉的地图。 - 逐节深入，要页码：
在第 4 节（第 23-41 页）列出每条编号义务，给原文措辞和页码。只对和目标相关的章节重复。 - 检查负空间。 问它”没有”什么：
一份供应商 MSA 通常会有的章节里，本文没有哪些？要具体。抓住你以为有的缺失条款。 - 手工验证。 至少核对 3 条引语 + 2 个数字对原文。任一处错了，先反推再继续——第一次幻觉没纠正后，准确率会持续下滑。
- 最后才要执行摘要， 必须在分节细节都核过之后：
现在写一页执行摘要，每条主张注明章节和页码。
一个实例，60 页服务协议：步骤 2 返回一个 11 节的大纲；你对第 4 节（费用）、第 7 节（终止）、第 9 节（责任）跑步骤 3-4；负空间检查发现没有数据泄露通知条款；你手工核对责任上限那句引语和付款条款数字；最后才要摘要。总耗时约 25 分钟。
为什么一节一节问，比一个大问题更准
长上下文模型在输入中段仍会丢信息。截至 2026 年，包括 Opus 4.7 在内的前沿模型，单针检索在 1M token 下约 90% 准确率，但多事实（“多针”）召回明显更低，处于 30%-70% 位置深度的信息相比开头结尾会有可测的 5-15 个点的检索下降。可靠做多事实活儿的实际有效上下文大致在 20 万到 40 万 token 区间，哪怕窗口是 500K 或 1M。把每个问题钉到具体章节和页码区间，能让目标贴近模型的注意力，绕开那段松软的中间。失败模式细节见 Claude 长上下文不稳定。
完成后检查
- 每条主张都有页或节标注。重要文档没例外。
- 至少手工验证过 3 条引用。挑最关键的几条。
- Claude 能说出”没有”什么（防止幻觉式覆盖的 sanity check）。
- 执行摘要的每条主张能追到具体章节，而不是”本文讨论了”这种泛话。
- 数字主张手算一行合计。LLM 对算术最自信最容易错。
怎么复用这套流程
- 把这套 prompt 序列存成模板（“长 PDF 入档 v3”）。
- 反复出现的文档类型（合同、论文、申报），按类型加专门问题，并维护一份”常忘问的”清单——希望当初问了的。每次 session 补一条。
- 要反复审同一批文档，就放进 Project，省去重新上传；Claude 会按每次提问检索相关页。
- 每季度用一份已知好文档复测；模型行为和限制都在演进。
FAQ
- Claude 的”长”是多长？：截至 2026 年 6 月，claude.ai 聊天里付费 plan 用 Sonnet 4.6 / Opus 4.7 是 500K token 窗口；Claude Code 和 API 能到 1M token。500K 粗略相当于 1,000-1,500 页纯散文，但密集 PDF 按页图解析会更快塞满。超过实际上限就按章节拆，不要按原始页数拆。
- 长 context 中段会掉吗？：会。单针召回在 1M token 下约 90%，但多事实召回会降，中段信息掉 5-15 个点（Claude 长上下文不稳定）。逐节深入能缓解。
- 一节一节问，还是一次性？：求准确就一节一节。一次性只在你已经熟悉文档、只是要回顾时用。
- 扫描 PDF 怎么办？：每页同时按文本和图像处理，所以干净扫描一般没问题，但重扫或倾斜的扫描会掉准确率。抽查 OCR，并让 Claude 把可疑那页以纯文本输出。
- 能一次比较两份长文档吗？：能，但 drift 更大。给每份明确角色（“文件 1 = 旧合同，文件 2 = 新红线稿”），并逐节比对，而不是做一个全局 diff。
- 怎么留长文档给以后用？：放进 Project（见 Claude 文件）。Project 持久存文件，并在提问时检索相关章节。
容易踩的坑
- “200 页给我 5 条总结”——拿到自信、似是而非、部分错的总结。
- 不要 citation——每条主张都同样可信，也同样可疑。
- 不复核数字——LLM 最自信的地方往往最容易错。
- 把 50 万 token 一次喂进去就提一个问题，以为它能精确覆盖文档中段——不把问题钉到具体小节，中段召回会悄悄掉（Claude 长上下文不稳定）。
- 把 Claude 的”找不到”当定论——有时是它漏了；用章节锚点换种说法再问。
- 在执行摘要这步就停，不回去对分节细节验证 citation。