文档解析根本不需要 AI：Rust 库零模型快 100 倍

你有没有被文档解析这摊事恶心过？

RAG 流水线搭到一半，发现 Word 要一个库、PPT 要一个、Excel 又要一个，PDF 还得接 OCR。四个依赖、四种怪脾气，输出格式还各不一样。

大家默认：解析文档这种活，总得靠点 AI、靠点大模型吧？

Firecrawl 刚开源的 anydoc，直接把这条"常识"砸了。

反常识：它号称 AI 解析器，里面却一行 AI 没有

anydoc 是 Firecrawl 从自家生产级 /parse 服务里抽出来的纯 Rust 库，干一件事：把 14 种办公文档统一转成干净的 GitHub-Flavored Markdown。

最离谱的不是它快，是它快得毫无"智能"。

整个库零机器学习、零 GPU、零 OCR。它不"理解"文档，只是老老实实读文档自己声明好的结构——标题在哪、列表怎么嵌套、表格哪些单元格合并。

一个号称"AI 文档解析器"的东西，里面一行 AI 都没有。这才是它最狠的产品决策。

结果呢？在官方基准里，anydoc 中位转换 4.4ms/文档，而带模型的 Docling 要 513.6ms——快了约 117 倍，四舍五入就是大家喊的"100 倍"。质量分（Claude Sonnet 盲评）还反过来更高：81 vs 70。

没有 GPU 负担，没有模型权重，往 CPU 上一扔就能跑。

它凭什么又稳又快

核心就一个设计：所有格式 funnel 进同一个文档模型，再走同一个序列化器。

Word、PPT、Excel、ODT、RTF、EPUB、CSV……每种格式先解析成同一套内部节点（blocks、inlines、tables、footnotes），再用同一个 Markdown 序列化器吐出来。

好处是致命的：修一个格式的 bug，等于修所有格式。docx 里表格转义写错了，改一处，rtf、odt、pptx 全跟着好。

而且它靠内容签名识别格式，不认文件后缀。你把一个 .docx 改名叫 report.txt 丢进去，它照样认得出来——丢给那些只看扩展名的库，直接傻眼。

PDF 单独走内嵌的 pdf-inspector：文本型 PDF 直接抽字，扫描件/图片型才标记出来交给 OCR 流水线。

一行接入，覆盖你整条解析栈

以前你得维护四五个库，现在一个就够：

# Pythonpip install firecrawl-anydoc import anydoc markdown = anydoc.to_markdown("contract.docx")  # Node.jsnpm install @firecrawl/anydoc const markdown = await toMarkdown("report.pptx")  # 或者直接 CLI，免安装体验 npx @firecrawl/anydoc report.docx

Rust、Python、Node.js、浏览器（WebAssembly，文件不出本地）、CLI 全有绑定。甚至能当 Agent Skill 装：npx skills add firecrawl/anydoc——之后你的 Claude Code / Cursor 碰到任何文档，自己就能读。

全程本地跑，无 API key、无外部服务、MIT 协议。

泼盆冷水

别被"100 倍"冲昏头，三条边界得说清：

第一，零 AI = 零 OCR。anydoc 只处理文本型文档。扫描件、图片型 PDF，它识别出来但不读——这部分得接 OCR（Firecrawl 托管的 /parse 才补上了 OCR 模型）。所以它是"文本文档解析之王"，不是"万能扫描仪"。

第二，"100 倍"是对比 Docling 的特定数字。对本身就很轻量的工具，领先没那么夸张，但依然稳稳压一头（比次快的工具快一个数量级）。

第三，PDF 其实绕过了那个"统一模型"——号称"每种格式输出一致"覆盖的是 13/14，最难的 PDF 是 pdf-inspector 自己吐的。设计上很合理，但宣传话术得打个折。

换句话说：它是 RAG 摄入文本文档的绝佳底座，但别指望它替你做扫描件识别。

怎么上车

# 浏览器跑 WASM 版，文件不出机，先感受速度 npx @firecrawl/anydoc report.docx  # 或丢进 Python 项目pip install firecrawl-anydoc

anydoc 火起来，戳破一个被行业默认很久的迷信：文档解析这事儿，难的从来不是"智能"，而是"干净地把结构读出来"。

当最快的解析器选择不要 AI，那堆为了"智能"硬塞进来的模型权重，是时候想想要不要拿掉了。

你现在的文档解析栈用的是什么？踩过哪些坑，评论区聊聊。