官网友情链接 wechatapi.net
个人微信二次开发接入AI以后，一个非常典型的问题是：
同一条消息重试两次，AI看到的上下文可能已经不同。
客户10:00发：
“这个怎么处理？”
系统创建AI任务。
第一次调用模型失败。
10:00:05客户又补充：
“其实是安卓端。”
10:00:06系统重试原AI任务。
如果重试时重新读取“当前上下文”，这次模型就看到了新增消息。
结果已经不再是对原任务的简单重试，而是实际上处理了一个新的上下文。
这会导致：
同一个task_id两次执行语义不同。
所以微信二次开发中的关键AI任务可以使用“业务快照”。
WechatApi 可以作为个人微信API接入层，把客户消息、附件、会话和引用带入系统。本地任务层在创建AI任务时固定当时上下文版本，后续重试仍然使用同一快照。
一、为什么任务重试应该保持输入稳定
重试的含义应该是：
同样的输入再执行一次。
如果输入变化：
应该创建新任务。
否则任务日志很难解释。
二、一个具体例子
AI任务A100创建时：
context_version=20。
输入：
M1 “登录失败”
M2 “错误1003”。
第一次模型超时。
重试时客户新增M3：
“安卓端。”
如果A100继续使用V20：
仍然处理原问题。
系统同时发现当前会话V21。
可以决定：
取消A100；
新建A101基于V21。
而不是让A100偷偷换输入。
三、快照包含什么
message_ids；
context_summary_version；
customer_profile_version；
knowledge_scope；
rule_version；
attachment_versions。
关键决策输入固定。
四、WechatApi 在这里的位置
WechatApi负责：
真实消息和附件事件。
业务任务层负责：
选择哪些事实进入本次快照。
五、不是所有任务都要完整快照
普通统计任务：
不需要。
客户可见AI回复、高风险判断、工单候选：
非常适合。
根据风险选择。
六、快照不能复制过多敏感数据
优先保存：
引用ID和版本。
必要时才保存文本摘要。
业务层通过版本读取。
避免大量重复客户隐私。
七、文件版本特别重要
AI分析PDF。
第一次使用：
file_version V1。
后来文件处理结果更新V2。
原任务重试仍使用V1，或者明确创建新任务。
否则结果无法复现。
八、知识库版本
第一次调用使用：
K10。
重试时知识库已经K11。
是用K10还是K11？
如果定义为真正重试：
继续K10。
如果要使用新知识：
创建新业务任务。
这对审计很重要。
九、Prompt版本
同样固定。
不能任务重试时恰好Prompt上线新版本，结果变化巨大。
task_snapshot里保存：
prompt_version。
十、客户资料
AI根据客户等级做回复。
任务创建时VIP。
重试时客户等级被改普通。
原任务应该使用当时快照。
但真正发送前仍要检查当前风险状态。
“生成依据”和“发送资格”可以分开。
十一、发送前为什么仍然看当前状态
快照用于保证计算可复现。
但客户已经人工接管。
即使快照任务生成成功，也不能发送。
所以：
生成使用历史快照；
发送使用当前安全状态。
两层并不矛盾。
十二、快照生命周期
任务完成后，快照可用于审计。
低风险任务一定时间后归档。
高风险消息长期保留必要版本引用。
十三、失败排查
AI回答明显错误。
查看任务快照：
当时客户只发了两条；
图片还未处理；
知识库K10。
很容易判断问题。
没有快照，只看到今天会话全部历史，很难复现。
十四、任务重放
历史规则需要重新测试。
可以选择：
使用原快照 + 新模型。
形成测试任务。
这对AI评测非常有价值。
十五、数据看板
因上下文变化取消旧任务；
快照重试；
重新生成；
平均上下文版本差。
可以优化消息聚合策略。
十六、权限
快照可能包含客户内容。
只有相关业务和技术人员按权限查看。
测试环境使用时脱敏。
十七、日志
task_id；
snapshot_id；
context_version；
model；
knowledge；
prompt。
全链可追踪。
十八、总结
个人微信二次开发中的AI任务如果每次重试都重新读取当前上下文，就会让“重试”变成一个输入不断变化的黑盒。
WechatApi 可以持续把真实微信消息和附件带入系统。
本地任务层通过业务快照固定任务创建时的消息、客户状态、知识库和Prompt版本，使同一个任务无论执行几次都拥有一致输入。
当客户上下文真正发生变化时，系统创建新任务，而不是偷偷改变旧任务语义。
这种设计让AI回复、工单候选和高风险判断真正可复现、可审计，也让重试不再成为隐藏的业务变化。
