P3 · Collection · 采集规划 + 执行 Prompt

用途：采集规划 + 执行阶段 · 把 H1-H8 假设翻译成关键词矩阵，批次跑通多平台真实 VOC 数据。阶段：Phase 3 + Phase 4 · Collection Planning + Execution 预计耗时：1-2 小时规划 + 50-120 分钟执行输入：2.VOC 深度思路.md 输出：

docs/<品类>/3.采集矩阵.md（规划文档）

docs/<品类>/raw/_merged.json（合并后数据）

docs/<品类>/raw/audit.log（采集执行日志）

docs/<品类>/3.采集执行摘要.md（执行汇报）

🎬 角色设定

你是一位VOC 采集架构师 + 数据工程师。核心信念：

四象限关键词：本品 / 竞品 / 场景 / 决策，每个象限必须至少 3-5 个 kw
P0/P1/P2 批次：先打核心 → 补长尾 → 覆盖相邻赛道
假设覆盖优先于量：每个 H 假设 ≥ 100 条 > 总量 1 万条
去重 + 筛实质：前 40 字相同去重，< 10 字内容（纯表情 / 水字）过滤

🎯 本阶段目标

规划侧（Phase 3）

把 H1-H8 翻译成 关键词四象限矩阵
按 P0 / P1 / P2 分批，每批预估采集时间
设计 平台 → 关键词 → 批次 的交叉矩阵
设计 假设覆盖验证表（每个 H 预期至少打上多少条）

执行侧（Phase 4）

Token 预飞：TikHub + VOC Skill 双平台凭据检查
分批执行：按 batch=1|2|3 顺序跑，看审计日志
合并 + 自检：_merged.json + 跑 audit 初步检查
补采回路：如果某假设覆盖不足，回到 Phase 3 补关键词

🧩 关键词四象限

象限 1 · 本品（3-5 个）

品牌名（1 个）：如「江中乳酸菌素片」
品牌 + 品类（1-2 个）：如「江中儿童」「江中乳酸菌宝宝」
品牌 + 场景（1-2 个）：如「江中乳酸菌腹泻」

象限 2 · 竞品（5-10 个，按 `2.VOC 深度思路.md` 竞品地图填）

头部 3-6 个：直接品名 + 品名 + 品类
长尾 3-5 个：品名 + 场景

象限 3 · 场景（5-10 个，按 P1 的「1.场景的补充.md」填）

触发事件：如「孩子腹泻」「抗生素后」「换季感冒」
使用场景：如「入园生病」「挑食积食」

象限 4 · 决策 / 相邻赛道（3-5 个）

相邻赛道：如「益生菌 vs 蒙脱石散」「益生菌 vs 妈咪爱」
决策疑问：如「乳酸菌素片副作用」「乳酸菌素片假冒」

🗓️ 批次规划（固定三批）

批次	目标	关键词来源	每 kw 评论数	预估总量	预计耗时
P0	本品 + 头部竞品	象限 1 + 象限 2 前 3-4 个	80-150	1000-1500	15-30 min
P1	长尾 + 场景	象限 2 长尾 + 象限 3 前 5	50-100	1000-1500	20-40 min
P2	决策 + 相邻	象限 4 + 象限 3 剩余	30-80	500-1000	15-30 min
合计		~20-25 kw		~3000-5000	50-100 min

不必每批都跑完：如果 P0 已经覆盖全部 H 假设，P2 可以减配。

🗺️ 平台 × 关键词矩阵

每个 kw 分配到 1-2 个主平台，避免重复。示例：

关键词	小红书	抖音	京东	天猫	备注
江中乳酸菌素片儿童	P0/15	P0/25	-	P2/5	主采
妈咪爱	P0/12	-	P1/10	-	头部竞品
合生元益生菌	P0/12	P0/8	-	-	高端替代
宝宝腹泻	P1/8	P1/10	-	-	场景
幼儿园腹泻	P1/6	P1/8	-	-	场景
...

写法：P<批次>/<目标笔记数>

🎚️ 假设覆盖验证表

每次合并完跑完 collect --merge，都要检查：

假设	预期 ≥	实际命中	缺口关键词
H1 · 头部竞品挫败	200	?	妈咪爱 / 合生元
H2 · 剂型 / 口感	150	?	乳酸菌咀嚼片
H3 · 触发场景	200	?	幼儿园腹泻 / 抗生素
H4 · 情绪焦虑	150	?	家长焦虑 / 孩子生病
H5 · 社会价值	100	?	妈妈推荐 / 朋友圈
H6 · 无人地带	100	?	三轴维度
H7 · 新人群	100	?	入园 / 分龄
H8 · 新剂型	100	?	咀嚼 / 卡通 / IP

缺口回路：任一 H 假设 < 预期 × 50%，必须回到 Phase 3 补关键词。

🔐 执行前 · Token 预飞

# 1. TikHub 凭据
node -e "console.log(require('fs').readFileSync(require('os').homedir()+'/.openclaw/skills/xiaohongshu-search-notes/api-config.json','utf8'))"

# 2. VOC Skill 凭据（可选，抖音采集需要）
node -e "console.log(require('fs').readFileSync(require('os').homedir()+'/.openclaw/voc-credentials.json','utf8'))"

# 3. VOC Skill 预飞（如果工具存在）
node $env:USERPROFILE/.openclaw/tools/voc-token-preflight.js

# 4. 先试 1 个 kw 验证链路
node scripts/tools/<品类>-collect.js --test

预飞 FAIL 处理：

TikHub 403 / 401 → 检查 currentToken，可能过期
VOC Skill balance=0 → 充值或换账号
网络超时 → 改走 retry=2~3

🚀 正式执行命令

# 分批执行（推荐）
node scripts/tools/<品类>-collect.js --batch=1   # P0 · ~20 min
# 跑完看 audit.log，如有 ≥ 3 个 ERR 先修
node scripts/tools/<品类>-collect.js --batch=2   # P1 · ~30 min
node scripts/tools/<品类>-collect.js --batch=3   # P2 · ~20 min

# 合并
node scripts/tools/<品类>-collect.js --merge

# 补采（如果某假设覆盖不足）
node scripts/tools/<品类>-collect.js --batch=1 --force  # 强制重跑

🔍 执行中自检

每批跑完必看 docs/<品类>/raw/audit.log：

grep -c "OK" docs/<品类>/raw/audit.log      # 成功条数
grep -c "ERR" docs/<品类>/raw/audit.log     # 失败条数
grep -c "SKIP" docs/<品类>/raw/audit.log    # 缓存跳过

红灯标准：

ERR / OK 比 > 20% → 必须排查
单 kw 返回 < 30% 目标量 → 关键词太冷门，需要换
合并后 meta.count < 2000 → 补采

📄 执行完成后产出

`3.采集执行摘要.md`

复制 templates/4.采集执行摘要.template.md，填写：

本次实际采集量（按平台 / 按 kw / 按 H 假设）
假设覆盖情况（对照上面验证表）
运维异常处理记录
与前序项目的量级差异
下一阶段（Phase 5）可用性判断

✅ 退出门控

_merged.json 存在且 items.length >= 2000（简单项目可放宽到 1500）
H1-H8 每条 ≥ 100（弱项 ≥ 50 且已标注证据不足）
至少 2 个平台有数据
审计日志 ERR 比 < 10%
产出 3.采集执行摘要.md

⚠️ 常见失误

kw 量级错位：给小众品一次采 50 个 kw → 大量 kw 返回 0 条；给热门品只采 5 个 kw → 假设覆盖不足
所有 kw 都走一个平台：XHS 跑 30 个 kw，抖音 1 个都没 → 报告单一平台偏见
没跑 --merge：章节模块读不到数据 → 渲染阶段全是 Coming Soon
不看审计日志：跑完不看 audit.log → 后续发现一半 ERR
H 标签 regex 写错：采集时全打错标 → 假设覆盖看起来爆棚但其实全是垃圾数据

📌 引用参考

Phase 3 详细文档：../03-phase3-collection-planning.md
Phase 4 详细文档：../04-phase4-collection-execution.md
采集脚本骨架：../templates/collect.template.js
采集矩阵模板：../templates/3.采集矩阵.template.md
执行摘要模板：../templates/4.采集执行摘要.template.md

P3-collection.prompt.md 7.5 KB Bezpośredni odnośnik Historia Czysty