让 AI 读 PDF，看起来应该很简单：把文件丢进去，转成文本，再总结。
真正用起来才知道，文档解析最怕“一把梭”。有文本层的 PDF、扫描件、图片、Word、HTML、表格，它们不是同一种问题。
为什么要分主路径和兜底
我更喜欢把 MarkItDown 放在主路径里。
它的定位很清楚：把常见文档转成 Markdown，让后面的 AI 抽取、总结、归档都吃统一格式。主路径越统一，后面的工作流越稳定。
但 MarkItDown 不是万能 OCR。图片、扫描件、复杂版式 PDF，可能会抽不出内容，或者只抽出很短的文本。
所以我现在不会把 OCR 当主流程，而是把它当失败兜底。
我的公开版流程
第一步，先走文档转 Markdown。
如果是 txt、html、docx、有文本层的 PDF，优先转成 Markdown。这样结果轻、可读、后续处理成本低。
第二步，判断输出是否可用。
不是只看工具有没有报错，而是看内容是否足够、结构是否合理、有没有明显空结果。
第三步，失败时再启用 OCR。
扫描件、图片类文档、纯截图 PDF，才进入 OCR 或视觉识别兜底。这样不会让所有文件都走重流程，也不会因为一个工具不适合某类文件就否定整个管道。
这件事给我的提醒
AI 文档工作流的重点不是“找到最强解析器”，而是把失败路径设计清楚。
主路径负责稳定，兜底路径负责救场，业务抽取和写入知识库要独立出来。这样某个解析工具换掉时，不会把整个系统一起打碎。
我现在更相信这种朴素结构：先统一入口，再承认边界，最后给失败留一条路。