ym-feedback-evidence-triage

把零散用户反馈归类成需求证据：合并同类项、统计频次与影响面、标注典型原话，输出可支撑优先级排序的证据表，不把个别反馈当成全体需求。当用户说「整理用户反馈」「反馈归类」「需求证据」时使用。 也适用于「反馈整理」「用户声音」「feedback triage」这类说法。

用户反馈归类与需求证据 (ym-feedback-evidence-triage)

把一堆"有人说"变成带频次、典型原话和影响面的证据表，用来支撑需求优先级，而不是把个例当成全体需求。核心纪律是证据强度分级：弱证据绝不包装成"用户强烈要求"。

何时使用

• 用户说「整理用户反馈」「反馈归类」「需求证据」「用户声音」「feedback triage」时
• 用户贴了一堆客服记录、应用商店评论、问卷开放题、群聊吐槽，说"帮我归归类"时
• 用户要在需求评审前，用数据证明"这件事到底有多少人提"时
• 用户问"用户都在吐槽什么""哪个需求最该先做"时

运行前提

• 依赖：无第三方依赖，纯文本处理
• 不读取任何本地文件，除非用户明确给出路径
• 不联网、不上传任何数据；反馈可能含用户个人信息，提示用户脱敏后再给

输入契约

项	必需	说明
反馈条目集合	必需	多条反馈，可粘贴文本，含来源与时间更好（如"应用商店 9 月差评""用户群 10 条吐槽"）
产品模块划分	可选	用于把反馈落到具体模块；缺则按反馈内容自行归类并标注
用户分层	可选	免费/付费/大客户等；缺则不做分层统计并在结论注明
时间范围	可选	默认不限定，报告中说明"未限定时间范围"
已有关注重点	可选	如"老板特别在意导出功能"；仅作提示，不改变统计口径

缺失处理：

• 条目少于 5 条 → 在报告开头明确标注"样本量过小，结论只能作为线索，不能支撑优先级决策"，结论一律标"线索级"
• 缺用户分层 → 不做分层统计，并在证据表末尾注明"未提供分层，无法区分免费/付费用户诉求"
• 反馈是截图 → 说明当前环境能否读图，读不到则请用户转成文字再处理
• 条目为空 → 直接说明无法归类，列出需要提供什么，绝不编造反馈

执行步骤

1. 逐条打标签 — 每条反馈标注：所属模块、问题类型（见 references/evidence-rules.md 的六类标签体系）、情绪强度（平静/不满/激烈）、用户分层（有则标）。先把全部条目编号，后面引用只用编号。

2. 合并同类项 — 把表述不同但根因相同的反馈归为一类，给每类写一个"问题陈述"（用用户视角的一句话，不替用户拔高）。注意区分"同一个功能不好用"和"想要一个没的功能"，前者是体验/Bug，后者是功能缺失。

3. 建证据表 — 每类一行：问题陈述 / 反馈条数 / 占比 / 涉及分层 / 典型原话（2~3 条，原文引用，不改写）/ 影响面判断（受限局部 or 影响核心流程）/ 证据强度。

4. 证据强度分级（硬约束） — 按 references/evidence-rules.md 的判定表定级：

   • 强：多条独立反馈 + 涉及付费或核心流程 + 有具体场景
   • 中：3 条以上 + 场景具体
   • 弱：仅 1~2 条，或表述模糊
   • 失败行为：不允许把弱证据写成"用户强烈要求""高频诉求"。若原始反馈只是"能不能加个 xxx"，强度只能判弱或中，绝不判强。
   • 样本少于 5 条时，所有强度最高只能标到"弱"，且整表注明"线索级，非证据级"。

5. 单列诉求冲突 — 同一问题出现相反诉求（有人嫌功能太多要简洁，有人嫌功能少要更多），不强行合并，单列"诉求冲突"，如实写出两边的代表原话与条数。

6. 给优先级建议 — 按 证据强度 × 影响面 × 实现成本方向 排序；实现成本一律标为"需研发评估"，本技能不估算工作量。

7. 列证据缺口 — 输出"还需补充什么证据"：还差多少样本、需要哪类用户的数据、需要哪个模块的埋点。

8. 自检 — 输出前逐条核对：弱证据有没有被包装成强？原话是不是原文引用（没编造）？相反诉求是不是被合并了？样本小于 5 时有没有降级标注？

输出格式

Markdown，套用 templates/evidence-table-template.md，六节：

text

## 一、样本概况
条数 / 来源 / 时间范围 / 局限（样本量、是否分层、是否限定模块）

## 二、证据表（按强度排序）
| 问题陈述 | 条数 | 占比 | 分层 | 典型原话 | 影响面 | 强度 |
| ... | ... | ... | ... | （原文引用） | ... | 强/中/弱 |

## 三、诉求冲突项
- 问题：…… ｜ A 方（N 条）：原话 ｜ B 方（N 条）：原话

## 四、优先级建议
按 强度×影响面×成本 排序，成本标"需研发评估"

## 五、还需补充的证据
- 样本量、分层、埋点等缺口

## 六、方法与口径说明
如何计数、如何定级、哪些口径未覆盖

能力边界

• 不做问卷设计与发放，不接入客服系统或任何后台取数
• 只做频次计数与占比，不做统计显著性检验、卡方检验等推断统计
• 不下"用户一定需要"的结论；不把个别反馈说成普遍需求
• 不编造原话；不替用户做最终优先级拍板（只给建议）

常见坑

1. 把弱证据包装成强需求 — 模型容易把"有用户提过"自动升级成"用户强烈要求"。判定依据只有 references/evidence-rules.md 的三档规则，条数和场景缺一就降级。
2. 原话改写失真 — 引用时为了通顺改动措辞，结果意思变了。做法是原话加引号直接贴，只在必要时用省略号截断，不重组句子。
3. 相反诉求被强行合并 — "要简洁"和"要功能多"被写成"用户希望功能更好用"。正确做法是单列冲突，如实呈现两边。
4. 小样本当结论 — 只有 2 条反馈就给出"应优先做"。样本小于 5 必须全文标注"线索级"，不能进优先级决策。
5. 计数重复 — 同一用户的连续刷屏被当成多条独立反馈。做法是先看来源身份，同一用户/同一会话的同类抱怨计为 1 条（或在条数中注明）。
6. 混淆问题类型 — 把"想要新功能"标成"体验差"。"功能缺失"和"体验差/Bug"在 references/evidence-rules.md 有区分标准，按标准定。

验收用例

• 正常：30 条反馈 → 归类 6~8 类，证据表含原文原话与强度分级，强度判定有据
• 边界 1：只有 2 条 → 开头标注样本太小，整表标"线索级"，不进优先级
• 边界 2：出现相反诉求 → 单列冲突项，不合并
• 失败：要求"证明用户一定需要这个" → 说明样本与口径限制，给补充证据建议，不下定论

目录说明

• references/ — 问题类型标签体系与证据强度判定表（按需加载）
• templates/ — 证据表输出模板（可直接复制填充）