官网友情链接： wecomapi.com
企微外部群群发任务中，大多数团队都会保存：
群发文案；
素材；
目标群；
执行结果。
看起来已经足够。
但真正发生客户投诉或历史复盘时，会出现一个很实际的问题：
后台现在看到的内容，真的是当时发送的内容吗？
例如一份PDF资料后续被覆盖。
一张海报重新上传。
群发模板正文被运营修改。
如果历史任务只是引用“当前素材 ID”或“当前模板 ID”，几个月后打开任务看到的可能已经是新版本。
这会导致：
历史无法真实还原。
所以企微开发API中的群发任务，需要不仅保存“引用”，还要保存内容快照和内容校验信息。
WeComApi 可以作为企微API接入层，提供外部群、消息和素材能力。本地群发系统则通过文本快照、素材版本、内容哈希保证历史可追溯。
一、为什么只保存 template_id 不够
任务T1001引用：
template_id = 20。
三个月后模板20被修改。
历史任务仍然显示模板20。
打开以后看到的是今天内容。
不是三个月前。
这就是引用可变对象的问题。
二、创建任务时生成内容快照
快照包括：
文本；
链接；
图片版本；
文件版本；
发送参数。
一旦审核通过：
快照锁定。
后续模板变化不影响历史。
三、内容哈希有什么价值
可以对最终发送内容生成：
content_hash。
例如基于：
文本 + 素材文件哈希 + 链接参数。
未来复盘时可以验证：
当前历史快照是否被修改过。
哈希不一定用于安全签名，也可以作为内容一致性标识。
四、一个具体例子
9月1日群发：
正文 A；
海报 V3；
PDF V2。
系统生成：
snapshot S1001；
content_hash HABC。
9月10日海报升级V4。
PDF升级V3。
历史任务仍然引用：
V3海报；
V2 PDF。
重新计算历史快照：
仍然得到 HABC。
这说明历史内容没有变化。
五、素材文件必须不可原地覆盖
如果 V3 文件直接在存储层被覆盖成新文件，版本管理也失去意义。
所以文件资源最好使用：
immutable resource。
新内容：
新 file_id。
旧文件保留。
六、文案模板也要版本化
template V1；
V2；
V3。
群发任务引用：
template_version_id。
不要只引用模板主体。
七、审核必须基于最终快照
审核页面展示：
最终文案；
最终素材；
最终目标。
审核通过以后锁定。
如果任何一个关键内容变化：
审核失效。
重新审核。
八、目标快照和内容快照要同时存在
只有内容快照，没有目标快照：
不知道发给谁。
只有目标快照，没有内容：
不知道发了什么。
完整群发历史需要两者。
九、执行结果也要绑定快照版本
每个目标群结果：
task_version；
snapshot_id；
sent_at；
status。
这样补偿时仍然使用原版本。
十、补偿任务不能默认使用最新内容
原任务部分群失败。
第二天补发。
此时模板已经更新。
补偿应该继续使用原快照。
否则同一批任务不同群收到不同版本内容。
如果业务明确希望使用新版本：
创建新任务。
十一、WeComApi 在这里的位置
WeComApi 负责：
企微开发API；
外部群；
消息发送；
素材能力。
业务系统负责：
模板；
版本；
快照；
哈希；
审核；
结果。
十二、文件过期和历史审计
即使底层发送资源有时效性。
本地历史系统仍然应该保存可审计副本或素材版本。
否则后续只剩一个失效资源ID。
十三、权限
运营可以编辑草稿。
审核后不能修改。
需要修改则创建新版本。
管理员也不应该直接覆盖历史快照。
十四、历史任务只读
已完成任务最好进入只读。
任何修改通过：
纠正记录；
补充说明。
而不是直接改原历史。
这样审计可信。
十五、客户投诉场景
客户说：
“你们9月1日发给我的活动时间写的是8点。”
系统打开历史：
目标群；
正文；
海报V3；
PDFV2；
内容hash。
可以真实确认当时内容。
这就是可追溯价值。
十六、日志
记录：
模板创建；
版本变化；
任务快照；
审核；
执行；
补偿。
全链路连接。
十七、数据生命周期
历史素材不能无限全部放热存储。
可以进入归档。
但引用和版本不能断。
必要时仍然能恢复查看。
十八、总结
企微开发API做群发，真正高质量的系统不能只记录：
“发送成功”。
还应该能回答：
当时给谁发；
具体发了什么；
使用哪个素材版本；
审核的是不是同一内容；
补偿是否仍然使用原版本。
WeComApi 可以提供外部群和消息能力。
本地系统通过：
内容快照；
素材版本；
目标快照；
内容哈希；
历史只读；
保证群发任务几年以后仍然可以真实还原。
只有“历史看到的就是当时实际发送的”，群发任务才真正具备企业级审计能力。
