用户之声
把散落在各平台的评论、反馈、客服记录，变成能用于决策的经营判断：先定问题、再洗数据、然后打标聚类、用原声佐证、比出趋势，最后落成一句话结论和几条能派下去的动作。
边界：本技能做的是从非结构化反馈到管理结论的完整方法，不是舆情监控（不追传播与危机处置），也不是客服话术（不写回复模板）。它回答的是三个问题——用户到底在说什么、这些声音变了没有、我该动哪一件事。
> 一条纪律贯穿全流程：没有原声支撑的结论不出报告，没有出处的数字不进结论。
这个技能产出什么
| 产出物 | 说明 | 模板 |
|---|---|---|
| 分析任务说明 | 要回答的问题、渠道范围、时间窗、样本量、口径 | assets/insight-report-template.md |
| 清洗记录 | 去重/去广告/去测试/去无关的条数与占比，可复核 | references/feedback-analysis.md |
| 痛点簇清单 | 每个簇：名称、条数、占比、典型原声、涉及产品维度 | references/feedback-analysis.md |
| 用户洞察报告 | 一句话结论 + 痛点排序 + 原声佐证 + 趋势 + 行动项 | assets/insight-report-template.md |
| 原声证据附录 | 结论 → 原声（原文、来源、时间、链接/工单号）的对应表 | assets/insight-report-template.md |
| 行动项清单 | 每条：做什么、谁做、按什么判有效、什么时候看结果 | references/insight-to-action.md |
何时用 / 何时不用
用：
- 手上有一批跨平台评论/评价，要判断"用户在抱怨什么、最该先改什么"；
- 要分析客服工单与售后记录，做差评归因：是产品问题、物流问题还是预期落差；
- 要做需求挖掘：从反馈里找选品方向、功能优先级、内容选题；
- 要回答"这期反馈和上期比有什么变化"，识别新增问题与已消解问题；
- 要出一份能上会的用户洞察报告，结论必须能被追问、能被验证。
不用：
- 舆情监测与危机公关（传播路径、声量预警、对外口径）→ 属于舆情工作；
- 写客服回复话术与安抚模板 → 属于服务执行；
- 单纯的情感倾向跑分（只给正负比例，不给经营判断）→ 那是中间产物，不是本技能的产出；
- 结构化经营数据的分析（销售、回款、库存）→ 那属于经营数据分析。
执行流程
六步。问题没定清不抓数据，数据没洗净不打标，结论没原声不出报告。
第 1 步 · 确定分析问题与范围
先写"分析任务说明"，它决定了后面每一步的取舍（问题定义方法见 references/feedback-analysis.md）：
| 要素 | 要写清的内容 | 常见错误 |
|---|---|---|
| 要回答的问题 | 一句话，且是可被证伪的问题（例：复购用户流失抱怨集中在哪一类） | "看看用户怎么说"（无法收敛） |
| 渠道范围 | 具体平台/系统（商城评论、社媒评论、客服工单、售后记录、问卷开放题） | 混着抓，事后说不清来源 |
| 时间窗 | 绝对日期区间；跨平台时间不一致时说明换算 | 用"近期"，导致趋势无法比 |
| 分析对象 | 全部用户还是某一人群（新客/复购/大客户/某渠道来源） | 人群混算，结论互相打架 |
| 样本量 | 各渠道条数；总量不足时的处置（扩大时间窗或明说样本不足） | 几十条就下普遍结论 |
| 口径约定 | 什么算"差评"、什么算"同一问题"、重复反馈怎么算 | 事后各算一套 |
样本量红线：总量少于 50 条时，只做问题清单，不出比例与趋势结论；少于 10 条时只做个案转述，不得归纳。
确认门 1：输出「分析任务说明」，让用户确认：按此分析 / 需要调整。未确认不进入抓取与清洗。
第 2 步 · 聚合与清洗
聚合不是把数据堆进一张表，是统一字段 + 逐条清理。
统一字段（缺一不可）：来源渠道、来源链接/工单号、发布时间、原文、用户标识（脱敏）、用户标签（新客/复购/等级）、关联产品/订单、评分或情感原始值。
清洗规则（按顺序执行，每步记录条数）：
| # | 规则 | 处理 |
|---|---|---|
| 1 | 完全重复（同源同文） | 保留最早一条，其余删除并计数 |
| 2 | 近似重复（同一用户多平台同文） | 合并为一个用户声音，标注跨渠道 |
| 3 | 广告与营销内容 | 删除（含返现诱导好评、推广文案） |
| 4 | 测试与内部数据 | 删除（测试账号、员工操作、演示数据） |
| 5 | 与本次问题无关 | 移入"范围外"，不删除，单列条数 |
| 6 | 无信息量内容 | 仅"好评""不错"等无指向的，标为"无信息量"，不计入聚类但计入总量 |
| 7 | 字段缺失 | 缺失字段标"缺失"，不得用推测值补齐 |
| 8 | 疑似异常集中（同一时段、同一样式大量相似内容） | 单独标记为"待核"，报告里单列，不并入结论 |
必须输出清洗记录：原始条数 → 去重后 → 去广告后 → 有效条数 → 范围外条数 → 待核条数，并给出各步占比。清洗记录缺失，报告不可采信。
第 3 步 · 打标与聚类
四维打标，一条反馈可同时带多个标签（标签体系与判定口径见 references/feedback-analysis.md）：
| 维度 | 标签来源 | 用途 |
|---|---|---|
| 主题 | 固定标签集（质量、价格、物流、功能、体验、服务、预期落差…）+ 其他 |
聚类主干 |
| 情感 | 正面 / 中性 / 负面（按原文判断，不按评分） | 差评归因 |
| 产品维度 | 具体品类/SKU/功能模块/页面 | 定位到可改的对象 |
| 使用场景 | 谁在什么情况下用（新客首购、复购、送礼、批量采购…） | 需求挖掘 |
打标三条规则：
- 标签集先定后用：固定标签 +
其他（须注明），不允许自由发挥；新增标签要在报告里说明。 - 一条反馈只归一个主标签：多主题时按"用户最想解决的问题"归主标签，其余记次标签。
- 情感与评分冲突以原文为准：5 星差评、1 星好评都要单独标注为反差样本，这类样本往往信息量最大。
聚类归纳要点：
- 先分簇再看量：先把语义相近的反馈归到一起，再统计条数；不要先按关键词数词频；
- 簇要能被命名：名字必须指向一个可处理的对象（例："包装破损导致到货即坏"），不要用"质量差""体验不好"这种大而空的簇名；
- 归并阈值：单簇少于 3 条时与其并入最近的簇，或单列为"零散问题"，不占簇位；
- 大簇必须再切分：一个簇占比超过 40% 时，要求继续切分到可执行粒度（按产品维度或场景），否则"什么都归到体验差"没有行动价值；
- 每簇写清三件事：现象（用户在说什么）、影响（对谁、什么后果）、涉及对象（产品/环节）。
第 4 步 · 原声佐证
每个结论配 2~3 条真实原声，这是本技能最硬的要求（选取标准与引用格式见 references/feedback-analysis.md）。
| 要求 | 具体做法 |
|---|---|
| 真实 | 逐字引用原文，不改写、不合并、不润色；错别字也保留 |
| 可追溯 | 每条标注来源渠道 + 时间 + 链接/工单号（脱敏） |
| 有代表性 | 2~3 条原声要覆盖该簇的不同侧面，不要挑三条一模一样的 |
| 不挑极端 | 避免只挑最激烈的一条；如需引用极端样本，须注明"极端个案" |
| 脱敏 | 隐去手机号、地址、订单号后四位等个人信息 |
| 平衡 | 存在相反声音的簇，必须同时给出反例原声 |
禁止的做法：用转述代替原文（"有用户反映…"）；只给结论不给原声；原声与结论对不上（结论说价格贵，原声说的是物流慢）。
第 5 步 · 趋势判断
趋势是同口径的对比，不是印象（对比方法见 references/feedback-analysis.md）。
| 变化类型 | 判定方式 | 报告里的说法 |
|---|---|---|
| 上升 | 本期该簇占比 − 上期占比 ≥ 3 个百分点，且本期条数 ≥ 5 | "环比上升 X 个百分点，主要来自 {渠道}" |
| 下降 | 同上，方向相反 | "环比下降 X 个百分点，需确认是改善还是投诉减少" |
| 新增 | 上期无此簇，本期 ≥ 3 条 | "本期新增问题，集中在 {场景}" |
| 消解 | 上期有该簇，本期 0 条 | "本期未再出现，需确认是已解决还是样本量不足" |
| 持平 | 变化 < 3 个百分点 | "基本持平，不作趋势结论" |
四条纪律：
- 口径必须一致：渠道范围、时间窗长度、清洗规则若与上期不同，只能比"结构占比"，不能比"绝对条数"；
- 小样本不判趋势：本期该簇少于 3 条时只记录、不下趋势结论；
- 区分"变少"与"变好"：投诉量下降可能是问题解决了，也可能是渠道流量下降了——必须结合各渠道样本量一起看；
- 首次分析不编趋势：没有上期数据时，本期只出基线，明确写"本期为基线，趋势自下期起可判"。
第 6 步 · 结论与行动项
一句话管理结论：用一句不用解释的话说清"最该动哪一件事"（写法与优先级判据见 references/insight-to-action.md）：
✓ 负面反馈的四成集中在"到货破损"，且集中在 {品类} 与 {渠道}，建议优先改造该品类的包装与承运方案。
✗ 用户反馈总体偏好，但仍有提升空间。（没有指向，无法行动）
痛点优先级判据（四个一起看，不只看条数）：
| 判据 | 说明 |
|---|---|
| 频次 | 该簇条数与占比 |
| 严重度 | 是否影响下单、是否造成退货/退款/投诉升级 |
| 可控性 | 是我方能直接改的（产品/包装/内容/流程），还是外部因素 |
| 商业影响 | 关联的品类/客群是否是我们重点经营的 |
行动项要素（缺一不可）：做什么 + 谁做（角色） + 按什么判有效（可观察的判据） + 什么时候回看。只写"加强/优化/重视"的一律退回重写。
三类建议的给法（详见 references/insight-to-action.md）：选品侧（做什么品类/规格/组合）、内容侧（详情页、卖点表达、预期管理）、服务侧（发货、包装、售后、响应时效）。每类最多给 3 条，按优先级排序。
确认门 2：输出洞察报告草稿（结论 + 原声 + 趋势 + 行动项），让用户确认：按此上报 / 需要补充样本。
产出物规格
| 产出物 | 必含字段 | 格式要求 |
|---|---|---|
| 分析任务说明 | 问题、渠道、时间窗、人群、样本量、口径约定 | 一页表格，样例数写实数 |
| 清洗记录 | 各步条数与占比、规则版本、执行时间 | 表格，数字可复核 |
| 痛点簇清单 | 簇名、条数、占比、主标签、涉及对象、影响 | 按占比降序，含"零散问题"行 |
| 用户洞察报告 | 一句话结论、痛点排序、原声、趋势、行动项、局限说明 | 见 assets/insight-report-template.md |
| 原声证据附录 | 结论编号 → 原声原文、渠道、时间、链接/工单号 | 逐条对应，可回溯 |
报告必带"局限说明"：样本覆盖不到的渠道、数据缺失、无法判断的分歧点。不写局限的报告视为不合格。
质量红线
- 不编造原声：所有引用必须是真实存在的原文；不得为凑格式而改写、拼接或生成"典型说法"。
- 不编造数字：条数、占比必须来自清洗后的真实计数；算不出来的写"无法计算"并说明原因。
- 不把个别当普遍：单条反馈只能作为个案引用，不得上升为群体结论；样本不足时明说。
- 不把情绪当需求：用户骂的是结果，需求要落到具体可改的对象上（"太慢了"→ 是发货慢还是页面加载慢）。
- 不删负面声音：只做去广告、去重、去测试；不得因为"不好看"而剔除负面或异常样本，异常样本单列并说明。
- 不混口径：跨期对比前先对齐渠道、时间窗与清洗规则，口径变了必须标注断点。
- 不泄露个人信息：引用前脱敏，不出现手机号、详细地址、完整订单号。
- 不越界结论：只对"用户说了什么"下结论；对"为什么"的解释必须标为推断，并给出可验证的方式。
参考文件索引
references/feedback-analysis.md—— 反馈分析方法：分析问题定义、清洗规则清单、四维标签体系、聚类归纳要点、原声佐证选取与引用格式、趋势对比方法references/insight-to-action.md—— 从洞察到行动：一句话管理结论写法、痛点优先级四判据、选品/内容/服务三类建议、行动项要素与转交、常见误判清单assets/insight-report-template.md—— 用户洞察报告模板 + 原声证据附录模板
关于产品（可选接入）
本技能自包含、可独立使用，不依赖任何外部系统，也不要求接入任何特定平台。
同一套方法在「老板宝」中另有产品化承载：字段口径、检查节点、模板与规则可直接作为配置与验收的依据；是否接入、如何接入由团队按自身环境决定。
