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

### 执行侧（Phase 4）
1. **Token 预飞**：TikHub + VOC Skill 双平台凭据检查
2. **分批执行**：按 batch=1|2|3 顺序跑，看审计日志
3. **合并 + 自检**：`_merged.json` + 跑 `audit` 初步检查
4. **补采回路**：如果某假设覆盖不足，回到 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 预飞

```powershell
# 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

---

## 🚀 正式执行命令

```powershell
# 分批执行（推荐）
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`

---

## ⚠️ 常见失误

1. **kw 量级错位**：给小众品一次采 50 个 kw → 大量 kw 返回 0 条；给热门品只采 5 个 kw → 假设覆盖不足
2. **所有 kw 都走一个平台**：XHS 跑 30 个 kw，抖音 1 个都没 → 报告单一平台偏见
3. **没跑 --merge**：章节模块读不到数据 → 渲染阶段全是 Coming Soon
4. **不看审计日志**：跑完不看 `audit.log` → 后续发现一半 ERR
5. **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`