👁 204 次阅读
在 RAG（检索增强生成）知识库和各类 AI 工作流里，最令人头疼的一环往往不是模型本身，而是把 PDF、Word、扫描件、截图、图表、公式这些异构文档，统一变成 AI 能够检索、引用和推理的 Markdown。过去，这个”文档解析”环节要么依赖笨重的 OCR 栈，要么锁定某家云厂商的按页计费 API。2026 年 8 月初，一个叫 doc7 的开源新工具在 GitHub 上迅速走红，它提出了一种截然不同的思路：让多模态模型自己”读”整页文档，而不是靠专门的解析器去抠字符。
一、doc7 是什么：一句话定位
根据项目官方 README（GitHub: magicrew/doc7），doc7 的定位是“Turn documents into AI-ready Markdown with visual understanding”，即通过视觉理解把文档变成 AI 就绪的 Markdown。它能处理 PDF、Office 文件、扫描件、截图、图表、公式和示意图，输出为 AI 可直接检索、引用与推理的 Markdown。
与常见方案最大的不同是：doc7 不内置 OCR 栈，也不绑定任何文档处理服务，而是通过用户自带、兼容 OpenAI 接口的多模态模型来理解整页内容。项目采用 MIT 协议，用 Go 编写，仓库创建于 2026 年 8 月 2 日，一周内即获得超过 830 颗星（据 GitHub API 查询，2026-08-09 时点为 832 颗星、27 个 fork），增长速度相当快。
二、核心原理：从”提取字符”到”看懂整页”
传统文档解析工具（如 MarkItDown 的默认路径）依赖文件专属解析器去提取文字和基础结构；而 doc7 的逻辑是：把每一页渲染成图像交给多模态模型，让模型理解整页的语义——包括文字、表格、公式、图表的连线关系、图片含义以及可见的 UI 状态，最后统一输出成一篇可搜索的 Markdown。
官方举例：用一张”Attention Is All You Need”论文的纯栅格页（没有文字层）做测试，doc7 能恢复论文身份信息、图 2、展示的公式、缩放原理说明、技术脚注，以及两个注意力示意图内部的有序关系，全部转成可搜索的 Markdown。也就是说，它”读的是整页”，而不是停在字符提取这一步。
模型层面，doc7 支持任何兼容 OpenAI 接口的多模态模型：既可以用 LM Studio 或 Ollama 起本地模型，也可以配置远程 OpenAI 兼容端点。首次运行会自动发现本机的模型端点、读取真实模型 ID，并在多个模型可用时让你选择，还会用一次真实的视觉探测来验证模型是否支持图像理解。
三、实测基准：同一模型下，doc7 表现如何
官方 README 公布了一组可复现的基准数据（运行时间 2026-07-30，darwin/arm64），对比了三类本地方案：
| 系统 | Attention 论文 | 视觉报告 | 合计 |
|---|---|---|---|
| #1 doc7 + qwen3.5-9b | 7/7 | 8/8 | 15/15 |
| MarkItDown 0.1.6 + OCR 0.1.0 + qwen3.5-9b | 3/7 | 6/8 | 9/15 |
| Docling 2.113.0 standard | 1/7 | 2/8 | 3/15 |
这组数据里，doc7 和 MarkItDown 的 OCR 插件走的是同一个本地 qwen3.5-9b 模型、同一个 OpenAI 兼容端点，因此对比相对公平。在”视觉报告”案例中，doc7 对文字、KPI 卡片、图表、表格、公式、LaTeX、工作流顺序、UI 状态 8 项检查全部命中（8/8），而 MarkItDown OCR 只命中 6/8、Docling 标准管线只命中 2/8。需要说明的是，这是官方公布的聚焦视觉理解场景的测试，并非通用产品排名，且结果依赖所选模型，官方也把每次的原始输出和评分规则都提交到了仓库供检验。
四、四类架构路线对比
README 还把当前主流方案分成了四条路线，方便理解 doc7 的定位差异：
| 主要路线 | 代表项目 | 做什么 |
|---|---|---|
| 格式与文本提取 | Microsoft MarkItDown 默认路径 | 专属解析器提取文字与基础结构 |
| 视觉模型 OCR 封装 | Zerox | 页面转图像后交给厂商视觉 SDK |
| 专用文档 AI 栈 | MinerU、Docling | OCR/版面/表格/公式模型组成流水线 |
| 整页视觉理解 | doc7 | 页面交给多模态模型整体重建 |
从 GitHub 星标看，这些头部项目各有规模：Microsoft MarkItDown 约 17.3 万星、MinerU 约 7.7 万星、Docling 约 6.4 万星、Zerox 约 1.2 万星（据 GitHub API，2026-08-09 查询）。doc7 目前只有不到一千星，但增长极快，其差异化在于”一个模型通吃所有文档类型”，不需要分别维护 OCR、版面、表格、公式、模型的堆叠。
五、成本与隐私：本地近乎零边际成本的卖点
doc7 官方明确：不卖文档额度，不按页、不按图、不按次收费。你用自己的多模态模型（可以是量化后的开源模型）跑在笔记本、工作站、服务器或私有推理机上，处理多少文档就看你硬件的上限。硬件已存在时，多转换一份文档的边际成本几乎只有电费和运行时间。
和云文档 API 相比，成本结构是根本性的差异——云 API 按页/按图/按功能调用计费（如 AWS Textract、Google Document AI、Azure Document Intelligence、以及阿里云/腾讯云/百度智能云的 OCR），文档量越大开销越高，且文档内容要离开本机；而 doc7 配合本地模型，文档数据不出你控制的基础设施，对 RAG 知识库和隐私敏感场景尤其友好。
当然，doc7 也支持远程 OpenAI 兼容端点，此时转换前会明确警告”文档内容将离开本机”；API key 存放在系统钥匙串、Windows 凭据管理器、环境变量或本地凭据文件中，不会写进仓库或发布包——这一设计对安全敏感用户是加分项。
六、使用方式：不止一个 CLI
用一个二进制就同时提供了多种用法（官方 README 背书）：
- 交互式 CLI：
doc7 report.pdf、doc7 screenshot.png，首次运行自动发现本地模型端点并保存选择。 - 批量与定向处理：
doc7 read ./documents -o ./knowledge递归处理目录；--pages 5,7只重处理指定页；--resume只重试失败页，成功页保持字节级不变。 - 聊天式 Agent：
doc7 chat "把 report.pdf 转成知识库 Markdown"，模型可通过受限的convert_document工具处理文件，且不会收到任意 shell 字符串（无管道、重定向、脚本、网络命令）。 - 异步 HTTP 服务：
doc7 serve --addr 127.0.0.1:8787，支持上传文件/ZIP、页选择、失败页重试，绑定公网需 bearer token。 - MCP 服务器：内置
convert_to_markdown工具，可接入各类 MCP 客户端。 - Go SDK 与 Docker（镜像内置 LibreOffice、MuPDF、Chromium 和 CJK 字体）。
七、值得注意的局限
作为一篇负责的评测，也要指出它的边界：
- 结果依赖所选模型：官方明确”不规定模型大小、不声称所有模型输出相同”。小参数量化模型在普通机器上可跑，但速度、质量、最低硬件要求都取决于你的模型与量化选择。
- 基准是聚焦性测试：官方强调这是”视觉理解聚焦案例，不是通用产品排名”，并提到大规模评估需用 olmOCR-Bench 的 1403-PDF/7010-fact 套件，doc7 尚未公布完整套件排名。
- 云 API 仍有价值：当团队想要托管容量、不想自己运维模型时，AWS Textract、Google Document AI 这类云服务依然有明确场景。doc7 面向的恰是相反的需求——复用本地/私有模型、消除周期性文档解析账单。
八、适用人群与总结
综合来看，doc7 最适合这几类人：一是自建 RAG 知识库、且对文档隐私敏感的用户，希望资料不出本地；二是已有本地多模态模型（LM Studio/Ollama）、想复用现有硬件而不是再开一张文档解析账单的开发者；三是把”文档转 Markdown”接进 MCP/AI Agent 工作流、想要一个跨平台单一二进制的团队。
如果你更看重”开箱即用、什么都不用运维”，且文档量不大、不强求数据本地化，那么成熟的云文档 API 或 MarkItDown/MinerU 这类成熟开源栈仍是稳妥选择。但如果你认同”文档解析应该从专用服务下沉为模型能力”这个方向，doc7 值得在本地起一个模型实测一下——毕竟它完全免费、MIT 协议、数据不出本机。据公开信息，该项目仍在快速迭代中，星标与功能的增长都值得继续关注。
数据来源：本文产品功能、基准数据、定价表述均引自 magicrew/doc7 官方 README 及 GitHub API（查询时间 2026-08-09）。