微信公众号数据复盘
Overview
本 Skill 为任意微信公众号运营者提供数据复盘能力：把后台数据整理成结构化复盘报告，反哺后续内容策略。不绑定任何特定账号或内容风格。
数据获取有两条路，优先走第 1 条：
- 自动抓取（默认）— 调用
scripts/fetch-gzh.js（文章数据）+scripts/user-analysis.js（粉丝数据），真实读取后台 - 用户提供（兜底）— 后台截图 / 复制的表格文本 / CSV、Excel
禁止在没有真实数据的情况下用模拟数据"跑一遍流程"。 用户要的是他的号，不是演示。
一、自动抓取（首选）
原理
微信公众平台「发表记录」页（cgi-bin/appmsgpublish?sub=list）是服务端渲染的，页面 <script> 里内嵌了一个完整的 JSON 对象 publish_page，结构为：
publish_page = { total_count, publish_count, masssend_count, publish_list: [ ... ] }
所以不需要解析 DOM、不需要模拟点击、不需要滚动加载——直接把这个变量取出来即可，稳定且字段齐全。
执行
node <skill目录>/scripts/fetch-gzh.js --dir=<输出目录> --max=30
node <skill目录>/scripts/user-analysis.js --dir=<输出目录>
fetch-gzh.js 参数：
| 参数 | 默认 | 说明 |
|---|---|---|
--dir= |
当前目录 | 输出目录 |
--max= |
30 | 最多翻多少页（每页 20 条发表记录） |
--chrome= |
自动探测 | chrome.exe 绝对路径 |
--profile= |
~/mp-wx-profile |
独立 Chrome 用户目录，保留登录态，只需扫码一次 |
--port= |
9555 | CDP 调试端口 |
输出文件（fetch-gzh.js）：
| 文件 | 内容 |
|---|---|
articles.json |
归一化文章列表（后续分析用这个） |
gzh_raw.json |
每页原始 publish_page，出问题时的排查依据 |
all.log |
运行日志 |
退出码：0 成功 / 2 未登录 / 1 其他失败。
未登录时怎么办（v3.1 更新：首选 wait-login2.js）
登录 token 会过期（微信安全机制，无法绕过，通常几天到几周不等）。过期后重跑 fetch 会拿不到 token，此时用扫码窗口等用户扫码：
node <skill目录>/scripts/wait-login2.js --dir=<输出目录> --wait=600
它会弹出 Chrome 登录页等用户扫码（二维码每 30 秒刷新），退出码 0=已登录 / 2=超时未扫码。扫码成功后重跑 fetch-gzh.js 即可，登录态存进 profile 长期有效。
为什么首选 wait-login2.js 而不是 wait-login.js：Chrome 154 实测发现，原脚本的 CDP 连接约 1 分钟后会出现 Runtime.evaluate 持续超时——表现为「用户明明扫了码，脚本却检测不到、最后超时退出」。wait-login2.js 增加了失联自动重连 + 连续失败 3 次自动重启 Chrome + 日志落盘（waitlogin2.log），实测 10 分钟窗口内检测全程稳定。wait-login.js 保留作备用。
无人扫码的兜底：用户不在电脑前时不要无限等。给 1~2 轮窗口（如 5 分钟 + 10 分钟）后收尾，明确告知用户「回来说一声『开始复盘』即可续跑」，并记录本次未完成的原因。不要编造数据。
粉丝数据（user-analysis.js）
粉丝数据（新关注 / 取消关注 / 净增 / 累计）不在发表记录页，在「数据 → 用户分析」页。user-analysis.js 用同一套 CDP 方案抓该页，产出三份原样数据（正式解析交给 AI，不在脚本里猜后台改版）：
| 文件 | 内容 |
|---|---|
useranalysis.html |
渲染后的完整页面（读汇总卡片 + 详细数据表） |
useranalysis_embedded.json |
页面内嵌 JSON 候选（扫 window 变量匹配关注类关键词的大对象） |
useranalysis_tables.txt |
页面所有 <table> 的 TSV 文本（逐行：日期 → 新增 → 取消 → 净增 → 累计） |
参数：--token= 可省略（自动从登录态取）；--days= 提示数据区间，默认 31。退出码同上。日志写入 user-analysis.log，末尾有页面摘要（新关注/取消/净增/累计的就近文本）可直接读。
字段映射（articles.json 每篇的字段）
| 字段 | 含义 | 来源 |
|---|---|---|
title digest link cover |
标题 / 摘要 / 原文链接 / 封面 | appmsg_info[i] |
send_time send_time_str |
发布时间戳 / YYYY-MM-DD HH:mm:ss（东八区） |
sent_info.time |
publish_date view_time status |
后台显示的日期 / 周几时刻 / 已发表·已删除·发表失败 | view |
read_num |
阅读人数 | read_num |
like_num / old_like_num |
点赞 / 在看 | like_num / old_like_num |
share_num |
分享人数 | share_num |
comment_num |
留言条数 | comment_num |
reprint_num |
转载数 | reprint_num |
moment_like_num |
朋友圈点赞 | moment_like_num |
copyright_type |
1 = 原创，0 = 非原创 |
copyright_type |
claim_source |
如「内容由AI生成」 | claim_source.claim_source |
is_deleted |
是否已删除 | appmsg_info[i].is_deleted |
> 注意：一次群发可能包含多篇图文，publish_list 的长度 ≠ 文章篇数。脚本已展开 appmsg_info 数组并按 appmsgid_itemidx 去重，所以 articles.json 的条数通常大于 total_count，这是正常的。
已知环境结论（实测沉淀，勿被旧结论误导）
- 整个流程写在一个 Node 脚本里，用
spawn(..., { detached: true })+unref()启动 Chrome，从头跑到尾再退出。不要跨多次工具调用分步执行。 - 用有头模式 + 独立 profile，不要 headless——登录态可复用，且用户能看见窗口、能扫码。
- Git Bash 调 Windows 程序务必用
C:/...风格路径，/c/...会被 MSYS 转换成C:\c\...。 Runtime.evaluate里做正则匹配曾出现「取到 URL 但页面内匹配恒为 false」。规避办法：在 Node 侧取值、Node 侧匹配（脚本已采用）。- Chrome 154 的 CDP 连接会间歇失联（约 1 分钟后 evaluate 持续超时），脚本内必须带重连逻辑（wait-login2.js 已实现；自写新脚本时注意）。
articles.json顶层是对象（{ token, total_count, count, articles }），取数组用.articles；发表记录接口无「在看」字段，「在看」=old_like_num。- 分页是真的分页：
begin=0,20,40...。
二、用户提供数据（兜底）
自动抓取失败、或用户只想复盘某个特定口径时，改用这条：
- 后台截图：发表记录页（含每篇的阅读/点赞/在看/评论/分享）+ 用户分析页（新关注/取消关注/净增）
- 复制表格文本：直接从后台页面复制粘贴
- 导出文件：CSV / Excel
字段提取规则与校验规则见 references/weekly-review.md。
三、核心流程
- 确认统计周期：用户指定；未指定则默认上周（周一 ~ 周日），并明确告知用户用的是哪个区间
- 取数：优先跑
scripts/fetch-gzh.js+scripts/user-analysis.js；失败则向用户索取 - 解析与校验：
- 从articles.json按周期过滤
- 千分位、1.2万等格式统一转数字（用户提供数据时才需要）
- 校验「净增 = 新关注 − 取消关注」等恒等式，发现矛盾先问用户，不要自行修正 - 生成《数据复盘报告》：按模板输出 → 模板见
references/weekly-review.md - 反哺内容策略：把复盘结论整理成下期内容 / 选题建议
四、数据口径
- 核心指标：阅读、点赞、在看、评论、分享、粉丝净增（= 新关注 − 取消关注）
- 可选指标：累计关注数（用于概览区展示）
- 不含收藏（如需可扩展）
- 数据缺失时：先明确告知缺哪几项，问用户是否补传；不要编造数字，也不要用估算值填充
五、报告结构
| 模块 | 内容 |
|---|---|
| ① 概览区 | 发表篇数、总阅读、平均阅读、最高/最低阅读、粉丝净增、累计关注 |
| ② 单篇明细表 | 日期、标题、内容分类（如有）、阅读、点赞、在看、评论、分享 |
| ③ 多维度分析 | 内容效果排行 / 标题规律（Top3 共性）/ 互动诊断 / 时间规律 |
| ④ 下期行动建议 | 下期优化点 + 反哺内容策略的倾斜建议 |
六、生成报告（可选）
数据量大或用户要 Word 交付时，用现成脚本搭骨架：
python <skill目录>/scripts/make_report.py --start=2026-08-24 --end=2026-08-31 --name=<账号名> --src=articles.json
脚本会自动产出：概览区表、单篇明细表（按阅读降序）、互动诊断、时段分布表、近 N 周趋势表、规则化行动建议。
依赖 python-docx（pip install python-docx）。
脚本只负责"算得出来的部分"——所有需要判断的地方它会插入 【需人工判断】 标记（3.1 排行共性、3.2 标题定性、3.4 时段结论、3.5 趋势归因、④ 补充动作、⑤ 反哺策略）。
生成后必须逐个补齐或改写这些标记，不要把带标记的稿子直接交给用户。
七、资源导航
| 文件 | 内容 | 何时读取 |
|---|---|---|
scripts/fetch-gzh.js |
文章数据抓取（Node，零依赖） | 取数时直接执行 |
scripts/user-analysis.js |
粉丝数据抓取（Node，零依赖） | 取数时紧跟执行 |
scripts/wait-login2.js |
扫码窗口（自动重连增强版） | 未登录时首选 |
scripts/wait-login.js |
扫码窗口（原版备用） | wait-login2 异常时 |
scripts/make_report.py |
Word 报告骨架生成器（python-docx） | 需要 .docx 交付时 |
references/weekly-review.md |
数据索取话术、字段提取规则、报告模板 | 生成报告时，必读 |
八、触发示例（用户会怎么说）
- "看看这周数据" / "做个周复盘" / "读一下我的公众号" → 自动抓取 + 复盘全流程
- "上周哪篇阅读最高" / "涨粉了吗" → 抓取后解析 + 回答
- "下周内容往哪个方向倾斜" → 反哺建议
