先说结论：AnyDoc 解决的是“结构化文本入口”，不是万能文档理解

内容团队把 Word、PPT、Excel、EPUB 和 PDF 接入 AI 工作流时，最大的摩擦往往不是模型，而是每种格式都要换一套转换器。AnyDoc 用 Rust 为多种 Office 与开放文档格式分别解析，再汇入同一个文档模型和 Markdown 序列化器。这样标题锚点、列表编号、表格转义、脚注、演讲者备注与嵌入资产可以在不同格式之间采用一致规则。Node.js 在 libuv 线程池运行，Python 释放 GIL，浏览器版则通过 WebAssembly 在本地处理文件，适合做不经服务器的快速预览。

官方基准很吸睛：100 份真实文档、14 种格式，中位转换 4.4ms，综合质量分 81。但这个数字必须连同方法一起展示。测试语料不能公开再分发；质量评估只取前六页，由 Claude Sonnet 5 盲评输出与 LibreOffice 渲染截图；不同工具支持的格式集合不同，速度测试也对库与 CLI 采用不同的启动成本处理。它是一个可审计的项目方基准，不是第三方定论。真正面向中文创作者的测试还需要补上中文字体、竖排、合并单元格、批注、复杂公式、图表和超长文档。

最实用的内容，是画清“文件从哪里到哪里”

一个可信教程应把流程拆成四段：原始文件进入浏览器或本地 CLI、解析为统一文档模型、序列化为 Markdown、最后才决定是否送入检索库或云端模型。前两段可以完全离线，不代表第四段也离线。应使用测试文件展示输出差异，检查是否遗漏工作表、备注、隐藏文本、公式结果、附件与外链图片，并在任何后续上传前让用户再次确认。

安全上也不能把解析器当普通字符串函数。老旧 Office 二进制、ZIP 容器、畸形 XML 与压缩炸弹都属于不可信输入。AnyDoc 已定义解压、嵌套和节点数量等资源限制错误，但部署者仍要在隔离进程中设 CPU、内存、文件大小和超时上限。版权上，MIT 只许可 AnyDoc 自身代码；客户合同、付费电子书、论文图表和品牌 PPT 转成 Markdown 后仍受原有权利约束。把这些边界写清，AnyDoc 才会从“爆火仓库”变成真正可用的创作者基础设施。