# 02. 标准化报告工作流：从人工快速出报告到 VOC Report Factory

## 目标

把现有“人工快速出报告”的经验沉淀成可培训、可复用、可审计、可交付的 **VOC Report Factory 标准工作流**。

该工作流适用于三类场景：

- **内部交付**：让不同成员按照同一标准完成企业 VOC 报告。
- **课程训练**：让学员从一次案例实操中掌握完整报告生产链路。
- **技能产品化**：为 `voc-report-factory` 套件提供 SOP、模板和后续 skill 抽象依据。

## 核心原则

1. **先定义问题，再采数据**：不能先抓一堆数据再找结论。
2. **先有假设，再有矩阵**：每个关键词、平台、批次都必须对应 H1-H8 假设。
3. **先保留证据，再写洞察**：每个结论必须能回溯到 VOC 原声、平台、关键词、批次。
4. **先审计，再交付**：没有经过完整 audit 的 HTML 报告不能对外交付。
5. **人机协同，不是全自动**：AI 负责规模化采集、整理、归纳，人负责业务判断、章节逻辑和最终质量。

## 标准 6 阶段流程

| 阶段 | 名称 | 目标 | 产出物 |
|---|---|---|---|
| Phase 1 | 需求摄入 | 明确客户业务问题、决策场景、品类边界 | `0.Intake.md` |
| Phase 2 | 假设与报告结构 | 将业务问题拆成 H1-H8 与章节框架 | `1.Hypothesis.md` / 报告大纲 |
| Phase 3 | 采集矩阵设计 | 形成关键词 x 平台 x 批次计划 | `3.CollectionMatrix.md` |
| Phase 4 | 数据采集执行 | API 调用、去重、合并、打标签 | `raw/`、`_merged.json`、`comments-flat.jsonl`、`audit.log` |
| Phase 5 | 分析与报告生成 | 章节分析、VOC 证据卡、HTML 渲染 | `reports/*.html`、章节 JS/MD |
| Phase 6 | 质量审计与交付 | 审计、摘要、交付包、客户沟通 | `4.CollectionExecutionSummary.md`、审计报告、交付清单 |

## Phase 1：需求摄入

### 输入

- 客户品牌/产品信息
- 当前业务目标
- 决策时间点
- 已知竞品
- 目标平台
- 希望回答的问题

### 标准提问

| 问题 | 目的 |
|---|---|
| 这次报告最终要支持哪个决策？ | 确定报告不是泛调研，而是决策工具 |
| 决策人是谁？ | 决定报告语言、结构和深度 |
| 你现在最不确定的 3 个判断是什么？ | 形成核心假设 |
| 已知竞品/替代品有哪些？ | 建立竞品池 |
| 你希望覆盖哪些平台？ | 确定采集资源和费用 |
| 交付时间与汇报形式是什么？ | 约束报告规模 |

### 产出模板

`0.Intake.md` 至少包含：

- 项目背景
- 业务目标
- 决策问题
- 品类/产品边界
- 平台范围
- 已知竞品
- 交付物定义
- 风险与不做事项

## Phase 2：假设与报告结构

### H1-H8 建议框架

| 假设 | 典型问题 |
|---|---|
| H1 品类机会 | 市场是否值得进入/加码？ |
| H2 用户需求 | 用户真实痛点和高频场景是什么？ |
| H3 产品缺口 | 当前产品/竞品哪里没有满足？ |
| H4 价格认知 | 用户对价格、规格、价值感如何判断？ |
| H5 渠道内容 | 哪些内容/平台影响用户决策？ |
| H6 竞品策略 | 竞品靠什么赢，哪里有漏洞？ |
| H7 定位表达 | 什么话术、概念、定位更能打动用户？ |
| H8 增长行动 | 下阶段最应该做哪些动作？ |

### 报告结构建议

企业级深度报告建议采用 6-7 章：

1. 执行摘要与核心判断
2. 品类与需求全景
3. 用户 VOC 与痛点结构
4. 竞品与替代方案分析
5. 定位、话术、产品/内容机会
6. 渠道与场景策略
7. 行动计划与验证路径

轻量报告可压缩为 4 章：

1. 结论先行
2. 用户声音
3. 竞品/平台发现
4. 行动建议

## Phase 3：采集矩阵设计

### 矩阵字段

| 字段 | 说明 |
|---|---|
| keyword | 关键词 |
| platform | 平台，如小红书、抖音、Amazon、TikTok |
| batch | P0/P1/P2 优先级批次 |
| targetCount | 目标采集数量 |
| hypothesisTags | 对应 H1-H8 |
| purpose | 该关键词要验证什么 |
| expectedSignal | 预期观察到的信号 |
| risk | 可能噪声或偏差 |

### 批次策略

| 批次 | 用途 | 建议规模 |
|---|---|---|
| P0 | 核心关键词和高置信方向 | 20%-30% 数据量 |
| P1 | 竞品、场景、功效、痛点扩展 | 40%-50% 数据量 |
| P2 | 长尾、异常、补证与反证 | 20%-30% 数据量 |

### 关键词四象限

- **产品词**：产品名、成分、品类名、功能词。
- **竞品词**：竞品品牌、替代品、对标品。
- **场景词**：使用场景、购买场景、人群场景。
- **长尾问题词**：怎么选、有没有用、副作用、避坑、对比。

## Phase 4：采集执行

### 数据目录建议

```text
docs/<project>/raw/
  xhs-<keyword>.json
  douyin-<keyword>.json
  amazon-<asin>.json
  _merged.json
  comments-flat.jsonl
  audit.log
```

### 执行顺序

1. token / credentials 预飞。
2. 单关键词小样本测试。
3. P0 批次采集。
4. 检查噪声、重复、平台偏差。
5. P1/P2 批量采集。
6. 合并、去重、字段归一。
7. 写入 `audit.log`。

### 必须保留字段

| 字段 | 用途 |
|---|---|
| platform | 证明来源平台 |
| keyword | 回溯采集入口 |
| batch | 证明优先级和采集顺序 |
| hypothesisTags | 对应 H1-H8 |
| author/nickname | VOC 原声可信度 |
| text/comment | 证据正文 |
| likeCount/commentCount | 判断权重 |
| url/noteId/videoId/asin | 可追溯链接或 ID |
| collectedAt | 审计与复跑 |

## Phase 5：分析与报告生成

### 分析顺序

1. 数据概况：平台、关键词、样本量、去重率。
2. 假设覆盖：H1-H8 每个是否有足够证据。
3. 高频主题：痛点、亮点、场景、竞品、价格、话术。
4. 反常信号：高赞负面、低频高价值、跨平台矛盾。
5. 章节写作：先结论，再证据，再业务解释。
6. HTML 渲染：统一封面、章节、证据卡、图表、行动页。

### 章节质量标准

每个主要章节必须包含：

- 一个结论性标题。
- 3-5 条关键洞察。
- 至少 3 张真实 VOC 证据卡。
- 一个业务解释框。
- 一个可执行建议。
- 如适用，附平台/关键词/假设标签。

## Phase 6：质量审计与交付

### 自动审计项

| 检查项 | 通过标准 |
|---|---|
| placeholder 检查 | 不得出现 `TODO`、`placeholder`、空章节 |
| 样本量检查 | 每个平台、每批次数量可解释 |
| 假设覆盖 | H1-H8 覆盖状态明确 |
| 重复检查 | 重复内容不影响结论 |
| 离题检查 | 高赞离题内容被标注或剔除 |
| 证据回溯 | 关键结论能回到原始 VOC |
| HTML 完整性 | 可打开、无明显样式破裂 |
| 封面一致性 | 样本量、平台、日期与正文一致 |
| 行动建议 | 有优先级、负责人/周期/验证方式 |

### 交付包

```text
<project>-delivery/
  report.html
  executive-summary.md
  4.CollectionExecutionSummary.md
  raw/
  scripts/
  audit.log
  README.md
```

## 从人工经验到技能化的拆解

| 人工步骤 | 可标准化模板 | 可技能化方向 |
|---|---|---|
| 访谈理解需求 | `0.Intake.md` | `voc-intake-builder` |
| 生成 H1-H8 | 假设模板 | `hypothesis-generator` |
| 设计采集矩阵 | `3.CollectionMatrix.md` | `collection-matrix-builder` |
| API 批量采集 | `collect.js` 模板 | 平台采集 skills |
| 合并去重 | `_merged.json` 规则 | `voc-data-normalizer` |
| 章节写作 | 报告章节模板 | `chapter-insight-writer` |
| HTML 渲染 | v2 renderer | `html-report-generator` |
| 审计交付 | audit checklist | `voc-report-auditor` |

## `voc-report-factory` 初版文件清单

在正式开发新 skill 之前，`voc-report-factory` 可以先作为 Markdown + script template 文档包发布。初版建议至少包含：

| 文件 | 用途 | 最低要求 |
|---|---|---|
| `0.Intake.template.md` | 需求摄入 | 能记录业务目标、决策人、平台范围、竞品和不做事项 |
| `1.Hypothesis.template.md` | H1-H8 假设 | 每条假设都有验证问题、所需平台和预期证据 |
| `2.ReportOutline.template.md` | 报告结构 | 区分轻量 4 章和企业 6-7 章版本 |
| `3.CollectionMatrix.template.md` | 采集矩阵 | 包含 keyword、platform、batch、targetCount、hypothesisTags |
| `4.CollectionExecutionSummary.template.md` | 采集汇报 | 汇总样本、平台、假设覆盖、异常与下一步 |
| `raw-schema.md` | 原始数据 schema | 规定 `_merged.json` 和 `comments-flat.jsonl` 必备字段 |
| `report-quality-audit.md` | 质量审计 | 覆盖 placeholder、样本量、证据回溯、HTML 完整性 |
| `delivery-readme.template.md` | 客户交付说明 | 说明报告、原始数据、脚本和复跑方式 |

## 单项目完成定义

每个使用该工作流交付的 VOC 报告，至少要满足以下完成定义：

1. **问题闭环**：报告开头明确回答 Phase 1 的核心决策问题。
2. **数据闭环**：封面样本量、正文平台分布、`_merged.json` 统计一致。
3. **假设闭环**：H1-H8 每条都有“已验证 / 证据不足 / 被反证”状态。
4. **证据闭环**：关键结论能追溯到真实 VOC 原声、平台、关键词与批次。
5. **行动闭环**：至少输出 P0/P1/P2 行动建议，并说明验证方式。
6. **审计闭环**：交付前完成质量审计，且严重问题为 0。
7. **复跑闭环**：交付包保留原始数据、脚本、矩阵和执行摘要，方便 30 天后复盘更新。

## 对课程和产品的意义

- 对内部：形成可复制交付，不再依赖个人发挥。
- 对课程：学员可以从一个小案例跑完整流程。
- 对市场：`voc-report-factory` 成为高阶包，承接 699 元单平台课之后的升级。
- 对 voc.market：将“99 元/月轻量 SaaS”与“AI Skills 299 元/月”连接到企业级报告能力。