智能订单识别平台
技术架构文档（Architecture 1.1 定稿）
1. 目标与范围
1.1 目标
在不改动客户既有 Win10 + IIS + 经典ASP + Access(mdb) 的前提下，引入“智能订单识别”能力，实现：
- 支持多来源订单提交（图片/PDF/Excel/文本）
- 平台完成识别与结构化，输出可编辑的识别结果
- 本地生成候选判断所需的“是否存在报价/产品”的依据（初期简化为“是否命中报价表”）
- 用户在“任务表”中逐一审核、修改、确认
- 确认后回写为系统订单
1.2 MVP 范围（你已定型）
- 候选集阶段：先不做复杂候选列表
初期只针对“某个项目的报价表”做匹配：输出 有 / 没有（命中与否）结果即可。 - 回写：只在用户确认后入库
不做自动入单；所有结果先进入任务表，由用户逐一确认。
2. 总体方案概览
系统由四部分构成：
- 旧系统（ASP + Access mdb）：业务主系统与数据主权
- 本地客户端（Local Client / Python 服务）：极简“任务调度 + 本地查询 + 回写”
- 云端平台（AI Platform）：识别、结构化、策略、计费、短期存证
- 模型 API：平台统一调用（OCR/LLM）
核心原则：
本地只做“任务管理、查本地库、回写”；智能全部在平台。
3. 部署形态（按你的环境定型）
3.1 客户内网（可控）
- OS：Win10 专业版
- Web：IIS（旧系统已经存在）
- 可安装：Python 运行环境（本地客户端服务）
本地客户端可选两种呈现方式（两者不冲突）：
- 后台服务：常驻运行，负责轮询、任务推进（推荐）
- Web UI：提供“任务表/任务详情/确认”页面，可被旧系统 iframe 嵌入
3.2 云端平台
- 允许短期保存原始信息（订单原文/原文件/解析过程）用于人工核查与追溯
- 平台承担：识别、解析、结构化、计费、审计
4. 角色职责边界（定死）
4.1 旧系统（ASP + Access）
- 仍是业务主系统
- 提供入口（iframe 打开本地客户端 UI）
- 最终订单与业务流程仍在旧系统内完成
- 不承担异步任务、平台轮询、复杂解析
4.2 本地客户端（Python 服务）
仅做三件事（极简）：
- 任务管理
- 按系统用户 ID 归属任务
- 任务状态推进、记录、展示
- 即使用户不打开页面，后台也可持续推进任务
- 本地匹配（初期简化）
- 在本地 Access(mdb) 中查询“项目报价表/报价相关表”
- 判断：对识别出来的关键字段（如客户/规格/材质/工艺关键字等）是否命中报价
- 初期输出：hit = true/false + 简要命中信息（如命中哪条报价）
- 结果回写
- 用户在任务详情中修改与确认
- 确认后才写回旧库生成订单（或订单草稿→再转订单，取决于你旧系统习惯）
本地客户端明确不做：OCR、文本清洗、理解、智能匹配裁决、Prompt 管理。
4.3 云端平台（AI Platform）
- 接收订单输入（文件/文本）
- OCR/PDF/Excel解析与文本归一化
- LLM 结构化识别（产出“可编辑的订单草稿结构”）
- 输出“本地查询条件/线索”（用于本地查报价表）
- 短期保存原始信息 + 审计日志 + 计费/鉴权/配额
5. 核心工作流（按你确定的“任务表审核”方式）
5.1 用户交互主线
- 用户在旧系统中打开“智能订单任务”（iframe 嵌入本地客户端页面）
- 用户提交订单（上传文件/粘贴文字）并指定客户/项目（如需）
- 任务进入用户自己的任务表（按系统用户ID隔离）
- 用户稍后打开任务表，逐一查看识别结果、修改、确认
- 用户点击“确认入库”后，生成正式订单
5.2 系统处理主线（后台推进）
A. 提交阶段（本地 → 平台）
- 本地客户端创建本地任务记录（状态：submitted）
- 将原始订单内容提交到平台（平台生成 task_id）
B. 识别阶段（平台内部）
- 平台完成解析与结构化（OCR/PDF/Excel → 统一文本 → LLM结构化）
- 平台将任务状态置为：parsed
- 平台生成“本地查询线索”（供查报价表）
C. 本地匹配阶段（本地）
- 本地客户端后台轮询，发现 parsed
- 拉取结构化识别结果 + 查询线索
- 查询本地 Access 的“项目报价表”
- 得到 hit true/false（以及命中信息）
- 将匹配结果补充回平台或直接记录在本地任务（两者都可；MVP 可先只记本地）
D. 审核确认阶段（用户）
-
用户查看任务详情：
- 平台识别的结构化结果
- 本地报价命中结果（有/无）
- 平台保存的原始信息可供核查（通过平台链接或摘要信息）
-
用户手工修正 → 点击确认
E. 入库阶段（本地 → 旧系统）
- 本地客户端把“用户确认后的结果”写回旧系统库
- 生成正式订单（或你旧系统既有的订单生成流程）
6. 任务表模型（概念级，不落字段细节）
你的确认方式决定：任务表是本地客户端的核心界面与枢纽。
任务表至少需要表达：
-
任务归属：system_user_id
-
任务状态：
- submitted（已提交）
- parsed_ready（已识别，可审核）
- need_fix（用户已修改未确认）
- confirmed（已确认待入库 / 已入库）
- failed（失败）
-
任务内容分三块展示：
- 原始订单（平台短期存证，用于核查）
- 识别结果（可编辑）
- 本地匹配结果（报价命中：有/无，及命中线索）
7. 平台存证与核查（按你要求）
平台允许短期保存原始信息，用于：
- 用户在确认环节对照核查（减少误识别风险）
- 售后争议追溯（平台日志与原始材料可审计）
- 模型持续优化（可按客户策略选择是否参与）
建议平台提供：
- 原始文件/原始文本的短期访问能力（受鉴权保护）
- 每次识别的版本与时间记录（便于复现）
8. 为什么这个版本“本地少做、平台更值钱”
- 候选/匹配在本地被你刻意简化为“查报价命中”，工程成本低、落地快
- 平台负责所有识别与结构化，价值集中、可持续收费
- 用户不会脱离平台：没有平台的识别结果，就无法进入审核确认流程
- 本地客户端只是“执行代理”，客户更愿意部署（不需要GPU、不需要维护模型）
9. MVP 实施建议（与你的范围一致）
建议第一版把复杂度压到最低：
- 平台输出：结构化订单草稿 + 本地查询线索
- 本地查询：只查“项目报价表”，输出有/无 + 命中记录ID（若有）
- UI：任务表 + 任务详情（可编辑 + 确认入库）
- 入库：只在确认后写旧库生成订单
10. 后续可扩展方向（不影响MVP）
在不改变模式的前提下，可以逐步增强：
- 报价命中由“有/无”升级为“多候选 + 推荐排序”
- 支持更多本地数据源（历史订单、产品档案等）
- 支持多人协作审核、主管复核
- 平台引入更细的置信度、风险提示、字段缺失提醒