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 指标、样本、对比口径和失败模式。