官网友情链接 wechatapi.net

AI 微信机器人为了降低上下文成本，通常会给客户生成长期摘要。

例如：

“客户来自杭州，关注产品A，价格敏感，曾有一次登录问题。”

下次客户再来时，AI不需要重新读取几千条历史消息。

这种设计非常实用。

但长期运行以后会出现一个新问题：

摘要本身也可能逐渐失真。

因为摘要会被再次摘要。

第一次遗漏一点。

第二次继续基于旧摘要生成。

几个月后可能已经和真实聊天存在差异。

所以个人微信二次开发中的长期客户摘要，需要“校验机制”。

WechatApi 可以作为个人微信API接入层，把真实聊天、群聊和文件持续沉淀。本地AI记忆层则保存摘要版本、来源消息范围，并周期性用原始事实校验。

一、摘要不是主数据

这是最重要原则。

客户正式公司；
负责人；
CRM阶段。

不能只存在摘要里。

摘要只是AI辅助记忆。

正式业务事实仍然来自结构化数据。

二、一个具体例子

V1摘要：

客户关注产品A。

后来客户明确说：

“不考虑A了，现在看B。”

系统生成V2。

如果V2仍然保留：

“重点关注A”。

说明摘要出现事实滞后。

校验任务可以发现：

当前结构化兴趣标签和摘要冲突。

三、摘要必须记录来源范围

summary_version V10。

来源：

messages 1000-1200；
ticket T20；
crm_snapshot C30。

这样可以重新生成和验证。

四、WechatApi 在这里的位置

WechatApi负责：

原始聊天事实。

摘要系统只是派生层。

原始数据不能被摘要替代。

五、周期性重建

不要永远：

旧摘要 + 新消息 → 新摘要。

每隔一定版本，比如10次，可以：

从可信结构化数据 + 最近重要历史重新生成。

减少累计误差。

六、关键事实校验

摘要里出现：

客户公司；
产品；
负责人。

系统可以和正式字段比对。

冲突时：

以正式数据为准。

摘要进入重建。

七、客户纠错消息优先

客户明确说：

“之前那个不是我的公司。”

这种纠错事件应该标记为高权重。

新摘要不能继续引用旧事实。

八、人工修正

客服发现摘要错误。

可以编辑。

形成：

human_verified_summary。

AI后续更新时保留人工确认事实，除非有新的明确证据。

九、摘要内容分类

长期稳定事实；
近期状态；
服务历史；
沟通偏好。

不同信息生命周期不同。

“本周出差”不能半年后还在摘要里。

十、过期字段

temporary_fact带：

expires_at。

生成新摘要时自动移除。

十一、摘要冲突

CRM说：

客户已成交。

摘要：

高意向未成交。

系统检测：

summary_conflict。

自动重建。

十二、群聊信息

客户在群里说了一句可能只是场景表达。

长期摘要使用时降低权重。

人工确认和CRM事实更高。

十三、隐私

长期摘要集中很多客户信息。

权限甚至应该比普通单条聊天更谨慎。

AI调用时只提供必要摘要。

十四、数据看板

摘要数量；
人工修正；
自动重建；
冲突；
平均版本；
过期事实清理。

可以评估AI记忆质量。

十五、模型升级

更好的模型上线。

可以对重点客户摘要批量重建。

但旧版本保留。

便于比较。

十六、摘要版本不能覆盖历史

V1、V2、V3。

当前指向latest。

历史可以审计。

十七、AI回答日志记录摘要版本

以后错误回复出现。

知道当时模型看到的是：

summary V12。

能判断是否摘要导致。

十八、总结

个人微信二次开发中的长期摘要可以大幅降低AI上下文成本，但它本质上仍然是一份机器生成的派生数据。

WechatApi 可以持续保留真实微信聊天、群聊和文件事实。

本地AI记忆层则通过来源范围、摘要版本、正式字段校验、周期性重建和人工修正，防止摘要经过多次压缩以后逐渐偏离真实客户。

真正可靠的AI长期记忆不是“生成一次摘要以后一直相信”，而是始终知道摘要可能出错，并且有原始数据和结构化事实可以定期把它拉回正确状态。