一直关注 Firecrawl 的朋友，对它的印象大概还停留在"给 AI 喂网页"的爬虫工具上。但这个团队8月连着爆了两件事，主角都不是爬虫。
先是8月初开源的 pdf-inspector，一个"先给 PDF 做分拣、再决定怎么解析"的小工具，上线几天星标就破了万。知乎
紧接着，一个用 Rust 写的文档转换库 anydoc 在8月第一周上线。上线一周星标就冲到约1.3万，8月13日达到13300星。哔哩哔哩知乎10天突破15000星。知乎
到8月19日，anydoc 的星标已经达到16800颗。哔哩哔哩Firecrawl CEO Nicolas Camara 的官宣推文拿到了3100多个赞、4600多个收藏。知乎
一个月，两个万星项目。Firecrawl 这次要解决的不是"让 AI 读网页"，而是被称为"AI 圈最土的活"的那件事——把办公文档转成大模型能直接吃的 Markdown。官网标语说得很直白：任何文档输入，Markdown 输出。
为什么这个"土活"配得上万星
做过 RAG 管线或者企业知识库的人，大概率都被这种活折磨过：收到的文件可能是 .docx、.pptx、.xlsx、.pdf、.rtf、.epub，每种格式要配一个解析库，每个库的输出格式还不一样，得自己写一堆胶水代码统一格式。有开发者描述过自己的真实组合：docx 走 markitdown，PDF 走 pdfplumber，pptx 先转 PDF 再解析——三个库、两套输出格式、一堆胶水代码。知乎
这活儿其实微软两年半前就开源了。知乎markitdown 生态最好，但格式支持不全；LibreOffice 什么都能转，单文件却要一秒多，转出来的 PDF 还得再来一套解析链路。
anydoc 的解法简单粗暴：给 Word、PowerPoint、Excel、OpenDocument、RTF、EPUB、CSV、PDF 等14种格式，每种都从零写 Rust 解析器，全部解析进同一个内部文档模型，再用唯一一个 GFM（GitHub-Flavored Markdown）序列化器统一输出。
这个架构带来两个直接好处。一是一致性：不管是2003年的 .doc 还是昨天生成的 .pptx，输出的 Markdown 结构完全一致，标题层级、嵌套列表、合并单元格的表格、脚注都能保留。二是可维护性：修好一种格式的表格转义，rtf、odt、pptx 跟着自动受益。
速度是最抓眼球的数字：中位转换时间4.4毫秒。按 Firecrawl 公布的基准，500个 docx 文件1.7秒处理完，比 LibreOffice 单文件1129毫秒快了约240倍。知乎知乎
它甚至不靠扩展名判断格式：PDF 看 header，RTF 看 open group，OLE 文件看 stream names，ZIP 看 mimetype——文件扩展名标错了也能正确解析。知乎
全网在聊什么：基准成绩和四种上手方式
讨论度最高的基准数据来自 Firecrawl 官方测试：100份真实文档、覆盖14种格式、与6个主流工具盲评，anydoc 得了81分，第二名只有65分。知乎它也是唯一覆盖全部14种格式的工具——其他竞品最多支持12种，少的只支持一两种。知乎
上手入口铺得也很全：Rust、Node.js、Python 三套编程接口，Node 版本的转换跑在 libuv 线程池上不阻塞事件循环，Python 版本转换时会释放 GIL。知乎
此外还有 CLI，并且被打包成了 Agent Skill——装进 Claude Code、Cursor、Codex，AI 遇到 .docx 会自己先转成 Markdown 再处理。知乎
对个人用户最有意思的是 WASM 浏览器版：文件在浏览器本地转换，永远不会上传到任何服务器。知乎处理合同、财报这类敏感文档的场景，会明白这句话的分量。官网还提供在线 Demo，可以先丢两个文件试试效果，再决定装不装。
三盆冷水：上手前自己泼
第一盆冷水：4.4毫秒和81分，都是 Firecrawl 自家测出来的数字。哔哩哔哩 UP 主8月25日发布的深度拆解视频专门扒了这一点："性能第一"的结论，是 Firecrawl 自己拿公开测试集跑出来的。哔哩哔哩同样，"54%的 PDF 根本不需要 OCR"这个 pdf-inspector 宣传里的关键数据，也是 Firecrawl 自己业务里的统计。知乎数字看着漂亮，结论可以先留个问号。
第二盆冷水：anydoc 有明确的能力边界——扫描版、图片版 PDF 它完全处理不了。知乎它快的前提是直接读文件本身的二进制结构，如果文档本质上是一堆图片——扫描的合同、拍照的论文——里面没有文字层可读。Firecrawl 官方给的方案也承认这个缺口：文本型 PDF 归 anydoc，扫描件还得走 OCR 链路。另外还有个容易踩的 API 坑：PDF 解析不走文档模型，不能用 to_document 方法，要用 to_markdown 或 to_markdown_bytes，照着其他格式的习惯写代码会当场报错。知乎
这里正好轮到 pdf-inspector 出场。这个8月初开源的"小弟"只做一件事：解析之前先分拣。知乎它会先区分 PDF 是文字版、扫描件还是混合版，文字版本地大约200毫秒内直接提取，只有真正需要 OCR 的页面才送出去——甚至能精确判断是哪几页需要识别。项目是 MIT 协议，支持 Python、Node.js，也能直接跑在浏览器里。
第三盆冷水最有意思：anydoc 爆火的同一周，同赛道的另一个项目 doc7 也破了万星——5天涨了1.1万星——路线却完全相反：先把文档每一页渲染成一张图，再让本地部署的视觉模型"看"图改写成 Markdown。在一项15项视觉事实的基准测试里，doc7 恢复了15/15，而 MarkItDown+OCR 只恢复9/15，Docling 标准流水线只有3/15。知乎
有知乎作者给出的判断很到位：anydoc 和 doc7 的差异不在技术好坏，而在世界观——前者假设文档是数据结构，赌解析器质量；后者假设文档是图片，赌视觉模型能力。知乎前者快而确定，天花板由格式知识决定；后者慢，但天花板跟着模型能力一起涨。一句话：文档是文本的，用 anydoc；文档是图片的，看 doc7。
谁该换、谁该等
把知乎、哔哩哔哩、小红书上的讨论信号汇总，给一个分人群的结论：
如果你主要处理标准办公文档（Word、PPT、Excel、电子版 PDF），拿它们喂 RAG 或知识库：anydoc 值得试。迁移成本低，Python、Node 绑定可以直接嵌进管线，4.4毫秒的延迟拖不慢索引速度。已经在用 markitdown 的也不用急着换，留着它当日常主力，让 anydoc 补上老 .doc、.rtf 这类 markitdown 不支持的格式就行。知乎
如果你是 Claude Code、Cursor 用户：装个 Agent Skill 就完事，让 AI 自己处理格式转换，别脏了自己的工作流。
如果你的材料以扫描合同、图片 PDF、拍照论文为主：别指望 anydoc，这个缺口它不补。更务实的组合是拿 pdf-inspector 做第一道分拣，只把必要的页面送去 OCR；如果文档价值在版式、公式和图表关系上，doc7 这种不上传数据、本地跑视觉模型的路线值得蹲一个后续版本。
如果你处理敏感文档：WASM 浏览器版本地转换、零上传，是目前 anydoc 最有区分度的能力。
如果你在观望：值得等两个信号。一是第三方权威复测，尤其是中文文档、复杂表格、老格式兼容性的实测；二是星标增速从爆发期回落后，项目更新是否还能跟上。
接下来看什么
Firecrawl 的棋局已经很清楚了：anydoc 管文本文档，pdf-inspector 管 PDF 分拣，自家的 Parse API 接住扫描件的 OCR，三条腿组成一条完整的"给 AI 喂文档"流水线。知乎从网页抓取公司到 AI 数据入口层，这一步逻辑是通的。
但要清醒：这一波的核心数据全是 Firecrawl 自测。1.68万星能证明社区对"文档转 Markdown"这个问题有多饥渴，不能证明 anydoc 的数字一分不掺水。对这类工具，我的建议是：工程架构和统一输出可以跟，基准分数先留余地；先分拣再 OCR，扫描版文档别直接喂给它。
微软开源 markitdown 两年半没彻底做完的活，现在有两个团队在抢着做。AI 圈最土的这件事，终于开始有真正的基础设施了。
