液化气配送智能统计助手

01 / PROJECT OVERVIEW

让问题、实现与交付连成一条线

把“识别出文字”与“得到可信统计”分开：先解析订单证据，再让使用者核对无法确定的信息，最后才生成正式报表。

业务场景

微信群订单与配送回复

交付形态

Windows 本地桌面工具

当前阶段

已交付使用并完成操作教学

设计重点

不确定信息留给人工判断

02 / BACKGROUND

项目背景

母亲所在单位通过微信群记录订单和配送完成回复。人工统计需要反复查找编号、匹配配送人和瓶数，再汇总为 Excel。

工具保留了原有群聊流程，使用者选择截图和统计日期，在本地整理信息。它没有自动读取微信聊天库，也不要求配送人员改用另一套系统。

03 / MY ROLE

个人职责

围绕母亲所在单位的配送统计需求，参与工具设计、开发、异常核对流程与 Windows 软件交付。

• 整理订单与完成回复的匹配规则，区分明确证据、候选信息和冲突。
• 在 AI 辅助下迭代桌面核对流程，让补录、修改、删除与独立冲突处理可以被使用者理解。
• 关注 Excel 最终交付、版本归档和本地软件打包，并保留真实使用者交付的验收边界。

项目在 AI 辅助下完成迭代。这里展示实际参与的需求、业务判断、实现与验收，不把辅助生成等同于独立精通。

MY DECISIONS / 个人贡献与取舍

我的取舍：让不确定性可以核对，再交付统计结果

母亲所在液化气配送企业用微信群记录订单与完成回复。改变整套日常工作方式会增加操作负担，所以工具以本地导入截图为入口。我参与整理编号、配送人、瓶数和完成回复之间的规则，并在 AI 辅助下推进解析、核对界面和 Excel 交付。

OCR 得到文字和位置，不等于得到订单事实。简写编号需要结合消息内前缀，一条回复可能展开多个订单；昵称只是候选，无法确认身份时不能凭订单文字猜配送员。瓶数证据不一致、多人回复或缺号需要独立处理。

OrderBook.conflicts 分开收集人员与瓶数冲突；候选保留来源，confirm 先调用 validation，问题未处理不确认。操作流程是导入 → 识别/解析 → 逐项核对原图、补录或修改 → 处理冲突 → 确认 → 导出“配送明细”和“配送员汇总”。人工审核是正常步骤，不是软件出错后的临时补救。

本地软件已交付使用，并向实际使用者做过操作教学，这是本人提供的交付事实。它不等于安装器已在所有电脑上验收，也不等于 OCR 准确率经过测量。当前仍应使用授权样本检查漏单、冲突和导出，不宣传百分之百自动识别。

依据：matching.py:21–55；order_book.py:218–258,263–280；既有 message_rules、Excel 审计；交付与操作教学依据本轮本人提供说明。

04 / TECH STACK

技术选择，要能解释用途

Python + PySide6

桌面表格、对话框、拖放与后台 OCR 工作线程。

PaddleOCR + PP-OCRv5

本地 mobile 检测与中文识别模型，使用 CPU；方向分类与去畸变未启用。

Pillow + 布局规则

处理中文图片路径与长图，按桌面浅色气泡布局筛选消息。

openpyxl

生成两张工作表，排序、筛选、冻结窗格并回读校验。

05 / SYSTEM ARCHITECTURE

系统架构

06 / CORE FEATURES

核心功能

07 / TECHNICAL CHALLENGES

技术难点：把业务例外放进设计

难点不在于调用一次模型，而在于把有误差的文字、含糊的业务回复和可靠的最终统计衔接起来。

• 识别坐标与聊天消息对不上 ↓
• 简写与一条消息中的多单 ↓
• 处理了人员，却掩盖了数量错误 ↓
• 自动化输出看似成功，实际还有漏单 ↓

08 / SOLUTIONS

解决方案

SOURCE EXCERPT

代码节选：从实现看取舍

这个函数体现了一个产品判断：处理了某一种冲突，不应自动抹去另一种冲突。

    def conflicts(self,row):
        issues=[]
        done=[e for e in row.evidence if e[0]=='delivered']
        names={e[2] for e in done if e[2]};nicks={e[3] for e in done if e[3]}
        if not row.sender_reviewed and (len(names)>1 or (len(nicks)>1 and not (all(e[2] for e in done) and len(names)==1))):
            issues.append('配送员冲突：请查看完成回复并选择实际配送员')
        quantities={e[1] for e in row.evidence if e[0] in ('original','delivered') and e[1] is not None}
        if not row.quantity_reviewed and len(quantities)>1:
            issues.append('瓶数冲突：请核对原始订单与完成回复的实际瓶数')
        return issues

DEVELOPMENT PROCESS

开发过程

按现有实现与版本资料整理阶段，不推断未经确认的具体开发日期。

1. 01

   从群聊流程提取业务语法

   围绕订单与完成回复，整理编号、人员、瓶数和来源证据，保留原有工作习惯。

2. 02

   连接识别、结构化与人工核对

   将模型输出接到布局与消息解析，再让冲突、缺号、补录和修正进入可操作的核对流程。

3. 03

   把最终文件作为交付对象

   完善正式导出门禁、两表格式、保存回读与历史版本，继续处理本地软件安装和使用门槛。

09 / TESTING & VALIDATION

测试与验收

仓库测试覆盖解析、布局、冲突流程和导出结构；涉及 OCR 的假模型测试验证规则与坐标，不等于真实识别准确率。

• ↳

  多单与区间语法

  已知前缀的多单回复按规则展开；倒序、歧义内容不自动通过。

  tests/test_business_messages.py
• ↳

  双重冲突不能相互覆盖

  确认人员后瓶数冲突仍在；新证据要求重新处理相应维度。

  tests/test_conflict_workflow.py
• ↳

  删除与重复导入

  删除错误记录后再次导入不复活；人工修正优先，新增证据仍需重新确认。

  tests/test_delete_history.py · tests/test_pending_preservation.py
• ↳

  正式报表的门禁和结构

  存在未处理问题时拦截正式导出；两表排序、筛选、冻结及汇总一致。

  tests/test_order_export.py · tests/test_excel_polish.py
• ↳

  保存失败不能显示成功

  备用路径保存并回读成功后才报告成功，失败保留可操作反馈。

  tests/test_conflict_gui.py

以上为业务项目源码中的验证设计与测试依据。本轮验证的是作品集网站，没有重新运行这些业务项目的完整测试，也没有对线上系统做操作。

11 / FUTURE IMPROVEMENTS

未来规划

以下是后续改进方向，不是已完成能力。

• 规划用经授权的脱敏样本建立逐单准确率与漏单基准，再讨论可量化效果。
• 规划在独立 Windows 电脑验证安装、升级、中文路径和实际使用者无指导操作。
• 规划若拓展手机或深色截图，独立设计布局规则和回归样本。
• 规划设计原图证据长期保存与授权策略，避免把临时定位当作永久追溯。

PROJECT GALLERY

项目截图与输出示例

真实软件主界面展示截图导入、统计日期、订单核对状态、增改删与 Excel 出口。当前空表没有真实订单或客户信息；独立冲突核对界面和脱敏 Excel 成品尚未提供。

已展示使用者提供的真实界面。脱敏报表和更多业务场景待补充；不以空数据截图证明识别准确率、运营规模或完整验收。