强强的AI落地观察:客户只肯在微信里喊“发货”,AI 怎么把它变成一张订单?

上个月，一个做小商品批发的老板找我。

他的公司有网站，有订单系统，业务员在系统里开单，仓库在里面拣货，流程都跑得通。可他说，系统再好，客户不上去用。

他的客户大多是老客户，拿货拿了几年，谁也不愿意登录网站挑商品、填地址、点下单。他们习惯在微信上发一句话：

"老样子，A 两箱，B 一箱，发上次地址。"

或者："那个红色的保温杯再来 50 个，要发票。"

或者干脆发一段 30 秒的语音，或者拍一张手写的单子。

这些消息，全靠一个文员一条条看，再一条条敲进订单系统。一天几十条，旺季上百条。敲错一个型号，发错货；漏了一条，客户打电话来问"我的货呢"。

老板问我："能不能让 AI 自动把这些话变成订单？"

我说能。但我先跟他说了一句实话：这件事最难的地方，不是 AI 会不会解析，是这些消息怎么进到 AI 手里。

个人微信，没有官方接口。这是整件事的起点。

一、先选通道，不是先写代码

我一开始也想走捷径，去查了个人微信的机器人方案。

网上确实有，行话叫 hook，通过把消息截下来实现。用过的人不少，代码也开源。但我查到一个数据，就放弃了：有人统计过，用这类用户目前只有很少量的没被封号，用主流框架的几乎全军覆没，而且同一个实名下的号会连坐。有些业界出名的开源项目，去年也已经归档停止维护。

拿这个给客户做生产系统，等于把客户的微信号架在火上。所以我没走这条路。

我把能做方案，摆在老板面前。

excel类录单助手：文员把消息转发或粘贴进来。零风险，当天能用，不改客户习惯；代价是还要人工"转一下"。

企业微信加会话存档：业务员用企微加客户，客户用微信就能聊。准实时，文字语音图片都能拿；代价是要客户同意存档，按人年付费。

个人微信 hook：什么信息都能拿；代价是封号，不建议用。

三种方式没有哪条绝对好，得看客户。因为这家店有三个业务员，算上老板自己，已经是小有规模。所以我推荐那位老板用企业微信的方案。

我听说有人上来就做全自动读微信，做完发现客户不肯迁移，钱和时间都白花。

用企业微信会弹出一条"客户同意存档"的说明，而当企微第一次和客户对话，对方是可以选择不同意。客户不同意，这段聊天就不进存档。虽然是整条链路最大的不确定，但是目前基本没什么人在意这个。

钱在存档费。服务版大约几百块一个业务员一年，企业版更贵，版本和人数档位不同，价格也不一样。几个业务员，一年也要千把块成本。

二、把"一句话"变成"一张单"

方案定了，开始干活。

我先让文员把她平时收到的消息导出来，看了一百多条。看完我心里有数了：客户说话，几乎没有一句是完整的。

有的是省略。"老样子。"就三个字，意思是上次那几样，同样的数量，同样的地址。

有的是别称。"那个红色的保温杯"，系统里叫"保温杯-红-500ml"。

有的是方言加单位。"来三箱"，一箱是 24 个。

有的是半路改单。"刚才那个 B 不要了，换成 C。"

还有的压根不是订单。"在吗？""这个多少钱？""上次那个还有货吗？"

所以第二件事，不是调模型，是把这些规矩写下来。

我做了几张表：

1. 商品别名表。客户怎么叫，对应哪个 SKU。几千个商品，一条条对，最枯燥，也最值钱。

2. 单位换算表。箱、件、打、个，各自等于多少。

3. 客户档案。折扣多少、现结还是赊账、默认收货地址。

4. 历史订单。这是"老样子"的解法：客户说老样子，就调他最近一单，照着补。

然后是判断规则，也就是我常说的 skills：

- 一条消息里有几个商品，就拆几行。

- 数量先统一换算成最小单位，再乘回去。

- 折扣按客户档案取，不按客户嘴上说的取。

- 地址对不上客户档案，标红，转人工。

- 品名匹配不到，转人工。

- 数量明显异常，比如平时两箱，这次两百箱，转人工。

- 语音识别置信度低，转人工。

- 同一客户十分钟内连发几条，按时间合并，最后一条为准。

- 出现"不要了""换成""加一个"，按改单处理，先生成新版本，不直接改旧单。

这里有个细节，我踩过坑：一开始我把整个商品库都塞进上下文，让模型自己找。结果 token 贵得离谱，还经常选错，因为相似的商品太多。

后来改成两步：先从客户的历史订单里，召回他常买的二三十个商品，再让模型在这个小范围里匹配。准确率上去了，成本也下来了。这就是"上下文工程"的真实含义，不是把东西塞得越多越好，是塞对。

解析的输出，我固定了几个字段，也同时要求人工对信息检查兜底：

- 客户：名字，或者企微里的外部联系人 ID。

- 明细：原文怎么写的、匹配到哪个 SKU、数量、单位、单价。

- 地址：默认地址，还是客户这次指定。

- 备注：要发票、要加急、指定物流。

- 置信度：0 到 100 之间，模型自己给，帮助客服能快速做第一轮判断。

- 待确认：它拿不准的地方，比如"单价是历史价，没含这次调价"。

最后两个字段最重要。模型不确定的地方，必须自己说出来，而不是硬编一个数。人看的是这两项，不是整段结果。

这一道坎，卡在整理别名。怕在别名错一条，那一类货全错。钱反而省，因为范围收窄了，token 花得少。

三、真上线：那条准实时的链路

真正上线，走的是企微会话存档。完整链路是这样的。

1. 企业认证，在企微管理后台开通会话内容存档，选服务版。

2. 设置存档范围，把几个业务员加进去。

3. 上传 RSA 公钥。这一步不做，企微不会存档。

4. 配一个公网回调地址。有新会话时，企微推一条"产生会话回调通知"过来，只带 token，不带内容，token 十分钟有效。

5. 收到通知，立刻调 sync_msg 拉取。一次最多 1000 条，每分钟不能超过 4000 次调用，而且只能拿最近 5 天的数据。

6. 用 SDK 解密，拿到消息体：谁发的、发给谁、什么时间、什么类型、内容是什么。

7. 图片、语音、文件只有一个媒体 ID，还得再调一次接口下载，然后转写或 OCR。

8. 去重。用 msgid 做幂等，同一客户短时间多条合并。

9. 解析成订单草稿，推到企微里给人确认，确认后写进订单系统。

延迟大概是这样的：文字单，从客户发出到出现草稿，1 到 3 秒；语音单，5 到 30 秒；手写单照片，10 到 40 秒。

上线第一周，问题全来了，而且没有一个是"模型不准"。

第一个是语音。有个客户说话快，带口音，"三箱"被转成了"三乡"。我们的处理是：数量字段单独再校验一遍，读音对不上任何商品单位的，一律转人工。

第二个是手写单。"1"和"7"、"0"和"6"经常认错。手写体 OCR 准确率大概九成，剩下那一成，只能靠人工。

第三个是撤回。客户发了单又撤回，存档里还留着。我们定的规则是：撤回的消息标记成"待确认"，不自动生成订单，等人看一眼。

第四个是重复。客户连发三条："在吗""发两箱 A""发上次地址"。这三条要合成一单，不能生成三单。

第五个是订单系统。他们系统的接口有限流，忙的时候会返回失败。我们加了重试，还加了一条每日对账：AI 生成的单，和系统里的单，一天结束对一次总数，对不上就报警。

第六个是人。业务员一开始不信，AI 生成草稿，她还是要自己从头核一遍；她又担心AI 记错账算自己头上。这个没法靠代码解决，只能靠两件事：一是让 AI 把"哪里不确定"标出来，二是把责任边界说清楚，草稿内容必须人兜底点确认，确认了才算数。

这一道坎，怕的东西是有顺序的。

错单最怕，发错货、报错价，客户直接损失。漏单第二怕，客户打电话来问"我的货呢"，口碑就没了。客户流失第三怕，就是那些不愿意存档的人。

钱在这一步最实：存档费按人年，几个业务员一年一两千；服务器要有公网地址；token 按单量走，一天上百单，一个月几百块；真正贵的是维护，客户改叫法、上新品、换折扣、订单系统改版，规则都得跟着动。

所以我给自己定了一条死规矩：宁可多一次人工确认，不要一次错单。每一单进来先落一个待办，写进系统成功才消掉，一天结束对总数。宁可多报一次，不能少一单。

收尾

回头看，这件事能走得顺当的节点主要靠以下：

第一条路走通，是因为没去碰个人微信，选了一个能拿消息的通道。

第二条路走通，是因为把客户嘴里的叫法、单位、习惯，一条条写成了表和规则。

第三条路走通，是因为把准实时的链路搭起来，然后一条条接住上线后冒出来的脏问题。

三道坎，其实就是三件事：选对通道，把规矩写下来，真上线去接反馈。

规模不同，选的路也不同。一个文员、老板自己接单，用录单助手，当天能上；想收拢入口，用微信客服；有几个业务员、客户关系在公司手里，上企微会话存档。

工具会变，接口会变，但这三道坎不变。因为客户永远会用最省事的方式下单，而最省事的方式，通常就是微信里喊一声。

客户不会为了你的系统改变习惯，你只能让系统去接住他的习惯。接得住，叫用好 AI；接不住，再强的模型也只是个会聊天的窗口。

最后分享一个开源项目供大家学习参考：

## AI 智能订单助手 — 生鲜 B2B 智能录单 Demo（生鲜 B2B 供应链：客户在微信群发一句话/一张图/一个 Excel，AI 识别成结构化订单，人工审核后一键下单）

推荐点：先用 rules.json 做别名精确映射（比如"韭王→韭黄"），再让 LLM 提取数量单价；进"待审核池"，支持合单、重识别、确认下单

https://github.com/JWick-lzh/XianDa-AI-Order-Agent

你们公司的客户，是不是也这样：有系统不上，就爱在微信里喊一声？现在是谁在录？欢迎在评论区聊聊。