RQ-01 · 多渠道需求归集结构化

注意标橙色那一份 —— 03_实施邮件（华正信息化科长）.txt。它邮件转发 · 2026-07-21，平时压根不在核对范围里。这个场景的价值，很大一部分就来自把它读进来。

短是因为「渠道方言识别、语义查重、字段抽取规则、证据包结构」都在能力包里。产品经理只要把原始记录扔进来。

江晓把微信记录、工单导出、实施邮件、语音转写、需求池现状全部扔进来 —— 归集的价值在「合并后的证据包」，不在任何单一来源。

证据等级的分布说明归集的必要：唯一一封书面邮件（最高等级）在收件箱里沉了一个月 —— 没有归集机制的团队，证据等级与被看见的概率无关。

查重的关键判定：民康 06-28 的两条工单相隔 2 小时、同一客户 —— 一条问数据导出（真需求）、一条问照片保存（操作问题）。「导出」一词的两义性正是需求池失真的缩影：不读原文的查重会把操作问题合进功能需求。

「频次与广度」一栏引用了 CX-01 的聚类结果 —— 归集与聚类是同一枚硬币的两面：归集管「这个需求的来源」，聚类管「这个主题的声量」。

旧决策的三根支柱（API 时间表/单客户/有替代）如今全部松动 —— 复活的讨论不是推翻旧决策，是旧决策的前提条件发生了变化。这个框架让沈知行 revisiting 自己的决策时没有面子负担。

证据包的五页里本场景直接产出两页、联动三页 —— 归集是需求管理的枢纽：向左接查重与回溯，向右接评审与商业论证。这也是它当旗舰的原因。