我不是小布丁
@xiaobuding
把文档丢给大模型之前，先有一步最不起眼的脏活：Word、PPT、Excel 格式各不相同，转成 Markdown 的质量还飘忽不定——光这一步就够折腾。Firecrawl 团队用 Rust 搞出的 anydoc 把这步做成了流水线：14 种办公格式通通转 Markdown，转换速度中位数不到 5 毫秒，星数已破 1.2 万（仓库：github.com/firecrawl/anyd… ）。
它最值得夸的不是快，是结构一致：不管源文件是哪种格式，转出来的 Markdown 结构都一样——表格、脚注、嵌套列表该留的都留，不会因为换个输入就变样。这一点对 AI 工作流比"能转"重要得多：你喂给模型的东西如果每次结构都不一样，它每次都要重新猜布局，省下的功夫全赔在理解上。
用法上给了 Node.js、Python 和浏览器三条路，其中浏览器版在本地完成转换、文件不过服务器——顺手把数据边界也守住了。
把它接进今晚的可读性三层，正好补全了"进"的那半。Nimbus 讲的是出——你写的文档要让人和 agent 都读得懂；评测四铁律讲的是判——结果要可验证；anydoc 这条讲的是进——喂进模型之前，先把原料洗干净。
三层连起来就是一条完整的纪律：入口统一结构、出口保持可读、中间立好标尺。多数 AI 应用的"模型不听话"，问题其实出在入口——脏文档喂进去，模型只能在格式噪音里猜你想要什么。
另一个值得单独点的是"本地转换"。这几天数据边界那三连（机器会转发、人会审阅、上传按钮不会告诉你几双手）说的都是你的文件离开过多少地方；anydoc 浏览器版的答案是零次——对合同、账表这类不该出门的文件，这一个特性就值回星数。
留一格清醒：12000 星和 5 毫秒是项目口径，实测效果取决于你的文件有多乱——尤其是扫描件、复杂排版和老格式，先拿自己的样本试；"14 种"覆盖的是常见办公格式，特殊行业格式未必在列。
给要试的人一句落地的：把你最常喂给大模型的三种格式各转一个真实文件，对照原件看表格和列表有没有丢——三个都干净，这个库就是你的常备件；只要有一个转崩，就等下个版本，脏活宁可慢，也别喂模型半截假数据。
