夜雨聆风AI读文档怎么省Token？别再只换格式
大家好，我是老张。昨天线下碰面的时候，我提了一句：把文档转成 MD 或 TXT，就一定能省 Token。
回来以后，我越想越觉得这句话有歧义。
它把四件不同的事混在了一起：文件解析麻不麻烦、正文占多少输入 Token、页面图片会不会进入视觉模型，以及多轮对话会不会反复把全文送进去。
所以我又把 OpenAI、Microsoft、Anthropic、Google 和 Pandoc 的官方资料翻了一遍，专门把这件事拆开看。结果是：
把 DOCX 转成 Markdown，就能明显省 Token？
不一定。
真正该处理的，是无关文字、重复上下文和用不到的页面图像。读完这篇，你能按任务选 DOCX、MD、TXT 或 PDF，还能直接带走一张投喂前清单。
事实说明：本文依据 OpenAI、Microsoft、Anthropic、Google 和 Pandoc 的公开官方资料整理，不包含作者对同一文档的 Token 对照实测，也不提供节省比例。
先给结论：真正要看的是这4件事
判断一份文档费不费 Token，不要先问后缀，先问：
1. 最后进入模型的有效文字有多少？
2. 页面图像、图表或扫描页有没有一起进入？
3. 长文是整份直传，还是只检索当前问题相关的片段？
4. 多轮追问时，全文有没有被重复放进上下文？
MD 和 TXT 的优势，是格式简单、容易清理，也方便按章节拆开。它们并不会让正文变成零 Token。
PDF 的优势，是能保住页面、图表和布局。代价是某些平台会把每一页同时当成图像处理。
DOCX 则处在中间：原生文字一般能直接提取，但图片、批注、文本框、复杂表格是否能被完整读到，要看具体平台和入口。
先把最容易搞反的地方说清楚
很多人看到 Word 文档结构复杂，会以为 AI 必须先拆文件、做识别，再把每一页变成截图。
原生 DOCX 通常不是这么读的。
DOCX 底层是一个 ZIP 封装的 Open XML 文档，正文主要位于 word/document.xml。只要文字能正常选择和复制，程序通常可以直接提取，不需要先做 OCR，也不必逐页截图。
可以把 DOCX 想成一个“装零件的文件夹”：
• word/document.xml 主要放正文
• word/header*.xml、footer*.xml 放页眉页脚
• word/footnotes.xml 放脚注
• word/styles.xml 放样式
• word/media/ 里可能放图片
这也解释了为什么同一份 DOCX，在不同平台得到的结果可能不一样。有的平台只拿正文，有的平台会顺带拿页眉页脚和脚注，还有的平台会忽略内嵌图片。不是文件打不开，而是平台选择了哪些零件交给模型。
还有一个很实用的判断：如果文字可以选择、复制，通常属于原生文字；如果整页只能像照片一样框选，那才更像需要 OCR 的扫描件。
平台可能在后台解析或拆块，但那是产品自己的处理流程，不能写成 DOCX 天生要走的固定步骤。
更可能带来视觉输入的，反而是 PDF。
OpenAI 官方文档明确说明：通过 Responses API 输入 PDF 时，系统会同时提取文字和每一页的页面图像；输入 DOCX、PPTX、TXT、MD 等非 PDF 文档时，只提取文字，文件里的嵌入图片和图表不会进入模型上下文。
这条差异很重要。
只想总结正文时，把几十页内容做成视觉完整的 PDF，未必更省。页面图像同样可能消耗输入 Token。
但如果任务是看财报图表、核对盖章位置、理解流程图或保留页面布局，视觉信息本来就是证据。此时强行转成纯文本，成本可能低了，答案也可能残了。
格式要服从任务。
先分清：你用的是聊天产品，还是API
很多争论对不上，是因为大家说的根本不是同一个入口。
在 ChatGPT 网页或 App 里上传文件，走的是产品封装好的流程；通过 Responses API 传 input_file，走的是开发接口；把文件放进 File Search，又是检索流程。三者不能混成一句“AI 都这么读”。
OpenAI 的文件上传 FAQ 说明，普通文档主要使用文字检索，文档里的图片会被丢弃；特定 Enterprise PDF 场景支持视觉检索。
Claude API 当前的公开说明也有自己的边界：PDF 可以同时处理页面文字和图像；.txt、.csv、.md 可以作为纯文本 document block 使用；.docx、.xlsx 等二进制格式不能直接作为该 document block，需要先转成文本或 PDF。
Gemini 的文档理解说明则强调：PDF 可以保留文字、图片、图表和布局；非 PDF 文档按普通文本处理时，图表和格式上下文会丢失。
所以，看到别人说“我上传 DOCX，AI 没看见里面的图”，先别急着判断模型不行。更可能的问题是：那个入口原本就只提取文字。
Token到底花在了哪里
把账拆开后，会清楚很多。
第一层：文件解析
平台要先打开 DOCX、PDF 或表格，找到里面的内容。这个过程会消耗平台的计算资源，但它不一定等同于你账单里的模型输入 Token。
真正需要关注的，是解析后有多少内容被送进模型。
第二层：文字输入
标题、正文、表格文字、提示词和历史对话，只要进入上下文，都会被 Token 化。
Token 也不等于文件大小。一个带大量图片的 PDF 可能文件很大，但字不多；一个只有几百 KB 的 TXT 也可能装着十几万字。只拿 MB 判断费用，容易判断反。
不同模型的分词方式也可能不同，因此不能用“一个汉字固定等于几个 Token”这样的口号估算所有平台。API 用户最好直接看 usage，或使用平台提供的 Token 计数工具。
第三层：视觉输入和OCR
如果页面图片进入视觉模型，尺寸、清晰度、页面数量和视觉细节都可能影响输入。扫描 PDF 还可能多一道 OCR 或视觉识别。
OpenAI Responses API 对 PDF 提供 detail 控制页面图像处理精度；官方说明中，low 会使用更少的输入 Token，high 更适合密集图表、小字和复杂示意图。这里调的是 PDF 页面图像的细节，提取出来的文字仍然会包含在输入中。
第四层：拆块、重叠和重复上下文
知识库为了保证上下文连续，分块之间可能会有重叠。重叠有助于避免一句话被从中间切断，也会让一部分文字重复出现在索引块中。
多轮对话同样如此：上传一次不代表后面一定免费。如果系统在每一轮都把全文重新放回模型上下文，输入仍可能反复发生。
Markdown和TXT轻在哪里
Markdown 和 TXT 更轻，主要因为它们少了页眉页脚、复杂样式、文本框和页面视觉信息。
正文不会因此免费。
只要文字进入模型上下文，就会被切成 Token。Markdown 里的标题符号、列表符号和链接也会占少量 Token。
一份 3 万字的 DOCX，如果转成 Markdown 后仍完整保留 3 万字，正文的输入不会凭空消失。真正有用的动作是清理：删掉无关目录、重复版权声明、修订残留、无关附件，以及当前问题根本用不到的章节。
Markdown 和 TXT 也不是一回事：
• TXT 只保留纯文字，最简单，但标题、列表、表格和引用层级容易混在一起
• Markdown 会保留 # 标题、列表、引用、代码块和链接，通常更适合长文和知识库
• 如果原文结构复杂，宁可留一点必要的 Markdown 标记，也不要为了少几个符号把层级全抹掉
AI 读一篇有清晰标题的长文，通常比面对一整块没有层级的文字更容易定位内容。省 Token 不能以破坏可读性为代价。
所以，别只看文件后缀。
看 AI 最后读进去了什么。
按这4种任务选格式
1. 只做总结、改写或提炼观点
保留一份原始 DOCX，不要直接改唯一副本。
复制文件后，删除与任务无关的目录、页眉页脚、重复声明、空白页和附件，再转成清洁 Markdown 或 TXT。
文章有标题层级、列表和引用关系时，优先用 Markdown；只有连续正文时，TXT 也够用。长文先给目录，再提交当前问题需要的章节，不要默认每轮都塞全文。
2. 正文和图表都要看
不用在「全部转纯文本」和「整份 PDF」之间硬选。
可以把正文转成 Markdown，需要计算的表格单独转成 CSV，只把必须看的图表或页面另存为图片或 PDF。提示词里写清每个附件的用途，例如：正文事实以 Markdown 为准，图片只核对趋势、布局或盖章位置。
这样能减少无关页面进入视觉处理，也能保留真正影响判断的图。
3. 扫描合同或拍照书页
先做 OCR，再把识别结果整理成 Markdown 或 TXT。
金额、日期、人名和合同条款容易识别错。把有争议的局部原图留下，交给 AI 或人工核对，不必为了三处信息反复提交整本扫描 PDF。
4. 长文需要反复追问
这时最该换的是工作方式。
把资料放进 File Search 或 RAG 知识库，提问时只召回相关片段。文件名、章节、日期和版本号要写清，回答时要求标注依据来自哪个文件、哪一节。
OpenAI Retrieval 当前文档中的默认分块设置是每块 800 Token，相邻块重叠 400 Token。它是向量库索引的默认参数，不是 DOCX 的固定读取规则，也不能据此推算某种格式必然多花多少 Token。
拿到file_id，不等于后续免Token
file_id 解决的是文件上传和引用问题。
它可以避免客户端反复传输同一文件，减少带宽和部分延迟，但不能推出模型读取内容不计 Token。MD、TXT 和通过 file_id 引用的文字，只要进入模型上下文，仍会产生输入消耗。
可以把它理解成“云端取件码”：文件已经放在服务器上，下一次不用再从你的电脑上传一遍；但模型真要阅读时，仍然需要把相关内容放进自己的工作区。省的是传输，不是把阅读内容变没。
还要区分两件事：
• Files API 负责保存和引用文件
• File Search / Retrieval 负责建立索引，并在提问时取回相关片段
拿到 file_id，不代表文件已经自动建好知识库，也不代表后面每次调用都不会再产生输入。
API 场景应查看实际 usage，或在正式调用前使用 Token Counting API 计算完整输入。
文件大小也不是可靠的 Token 账单。一张高清扫描图可能字很少，纯文本文件可能字很多。两者的处理路径和成本来源都不同。
一套普通人也能照着做的流程
第一步：保留原件
先复制一份 DOCX 或 PDF，原件不要动。后面发现表格、脚注或图片丢了，还能回去核对。
第二步：写清楚任务
同一份报告，“总结观点”和“核对图表”需要的材料完全不同。先把任务写成一句话，例如：
只根据第三、四章，整理出5条行动建议，不需要分析图片和排版。
这句话能帮你判断哪些内容该留，哪些可以不交给 AI。
第三步：做一份清洁副本
在副本中删除当前任务用不到的目录、页眉页脚、重复免责声明、空白页、附件和无关章节。修订模式下的删除痕迹、批注和隐藏内容也要检查，避免把不准备外发的信息一起传出去。
如果资料涉及客户信息、手机号、合同金额、内部账号等敏感字段，先脱敏。省 Token 之前，先保证不把不该上传的数据交出去。
第四步：按内容拆格式
• 连续正文：TXT
• 有标题层级和列表：Markdown
• 需要筛选、排序、计算的表格：CSV 或 XLSX
• 必须看的图表、盖章页、扫描页：单独导出图片或 PDF
一份文件不必从头到尾只用一种格式。正文、表格和图片各走适合自己的通道，通常比整份 PDF 全部送入更清楚。
第五步：转换后抽查
至少检查以下位置：
• 标题层级有没有乱
• 表格行列有没有错位
• 脚注有没有丢
• 金额、日期和人名有没有变化
• 图片与图注还能不能对应
• 删除的修订内容有没有意外出现
转换成功只代表文件生成了，不代表信息完整。
第六步：长文按章节提交
先给 AI 目录，再给当前问题相关章节。让它明确告诉你缺哪一节、哪一页，而不是一缺信息就重新上传全文。
第七步：用结果反查原件
涉及金额、合同条款、政策日期和重要结论时，用原始 DOCX/PDF 再核一次。清洁文本负责提高效率，原件负责保真，二者不是互相替代。
转格式前，别丢了这些信息
DOCX 转 Markdown 时，复杂表格、文本框、批注、修订记录、脚注和图片关系都可能丢失。PDF 转纯文本时，页面布局和视觉证据也会消失。
Claude 的 PDF 支持会把每页作为图像，同时提供提取文字；Gemini 的 PDF 文档理解也保留视觉信息，而非 PDF 文档按普通文本处理时，图表和格式上下文可能丢失。
比较稳妥的办法是准备两层材料：
• 一层是给 AI 阅读的清洁文本
• 另一层是需要核对时才提供的原始文件或关键页面
不使用命令行，也可以先把需要的正文复制到纯文本编辑器，再按标题补成 Markdown。重点不是工具多高级，而是转换后必须抽查结构和关键数据。
如果真想比较，测试要这样做
很多“某格式能省一半”的结论不可靠，是因为测试条件根本不一样。
要比较 DOCX、Markdown 和 PDF，至少保持下面这些条件一致：
• 同一份原始内容
• 同一个模型和产品入口
• 同一条提示词
• 同样的对话历史
• 同样的输出要求
• 分别记录输入 Token、输出质量和信息遗漏
不要只比 Token 数，还要检查：PDF 的图表是否被正确理解，Markdown 的脚注是否丢失，复杂表格是否错位，最终花了多少人工时间返工。
如果 Markdown 少了一点输入，却让你重新整理半小时表格，这次优化就未必划算。
投喂前检查清单
下次上传文档前，逐项勾一遍：
• [ ] 这次任务真的需要看排版和图片吗？
• [ ] 能否删掉目录、页眉页脚、重复声明和无关附件？
• [ ] 只需正文时，是否已转成清洁 MD 或 TXT？
• [ ] 复杂表格是否应该单独转成 CSV 或 XLSX？
• [ ] 是否只保留了必须看的关键页或关键图？
• [ ] 长文是否按章节拆开，并带有目录、日期和版本号？
• [ ] 多轮问答是否该改用检索，避免每轮重传全文？
• [ ] 是否保留原始 DOCX 或 PDF，方便争议时核对？
• [ ] API 场景是否查看实际 usage 或使用 Token Counting API？
再把这段提示词一起发给 AI：
我会提供一份清理后的 Markdown 正文，以及少量必须核对的页面图片。请按以下规则处理： 1. 只读取与当前问题有关的章节，不要重复复述全文； 2. 正文事实以 Markdown 为准； 3. 页面图片只用于核对图表、布局或扫描内容； 4. 如果信息不足，请告诉我还需要哪一个章节或哪一页，不要要求我重新上传整份文件； 5. 回答时标注依据的章节标题或文件名； 6. 无法确认的信息标为「待确认」，不要补写。当前任务：【填写】
这段提示词不会让 Token 神奇消失。它的作用更实际：减少无效阅读、重复输入和不必要的视觉页面。
该省的是无关内容。
会影响结论的证据，一页也别省。
如果以后要在文章里写具体 Token 数或节省比例，必须先用同一份真实文档制作 DOCX、清洁 Markdown 和 PDF 三个版本，在相同模型、相同提示词、相同入口下测试，并同时记录图表、脚注、批注和复杂表格有没有丢失。
看到这了点个关注，我们下期见。
