02. 标准化报告工作流：从人工快速出报告到 VOC Report Factory
目标
把现有“人工快速出报告”的经验沉淀成可培训、可复用、可审计、可交付的 VOC Report Factory 标准工作流。
该工作流适用于三类场景：
- 内部交付：让不同成员按照同一标准完成企业 VOC 报告。
- 课程训练：让学员从一次案例实操中掌握完整报告生产链路。
- 技能产品化：为
voc-report-factory 套件提供 SOP、模板和后续 skill 抽象依据。
核心原则
- 先定义问题，再采数据：不能先抓一堆数据再找结论。
- 先有假设，再有矩阵：每个关键词、平台、批次都必须对应 H1-H8 假设。
- 先保留证据，再写洞察：每个结论必须能回溯到 VOC 原声、平台、关键词、批次。
- 先审计，再交付：没有经过完整 audit 的 HTML 报告不能对外交付。
- 人机协同，不是全自动：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 章：
- 执行摘要与核心判断
- 品类与需求全景
- 用户 VOC 与痛点结构
- 竞品与替代方案分析
- 定位、话术、产品/内容机会
- 渠道与场景策略
- 行动计划与验证路径
轻量报告可压缩为 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：采集执行
数据目录建议
docs/<project>/raw/
xhs-<keyword>.json
douyin-<keyword>.json
amazon-<asin>.json
_merged.json
comments-flat.jsonl
audit.log
执行顺序
- token / credentials 预飞。
- 单关键词小样本测试。
- P0 批次采集。
- 检查噪声、重复、平台偏差。
- P1/P2 批量采集。
- 合并、去重、字段归一。
- 写入
audit.log。
必须保留字段
| 字段 |
用途 |
| platform |
证明来源平台 |
| keyword |
回溯采集入口 |
| batch |
证明优先级和采集顺序 |
| hypothesisTags |
对应 H1-H8 |
| author/nickname |
VOC 原声可信度 |
| text/comment |
证据正文 |
| likeCount/commentCount |
判断权重 |
| url/noteId/videoId/asin |
可追溯链接或 ID |
| collectedAt |
审计与复跑 |
Phase 5：分析与报告生成
分析顺序
- 数据概况：平台、关键词、样本量、去重率。
- 假设覆盖：H1-H8 每个是否有足够证据。
- 高频主题：痛点、亮点、场景、竞品、价格、话术。
- 反常信号：高赞负面、低频高价值、跨平台矛盾。
- 章节写作：先结论，再证据，再业务解释。
- HTML 渲染：统一封面、章节、证据卡、图表、行动页。
章节质量标准
每个主要章节必须包含：
- 一个结论性标题。
- 3-5 条关键洞察。
- 至少 3 张真实 VOC 证据卡。
- 一个业务解释框。
- 一个可执行建议。
- 如适用，附平台/关键词/假设标签。
Phase 6：质量审计与交付
自动审计项
| 检查项 |
通过标准 |
| placeholder 检查 |
不得出现 TODO、placeholder、空章节 |
| 样本量检查 |
每个平台、每批次数量可解释 |
| 假设覆盖 |
H1-H8 覆盖状态明确 |
| 重复检查 |
重复内容不影响结论 |
| 离题检查 |
高赞离题内容被标注或剔除 |
| 证据回溯 |
关键结论能回到原始 VOC |
| HTML 完整性 |
可打开、无明显样式破裂 |
| 封面一致性 |
样本量、平台、日期与正文一致 |
| 行动建议 |
有优先级、负责人/周期/验证方式 |
交付包
<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 报告，至少要满足以下完成定义：
- 问题闭环：报告开头明确回答 Phase 1 的核心决策问题。
- 数据闭环：封面样本量、正文平台分布、
_merged.json 统计一致。
- 假设闭环：H1-H8 每条都有“已验证 / 证据不足 / 被反证”状态。
- 证据闭环：关键结论能追溯到真实 VOC 原声、平台、关键词与批次。
- 行动闭环：至少输出 P0/P1/P2 行动建议，并说明验证方式。
- 审计闭环：交付前完成质量审计，且严重问题为 0。
- 复跑闭环：交付包保留原始数据、脚本、矩阵和执行摘要，方便 30 天后复盘更新。
对课程和产品的意义
- 对内部：形成可复制交付，不再依赖个人发挥。
- 对课程：学员可以从一个小案例跑完整流程。
- 对市场：
voc-report-factory 成为高阶包，承接 699 元单平台课之后的升级。
- 对 voc.market：将“99 元/月轻量 SaaS”与“AI Skills 299 元/月”连接到企业级报告能力。
