把项目定位为多模态 RAG Demo，而不是 OCR 工具
为什么这样做
真实价值不在于识别出文字，而在于将复杂图纸恢复为可检索、可抽取、可展示、可复核的结构化知识。
备选方案
- 直接做一个通用 OCR 工具
- 一开始就按企业级生产系统设计
项目案例
进行中
RouteRAG（公开仓库当前为 MyOCR）
围绕复杂光缆路由图场景设计多模态 RAG Demo 骨架，完成 PRD、三层架构、固定 schema、检索 / 抽取链路与 review_required 机制设计，当前推进 MVP 闭环验证
Qwen3-VL-EmbeddingQwen3-VLPostgreSQL + pgvectorPython + FastAPI轻量 Web Demo
项目概述
RouteRAG 来源于复杂工程图资料处理需求，目标不是做一个普通 OCR 工具，而是把复杂光缆路由图中的非结构化信息恢复为可检索、可抽取、可展示、可复核的结构化知识，形成面向复杂工业图纸场景的多模态 RAG Demo
核心问题
复杂工程图的难点不只是识别文字，而在于恢复文本、图形、连线与拓扑关系之间的业务语义。传统 OCR 工具只能拿到碎片化文本，无法稳定支撑检索、问答与结构化抽取。
项目约束
- 首期只验证标准格式图纸场景，不虚写复杂手绘图和大规模生产落地
- 项目当前定位是 MVP 骨架，不是成熟企业级平台
- 结果默认视为 draft，低置信度结果必须带 review_required
- 每轮只推进一个切片，优先保证可演示、可复现、可扩展
方案路径
把项目收敛为“解析 → 切块 → 向量入库 → 检索 → 结构化抽取 / QA → 展示”的最小闭环，先通过 PRD、架构文档和项目状态文档锁定边界，再围绕固定 schema、风险标记和展示复核链路设计 Demo 骨架。
关键判断
输出默认视为 draft，并引入 review_required / uncertain_fields
为什么这样做
复杂图纸理解存在较高误判风险，必须显式暴露不确定性，避免把“看起来正确”误当成“已经验证通过”。
备选方案
- 直接输出确定性结果
- 仅做文本结果展示，不暴露风险状态
关键能力 / 技术要点
- Qwen3-VL-Embedding
- Qwen3-VL
- PostgreSQL + pgvector
- Python + FastAPI
- 轻量 Web Demo
结果与价值
- MVP 骨架构建项目阶段
- 解析→检索→抽取→展示核心链路
- draft + review_required输出机制
这条项目线补齐了我从“会做 AI 方案的产品人”走向“能定义问题、控制边界、设计 RAG Demo 骨架”的技术可信度，也成为我最值得长期经营的个人技术型作品集项目。
项目收获
- 复杂图纸理解的核心难点在关系恢复，而不只是 OCR 识别
- AI Demo 也需要明确的边界控制和质量闸门
- 项目状态文档、PRD 与架构文档分层清晰，能显著提升协作效率
项目定位
项目名对外统一使用 RouteRAG，公开仓库当前命名为 MyOCR。这并不冲突：前者是产品/方案名称，后者是当前代码仓库载体。
这条项目线最重要的价值，不是证明我已经做成了成熟系统，而是证明我能把复杂图纸场景的问题定义、RAG 路线、输出 schema 和 Demo 骨架设计清楚。
当前骨架
当前项目已经明确三层设计：
- 识别处理层：上传、OCR / 解析、切块、中间结果保存
- 智能理解层：embedding、向量检索、多模态抽取、QA、规则校核
- 展示复核层：原图展示、命中块展示、结构化结果展示、review_required 提示
仓库入口
当前公开代码仓库仍使用 MyOCR 这个仓库名，下面这个入口可直接跳转查看：
为什么它对我重要
相比前面的公司项目，RouteRAG 更能证明：
- 我不只是会做 AI 项目的需求和方案
- 我也能围绕真实问题去定义工程链路和输出边界
- 我能把一个个人项目组织成长期可经营的作品集资产