BACKGROUND
项目不是从“我要一个新系统”开始，而是从现有问题开始
针对物流订单批量更新场景，把发票和Packing List中的关键字段自动提取并写入对应订单，减少人工逐项复制。
这类项目的关键不在于堆功能，而在于识别哪些资产应该保留、哪些技术债必须处理，以及上线过程中怎样不影响正在运行的业务。
01 / CHALLENGE
原系统 / 原流程的问题
- 客户提供的发票和箱单格式不统一
- 同一PDF可能同时包含Invoice与Packing List
- 不同文件负责不同字段，不能简单全文抓取
- 识别结果还需要与正确订单、附件和后台字段关联
02 / SOLUTION
我们怎么拆解和改造
- 先判断文档类型，再按规则提取不同字段
- 发票重点识别发票号，箱单识别客户、收货人、库位、运输等业务信息
- 增加字段校验与人工确认层，避免“AI直接覆盖数据”
- 原始文件同步归档到对应订单，便于后续追溯
03 / OUTCOME
最终形成的业务能力
这里不使用无法验证的“提升XX%”式数据，而是展示改造后真正可以持续使用和继续扩展的能力。
- 把重复录入变成“自动提取 + 人工确认”流程
- 文件、字段与订单建立统一关联
- 保留人工核对入口，兼顾效率与准确性
- 为后续邮件附件自动入库、异常检测提供基础
OUR PRINCIPLE
先判断怎么改，再决定写多少新代码
已有源码、数据库和在线业务时，最重要的是连续性。我们倾向通过可验证的增量改造降低风险，同时把未来需要AI、API和业务扩展的边界预留出来。
现状
先跑通业务链
理解角色、数据和真实操作流程。
边界
确定保留范围
能稳定工作的资产不轻易推翻。
施工
按优先级迭代
先处理影响业务和维护成本最高的部分。
上线
保留回滚能力
部署、数据与权限都纳入验收。
你也有类似的旧网站、ERP、Shopify或业务系统？
把网址、后台截图、源码框架或希望改造的部分发过来，可以先判断适合升级、二开、重构还是重新开发。