官网友情链接： wechatapi.net

微信智能客服系统里，除了客户消息，还有大量“系统生成”和“人工编辑”的消息。

AI先生成一版回复。

客服修改。

主管可能再次调整。

最终才发送给客户。

如果数据库只保存最终文本，就会丢失一个非常重要的过程：

这句话最开始是谁生成的？

人工改了什么？

为什么改？

这对于 AI 优化、客服审计、高风险回复复盘都非常重要。

所以个人微信二次开发进入“AI + 人工协同”以后，消息不仅需要发送记录，还需要编辑历史。

WechatApi 可以作为个人微信API接入层，把客户消息和最终回复带入微信场景。本地回复系统则维护草稿版本、编辑记录、审批和最终发送内容。

一、最终消息和编辑版本要分开

最终发送消息：

sent_message。

编辑历史：

message_revision。

每次变化生成新revision。

不要直接覆盖 draft.content。

二、一个具体例子

AI生成V1：

“这个套餐可以退款。”

客服修改V2：

“这个套餐是否可以退款需要结合实际使用情况确认。”

主管修改V3：

“退款规则需要结合当前套餐和使用情况确认，我先帮您核实。”

最终发送V3。

历史仍然完整保留V1、V2、V3。

后续可以分析：

AI哪里过度承诺。

三、版本字段

revision_no；
editor_type；
editor_id；
content；
created_at；
reason。

editor_type可以是：

ai；
human；
supervisor；
system_rule。

四、为什么人工修改原因很重要

只看文本差异不一定知道原因。

可以选择：

事实错误；
风险；
语气；
信息缺失；
上下文变化；
客户身份变化。

这些原因是优化AI最好的反馈数据。

五、WechatApi 的位置

WechatApi负责：

客户消息接入；
最终消息发送。

本地业务系统负责：

草稿；
revision；
审批；
审计。

六、历史版本不能被再次编辑

V1一旦生成。

后续创建V2。

不要修改V1。

这样历史可信。

七、发送要绑定最终revision

sent_message记录：

revision_id = V3。

以后打开历史，知道客户真正收到的是哪版。

八、AI重新生成也要新版本

客服点击：

“重新生成。”

不是覆盖V1。

生成：

V2_ai。

然后人工再编辑。

所有分支保留。

九、上下文变化可以让旧草稿失效

客户新发消息。

旧草稿不再适用。

状态：

expired。

但历史版本仍保留。

十、多人编辑需要锁

客服A编辑草稿。

客服B同时打开。

可以使用编辑锁或乐观版本号。

避免B保存时覆盖A的新内容。

十一、乐观锁

draft_version = 5。

A保存时提交：

expected_version = 5。

成功后变6。

B仍然基于5保存：

冲突。

提示重新加载。

这比直接最后写入者覆盖更安全。

十二、高风险回复需要审批版本

客服V2编辑完成。

主管审批。

如果客服之后再改成V3：

原审批失效。

需要重新审核。

审批必须绑定revision_id。

十三、AI质量统计

AI原始V1和最终V3差异。

可以做：

编辑距离；
人工改动比例；
高频修改类型。

帮助优化Prompt和知识库。

十四、客服质量也可以复盘

主管发现某些人工编辑反而引入错误。

可以针对性培训。

编辑历史不仅服务AI，也服务客服管理。

十五、权限

普通客服看自己会话编辑历史。

主管查看团队。

AI管理员查看脱敏后的统计。

敏感客户内容仍要遵守权限。

十六、数据生命周期

最终发送记录长期保留。

中间AI草稿可以根据需要缩短保存周期，但高风险业务最好保留足够审计时间。

具体按企业要求。

十七、日志

编辑；
审批；
驳回；
发送；
过期。

全部关联trace_id。

完整链路。

十八、总结

个人微信二次开发进入AI和人工协作阶段以后，回复内容不再是“一次生成一次发送”。

它可能经历多轮机器生成、人工修改和主管审核。

WechatApi 可以把客户消息和最终回复带进真实微信场景，本地系统则通过消息revision记录每一次变化。

这样客户最终收到什么、AI最初说什么、人工为什么修改、谁批准了最终版本都能还原。

只有消息内容本身也具备版本历史，AI质量优化和企业客服审计才真正有可靠数据基础。