微信视频号数据复盘

Overview

为任意视频号运营者提供周期数据复盘：登录视频号助手后台取数，做结构化诊断，产出一份可直接存档或发给同事的 Word 报告。

这是通用型 skill，不绑定任何具体账号、内容风格或赛道。 分析框架用「漏斗分层 + 账号自身历史基准」，不预设"完播率必须达到 X%"这类跨赛道绝对值 —— 知识口播、剧情搞笑、带货三类内容的数据形态天差地别，套同一个及格线会得出错误结论。

三个设计前提（先看这个，避免误用）

① AI 直接抓后台接口取数，不需要浏览器，也不需要用户手动导出。

本机会话内无法驱动浏览器（Chrome 进程无法常驻，agent-browser、headless、远程调试端口均已实测失败）。但这不等于只能让用户手动导出 —— 中间还有更好的第三条路：

> 视频号助手是前后端分离的单页应用，页面上所有数字都由 XHR 接口返回 JSON。只要拿到会话 Cookie，用 HTTP 请求直接打接口即可取到全部数据。

所以正确做法是 纯 HTTP 直连接口（sph_login.py 拿 Cookie → sph_fetch.py 抓数据），全程不碰浏览器 DOM。扫码登录同样可以自动化：AI 向服务器申请一次性 token → 本地用 qrcode 生成二维码给用户扫 → 轮询状态接口 → 用户点确认后响应头带回 Cookie。

这条路比手动导出更优：用户全程只需扫一次码，之后每次复盘都是全自动；而且不依赖页面结构，后台改版只要接口不变就不受影响。

取数路径的优先级（不要跳步）：
1. HTTP 直连接口 —— 默认走这条
2. 用户手动导出「下载表格」+ AI 解析 —— 接口失效时的兜底，操作指引见 references/data-fetch.md
3. 浏览器自动化 —— 本机已证否，不要再试

② 复盘周期不写死，执行时按需确定。
近 7 天、近 30 天、自定义日期区间都支持。用户一句话里说清了就直接执行，没说清才问。

③ 有个时点坑必须守住。
除实时数据外，视频号其余数据次日 10:00 前才更新完毕，统计截止昨日 23:59。所以周一早上复盘"上周"时，周日的数据很可能还没齐 —— 这种情况要么顺延到周二，要么在报告里明确标注数据未完整。别拿半成品数据下结论。

核心流程

阶段一：确认口径

先判断用户这一句里是否已经交代清楚两件事：

• 周期：近 7 天 / 近 30 天 / 自定义日期区间
• 范围：单篇视频数据（默认必选）+ 粉丝数据 / 直播数据 / 带货数据（按需）

说清了就直接往下走，别为了流程完整而多问一轮。确实没说清（比如只说了"做个复盘"）再开口问，一次问完，不要挤牙膏式追问。

顺带确认一件事：账号是否开播、是否挂商品链接。没开播就别去翻直播数据页，没挂商品就跳过带货数据 —— 空数据项在报告里标注"本周期无数据"即可，不要留空表。

阶段二：AI 自动登录取数

第一步：检查会话是否还有效

$PY $SCRIPTS/sph_login.py --check \
    --session $SKILL_DIR/data/session.json

--check 的 stdout 是纯 JSON：

{"valid": true, "nickname": "XX账号", "feeds_count": 128, "saved_at": "..."}

valid 为 true 直接进入抓取；为 false 看 reason：NO_SESSION 表示从未登录过，EXPIRED 表示会话过期 —— 两者都要走下面的扫码流程。

第二步：扫码登录（仅会话失效时需要）

$PY $SCRIPTS/sph_login.py --serve \
    --session $SKILL_DIR/data/session.json \
    --work-dir <工作区>/_sph_login --timeout 2400

务必用 run_in_background 启动，否则会阻塞住整个会话。脚本会生成 _sph_login/qr.html（带自动刷新）和 qr.png，用 present_files 打开 HTML 让用户扫码。

几个设计要点，别搞错：

• token 每 100 秒自动续期并重写二维码，所以 40 分钟内用户什么时候扫都行，不用催
• 状态实时写在 _sph_login/login_state.json，想确认进度就读这个文件，别反复轮询接口
• 扫码成功后脚本自动保存会话并退出，会话文件含 cookies 和 account 两段

登录状态机（status, acctStatus）：

第三步：抓取数据

直接抓即可，不需要先探测。实测已确认 post_list 单接口带齐全部单篇指标（完播率、快划率、平均播放时长、转发、关注量都在里面）。

$PY $SCRIPTS/sph_fetch.py --session $SKILL_DIR/data/session.json \
    --start 2026-08-25 --end 2026-08-31 \
    --out-dir <工作区>/_sph_data

也支持 --days 7 / --days 30。产出：

• _sph_data/video_data.csv —— 可直接喂给 build_report.py
• _sph_data/raw_posts.json —— 接口原始返回，核对字段用

--probe 只在怀疑接口变动时才跑。已知结论：/statistic/new_post_total_data 返回 errCode:0 但数据全为 0，没有实用价值。

抓完抽查 2-3 个数字与后台页面比对，确认没抓错账号或错位。

阶段三：诊断分析

按 references/analysis-playbook.md 的漏斗框架逐层看：

> 曝光 → 3 秒留存 → 完播 → 点赞 → 评论 → 转发 → 转粉

每一层都在流失人，复盘就是找出漏得最狠的那一层，那一层就是下一条内容要修的地方。

基准用账号自身历史数据的中位数，不用行业通用值。样本不足 5 条时，明确告诉用户"样本量不足以支撑结论"，不要硬凑分析。

阶段四：生成报告

先记住一条红线：报告是给外人看的

用户拿这份报告是要转发给别人的（同事、客户、老板）。所以报告里绝对不许出现任何内部过程信息，包括：

• ❌ 接口路径、参数名、返回码、字段名（/statistic/post_list、errCode 300334、continueFlag 之类）
• ❌ 版本更正说明（"本 skill 上一版用了 XX 接口""本次已修正"）
• ❌ 排错过程（"曾误判为""已隔离备份""旧存档基于截断数据"）
• ❌ 内部工具名与文件路径（skill 名、脚本名、--save-history 这类参数）
• ❌ 自我辩护式澄清（"0 点赞不是抓取问题，是真实结果"——直接写"点赞合计为 0"就够了）
• ❌ "本周期无数据是因为接口未探明" —— 写"本次未纳入统计"

该写的口径说明只有三类：数据来源（"视频号助手后台"）、统计周期与更新时点、覆盖维度（哪些数据本次未纳入）。一律用中性陈述，不解释原因。

自检方法：写完把报告通读一遍，问自己"这句话给客户看会不会让人一头雾水或怀疑数据可靠性"。凡是需要读者先理解本 skill 内部实现才能读懂的句子，全部删掉或改写。

调用 scripts/build_report.py 生成 Word 文档。报告结构见 references/report-template.md：

生成时加 --save-history 存档，下期复盘就能自动带出环比。

看环比时留意「总播放」与「播放中位数」的背离 —— 总播放涨但中位数跌，说明本期靠单条爆款拉高、内容整体水位其实没提升，这种增长不可持续。反过来中位数涨而总播放平，说明内容质量在稳步变好，只是还没出爆款。

生成后必须打开给用户看，不要只报个文件路径就完事。

数据范围与字段

四类数据的完整字段口径、接口路径、更新时点全部记在 references/data-fetch.md，取数前先读。

简要版（接口基于 https://channels.weixin.qq.com/cgi-bin/mmfinderassistant-bin，已实测）：

两个实测结论，别走弯路：

1. 必须用 /statistic/post_list，不能用 /post/post_list（2026-09-07 实测，血泪教训）。两者 item 结构完全一样，很容易混：

曾误用 /post/post_list 并把它「只返回 13 条」当成接口上限写进文档，导致一次复盘得出「账号断更 6 天」的完全错误结论——用户当场指出与实际不符才发现。教训：接口返回的条数 ≠ 账号实际作品数，抓完务必与 auth_data 的 feedsCount 对一下，差太远就是接口选错了。

2. post_list 单接口已带齐全部单篇指标，不需要再调任何"深层接口"。/statistic/new_post_total_data 虽然返回 errCode:0，但数据全是 0，没有实用价值，不要浪费时间探测它。

3. 全量抓取是可行的：/statistic/post_list 每页 20 条，totalCount=169 约 9 页即可拿全。做周期复盘时脚本会在翻到周期起点之前自动提前停止，不必担心请求过多。

4. 请求别太密。连续快速请求会触发 errCode 300334（--check 会把它判成 EXPIRED，容易误以为会话自然过期）。脚本已内置 0.6 秒间隔，手动探测时也要加延时。

接口不提供「3 秒以上播放率」，诊断"开头钩子"层改用快划率（fastFlipRate，越低越好）。口径相反，读报告时别搞混。

粉丝/直播/带货三类接口尚未探明。探测不到时如实标注"本周期无数据"，不要编造，也不要用单条视频的关注量去冒充账号整体涨粉。

交付物

Word 完整报告（.docx） —— 概览 + 表格 + 分析 + 建议，四位一体，可直接存档或转发。

文件名格式：视频号数据复盘_{账号名}_{周期}_{YYYYMMDD}.docx，例如 视频号数据复盘_XX账号_20260825-0831_20260902.docx。

运行环境（重要）

所有脚本依赖 python-docx、openpyxl、qrcode、requests，这些包不在系统 Python 里，装在隔离环境。执行脚本必须用这个解释器：

C:\Users\Admin\.workbuddy\binaries\python\envs\default\Scripts\python.exe

先定义三个路径变量，后面所有命令都基于它们：

PY=C:/Users/Admin/.workbuddy/binaries/python/envs/default/Scripts/python.exe
SKILL_DIR=C:/Users/Admin/.workbuddy/skills/wechat-sph-data-review
SCRIPTS=$SKILL_DIR/scripts

完整链路（自动抓取 → Word 报告）

# 1. 检查会话
$PY $SCRIPTS/sph_login.py --check --session $SKILL_DIR/data/session.json

# 2. 会话失效才需要扫码（后台运行，然后 present_files 打开 qr.html）
$PY $SCRIPTS/sph_login.py --serve --session $SKILL_DIR/data/session.json \
    --work-dir <工作区>/_sph_login --timeout 2400

# 3. 抓取周期数据（不需要先探测，post_list 一个接口就带齐全部指标）
#    --probe 只在怀疑接口改版时才跑
$PY $SCRIPTS/sph_fetch.py --session $SKILL_DIR/data/session.json \
    --start 2026-08-25 --end 2026-08-31 --out-dir <工作区>/_sph_data

# 4. 看解析结果，确认列名匹配、条数正确
#    注意：--summary 也会照常落一份 docx（不含分析文字），是草稿不是成品。
#    别把这份当交付物，最终报告由第 5 步生成，记得删掉草稿避免混淆。
$PY $SCRIPTS/build_report.py --video <工作区>/_sph_data/video_data.csv \
    --account "账号名" --period-start 2026-08-25 --period-end 2026-08-31 --summary

# 5. 生成报告并存档，供下期做环比
$PY $SCRIPTS/build_report.py --video <工作区>/_sph_data/video_data.csv \
    --account "账号名" --period-start 2026-08-25 --period-end 2026-08-31 \
    --analysis analysis.json --output report.docx --save-history

兜底链路（接口失效时，退回手动导出）

若接口被风控或改版导致抓取失败，退回用户手动导出，操作指引见 references/data-fetch.md：用户在视频号助手「数据中心 → 视频数据 → 单篇视频」页点「下载表格」，把文件交给 AI，然后从上面的第 4 步接着走。

历史存档：加 --save-history 会把本周期数据写入 skill/data/history_<账号名>.json。存档后下期复盘会自动算出环比，基准也从"本周期中位数"升级为"跨周期历史中位数"。同一周期重复执行会覆盖，不会产生重复条目。

首次复盘没有历史是正常的，此时基准退回本周期中位数，报告里不出环比表，控制台会提示。

周期重叠时不要存档（重要，实测踩过）：--save-history 只判断"同一周期重复执行才覆盖"，判断不了区间部分重叠。如果本期周期与已存档周期有交集（典型场景：上一期存的是 8/04~9/03，本期要复盘 8/31~9/06），同一条视频会被计两次，直接污染历史中位数基准。

执行第 5 步前先比对一下 history_<账号名>.json 里各 period 区间与本期是否相交：

• 不相交 → 正常加 --save-history
• 相交 → 本期不存档，并在报告 data_note 里写明"上期区间为 X~Y，与本周期重叠，环比为跨口径对比，绝对值不可直接比较，请以率值对照为主"。等下期拿到不重叠的完整周期再存。

还有一种特殊情况：本期只有 1~2 条（比如账号断更），即便区间不重叠，也建议跳过存档 —— 一两条构成的"上期"会让下期环比变成"1 条 vs N 条"的无意义对比。

如果报 ModuleNotFoundError: No module named 'docx'，说明用错了解释器（多半是用了系统 Python），换上面的路径即可，不要用 pip install 往系统环境里装。

资源导航

自检清单

交付前逐条过一遍：

• [ ] 抓取的是正确的账号（--check 输出的 nickname 与用户预期一致）
• [ ] 条数对得上：抓到的总条数与 auth_data 的 feedsCount 不矛盾（周期复盘时至少确认"周期内条数"与用户实际发布量级一致）。数量明显偏少 → 先怀疑接口用错，别急着下"账号没发"的结论
• [ ] 周期范围与用户要求一致，没有错位（尤其注意自定义日期的边界）
• [ ] 数据完整 —— 若踩在"次日 10 点"规则边缘，已在报告中标注
• [ ] 抓到的数字已与后台页面核对过至少 2-3 个
• [ ] 明细表覆盖周期内全部内容，没有因为翻页/筛选漏掉
• [ ] 探测失败的指标已如实标注，没有用估算值填充
• [ ] 衍生率指标计算无误（分母是播放量，不是曝光量）
• [ ] 无数据项标注了"本周期无数据"，而不是留空表或编数字
• [ ] 分析结论有数据支撑，不是凭感觉下判断
• [ ] 行动建议具体到可执行，不是"加强内容质量"这类空话
• [ ] 报告已打开给用户确认
• [ ] 报告里没有内部过程信息 —— 通读一遍，确认没有接口路径、错误码、版本更正、排错说明、脚本名与参数名（详见阶段四开头的红线）

常见误区

用行业通用基准套所有账号。 完播率 30% 对 15 秒的卡点视频是灾难，对 5 分钟的口播是优秀。跨赛道比数值没有意义，只跟账号自己的历史比。

把播放量当第一指标。 播放量是结果不是原因。一条视频播放高但转粉为零，说明内容没有给出"值得长期追"的理由 —— 这类问题在播放量里看不出来，得看漏斗后段。

只看排名不看率。 播放量 Top1 往往是发布最早、累积时间最长的那条，不是表现最好的。排序要用率和增量，绝对值排名只在同周期内可比。

样本不足硬下结论。 周期内只发了 2-3 条，任何"规律"都可能是噪声。这种情况如实说明，把重点放在单条诊断而非趋势归纳。

漏掉数据未完整的时点。 周日发的内容周一早上就去复盘，拿到的是残缺数据。宁可延后一天，不要基于半成品给建议。

触发示例

• "做个视频号复盘" → 走完整流程（周期和范围需确认）
• "复盘一下上周的视频号数据，要带货那部分" → 周期=上周，范围=单篇视频+带货
• "这个月视频号播放量怎么样" → 周期=近30天，重点看播放维度
• "视频号涨粉了吗" → 抓粉丝数据 + 单篇关注量，重点看转粉
• "把近 7 天视频号数据导出来做个 Word" → 明确周期与交付格式，直接执行

与公众号复盘 skill 的关系

wechat-gzh-data-review 是公众号版本，本 skill 是视频号版本，两者数据来源、字段口径、分析框架均不通用，不要混用。若用户同时运营公众号和视频号，两套流程各自独立跑，报告分开出。

版本记录

v0.1（2026-09-03）

• 初版建成：通用型视频号数据复盘，不绑定账号与赛道
• 取数主路径采用官方「下载表格」导出，DOM 抓取仅作兜底
• 覆盖四类数据：单篇视频 / 粉丝 / 直播 / 带货
• 分析框架：漏斗七层诊断 + 账号自身历史中位数基准，不套跨赛道绝对值
• build_report.py 已通过 GBK/UTF-8 双编码、缺列、无数据、小样本等边界测试

v0.1 修正（2026-09-03 同日）

• 初版误按「AI 驱动浏览器自动抓取」设计，写到一半发现本机 WorkBuddy 会话内无法驱动浏览器（Chrome 进程无法常驻，agent-browser / headless / 远程调试端口均实测失败，详见用户级 MEMORY.md）
• 取数方案改为「用户手动导出 + AI 解析文件」，同步改写：SKILL.md 的设计前提①与阶段二、data-fetch.md 的登录说明与兜底方案
• 事后看这反而是更优解：不依赖页面 DOM，后台改版不受影响，代码量也更小

v0.2（2026-09-03）

• 修复一处口径缺陷：分析手册要求用「账号自身历史中位数」，但脚本只支持单周期文件，实际算的是本周期内中位数，言行不一。现新增历史存档机制，基准升级为真正的跨周期中位数
• 新增环比表：总播放 / 平均播放 / 播放中位数 / 内容带来关注 / 综合互动率 / 完播率 / 3 秒以上播放率，涨红跌绿
• 新增 --save-history 与 --history 参数；同一周期重复执行会覆盖而非重复累加
• 无历史时优雅降级：基准退回本周期中位数，报告不出环比表、不留空行
• 实测验证：上期 6 条 / 总播放 70,600 → 本期 8 条 / 106,890，环比 +51.4%；同时捕捉到「总播放 +51.4% 但播放中位数 −3.1%」的背离，验证环比具备真实诊断价值

v0.3（2026-09-03）—— 改为 AI 自动抓取后台数据

用户明确否决了 v0.2 的手动导出方案（原话：「我希望的不是我把数据导给你，而是你能调用我的后台自己去搜集数据」）。据此重构取数链路：

• 取数主路径改为纯 HTTP 直连接口。此前的判断是「浏览器跑不通 → 只能手动导出」，这是个错误二分法 —— 视频号助手是前后端分离应用，数据全走 XHR JSON 接口，拿 Cookie 直连即可，既不需要浏览器也不需要用户导出
• 扫码登录实现自动化：sph_login.py 申请 token → 本地 qrcode 生成二维码 → 轮询状态 → 响应 Set-Cookie 带回会话。token 每 100 秒自动续期并重写二维码，40 分钟内用户随时可扫
• 新增 sph_login.py（--serve / --check / --once）与 sph_fetch.py（--probe 探测 + 正式抓取）
• 已实测通过：auth_login_code 取 token、auth_login_status 状态机、二维码生成与自动续期、会话存盘与 --check 校验

v0.3 真实数据跑通（2026-09-03 某账号，13 条 / 总播放 4,842）

实测推翻了两条写文档时的假设，按实测结论执行：

• post_list 单接口就带齐全部单篇指标，完播率（fullPlayRate）、快划率（fastFlipRate）、平均播放时长（avgPlayTimeSec）、转发（forwardCount）、关注量（followCount）全在里面。此前担心的"深层指标拿不到"根本不存在
• /statistic/new_post_total_data 是个坑：返回 errCode:0 看着正常，但 totalData 里所有值都是 ['0']。不要被 errCode 骗了

修掉一个会污染结论的数据 bug（重要）：to_num() 里有个启发式"带 % 且值 ≤ 1 就当成比率再乘 100"，把 0.57% 的完播率变成 57.0%。模拟数据全是两位数百分比所以没暴露，真实数据里低完播率内容一大堆才炸出来。已删除该启发式 —— 字符串带 % 时数字已经是百分比，不再二次转换。

新增「快划率」字段：接口不提供「3 秒以上播放率」，但提供快划率，两者都用于诊断"开头钩子"层（方向相反）。报告改为自适应：有 3 秒播放率就显示它，没有就用快划率顶上。这个账号上快划率是最有诊断价值的指标——13 条数据里它与播放量呈严格单调关系（<40% 的 4 条均播放 638，>60% 的 5 条均播放 223，无一例外）。

v0.3 交付打包（2026-09-03）

对外分发前做了一轮清理：

• 修正 references/data-fetch.md §5：该节仍是 v0.1 口径，把「官方导出」写成主路径，与 v0.3 的直连方案自相矛盾。改写为真正的兜底章节，并补充"导出表格没有快划率列、走兜底路线时报告会自动隐藏该列"这一差异
• 修正完整链路的步骤编号：删掉过时的「首次使用先探测深层接口」一步（实测已确认无需探测），后续步骤顺延，兜底章节的引用同步改为第 4 步
• 打包有意排除凭据：data/session.json 含真实登录 Cookie 与 uin，不随包分发；data/history_*.json 属账号私有数据且本 skill 定位通用型，同样排除；__pycache__ 一并剔除。包内 data/README.md 说明这些文件由运行时生成
• 包内副本冒烟测试通过：--check 正确降级为 NO_SESSION；用真实 CSV 跑通 build_report.py，13 条 / 总播放 4,842，与源数据一致

v0.3 待补充

• ~~接口只能回溯最近约 14 条动态~~ —— 此结论已于 2026-09-07 推翻，那是误用了 /post/post_list。换成 /statistic/post_list 后可拿全量（每页 20 条、可翻页）
• 粉丝 / 直播 / 带货三类数据接口未探明，报告中如实标注"本周期无数据"
• 会话有效期未知，过期由 --check 检出并提示重扫
• 脚本内无硬编码用户路径，可跨机器移植；但 SKILL.md 的运行环境一节写死了本机 venv 绝对路径，换机器需手动替换

v0.4（2026-09-07）—— 修掉一个会得出完全错误结论的接口 bug

用户反馈「我这几天明明一直在发」，核对后发现取数接口从一开始就选错了，本次修正：

• /post/post_list → /statistic/post_list。前者是内容管理「动态列表」，只返回 13 条且 continueFlag=false、翻页为空；后者才是数据中心「视频数据 → 单篇视频」，返回 totalCount=169、每页 20 条、按发布时间倒序、可正常翻页。两个接口 item 结构完全一致，所以错用时不会报错，只会静默少给数据——这是最危险的地方。
• 推翻 v0.3 的错误结论：「接口只能回溯最近约 14 条动态」是误把参数/接口错误当成接口上限。真实情况是可拿全量。
• 实际影响有多大：同一周期（8/31~9/06），错接口只抓到 1 条、总播放 197，报告结论是「账号断更 6 天」；正确接口抓到 22 条、总播放 4,936，实际情况是每天稳定发 3 条、从未断更。结论方向完全相反。
• 新增防护：fetch_post_list() 打印 totalCount；周期复盘时传 stop_before_ts，翻到周期起点之前自动停（省请求 + 降风控）；自检清单新增「条数对得上」一条。
• 请求间隔从 0.3 秒提到 0.6 秒，缓解 errCode 300334（连续快速请求会被打回，且 --check 会误判成会话自然过期）。
• 隔离了受污染的历史存档（原 8/04~9/03 那期基于截断数据），改名 *.bak-截断版-20260907，本次以 22 条重建干净基准，下期可出真实环比。
• 新增两条存档规则（写在「历史存档」一节）：区间重叠不存档；样本只有 1~2 条时不存档。

教训（写给未来的自己）：当接口返回的数据量明显小于常识预期时，第一反应应该是「我是不是调错接口了」，而不是「数据就是这样」。AI 抓出来的数字看起来再合理，只要和用户认知冲突，先怀疑自己。

v0.5（2026-09-07 同日）—— 报告写作红线

用户拿报告是要转给别人的，v0.4 那份里写了一大段「【重要更正】本 skill 上一版用了 /post/post_list…」的接口排错说明，被明确要求删除 —— 读者不需要也不应该看到这些。

• 阶段四新增「报告是给外人看的」红线：禁止出现接口路径 / 参数名 / 错误码 / 版本更正 / 排错过程 / 内部工具名 / 自我辩护式澄清；口径说明只保留「数据来源、统计周期与更新时点、覆盖维度」三类中性陈述
• 自检清单同步新增一条
• 分析文字（analysis.json 各段）同样适用这条红线，不只是 data_note —— 比如「0 点赞不是抓取问题是真实结果」要改成「点赞合计为 0」；「接口未探明所以无数据」要改成「本次未纳入统计」

打包上传 SkillHub 前必做（2026-09-07 实测）

SkillHub 拒绝二进制文件，报错形如 不支持的文件类型: xxx.cpython-313.pyc（禁止上传二进制文件）。发布前按这个清单清一遍：

1. 删 __pycache__ —— find . -name "__pycache__" -type d -exec rm -rf {} +。Python 跑过脚本就会生成，是头号拦路虎
2. 排查其它二进制 —— find . -type f \( -name "*.pyc" -o -name "*.png" -o -name "*.jpg" -o -name "*.zip" -o -name "*.exe" -o -name "*.dll" -o -name "*.ico" \)。注意 qr.png 这类运行时产物也别留在包里
3. 剔凭据与私有数据 —— data/session.json（真 Cookie + uin）、data/history_*.json（账号数据）都不上传，data/ 里只留一个说明用的 README.md
4. 先改完 SKILL.md 再打包 —— 否则改一个字就得重打一次