PDF、Word、Excel、PPT转成结构化的Markdown,这2个工具足够

一句话先说清

大模型读的是 token，PDF 和 Office 给的是二进制布局。中间那一步「转成结构化的 Markdown」，过去要手写脚本，现在有两个开源项目可以直接用。

模型看不到「这一行是标题、这三列是一张表」，它只看到一串 token。PDF 和 Office 文件里，标题层级、表格边界、列表编号都靠排版坐标画出来，不做转换直接抽文字，结构基本就丢了——表格会散成一行行句子，跨页的段落会断在奇怪的位置。Markdown 用最少的标记把这些结构保住，而且是 token 效率最高的形式之一，这正是 MarkItDown 官方文档给出的第一个理由。

两个项目的定位不一样，先分清楚。

选型其实只有两个问题：要不要 OCR，决定了选型的一半；输出保真度够不够用。速度排在后面——两者差的那点时间，在一次人工核对面前可以忽略。

markitdown：覆盖最广的那一个

安装时把可选依赖一起装上，省得后面遇到 PDF 报缺库：

命令行用法就是一条命令进出：

想在脚本里调用，接口只有一个对象：

anydoc：2026 年新开源的快枪

最省事的跑法是用 npx，第一次运行会自动下载对应平台的预编译二进制：

要留一个常驻命令，或者在自己的代码里调用：

它还有一个能力值得单独提：装 @firecrawl/anydoc-wasm 之后可以直接在浏览器里转换，文件不出本机。

把两者的差异压到一张表里，逐行看就行：

最后一行是选型时最容易被忽略的。anydoc 星数涨得快，但开源才两个月、最近一次提交停在 2026 年 8 月底，新项目最大的变量是发版节奏。要把它放进生产流水线，先观察它一段时间的发版；如果是离线批处理、坏了能立刻换回，那它现在的性价比很高。

格式覆盖的具体边界

对照表里的「格式覆盖」只是一句结论，具体到扩展名要单独看：

手里还有 .doc、.odt、.xlsb 这类老格式时，先确认工具在不在覆盖范围里。anydoc 的 14 种是它对外宣称的全集，一次装好；markitdown 的格式覆盖靠可选依赖拼起来，所以要用 [all] 装，漏装哪一项，对应的文件类型就会直接报缺库。

日常用法其实就两类。

一是批量转换，把目录里的 Office 文件全部转成同名 Markdown：

二是交给编码代理。anydoc 本身就打包成了一个 Agent Skill，装完代理就能自己读 Office 文档：

转换之后得到的 Markdown 再进入切块与索引，比直接对 PDF 抽纯文本要稳：标题层级还在，切块可以按标题走；表格还在，不会被切成几段无意义的碎片。转成 Markdown 只是第一公里，它负责让后面的处理有结构可依，不负责替你理解文档。

两个项目都是 MIT，都能一条命令跑起来，所以别在选型上纠结太久：先跑通，再拿十份真实文档各过一遍。

用你自己的十份文档各跑一遍，比任何榜单都准。真正决定成败的从来不是转换器，而是你喂进去的那份文档里，到底有没有模型需要的结构。

如果这篇内容对你有帮助，欢迎点赞、在看、转发三连，我们下篇见。

既然看到这里了，如果觉得有用，随手点个赞、在看、转发三连吧。

THANKS FOR READING