给开发者：PDF 转 Markdown 怎么用

我从一个用 Claude Code 做小网站的开发者视角写。我转 PDF 到 Markdown，绝大多数时候不是为了生成文档，而是为了塑造输入——Markdown 是大模型读得最舒服的格式，而我想喂给模型的素材里很多藏在 PDF 里。

如果你是开发者，在考虑把 PDF→Markdown 接进自己的工作流，下面是我会真去做的事。

主战场：喂大模型

这是 Markdown 真正的价值所在。我做网站要接某个 API（比如支付服务、搜索服务、消息服务），起点经常是抓官方文档。一半时候文档是 PDF（尤其银行、支付公司），另一半是文档站，但我想要一份离线副本。

最朴素的做法是把 PDF 直接贴进 Claude。这做得很烂。Claude 是能读 PDF，但 token 数大、结构含混、模型经常漏读章节。先转 Markdown 有三个收益：

• 同样内容，token 数小很多。 PDF 自带大量版面冗余。
• 结构留下来。 标题还是标题，Claude 把标题层级当成导航地图。
• 可编辑。 我可以删掉用不上的章节再贴。一份 200 页的 reference，我通常只想要 "Authentication" 那一章。

我的循环是：PDF 进 → PDF2MD → 手工裁掉 → 贴进 Claude Code 当上下文 → 让它写集成代码。从开始到代码开始流出来，大概两分钟。

在构建流水线里用

如果想把 PDF 转换接进 CI/CD 或者批处理，浏览器工具不是答案。用 CLI：

• Marker 是 Python 库，我会优先选它。pip 装、命令行跑、单文件或整个目录都行。带 OCR、能识别标题和表格。
• MinerU 类似。中文更强，配置略重。
• Pandoc 处理非 PDF 的部分（DOCX、HTML、EPUB），可以和上面任意一个串成统一流水线。

我用过的一个模式：一个小 repo，watch docs/*.pdf，每次 push 触发 GitHub Action 跑 Marker，把 docs/*.md 也提交回去。这样 LLM 友好的版本永远比原始 PDF 慢一个 commit。

编辑器集成

我用 Obsidian 做个人笔记，VS Code 写代码，两者都把 Markdown 当一等公民，没什么集成步骤——保存到对的目录就行。

几个我加的小便利：

• 一个 Obsidian QuickAdd 动作，直接用当前 PDF 打开 PDF2MD。少点三下。
• 一个 VS Code 任务，对当前打开的 PDF（用某个 PDF 预览扩展时）跑 Marker，输出同名 .md。
• 调研资料专用的小脚本：每篇文章一个文件夹，脚本把里面所有 PDF 和 Word 转成 Markdown。这样我能 grep。不转，就 grep 不了，这是关键。

RAG 和向量

如果你做 RAG 流水线，Markdown 是个合理的中间格式。大部分 chunker 按标题切，所以转换时保留标题结构很重要。这事 Marker 和 Nanonets 做得不错；那种把一切压扁成纯文本的提取器会让你的 chunk 质量更差。

另一个要注意的：表格。大部分嵌入模型不太懂表格结构，输出干净 pipe-Markdown 表格的转换器会比输出 "Column1: 值 Column2: 值" 这种散文化的转换器，给出更可检索的 chunk。如果语料里表格密度高（财报、科学数据），先用一份代表性文档对比几家转换器，看哪家的 embedding 检索质量好。

隐私与自托管

只要涉及客户数据、合同、未发布的工作，我都不会用服务器端转换器。不上传文件的方案：

• 纯浏览器，比如 PDF2MD。页面加载完，文件本地处理，什么都不离开。适合临时用。
• 自托管 CLI，比如 Marker、MinerU。适合流水线。
• 自托管服务，如果想要长期运行的内部 API。Marker 有 server 模式，MinerU 也有。

我会避开的：要求上传、又不明确说怎么处理文件的服务。哪怕它写了"处理完即删"——我没办法验证，干脆不用。

我已经放弃的几条路

• 承诺 PDF→Markdown 的浏览器扩展。 多数是包装服务器 API，隐私故事讲不清。
• "AI 加持"的在线转换器用于喂大模型这个场景。我宁愿要一份确定的转换结果，让 Claude 在另一边做智能。两层 AI 等于两层不透明。
• 自己写 PDF 解析器。 我试过，是个大坑。用现成的工具。

开发者视角就讲这些。整条流水线最大的杠杆，就是"把 Markdown 喂给 Claude Code，而不是 PDF 喂给 Claude"——这点跟你选哪个转换器没关系。

最后更新：2026 年 4 月 6 日