特性请求: 本地 OCR 提供者钩 (- ocr 命令) - 将 OCR 委托给用户提供的引擎

□ 内容

AnyDoc完全本地化地转换出生来的数字文件,而扫描/图像专用的PDF则会用"NeedsOcr"(CLI中的出站代码3)快速失效. 今天唯一的内置完成路径是 " ocr hosted " ,将整份文件上传至Firecrawl Parse。

□ 问题

对于对隐私敏感、空气加固或调节的工作流程,无法在当地完成管道。 已经运行本地OCR引擎的用户(marker,PaddleOCR,Testeract,ocrypdf,.)必须从外部包起CLI:抓取出站3,将文件重排到自己的引擎上,并自行合并输出.

相关但与第146号不同:这个问题需要捆绑/安装OCR引擎。 这一请求要求采用规模较小、保存哲学的备选办法:一种代表团式钩子。 AnyDoc本身仍然不会运送任何型号,也不会发出网络呼叫;用户会带来引擎.

□提议

添加一个逃生舱门, 将 OCR 代表给本地命令, 而不是 Firecrawl Parse :

anydoc 输入.pdf --ocr 命令 --ocr 命令 "my-ocr {input} -- pages {pages} --out {output}"

(或像 “ ANYDOC OCR COMMAND' ” 的外观)

合同草图 :

• Anydoc为 OCR- request pages 引用命令(或首先为整个文件引用命令,如果每页拆分最初超出范围)
• 命令将标记下/ 文本写入文件或 stdout
• Anydoc 将结果合并到普通文档模型中,并通过现有的 GFM 序列器将其序列化,因此下游格式化保持不变

这将使 " ocr " 选项具有当地第三种模式: " 无 " (当前缺省,出站3)/ " 托管 " (现有)/ " 指挥 " (新)。

□为什么这适合项目

• 保持"没有ML模型,没有外部服务"核心完整:没有捆绑模型,没有网络呼叫,钩子是用户拥有的本地执行
• 使任何文件成为代理管道(Claude 代码/代码技能、CI、批量工作)的完整单CLI解决方案,必须保证文件永远不离开机器
• 引擎选择保留在用户手中:CPU(Tesseract),GPU(标记器,PaddleOCR),无论他们的硬件支持如何

□ 现实世界的工作,我们今天运行

我们用外接包将任何doc - > 第 3 - > 标记(GPU OCR)传送到外接包中,并且不得不为混合 PDF 添加一个 PDF 相分分分分分分分分分分分分分分分分分分分分分分分分分分分分分分分分分分分分分分分分分分分分分分分分分分分分分分分分分分分分分分分分分分分分分分分分分分分分分分分分分分分分分分分分分分分分分分分分分分分分分分分分分分分分分分分分分分分分分分分分分分分分分分分分分分分分分分分分分分分分分分分分分分分分分分分分分分分分分分分分分分分分分分分分分分分分分分分分分分分分分分分分分分分分分分分分分分分分分分分分分分分分分分分分 一个本地的钩子,最好是每页颗粒, 让我们删除大部分的包装码。

如果有兴趣的话,乐于测试一个原型或提供包装合同的细节.