建材批发订货消息解析 Agent：草稿由模型生成、写库由人工确认，8 周交付

下游五金店与装修队在微信里发一段话或拍一张手写单来订货，业务员手工录入既有订货系统，旺季一天上百单，录错规格、漏记数量、单位理解偏差要到对账时才发现。客户最初想要「AI 自动下单」，评估阶段被否掉——模型直接写库，解析一错就是发错货。

改成模型只生成草稿、写库由人确认的形态。解析出商品、规格、数量、单位、交货方式与备注后，商品名先走由商品档案与历史订单构建的别名表精确匹配，匹配不上再检索候选交模型选择并给出理由，候选都不像时字段留空并标记为待确认。复核界面左边放原始消息或图片、右边放行项目，字段按确定程度三色区分，业务员的每次改动都记日志并回流成别名表候选。

背景

这家建材批发商在绍兴，下游是几百家五金店与装修队。订货的方式非常朴素：客户在微信里发一段话，或者拍一张手写单子的照片，业务员看完手工录进订货系统。旺季时一个业务员一天要录上百单，录错规格、漏记数量、把「一件」当成「一个」的情况时有发生，对账时才发现。

客户最初想要的是「让 AI 自动下单」。这个说法在评估阶段就被否掉了：订单直接由模型写库，一旦解析错就是发错货，代价落在物流与客情上。改成现在这个形态——模型只负责把消息解析成订单草稿，业务员在后台看一眼、改一改、按确认，写库由确认动作触发。

需求形态

核心是三件事。第一，把自由文本与图片里的订货信息抽成结构化字段：商品、规格、数量、单位、交货方式、备注。第二，把抽出来的名称对上系统里的商品编码——这是最难的一环，客户嘴里的「四分管」「PPR 20 的」「就上次那个」在系统里都是具体的 SKU。第三，把草稿摆到业务员面前，让改比录更快。

还有一条硬约束：解析不确定的字段必须标出来，而不是猜一个填上。业务员宁可看到一个空着并标红的规格字段，也不愿看到一个填得很像但其实是错的。

方案

商品匹配没有全交给模型。系统先用客户已有的商品档案与历史订单建了一份别名表：每个 SKU 挂上它在真实对话里出现过的各种叫法。解析时先走别名表精确匹配，匹配不上再走检索找候选，最后由模型在候选里选并给出理由；候选都不像时字段留空并标记为待确认。这样做的好处是常见叫法走确定性的路径，只有真正模糊的才交给模型判断。

图片走文字识别再进同一条解析链路。手写单子的识别结果质量参差，所以图片来源的草稿一律整单标记为需要逐字段核对，不允许一键确认，必须逐行点过。

「就上次那个」这类指代靠上下文解决：解析时带上该客户最近若干张订单作为参考，模型可以引用某张历史订单来解释自己的选择，业务员在草稿上能看到「参考了 3 月 12 日那单」这样的说明，判断起来快得多。

复核界面是这个项目里花时间最多的地方。左边是原始消息或图片，右边是解析出来的行项目，字段按确定程度用三种底色区分：确定、需确认、未解析。业务员改动任何字段都会记一条修改日志，日志同时回流成别名表的候选，下次同样的叫法就能直接匹配上。

交付

交付 Agent 服务端源码、订单草稿与复核模块源码、别名表维护后台、与既有订货系统对接的接口层源码、数据库结构、接口文档与部署文档，另有业务员操作手册与一次培训。既有订货系统没有改动源码，只新增了一组受限接口：读商品档案与历史订单，写订单时必须带业务员确认标记，没有标记的请求一律拒绝。

验收用了客户提供的 300 条真实订货消息与 80 张手写单照片，逐条跑出草稿后由业务员按现有流程复核，把每一处改动都记录下来分类：别名没收录、规格表述歧义、图片识别不清、模型选错候选。四类分别处置后再跑一轮，对照记录随交付材料提交。

复盘

最重要的设计决定是「模型不写库」。项目中期客户曾提出对高频老客户开放自动确认，被我们建议保留人工一步——因为一旦某类解析出现系统性偏差，自动确认会把错误批量放大，而人工确认这一步能把它挡在发货之前。这个建议写进了交付说明。

另一条经验是别名表比模型更值钱。项目结束时别名表已经积累到相当规模，而它是纯粹的客户资产：即使将来换掉整套 Agent 实现，这张表仍然有效。所以我们把别名表的维护后台做成独立模块并写进交付清单，而不是藏在配置文件里。

本案例为按典型项目形态整理的示例，不涉及任何真实客户信息。