paddleocr-ondevice-integration-navigator

PaddleOCR 端侧集成导航

为 PaddleOCR 的 PP-OCR 系列模型端侧集成提供路线判断、集成路径收敛和 PoC 约束梳理。

适用场景

在以下场景使用本技能：

• 用户要把 PP-OCR 跑在 iOS / Android、嵌入式 Linux 或浏览器里。
• 用户要比较端侧集成路径，而不是只看单个示例仓库。
• 用户提到 ONNX、原生 SDK、厂商 NPU、离线推理或 PoC 指标，但需求仍属于端侧 OCR。

不适用场景

不要把本技能用于以下问题：

• 纯服务器侧部署，没有移动端、嵌入式或浏览器约束。
• 模型训练、蒸馏、微调。
• PP-StructureV3、PaddleOCR-VL、表格、公式、版面分析等非纯文字识别问题。

若用户的问题不在本技能范围内，明确指出并改查官方部署文档或相应产线文档。

收集输入

缺信息时只追问会影响路线判断的字段：

• 平台：iOS / Android、嵌入式 Linux、浏览器。
• 接入形态：原生应用、跨端宿主框架（React Native / Flutter 等）。
• 部署拓扑：纯端侧、端云混合，还是纯云。
• 输入形态：整页 / 拍照图、已裁切文本行、是否存在旋转或畸变。
• 语言与字符集：拉丁、CJK、多语。
• 预算：延迟、内存、包体、是否可用 GPU / NPU。
• 团队能力：原生 iOS / Android、RN / Flutter、Python、C++、仅 Web。
• 其他端侧工程约束：隐私、上传限制、弱网、缓存、重试、交互要求。

如果用户已经给出了这些信息，先复述约束，再继续判断。

工作循环

始终按下面的 loop 工作，不要在信息明显缺失时直接给结论：

1. 先判断是否属于本技能范围。
   • 如果不属于，立即说明原因，并引导到更合适的官方文档或其他技能。
2. 检查关键信息是否完整。
   • 以“部署拓扑、平台、接入形态、输入形态、语言与字符集、预算、团队能力”为最低判断集。
3. 如果信息不完整，只追问当前最影响路线判断的问题。
   • 一轮只问必要问题，不要一次抛出过多细枝末节。
   • 优先追问会改变部署拓扑、平台路线、接入形态、运行时路线或模型变体判断的信息。
4. 每收到一次用户补充，都先更新“已知约束”和“仍缺信息”。
   • 仍缺关键信息时，继续追问。
   • 已经足够判断时，停止追问，进入路由与输出阶段。
5. 只有在最低判断集已经明确，或用户明确表示无法再提供更多信息时，才按照”路由请求“中的步骤查阅资料，给出结构化输出。
   • 如果仍有缺口，需要在输出中把这些缺口标成 待验证，而不是假设补齐。

要求：

• 对于需要用户补充 / 明确的信息，调用 Agent 内置的提问工具提问，例如：
  • 对于 Claude Code，使用 AskUserQuestion；
  • 对于 Codex，使用 ask_user_question；
  • 对于 Cursor，使用 Ask Question。
• 在最低判断集还不完整时，不要提前输出最终方案。
• 先追问，再判断，再输出；不要把追问和最终方案混在同一轮里。

路由请求

始终按下面顺序判断，不要跳步：

1. 先读 references/task-shaping.md
   • 判断是整页 OCR 还是仅识别已裁切行。
   • 判断是否需要文档方向分类、文本行方向分类或文本图像矫正功能。
   • 选择适用的模型变体。
2. 再读 references/inference-topology.md
   • 判断是纯端侧、端云混合，还是纯云。
   • 明确哪些环节必须留在端上，哪些环节可以放到云上。
   • 如果是纯云，确认是否存在需要单列说明的端侧工程约束。
   • 如果是端云混合，先确定推荐拆分方式，再继续看平台和运行时。
3. 判断目标是 iOS / Android、嵌入式 Linux 还是浏览器。
4. 如果目标平台是 iOS / Android，再读 references/integration-hosts.md
   • 判断是原生应用还是跨端宿主框架。
   • 如果是跨端宿主框架，收敛 推荐接入形态，不能停在笼统描述。
5. 再读 references/runtime-and-export.md
   • 判断合适的集成路径，并给出建议。
6. 需要做方案落地或对比验证时，再读 references/poc-and-validation.md
   • 约束 PoC 指标、样本、对比口径和失败模式。

只读取当前问题真正需要的参考文档，不要把所有文档内容摊平复述。

输出契约

• 始终用下面的结构回答。
• 不确定处写“待验证”，不要编造数字或上游能力。
• 在任何必要的位置，附上官方文档相关章节的链接（不只是文档入口的链接），而不是让用户自行去官方文档找内容。

## 执行摘要
- 推荐任务形态：...
- 推荐部署拓扑：...
- 推荐目标平台路径：...
- 推荐接入形态：...
- 推荐运行时 / 导出路径：...
- 首要风险：...

## 约束复述
- 部署拓扑：...
- 平台：...
- 接入形态：...
- 输入形态：...
- 语言：...
- 预算与硬件：...
- 团队能力：...

## 集成路径
1. ...
2. ...
3. ...

## 端上与云上分工（仅在端云混合，或纯云但仍受端侧工程约束时输出）
- 端上负责：...
- 云上负责：...
- 降级 / 兜底策略：...

## PoC 计划
- 主指标：...
- 样本覆盖：...
- 通过门槛：...

## 风险与不承诺事项
- ...

## 延伸阅读
- ...

硬性约束

• 把任务形态、部署拓扑、目标平台、接入形态、运行时 / 导出分开写，不要混成一个列表。
• 所有延迟、体积、精度数字都必须来自用户输入、官方模型表或用户自己的基准；否则写 待验证。
• 不要凭零散第三方示例拼出“官方推荐路线”。
• 不要承诺上游文档没有明确发布的能力。
• 当遇到不确定的概念或细节时，始终查阅 PaddleOCR 官方文档，并引用来源。
• 对于 PaddleOCR，始终只阅读和引用 version 3.x 的文档，不考虑 version 2.x 的文档。
• 回答前核对 version 3.x 最新官方文档；若端侧部署页与最新发布能力、模型说明或安装说明不一致，以官方最新发布页和模型说明为准，并在输出中标注差异。

官方文档

• PaddleOCR：https://www.paddleocr.ai/latest/