用户反馈归类与需求证据 (ym-feedback-evidence-triage)
把一堆"有人说"变成带频次、典型原话和影响面的证据表，用来支撑需求优先级，而不是把个例当成全体需求。核心纪律是证据强度分级：弱证据绝不包装成"用户强烈要求"。
何时使用
- 用户说「整理用户反馈」「反馈归类」「需求证据」「用户声音」「feedback triage」时
- 用户贴了一堆客服记录、应用商店评论、问卷开放题、群聊吐槽，说"帮我归归类"时
- 用户要在需求评审前，用数据证明"这件事到底有多少人提"时
- 用户问"用户都在吐槽什么""哪个需求最该先做"时
运行前提
- 依赖：无第三方依赖，纯文本处理
- 不读取任何本地文件，除非用户明确给出路径
- 不联网、不上传任何数据；反馈可能含用户个人信息，提示用户脱敏后再给
输入契约
| 项 | 必需 | 说明 |
|---|---|---|
| 反馈条目集合 | 必需 | 多条反馈，可粘贴文本，含来源与时间更好（如"应用商店 9 月差评""用户群 10 条吐槽"） |
| 产品模块划分 | 可选 | 用于把反馈落到具体模块；缺则按反馈内容自行归类并标注 |
| 用户分层 | 可选 | 免费/付费/大客户等；缺则不做分层统计并在结论注明 |
| 时间范围 | 可选 | 默认不限定，报告中说明"未限定时间范围" |
| 已有关注重点 | 可选 | 如"老板特别在意导出功能"；仅作提示，不改变统计口径 |
缺失处理：
- 条目少于 5 条 → 在报告开头明确标注"样本量过小，结论只能作为线索，不能支撑优先级决策"，结论一律标"线索级"
- 缺用户分层 → 不做分层统计，并在证据表末尾注明"未提供分层，无法区分免费/付费用户诉求"
- 反馈是截图 → 说明当前环境能否读图，读不到则请用户转成文字再处理
- 条目为空 → 直接说明无法归类，列出需要提供什么，绝不编造反馈
执行步骤
-
逐条打标签 — 每条反馈标注：所属模块、问题类型（见
references/evidence-rules.md的六类标签体系）、情绪强度（平静/不满/激烈）、用户分层（有则标）。先把全部条目编号，后面引用只用编号。 -
合并同类项 — 把表述不同但根因相同的反馈归为一类，给每类写一个"问题陈述"（用用户视角的一句话，不替用户拔高）。注意区分"同一个功能不好用"和"想要一个没的功能"，前者是体验/Bug，后者是功能缺失。
-
建证据表 — 每类一行：问题陈述 / 反馈条数 / 占比 / 涉及分层 / 典型原话（2~3 条，原文引用，不改写）/ 影响面判断（受限局部 or 影响核心流程）/ 证据强度。
-
证据强度分级（硬约束） — 按
references/evidence-rules.md的判定表定级：
- 强：多条独立反馈 + 涉及付费或核心流程 + 有具体场景
- 中：3 条以上 + 场景具体
- 弱：仅 1~2 条，或表述模糊
- 失败行为：不允许把弱证据写成"用户强烈要求""高频诉求"。若原始反馈只是"能不能加个 xxx"，强度只能判弱或中，绝不判强。
- 样本少于 5 条时，所有强度最高只能标到"弱"，且整表注明"线索级，非证据级"。 -
单列诉求冲突 — 同一问题出现相反诉求（有人嫌功能太多要简洁，有人嫌功能少要更多），不强行合并，单列"诉求冲突"，如实写出两边的代表原话与条数。
-
给优先级建议 — 按 证据强度 × 影响面 × 实现成本方向 排序；实现成本一律标为"需研发评估"，本技能不估算工作量。
-
列证据缺口 — 输出"还需补充什么证据"：还差多少样本、需要哪类用户的数据、需要哪个模块的埋点。
-
自检 — 输出前逐条核对：弱证据有没有被包装成强？原话是不是原文引用（没编造）？相反诉求是不是被合并了？样本小于 5 时有没有降级标注？
输出格式
Markdown，套用 templates/evidence-table-template.md，六节：
## 一、样本概况
条数 / 来源 / 时间范围 / 局限（样本量、是否分层、是否限定模块）
## 二、证据表（按强度排序）
| 问题陈述 | 条数 | 占比 | 分层 | 典型原话 | 影响面 | 强度 |
| ... | ... | ... | ... | （原文引用） | ... | 强/中/弱 |
## 三、诉求冲突项
- 问题：…… ｜ A 方（N 条）：原话 ｜ B 方（N 条）：原话
## 四、优先级建议
按 强度×影响面×成本 排序，成本标"需研发评估"
## 五、还需补充的证据
- 样本量、分层、埋点等缺口
## 六、方法与口径说明
如何计数、如何定级、哪些口径未覆盖
能力边界
- 不做问卷设计与发放，不接入客服系统或任何后台取数
- 只做频次计数与占比，不做统计显著性检验、卡方检验等推断统计
- 不下"用户一定需要"的结论；不把个别反馈说成普遍需求
- 不编造原话；不替用户做最终优先级拍板（只给建议）
常见坑
- 把弱证据包装成强需求 — 模型容易把"有用户提过"自动升级成"用户强烈要求"。判定依据只有
references/evidence-rules.md的三档规则，条数和场景缺一就降级。 - 原话改写失真 — 引用时为了通顺改动措辞，结果意思变了。做法是原话加引号直接贴，只在必要时用省略号截断，不重组句子。
- 相反诉求被强行合并 — "要简洁"和"要功能多"被写成"用户希望功能更好用"。正确做法是单列冲突，如实呈现两边。
- 小样本当结论 — 只有 2 条反馈就给出"应优先做"。样本小于 5 必须全文标注"线索级"，不能进优先级决策。
- 计数重复 — 同一用户的连续刷屏被当成多条独立反馈。做法是先看来源身份，同一用户/同一会话的同类抱怨计为 1 条（或在条数中注明）。
- 混淆问题类型 — 把"想要新功能"标成"体验差"。"功能缺失"和"体验差/Bug"在
references/evidence-rules.md有区分标准，按标准定。
验收用例
- 正常：30 条反馈 → 归类 6~8 类，证据表含原文原话与强度分级，强度判定有据
- 边界 1：只有 2 条 → 开头标注样本太小，整表标"线索级"，不进优先级
- 边界 2：出现相反诉求 → 单列冲突项，不合并
- 失败：要求"证明用户一定需要这个" → 说明样本与口径限制，给补充证据建议，不下定论
目录说明
references/— 问题类型标签体系与证据强度判定表（按需加载）templates/— 证据表输出模板（可直接复制填充）
