微信聊天记录全量分析
本技能解决一个具体问题：微信本地库是加密的、结构非标的、消息是噪音密集的，直接读不了也读不完。
把"解密 → 导出 → 排序 → 提炼 → 出结论"这条链路固化成可重复执行的流程。
与常见"微信读取"类工具的关键差异：
| 环节 | 常见做法 | 本技能做法 |
|---|---|---|
| 密钥 | 从进程内存提取，或对候选做 PBKDF2 | 密钥由使用者自备，只做 HMAC 校验（不碰任何其他进程） |
| 分析 | 按时间顺序堆砌消息摘要 | 五层提炼法（已签/丢单/机会/人/环境）+ 业务价值打分排序 |
| 输出 | 一段文字总结 | 结论先行 + 联系人分级 + P0/P1/P2 行动清单 + 可编辑台账 |
何时使用
- "分析我最近 N 个月的微信聊天记录"
- "这周我都忙了些什么"（周期性复盘）
- "哪些客户/群对我最有价值""哪些群可以退"
- "把这个月的沟通整理成报告"
- 需要从聊天记录里找回某个项目/报价/联系方式的上下文
不适用：只需查某个联系人的电话或某条消息 → 直接 grep 导出文本即可，不必走全流程。
前置条件
- Windows，微信 4.0+（4.1.x 已实测通过），数据库已落盘
- Python 3.10+
pip install pycryptodome zstandard（AES 与消息解压）- 一份可用的数据库密钥（64 位 hex）。密钥从哪里来由使用者自行决定并自行负责，本技能只接受、只校验、只使用
> 本技能不需要管理员权限，不读取微信进程内存，不注入、不挂钩、不修改微信任何文件。
> 密钥处理细则见 references/key-handling.md。
先跑环境探测，确认各项都满足再继续：
python scripts/wechat_export.py env
输出会给出：检测到的账号目录、哪个是当前活跃账号、库文件数与体量、依赖是否齐。
多账号环境务必确认"当前活跃"那个就是用户想分析的账号——密钥只对生成它的那个账号有效。
工作流
第 1 步：准备并校验密钥
密钥两种给法，任选其一：
# A. 单库/同密钥：直接给
python scripts/wechat_export.py verify --key <64位hex>
# B. 多库不同密钥：给一份映射文件
python scripts/wechat_export.py verify --keys my_keys.json
my_keys.json 格式（键是库的相对路径，可以是单个 hex，也可以带 enc_key 字段）：
{
"message/message_0.db": "028ab9c7d1644905154a05ebeed0c93b9aabef6b1f9cda2b051f3958bab8d91c",
"contact/contact.db": { "enc_key": "…64位hex…" }
}
verify 只读每个库的第 1 页做 HMAC 校验，不解密、不写盘、不碰进程，几秒出结果：
[*] 待校验库 41 个
[+] 校验完成：通过 41 / 不通过 0
全部通过，可以执行 decrypt
有不匹配时会逐个点名，并给出汇总：
[MISMATCH] contact/contact.db 密钥校验未通过
[+] 校验完成：通过 40 / 不通过 1
校验失败：确认密钥属于当前登录账号；不同账号密钥不通用
出现 [MISMATCH] 时按此顺序排查：密钥是否属于当前账号 → 多账号目录是否选错 → hex 是否复制不全（应为 64 位）。
若确认密钥无误仍全部失败，几乎一定是把"明文 key"当成了"passphrase 去派生"，见 references/database-and-crypto.md 第 6 节。
第 2 步：解密
python scripts/wechat_export.py decrypt --key <64位hex> --dec-dir wxdec
# 或：--keys my_keys.json
逐页 AES-256-CBC。每个库先做 page1 HMAC 校验，通过才解，校验不过直接跳过并报 [MISMATCH]，不会产出坏库。0.8GB 约 1–2 分钟。
解密 + 导出也可一步到位：python scripts/wechat_export.py all --key <64位hex> --days 30。
第 3 步：导出消息
python scripts/wechat_export.py extract --dec-dir wxdec --out-dir wxout --days 62
产出：
- wxout/all.json — 结构化全量消息（发言人、时间戳、类型、文本）
- wxout/conv/*.txt — 每会话一个可读文本，文件名前缀是消息条数（便于排序）
- 自动解析 type 49 的标题/摘要/引用，把链接渲染成 [链接] 标题 | 摘要，引用渲染成 <<引用:...>>
--days 决定时间窗：周复盘 7、月度 30、季度 90。
第 4 步：打分与分级
python scripts/wechat_analyze.py --in wxout/all.json --out wxout
产出 rank.json（会话业务价值排序）与 digest.md（优先读这个）：消息类型分布、按月分布、业务价值 Top N、生活/家庭相关会话、零业务会话清单。
业务命中前 20 的会话通常占全部业务信息的 70%–90%——这就是"不要平均用力"的依据。
关键词表可按行业替换：--keywords my_kw.json（格式 {"分类": ["词", ...]}）。
第 5 步：精读并提炼
按 references/analysis-playbook.md 的五层提炼法执行：
- 已签/在交付 → 交期、到货款、卡在谁手里
- 丢单/受阻 → 死于价格、手续还是资格
- 新机会 → 按窗口紧迫度排序，不按规模
- 人 → S/A/B 分级，判据是"说过的话有没有改变过你的动作"
- 环境 → 价格锚、政策变化、内部风向，一律转成"对客户说的话"
精读顺序：先读 digest.md → 完整读业务 Top 5–10 会话 → 其余用 grep 定位：
grep -nE "报价|合同|交期|交付|回款|中标|招标|业主|签约|违约|罚则" wxout/conv/<文件>.txt
grep -oE "\[链接\].*" wxout/conv/<情报群>.txt | sort -u
第 6 步：出报告
以 assets/report_template.md 为骨架写 Markdown，再按用户偏好导出 PDF（本机若有 md2pdf_kb.py 则复用，否则用 docx/HTML）。
报告必须包含：结论先行 → 数据底座 → 五层提炼 → 联系人分级 → 结论 → P0/P1/P2 行动清单 → 方法与局限。
用户若需要可编辑版本，另出一份 xlsx，典型 4 个 sheet：联系人与群分级、项目台账、情报清单、行动清单。
周期性复盘的特征
用户把本技能设为自动任务时，通常要求"每周总结这周的重要工作和生活内容"。此时：
- 时间窗
--days 8（覆盖上周一至本周一，防漏） - 周复盘只做第 1 层（交付与回款）+ 本周新增机会 + 下周 P0，控制在一屏内
- 生活维度单独一节，只写"需要我处理的事"（家人健康、子女教育、家庭事务、个人状态），不写流水账
- 结论要能直接复制进周报，不要过程描述
常见问题
| 现象 | 原因 | 处理 |
|---|---|---|
verify 全部 [MISMATCH] |
把明文 key 当 passphrase 做了 PBKDF2；或 hex 复制不全 | 见 references/database-and-crypto.md 第 6 节；确认 hex 为 64 位 |
verify 部分 [MISMATCH] |
密钥属于另一个账号 | 多账号目录选错，用 --db-dir 指定 |
decrypt 大量 [SKIP] 无对应密钥 |
只给了 --key 但各库密钥不同 |
改用 --keys 逐库给出 |
| 最新消息停在几小时前 | 消息在 WAL 未 checkpoint | 退出微信重解，或解 WAL 帧 |
| 部分消息是乱码 | WCDB_CT_message_content 压缩未解 |
装 zstandard |
| 解密成功但 sqlite 打不开 | AES padding 处理错误 | 确认为无 padding 的 CBC |
| 语音/图片无内容 | 本来就不在文本列 | 属已知盲区，在报告"局限"里声明 |
边界
- 所有数据仅在本机处理，不上传、不外发
- 导出的
wxdec/、wxout/含全量私密内容，分析完成后应提示用户删除或自行保管 - 密钥只在本进程内使用，不写盘、不缓存、不打印明文；使用者自行提供的密钥文件请勿提交到任何仓库
- 本技能不提取密钥、不读取其他进程内存、不注入微信进程、不修改微信文件——密钥来源由使用者自己决定并自负责任，详见
references/key-handling.md - 本技能只读，不提供发送消息能力
