功能描述 / Feature Description
背景
#776 报告了 macOS 上 CoreML EP 运行 PaddleOCR 模型时存在识别结果不稳定的问题（同图 10–50% 概率漏字），维护者在 commit 12764784 中通过在 OCRResMgr::use_coreml() 内注释掉 CoreML 调用并强制 use_cpu() 进行了止血：
// det_option_.UseCoreML(coreml_flag);
// rec_option_.UseCoreML(coreml_flag);
LogWarn << "OCR with CoreML is very poor. I don't know the reason yet. Roll back to using CPU";
use_cpu();
这导致 macOS 上 OCR 识别目前无法利用 GPU/NPU 硬件加速。
提议
macOS 系统内置了 Vision.framework（VNRecognizeTextRequest），这是苹果自研的文字识别引擎，运行于 GPU 与 Neural Engine (NPU) 上。与当前方案的关键区别在于：
可行性验证
我在下游项目中通过 Python (pyobjc-framework-Vision) 调用 VNRecognizeTextRequest 进行了初步验证：
- 中日韩文字识别准确率良好，支持
VNRequestTextRecognitionLevelAccurate 精确模式
- 硬件加速生效，GPU/NPU 被正确调用
- 输出包含文本、置信度及归一化 bounding box（左下角原点，需转换为左上角像素坐标）
如果在框架层实现的优势
在下游各项目的应用层（Python / C# 侧）各自实现该方案存在明显的维护问题，正如 [MFABD2#432](sunyink/MFABD2#432) 中项目维护者 @sunyink 指出的：
expected 字符串强绑定：下游项目的 pipeline JSON 中大量 expected、replace 字段是对着 PaddleOCR 的具体输出行为标定的。更换引擎后，同一份 JSON 无法同时兼容两个引擎的输出差异，每新增或修改一个 OCR 节点都需要在两个引擎上分别验证。- Custom 识别无原生 draw 回显：应用层接管后无法利用框架的 vision debug 图进行排查。
- 各下游项目重复造轮子：每个基于 MaaFramework 的项目都要独立实现一套坐标转换、ROI 裁剪、回退逻辑。
如果在框架层统一接入 Vision.framework 作为 macOS 上的 OCR 后端：
- 框架可以保证 OCR 输出的归一化行为跨平台一致（在框架内部处理 PaddleOCR 与 Vision 的输出差异映射）
- 所有下游项目零改动即可受益
- draw 回显、threshold 过滤等框架级功能天然可用
需要讨论的点
- 输出一致性：
Vision.framework 的识别结果与 PaddleOCR 在字符级别上必然存在差异（如 bounding box 的 padding、特殊字符处理等）。是否可以在框架内部做一层归一化映射来抹平差异，还是允许 macOS 上的输出与其他平台存在可接受的偏差？
- C++ / Objective-C 混编：
Vision.framework 需要通过 Objective-C 或 Swift 调用，需要在 CMake 构建中引入 .mm 文件混编。对现有构建体系的侵入程度需要评估。
- 是否作为可选后端：可以考虑作为 macOS 上的可选 OCR 后端（类似 DirectML/CUDA 的角色），通过配置切换，而非强制替换。
相关引用
MaaFramework 版本 / Version
No response
其他信息 / Additional Information
No response
功能描述 / Feature Description
背景
#776 报告了 macOS 上 CoreML EP 运行 PaddleOCR 模型时存在识别结果不稳定的问题（同图 10–50% 概率漏字），维护者在 commit
12764784中通过在OCRResMgr::use_coreml()内注释掉 CoreML 调用并强制use_cpu()进行了止血：这导致 macOS 上 OCR 识别目前无法利用 GPU/NPU 硬件加速。
提议
macOS 系统内置了
Vision.framework（VNRecognizeTextRequest），这是苹果自研的文字识别引擎，运行于 GPU 与 Neural Engine (NPU) 上。与当前方案的关键区别在于：可行性验证
我在下游项目中通过 Python (
pyobjc-framework-Vision) 调用VNRecognizeTextRequest进行了初步验证：VNRequestTextRecognitionLevelAccurate精确模式如果在框架层实现的优势
在下游各项目的应用层（Python / C# 侧）各自实现该方案存在明显的维护问题，正如 [MFABD2#432](sunyink/MFABD2#432) 中项目维护者 @sunyink 指出的：
expected字符串强绑定：下游项目的 pipeline JSON 中大量expected、replace字段是对着 PaddleOCR 的具体输出行为标定的。更换引擎后，同一份 JSON 无法同时兼容两个引擎的输出差异，每新增或修改一个 OCR 节点都需要在两个引擎上分别验证。如果在框架层统一接入
Vision.framework作为 macOS 上的 OCR 后端：需要讨论的点
Vision.framework的识别结果与 PaddleOCR 在字符级别上必然存在差异（如 bounding box 的 padding、特殊字符处理等）。是否可以在框架内部做一层归一化映射来抹平差异，还是允许 macOS 上的输出与其他平台存在可接受的偏差？Vision.framework需要通过 Objective-C 或 Swift 调用，需要在 CMake 构建中引入.mm文件混编。对现有构建体系的侵入程度需要评估。相关引用
MaaFramework 版本 / Version
No response
其他信息 / Additional Information
No response