Appearance
项目背景与目标
1. 这件事在做什么
当前项目的目标，是把第三方聊天存档页面中的会话和消息结构化采集下来，形成可查询、可分析、可对接业务系统的数据。
目前可覆盖的范围包括：
- 客户单聊会话
- 内部同事单聊会话
- 群聊会话
- 文本消息
- 图片消息链接信息
- 混合消息、撤回消息、引用消息等常见结构
本项目当前更接近“可运行的采集系统原型”，已经具备落地能力，但还没有达到完全无人值守的数据平台形态。
2. 目前已经做到什么
当前已打通的能力包括：
- 能枚举员工下的客户、同事、群聊会话
- 能分页抓取消息索引
- 能调用企业微信开放页面对应的解密接口获取消息明文
- 能按会话做增量同步，避免每次全量重抓
- 能把数据落到本地数据库
- 能识别登录失效、超时、临时失败，并记录失败会话
简单说，链路已经跑通，不再停留在验证阶段。
3. 这件事能带来什么价值
如果持续运行，后续可以支持这些业务用途：
- 聊天记录沉淀，减少只依赖页面人工查看
- 客服或销售过程复盘
- 运营跟进质量检查
- 对接内部接口，进入业务系统做统计和分析
- 后续做会话质检、关键词分析、消息看板
对于管理层来说，最大的价值不是“爬消息”本身，而是把原本散落在页面里的聊天数据，变成可持续利用的数据资产。
4. 需要准备什么
4.1 人员与协作
至少需要以下配合：
- 1 名业务负责人确认采集范围和用途
- 1 名可操作系统的人员负责登录恢复
- 1 名技术人员维护脚本、处理接口变化、优化调度
4.2 运行环境
当前阶段不需要高性能服务器，但需要稳定环境：
- 1 台长期在线的 Windows 机器
- 固定浏览器环境，用于维持登录态
- 稳定网络
- 可远程操作能力
如果当前只保存文本和图片链接，不下载图片实体，那么硬件压力很小，普通办公机即可承担。
4.3 登录态准备
当前系统运行依赖以下登录态信息：
- 第三方服务商页面 Cookie
- 企业微信开放页 Cookie
- 企业微信开放页会话凭证
- 请求头字段：
open-msg-user-sid - 请求体字段：
sid - 当前样本中两者值一致
- 请求头字段：
这意味着系统不是完全脱离人工的，需要在登录失效后人工扫码恢复。
5. 目前最大的三个问题
5.1 登录态不稳定
这是当前最核心、也是最难彻底消除的问题。
现状：
- 运行依赖浏览器登录态
- 登录失效后需要人工重新登录
- 不能承诺永久免扫码
结论：
- 这个问题不能彻底解决
- 但可以识别、告警、停机保护、人工恢复后继续跑
5.2 会话规模大，不能靠全量高频跑
客户会话数量已经非常大，继续增长是大概率事件。
现状：
- 单个员工下客户会话已超过万级
- 每个会话还有历史消息分页
- 每页消息还要再次解密
结论：
- 可以做全量补采
- 但不能把全量模式当作日常同步模式
- 日常必须改成“活跃会话优先”的增量调度
这个问题是确定可以解决的，属于调度设计问题。
5.3 数据完整性和验数体系还不够强
现状：
- 链路已打通
- 但还缺更完整的统计、对账、质量检查机制
风险：
- 会出现“会话有了，但消息没补全”
- 或“消息索引有了，但解密正文缺失”
结论：
- 这个问题也是确定可以解决的
- 需要补充统计、失败补偿、抽样验数和数据校验机制
6. 关于消息实时性
当前系统不适合定义为“严格实时消息系统”，更适合定义为“准实时同步系统”。
原因：
- 数据来自第三方页面和企业微信开放页的运行态接口
- 不是官方标准消息订阅链路
- 需要先拉消息索引，再解密明文
- 登录态、分页、重试都会带来延迟
因此，现实可达成的目标是：
- 分钟级同步
- 或小时级补齐
而不是：
- 秒级毫无延迟
- 完全实时推送
对于管理层，建议把预期定义为：
- 日常可满足业务查看和统计
- 不建议承诺毫秒级或秒级实时
7. 这件事能不能“爬全”
能。
但要区分两种场景：
7.1 全量历史补采
技术上可以做，适合：
- 首次建设时补历史
- 夜间低频跑
- 分员工、分时间段分批执行
7.2 日常运行
不适合持续全量重抓。
更合理的方式是：
- 先刷新会话列表
- 只抓今天或最近几天活跃过的会话
- 对这些会话做消息增量
- 对失败会话单独补偿
所以，“能爬全”成立，但“日常全量跑”不现实。
8. 当前最合理的运行方式
建议采用分层任务，而不是单一任务：
- 高频任务：同步今天活跃会话
- 中频任务：补扫最近几天活跃会话
- 补偿任务：重跑失败会话
- 低频任务：历史补采或专项修复
这样的好处是：
- 控制请求量
- 降低登录态中途失效的影响
- 提高日常同步的成功率
- 保证成本可控
9. 管理上应该如何判断这件事是否值得继续投入
如果项目目标是以下方向，这件事值得继续投入：
- 聊天数据沉淀为内部资产
- 客服、销售、运营过程留痕
- 后续做统计、质检、回访分析
- 对接企业内部系统和报表
如果期望是以下方向，则要谨慎：
- 完全无人值守
- 永久免扫码
- 严格实时
- 长期零维护
因为这几项不符合当前技术边界。
10. 一句话结论
这个项目已经证明“能跑通、能采集、能沉淀数据”，具备继续推进价值。
但它当前的最佳定位不是“正式稳定消息总线”，而是：
一个可以稳定运营、可人工恢复、可持续积累聊天数据的准实时采集系统。
如果继续投入，最值得优先解决的不是“能不能抓”，而是：
- 让日常增量调度更轻
- 让失败补偿更稳
- 让数据质量更容易验证
- 让登录失效后的恢复更顺畅