同一天榜单上，两个文档解析器吵起来了：一个拼命转 Markdown，一个偏说 LLM 不需要
同一天榜单上，两个文档解析器吵起来了：一个拼命转 Markdown，一个偏说 LLM 不需要
今天这张榜单有意思的地方，得对着看才能看出来。
榜二是微软的 markitdown，榜八是 LlamaIndex 的 liteparse，俩项目干的是同一件事——把 PDF、Word、PPT 这些乱七八糟的文档，变成大模型能读的东西。RAG、Agent、喂 prompt，第一步都卡在这。但你把两家的 README 摆一起读，会发现它们对「大模型到底想要什么」的判断，几乎是反的。
这种对着干，比单看哪个项目都好玩。今天就顺这条线聊。
microsoft/markitdown
先说榜二这个老牌选手，今天 +1873 star，累计已经 13 万了。
它的事一句话讲清：把一切转成 Markdown。PDF、DOCX、XLSX、PPTX、HTML、EPUB、CSV、图片（带 OCR）、音频（带转写）——二十多种格式，统统吐成带标题、列表、表格的干净 Markdown。出自微软 AutoGen 团队，起因是他们自己受够了「每接一种文档格式就要写一套脆得要命的预处理」。
为什么是现在火？三个字：MCP。markitdown 内置了一个 MCP server，就暴露一个工具 convert_to_markdown(uri)，Claude Desktop、Cursor 这些直接挂上就能在对话里转文档。它精准踩在了今年最热的那条线上——RAG 管线、AI Agent、MCP 生态，三个风口它一个项目全占了。
逻辑也站得住：主流大模型本来就「说」Markdown，GPT、Claude 不用你教就会用 # 和 | 排版。原始 PDF 抽出来的文本经常是断段、丢标题、表格稀烂的一坨，Markdown 既保住了层级，又比纯文本省 token。
谁该看：在搭 RAG、做知识库、需要把一堆杂格式文档批量灌进向量库的人。
我的判断：markitdown 的价值在「全」和「省心」，不在「准」。它是那种你不会单独夸它、但拆掉就难受的基础件——20 种格式一个接口搞定，这件事本身就值了。但你要真拿它去啃多栏学术论文、复杂嵌套表格，照样翻车，该上 Azure Document Intelligence 还得上。它是个称手的瑞士军刀，不是手术刀。
run-llama/liteparse
然后是榜八，今天 +701，LlamaIndex 出的 liteparse。它有意思就有意思在——它公开跟 markitdown 唱反调。
LlamaIndex 把市面上所有不靠大模型的解析器（pypdf、pymupdf、markitdown、pdftotext……）拉出来在 LLM 问答任务上跑了一遍 benchmark，结论是 liteparse 准确率并列第一、速度还最快。5 月底刚发的 v2.0 更狠，整个核心用 Rust 重写，号称比旧版快百倍，还编了 WASM 包能在浏览器和边缘端跑，Python / JS / Rust 三套绑定齐活。
但真正值得说的是它的设计哲学。markitdown 拼了命想把文档转成结构化 Markdown，liteparse 偏偏说：别转了，Markdown 反而是负担。
它的理由很直接——大多数工具费劲去「识别」表格再转成 Markdown，这套检测管线又慢又容易错。liteparse 干脆不检测，把文字按原始的空间坐标投影到一张网格上，列和列之间的关系靠空格保留：
1 | Item Qty Price |
它赌的是：大模型早就在 ASCII 表格、代码缩进、README 上训练过了，你把版面原样喂给它，它自己会读，根本不需要你先转成 |---|---|。 所以 liteparse 故意不出 Markdown、不做表格转 CSV、不做 schema 抽取，输出就是文本、截图、bounding box 三样。这不是没做完，是它认为不该做。
谁该看：做 Agent、做实时文档管线、要在本地/浏览器里跑解析、对速度敏感的人。
我的判断：这是我今天最欣赏的一个项目，因为它有立场。「LLM 不需要你帮它把表格转成 Markdown」这个判断很可能是对的——我们这两年给模型喂了太多它本来就消化得了的预处理。当然它也老实承认短板：多栏论文、手写表单、糊成一团的扫描件，它一样搞不定，那些还得交给重型的 LlamaParse。但光是「敢砍掉 Markdown 这一步」的决断，就比那些功能堆得满满当当的解析器清醒。markitdown 和 liteparse 放一起，本质是两种世界观：一个觉得要替模型把饭嚼碎，一个觉得模型牙口好得很。 我押后者。
EveryInc/compound-engineering-plugin
换个赛道。榜三这个今天 +353，是 Every（就是 Every.to 那家媒体公司）出的 Claude Code 插件，叫 compound-engineering。
「复利工程」这套说法是 Kieran Klaassen 在做 Cora（一个 AI 邮箱助手）时攒出来的，核心就一句话：每写一段代码，都该让下一段更好写，而不是更难写。 大多数代码库是越加功能越烂，复利工程想反过来——bug 修一次就消灭一整类、模式固化成工具、经验回灌进系统，让 Agent 越用越聪明。它把这套流程拆成四步循环：Plan → Work → Review → Compound，而且强调 plan 和 review 该占你 80% 的时间，真正敲代码只占 20%。
落到插件里，它塞了 37 个 skill、51 个 agent，靠 /ce-plan、/ce-work、/ce-code-review 这些斜杠命令跑。最唬人的是 review——一次并行开 14 个专门审查 agent：安全、性能、数据完整性、架构、代码简洁性，外加一堆框架专属的（Rails、TypeScript、Python），审完汇总成一张排好优先级的清单。
谁该看：重度用 Claude Code、想要一套现成成体系工作流、而不是自己零散攒 prompt 的人。
我的判断：理念我是真认同——「让每次改动都给系统留下经验」这件事，是 Agent 编程里被严重低估的一环。但这插件的问题也很实在，社区已经在吐槽了：小任务用它就是杀鸡用牛刀，14 个 agent 并行审查，token 哗哗烧，改个 typo 也给你走一整套流程。而且它假设你愿意接受 Every 那套工作流，挺「我有主见」的。我的建议跟昨天聊 ECC 时一样——当字典查，别当框架装。它的 skill 和 agent 全是开源明文，挑你需要的那几个审查器拆出来用，比整包吞下、然后被 token 账单吓到要理性得多。
顺嘴一提，今天榜七还有个 cursor/plugins——Cursor 官方的插件规范。markitdown 抢 MCP、compound-engineering 做 Claude Code 插件、Cursor 自己出插件标准……「给 Agent 装插件」这件事正在被各家抢着定标准，这条线值得盯，今年大概率还要热闹。
写在最后。今天这张榜单的暗线，其实是**「怎么把东西喂给大模型」这件事正在分化**。
文档解析这层，markitdown 和 liteparse 已经为「要不要替模型嚼碎」吵起来了；工具这层，各家在抢插件标准。说明一个信号：大模型本身的能力卷得差不多了，下一轮竞争挪到了「怎么把上下文递给它」。这层活儿不性感，但谁的判断更接近模型的真实口味，谁就赢。我今天赌 liteparse 那种「别低估模型」的方向。
