官网友情链接 wechatapi.net
AI 微信机器人进入高风险场景以后,人工审批是非常常见的安全机制。
模型生成一段回复。
客服审核。
点击批准。
然后发送。
看起来流程很完整,但如果系统没有“审批版本”,仍然存在一个非常危险的竞态。
客服审核的是版本V1。
在真正发送之前,系统因为客户新消息、模型重试或者“重新生成”操作,把草稿更新成V2。
如果审批状态仍然保留:
approved=true。
最终发出去的可能是人工根本没看过的V2。
所以个人微信二次开发中的AI审批必须绑定具体内容版本,而不是绑定“这条任务”。
WechatApi 可以作为个人微信API接入层,把客户会话、消息和最终发送能力带入系统。本地AI草稿系统则维护draft_revision、approval和发送版本一致性。
一、审批的是内容,不是任务ID
task A100。
生成:
revision V1。
客服批准:
approved_revision=V1。
后续产生V2。
即使task仍然是A100:
V2没有批准。
必须重新审核。
二、一个具体例子
客户问:
“退款能退多少?”
AI V1:
“需要根据当前套餐和使用情况确认,我先帮您核实。”
客服批准。
此时客户又补充:
“已经用了半年。”
系统重新生成V2:
“使用半年后可能无法退款。”
如果系统直接沿用V1审批:
风险很高。
V2必须重新审核。
三、可以保存内容hash
每个revision生成:
content_hash。
批准记录绑定:
revision_id + hash。
发送前再次核对。
任何文本变化都会使批准失效。
四、WechatApi 在这里的位置
WechatApi负责:
最终发送已经审批的内容。
业务系统在进入WechatApi前必须验证:
sent_revision == approved_revision。
五、人工修改也生成新版本
客服直接编辑AI草稿。
V1 AI。
人工改成V2。
点击批准V2。
不能在V1对象上直接改text。
否则历史看不到人工改了什么。
六、主管二级审批
高风险内容可能:
客服审核;
主管审核。
两级审批都绑定同一revision。
客服批准V2。
主管批准V2。
后续V3出现:
两级全部失效。
七、上下文变化不一定必须自动生成新版本
客户新消息进入。
可以先把草稿状态:
stale。
提示人工:
“客户已有新补充,请重新生成或继续使用当前草稿。”
由业务决定。
但不能悄悄修改批准内容。
八、知识库变化也一样
草稿V1基于K10。
知识库升级K11。
如果系统自动重新生成V2:
审批失效。
历史仍然知道V1依据。
九、发送前安全门
检查:
任务有效;
会话状态;
人工接管;
客户限制;
approved_revision;
current_revision;
content_hash。
任何不一致阻断。
十、审批过期
客服上午批准。
任务晚上才发送。
期间客户情况变化。
可以给审批设置:
valid_until。
超过重新确认。
高风险场景尤其有价值。
十一、审批人权限
普通客服可以审核普通FAQ。
退款、合同等需要主管。
revision本身携带risk_level。
决定审批链。
十二、发送失败重试
已经批准V2。
第一次发送技术失败。
重试仍然发送V2。
不需要重新审批。
除非内容或业务状态变化。
十三、人工取消
审批后发现不需要发送。
状态:
cancelled。
不要删除审批历史。
以后知道曾经批准但最终取消。
十四、数据看板
AI草稿;
人工修改;
审批;
因版本变化失效;
因过期重新审核;
高风险通过率。
这些能评估AI质量和审核效率。
十五、审计
原AI版本;
人工修改;
批准人;
主管;
最终发送版本。
客户争议时完整可查。
十六、群聊更严格
群里一条内容影响多人。
审批版本和发送内容一致性更加重要。
尤其活动、价格、服务政策等。
十七、异常
系统检测:
sent_revision != approved_revision。
这是严重安全异常。
应该理论上由数据库和发送网关双重阻止。
十八、总结
个人微信二次开发里的AI人工审核,如果只是保存一个 approved=true,并不能真正保证客户收到的是人工看过的内容。
WechatApi 可以负责最终微信消息发送,而本地AI系统必须让每一次人工审批绑定具体草稿revision和内容hash。
任何模型重新生成、人工修改、上下文变化导致的新内容,都必须形成新版本并重新确认。
只有“审核的是什么,最终就发什么”被系统严格保证,AI微信机器人才能真正进入退款、合同、售后等需要人工把关的高风险业务场景。