官网友情链接 wechatapi.net
很多企业使用微信处理售后问题。
客户通过私聊发一句：
"这个功能报错了。"
随后发一张截图。
客服看到以后手工创建工单，再把截图和客户信息复制进去。
客户量少的时候，这种方式没有太大问题。
但当多个微信账号、多个微信群、多个客服同时工作以后，依靠人工把微信问题整理成工单，会出现漏单、重复工单、上下文缺失和处理进度无法追踪的问题。
所以很多微信二次开发项目会考虑：
收到售后关键词以后自动创建工单。
这个方向没有错，但如果直接把"微信消息 = 工单"，很快又会产生另一个问题：
无效工单会大量增加。
客户说一句"好像有问题"，可能并没有形成一个完整问题。
客户连续发 5 条消息，如果每条都触发一次，就可能创建 5 个工单。
所以微信消息和正式工单之间，需要一个中间层：
工单候选。
WechatApi 可以作为微信API 和个人微信API 接入层，把微信私聊、微信群、图片、文件和语音消息接入业务系统。业务系统再基于这些消息生成候选，经过规则或人工确认后进入正式工单。
一、为什么不能直接创建工单
微信聊天具有碎片化特点。
客户可能这样描述：
"有问题"
"刚才突然不行了"
发送截图
"点这里的时候"
"提示失败"
这五条消息其实属于同一个问题。
如果系统每条都实时判断，就很容易重复创建。
而且第一条"有问题"信息太少，不具备完整工单条件。
工单候选层可以先收集上下文，等信息达到一定完整度后再判断。
二、候选工单应该保存什么
一个候选记录可以包含：
客户主体；
微信关系；
所属微信账号；
来源会话；
来源微信群；
原始消息集合；
图片和文件；
语音转写；
问题分类；
AI摘要；
风险等级；
建议处理人；
候选状态。
这样候选不是一条孤立消息，而是一个已经初步整理的问题。
三、候选状态怎么设计
候选可以设计：
收集中；
待确认；
已转正式工单；
已合并；
已忽略；
等待补充；
已过期。
"收集中"很有价值。
比如客户刚发一句"打不开"，系统先建立候选，但等待短暂上下文。
随后客户发截图，候选自动补充。
几秒后客户补充错误信息，候选更加完整。
然后系统再进入待确认。
四、一个具体例子
客户 A 私聊客服微信：
10:00 "上传一直失败"
10:01 发送截图
10:01 "今天上午开始的"
10:02 "换了两个文件都一样"
WechatApi 将这几条微信消息接入系统。
业务系统按照同一客户、同一会话、短时间窗口聚合。
系统识别：
问题类型：文件上传异常；
发生时间：今天上午；
已尝试操作：更换文件；
附件：错误截图。
于是生成一条工单候选。
客服打开后台时，看到的已经不是四条零散消息，而是一条完整问题摘要。
确认后转正式工单。
五、微信群场景更需要候选层
微信群里一个问题可能被多人补充。
客户 A 发问题。
客户 B 说：
"我也有。"
员工 C 说：
"我先看一下。"
如果直接按群消息创建工单，会非常混乱。
系统应该先识别：
谁是问题发起人；
哪些消息属于问题补充；
哪些是员工回复；
是否已经有相关候选或正式工单。
WechatApi 解决微信群消息接入，本地系统负责问题聚合。
六、已有工单要优先关联
客户已经有一个"文件上传失败"的工单正在处理中。
这时客户再次通过微信发一张新截图。
系统不应该创建第二个工单。
可以先判断：
客户当前有没有未关闭工单；
问题类型是否相同；
发生时间是否接近。
如果符合条件，新消息直接作为工单补充信息。
这样可以减少重复工单。
七、AI 可以做什么
AI 很适合候选层。
它可以：
总结客户消息；
提取问题现象；
提取发生时间；
识别可能分类；
生成工单标题；
判断是否信息不足。
但 AI 不应该默认拥有最终工单创建权。
对于高风险、复杂或信息不完整的问题，仍然需要人工确认。
AI负责整理，人工负责业务判断。
这会比完全自动创建稳妥很多。
八、图片和文件如何处理
客户发送的截图、日志、文档都可能成为工单附件。
WechatApi 把文件消息接入以后，可以异步下载并建立文件资源。
候选记录只引用文件资源 ID。
转正式工单时，再把相关文件关联过去。
这样文件处理和工单逻辑不会耦合得太紧。
九、语音也可以进入候选
很多客户习惯发语音描述问题。
系统可以：
保存原始语音；
执行语音转文字；
将转写结果加入候选上下文。
但需要记录：
该文本来自自动转写。
人工客服可以查看原始语音进行确认。
避免因为转写错误造成工单信息错误。
十、候选超时怎么处理
有些候选会一直信息不足。
比如客户说：
"有问题。"
然后再也没有补充。
系统不能让这条候选永久存在。
可以设置超时。
例如 30 分钟没有新消息后：
普通候选自动归档；
重点客户候选提醒人工；
售后客户候选转人工确认。
这需要根据业务类型配置。
十一、权限和责任人
工单候选不一定所有客服都能看到。
可以根据：
所属微信账号；
客户负责人；
服务团队；
微信群；
问题类型
分配可见范围。
销售咨询进入销售待办。
售后问题进入客服池。
技术问题进入技术候选。
这样消息一进入系统，就开始按业务流转。
十二、候选和自动回复如何配合
识别到售后问题后，机器人可以先回复：
"问题已经记录，请补充发生时间和截图。"
同时候选状态是"等待补充"。
客户补充以后，候选进入待确认。
这样自动回复不是单纯回答，而是在帮助系统收集工单信息。
这种模式非常适合微信智能客服。
十三、日志必须串起来
系统应该能够追溯：
哪些微信消息形成候选；
候选什么时候创建；
AI 做了什么摘要；
谁确认；
是否和已有工单合并；
最终工单 ID；
是否有附件。
这样客户后续问"这个问题什么时候提交的"，业务人员可以完整还原。
十四、WechatApi 和工单系统的边界
WechatApi 负责：
微信消息接入；
微信群消息；
图片和文件；
语音消息；
相关回调。
本地业务系统负责：
消息聚合；
工单候选；
AI摘要；
重复识别；
人工确认；
正式工单；
状态流转。
这个边界越清楚，系统越容易扩展。
十五、总结
微信消息转工单，最危险的两个极端是：
完全靠人工整理，容易漏单；
完全自动创建，容易产生大量垃圾工单。
工单候选层解决了两者之间的问题。
WechatApi 可以作为个人微信API 接入层，让微信私聊、微信群、文件和语音进入业务系统。
业务系统再通过上下文聚合、AI摘要、重复判断、人工确认，把碎片化微信消息转成结构化工单。
微信二次开发真正有价值的地方，不是把聊天记录搬进后台，而是把客户问题从聊天状态变成可分配、可追踪、可关闭的服务流程。
只有候选层、正式工单、自动回复和人工接管之间形成闭环，微信智能客服才能真正从"机器人回复消息"升级成完整的客户服务系统。