夜雨聆风昨天下午，我把一份10KB的Word扔给一个刚装好的开源库。扔之前掐了表。
1.97毫秒，Markdown出来了。表格还是表格，公式变成了LaTeX，列表一个没丢。我不信邪，又跑了四遍，最快一次1.17毫秒。
这个库叫anydoc，Firecrawl 8月3号开源的，20天拿了1.79万颗星。
它是什么
Rust写的文档转换库，14种格式进，一种格式出。
Word、PPT、Excel、PDF、RTF、EPUB、CSV、OpenDocument，全部转成干净的GitHub风格Markdown，大模型偏爱吃的那种。MIT协议，绑了Node.js、Python、浏览器WASM三种环境，还带一个命令行。
Firecrawl是做爬虫给大模型喂数据那家公司，自家解析服务就跑在这套代码上，算拿生产环境验证过。
它解决什么问题
你大概也遇到过：把Word喂给大模型，表格碎成一地，标题层级没了，公式成了乱码。
提示词写得再花，也救不了一份被转烂的表格。
老办法各有各的难受。pandoc要装环境，格式覆盖不全；markitdown绑死Python生态；云API得上传文档，合同、财报这种东西，很多人压根不愿意传出去。
anydoc走另一条路：本地跑，不联网，没有ML模型。快是副产品，干净才是目的。
按项目自己的基准测试，14种格式全覆盖，中位耗时4.4毫秒，转换质量得分81；对比里markitdown是65，pandoc只有56。数据是他们自己测的，打个折听，但方向应该没错——我这次实测比它的中位数还快。
怎么用
最省事的办法，终端一行：
npx @firecrawl/anydoc 报告.docx
Markdown直接打到屏幕上，加个重定向就能存成文件。
写代码就npm装包，核心两个函数：toMarkdown传文件路径，toMarkdownBytes传内存字节。用Claude Code这类编程Agent的，还有更懒的办法：npx skills add firecrawl/anydoc，装完它就成了Agent随叫随到的技能。Python那边是pip install firecrawl-anydoc，这台机器没装Python，这条我只转述，没实测。
实测之后，说点真实判断
先说好的。
表格真稳。我故意造了份刁钻文档去为难它：合并表头、加粗斜体、内嵌图片、求根公式，全塞一份docx里。输出里表格是标准管道表，公式包上$符号变LaTeX，列表原样。Excel多sheet各自成章，中文CSV零乱码。
错误处理体面。我把一段纯文本当文档喂进去，它没崩，返回错误码unsupported，附一句人话提示。把docx改后缀成.bin，照样认出来——它读文件头，不看后缀名。
再说踩坑的，这部分README不会告诉你。
第一个坑，README示例和实际包对不上。文档写的toMarkdownBuffer和includeAssets参数，v0.2.3里根本没有，实际导出的是toMarkdown、toMarkdownBytes、toDocument三个。照抄示例直接报错，你得自己翻类型定义。
第二个坑，CLI丢图。命令行转docx，嵌入图片无声消失。后来发现图片要走toDocument接口，从assets数组按字节取——我那张测试图确实原封不动躺在里面，连mediaType都标了，虽然标的是octet-stream而不是image/png，有点糙。
第三个坑，命令行单次转换530毫秒，不是2毫秒。2毫秒是库在进程内的耗时，CLI每次要起一个Node进程，开销全在这。批量转换请写脚本调API，别一个文件起一次命令行。
第四，扫描版PDF直接报不支持，它不做OCR。公式单元格如果文件里没存计算值，出来的是=SUM(D2:D3)原文。
跑个题：测试时为了造样本文档装了个依赖，npm刷了一屏deprecated警告，跟anydoc无关，但看着真闹心。
这速度什么概念？人眨一次眼约300毫秒，够它转完150份文档。
适合谁？做RAG知识库的、AI应用要吃文档的、批量整理档案的。指着它读扫描件、想要托管服务的，绕行。
测试完，我把那份刁难它的Word又转了一遍，还是2毫秒上下。这篇文章写到一半，我已经在想手头哪个项目的文档解析可以换成它。
好工具的标志就一条，你压根不想卸载它。