官网友情链接： 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质量优化和企业客服审计才真正有可靠数据基础。
