工蜂爆款笔记采集【星元科技·WorkerBee·出品】
前置：拿到工蜂接口的 base_url 和钥匙（用户从工蜂 设置 → 接口开放 复制「给 AI 的说明」粘给你，或读 discovery 文件 <appData>/工蜂/api.json；接口说明书在 GET /api/docs）。下文 $BASE/$KEY 指代它们。
第 0 步：先问清能力，再决定怎么打（不许跳过）
这套流程里有两个环节依赖用户手上有没有特定条件。不问清就开工，很可能白干一场。
一次性把两个问题问完，别挤牙膏：
> 开工前确认两件事，决定用哪条路线：
>
> 1. 你有小红书蓝V（企业认证）账号、能登录蒲公英后台吗？
> 笔记的阅读数只有蒲公英看得到，小红书公开页面不给。有蓝V才能按阅读数筛爆款。
>
> 2. 你有 root 过的安卓手机（并且在工蜂里配好了）吗？
> 有的话找博主 UID 会快很多（秒级抓搜索接口）；没有也能做，用普通手机跑，慢一些。
两个问题的答案决定下面两处分支，其余流程完全一样。
分支 A：找 UID 用哪条路
| 用户有 root 手机 | 用 root_keyword_search——秒级抓搜索接口，一次几十个 UID，不占普通手机 |
|---|---|
| 没有 root 手机 | 用 creator_discovery——普通手机扫笔记流，慢一些但结果一样能用 |
不要因为用户没 root 就说做不了，这只是快慢差别。
分支 B：按什么筛爆款
| 用户有蓝V | 按阅读数筛（默认阈值 300，跟用户确认）——最准 |
|---|---|
| 没有蓝V | 按互动热度筛：赞 + 藏×2 + 评×5。如实说明拿不到曝光/阅读数据 |
没蓝V时要主动说清楚：
> 没有蓝V就看不到阅读数，但不影响做爆款研究——改用互动热度排序，对多数选题够用了。
> 真正非要阅读数的场景是跟品牌方汇报 CPM/曝光量。你是哪种需求？
蒲公英导出还要看工具能力
即使用户有蓝V，还得看你（AI）能不能驱动一个已登录蒲公英的浏览器：
- 能（如 Codex 桌面端内置
@Browser，需在 设置 → Browser → Developer mode 开完整 CDP）：
加载pgy-notes-export技能执行导出，优先解析页面原生请求，不要逐个点击。 - 不能（多数命令行 AI）：直说，请用户自己在蒲公英后台导出 Excel 交给你，其余流程照常。
别硬撑——假装能做然后卡住，比一开始就说清楚糟糕得多。
完整流程
1. 找到这个行业的博主 UID
有 root 手机：
curl -s -X POST "$BASE/api/local/tasks/advanced" -H "X-Api-Key: $KEY" \
-H "Content-Type: application/json" \
-d '{"task_type":"root_keyword_search","keyword":"行业词","pages":3,"device_serial":"<root机序列号>"}'
设备序列号从 GET /api/state 的 devices[] 里找。UID 在结果的 notes[].user_id 和顶层 uids。
没有 root 手机：
curl -s -X POST "$BASE/api/local/tasks/advanced" -H "X-Api-Key: $KEY" \
-H "Content-Type: application/json" \
-d '{"task_type":"creator_discovery","keywords":["行业词"],"note_limit_per_keyword":30,"max_scrolls":10}'
两条路的共同要点：
- 目标按「每个关键词拿到 N 个不同 UID」表达，不是「扫 N 张卡片」。卡片会重复，UID 才是产出。
- 默认每轮只跑 1-2 个词，看完战况再定下一轮，别一次堆十个泛词。
- 跨关键词全局去重，同时记住每个 UID 的首次来源词和所有命中词。
- 明显无业务关系的素人生活内容先排除，再统计新增 UID。
- 用「累计不同 UID / 当轮新增 / 重复率 / 边际新增率」判断收敛——新增趋近于零就该停，
不是跑满页数才停。用户说停止扩词就立刻冻结 UID 库。 - 下一轮关键词从上一轮的标题、卡片文本、城市、服务场景裂变而来，禁止无依据堆泛词。
2. 蒲公英按 UID 导出笔记元数据（需蓝V）
一个 UID 一个 Excel，统一放同一目录。要拿到的字段：
标题 / note_id / 发布时间 / 笔记类型 / 曝光数 / 阅读数 / 点赞 / 互动 / 收藏 / 粉丝数 / 地区 / 图片URL / 来源UID。
保留失败清单；少数 UID 导不出就继续走，不要为此重跑全部 UID。
3. 筛爆款候选（严格按顺序）
- 热度门槛：有蓝V按
阅读数 > 阈值（默认 300）；没蓝V按互动热度排序取头部 - 标题/元数据的业务相关性——跟用户的行业真的有关吗
- 地域优先级（用户有地域偏好时）
- note_id 去重
通过筛选的全部列入「爆款候选_全量」。
「Top 30」是交付批次，不是筛选标准——不许从全量里无依据抽 30 条充数。
4. 深采候选笔记
只深采候选 note_id，不要把博主所有帖子都采一遍（白费手机和额度）。
curl -s -X POST "$BASE/api/local/tasks/batch" -H "X-Api-Key: $KEY" \
-H "Content-Type: application/json" \
-d '{"pool":"池名","keywords":["https://www.xiaohongshu.com/explore/<note_id>"],"limit":1}'
- 短链必须先解析成
https://www.xiaohongshu.com/explore/<note_id>再建单，
否则xhslink.com/m/会被判成商品任务。 - 用在线且空闲的普通手机并行；root 设备只在空闲且用户允许时才参与深采。
- 深采字段追加在候选行后面，不要把候选表替换成只有深采字段的新表。
5. 质检（每条合格记录都要满足）
- note_id 唯一
- 最终笔记链接优先用 App 分享短链
- 正文存在，或明确记录「平台确实无正文」
- 封面链接非空；视频笔记的
video_url非空 - 笔记标签只从正文
#话题提取——蒲公英的分类/筛选标签不是笔记标签 - 主页链接是
xiaohongshu.com/user/profile/<UID>，不是蒲公英链接 - 重采合并时保留旧的非空字段，别为补一列覆盖整行
partial_missing_cover/video/body 是内容字段缺口，不是设备故障——允许重试换机，
但别因此把正常手机判成坏的。
字段清单与飞书类型见 references/field-contract.md。
6. 写回飞书
用固化模板端点，不要自己拼字段调飞书 API：
curl -s -X POST "$BASE/api/feishu/export" -H "X-Api-Key: $KEY" \
-H "Content-Type: application/json" \
-d '{"task_ids":[深采任务号...],"template":"note","table_name":"行业爆款笔记"}'
服务端会建齐笔记模板字段、把封面下载成附件、多选标签回读校验、把表移交给用户。
详见 workerbee-feishu-delivery。
蒲公英特有字段（曝光数/阅读数/粉丝数）模板里没有——让用户在飞书表里自行加列，
或在汇报里以表格给出，不要为此绕开端点自建表。
写完必须回读确认，给出可点击的飞书链接。
完成门槛（都满足才能说做完）
- 关键词、不同 UID 数、每轮新增、收敛依据可追溯
- 每个关键词达到约定的 UID 目标；没达到就如实报缺口，不许标成完成
- 有蓝V时：每个 UID 有蒲公英导出结果或在失败清单里
- 候选筛选有通过/拒绝原因
- 全量候选都已深采或有明确失败原因
- 封面缺失 0；视频笔记视频链接缺失 0
- 正文标签与正文提取结果一致
- 飞书回读差异为 0，给出可点击链接
- 手机已释放，无遗留 running 任务
禁止事项
- 没问清蓝V和 root 就开工——这是最容易白干一场的地方
- 因为用户没 root 就说这事做不了（只是慢一点）
- 把搜索卡片数当作不同 UID 数
- 从搜索页的用户名猜 UID
- 把蒲公英的分类/筛选标签写成笔记标签
- 把裸短链直接丢给任务分类器
- 从全量候选里无依据抽 30 条当交付
- 没回读飞书就报告「已写入」
- 阅读数拿不到时编一个——拿不到就说拿不到，改用互动指标并讲明区别
