处理重复需求时，直接删除或简单标注“重复”会让反馈来源一起消失，后续无法判断某条需求背后有多少用户在提、来自哪些渠道。更稳妥的做法是把重复需求整理成“主需求 + 关联反馈”的结构：选定一条主需求承载方案与状态，其余需求作为关联项保留原始提交人、渠道、时间和原文。本文按判定口径、关联步骤、来源字段、角色分工、示例和检查清单展开，适用于需求池维护人建立可执行的合并机制。
要点总览（TL;DR）
- 重复需求按“同一用户问题、同一业务对象、同一期望结果”三要素判定，表述相似但场景不同的需求不宜直接合并。
- 合并采用“主需求 + 关联需求”结构：主需求承载方案与状态，其余需求标注关联指向并保留原条目。
- 反馈来源以独立记录挂在主需求下，至少保留提交人、渠道、提交时间、原始描述和客户或业务标识，合并只改归属不删原文。
- 需求池维护人负责判定与关联，提交人和业务方确认诉求未被曲解，评审角色复核合并结果与来源完整性。
- 误合并时解除关联、恢复原需求独立状态并保留来源记录，同时回看判定口径是否需要修正。
先定判定口径：什么算重复需求
重复判定决定后续所有动作的方向。判定过宽，会把不同场景的诉求压成一条，导致方案偏离；判定过窄，需求池里会堆积大量实质相同的条目。建议以三个要素同时成立作为重复标准：同一用户问题、同一业务对象、同一期望结果。
三个要素需要逐项核对，不能只看标题措辞。例如“导出报表太慢”和“希望报表支持批量导出”，前者是性能问题，后者是功能诉求，即使都涉及报表，期望结果不同，不应判为重复。反过来，两个用户分别用“查询卡顿”和“筛选后要等很久”描述同一页面的响应问题，表述不同但三要素一致，可以合并。
实际操作中，可以把重复分成三种情况分别处理：
- 表述重复：同一问题、同一对象、同一期望结果，只是用词不同。这类可以直接合并，主需求选择描述最完整的一条。
- 场景重复：问题相同，但发生在不同业务场景或不同客户环境中。需要确认方案能否覆盖全部场景，能覆盖则合并，不能覆盖则保留为独立需求并互相引用。
- 方案重复：用户提出的解决方式不同，但底层问题一致。这类要回到用户问题层面判断，避免把某一种方案当成唯一需求。
每次判定都要留下记录，至少包含判定人、判定时间和判定依据。判定依据写清楚三要素分别对应哪些原文内容，便于后续复核时还原当时的判断逻辑。判定记录建议直接写在主需求的描述或关联说明中，与需求本身放在一起，避免散落在聊天记录里。
主需求与关联需求的操作步骤
从发现重复到建立关联，可以拆成五个动作。每个动作都有明确的输入、输出和完成标志，需求池维护人按顺序执行即可。
| 步骤 | 输入 | 动作 | 输出 | 完成标志 |
|---|---|---|---|---|
| 1. 识别候选重复 | 新提交需求或池内待整理需求 | 按三要素在需求池中检索相似条目，逐条打开原文核对 | 候选重复清单 | 每条候选都附有原文链接或编号 |
| 2. 选定主需求 | 候选重复清单 | 比较描述完整度、影响范围、已有讨论和方案进展，选出一条作为主需求 | 主需求及选择理由 | 选择理由可被第三人理解 |
| 3. 建立关联 | 主需求、其余需求条目 | 在其余需求上标注关联到主需求，并写明关系类型（完全重复、场景重复、方案相关） | 关联关系记录 | 每条被合并需求都有明确指向 |
| 4. 处理状态变化 | 主需求状态更新 | 主需求进入评审、开发或关闭时，检查关联项是否需要同步说明 | 状态同步说明 | 关联项上能看到主需求当前进展 |
| 5. 保留原条目 | 被合并需求 | 保留原条目及其来源信息，改为关联状态，不删除、不覆盖原文 | 可追溯的历史条目 | 通过原条目能回到提交人和原始描述 |
选定主需求时，优先考虑描述最完整、已经过业务确认、或已有方案讨论的那一条，而不是简单取最早提交的条目。主需求承担方案设计和状态推进，选择依据要写进关联说明，方便后来者理解为什么是这一条。
关系类型建议控制在少量固定选项内，例如“完全重复”“场景重复”“方案相关”。类型过多会增加填写负担，类型过少又无法区分处理方式。完全重复的关联项通常只需保留来源；场景重复的关联项可能需要在主需求下补充场景说明；方案相关的条目则要明确是否纳入同一方案范围。
主需求状态变化时，关联项不必跟随改变状态，但应在关联项上能看到主需求的当前进展。这样提交人回看自己的需求时，能知道事情推进到哪一步，而不需要再去别处询问。合并后的原需求条目保持可检索、可打开，原文和来源字段完整保留。
反馈来源如何保留：字段与挂载方式
来源保留的关键是“独立记录、挂在主需求下”。合并动作只改变归属关系，来源记录本身不删除、不覆盖。每条来源至少应包含以下字段：
| 字段 | 内容说明 | 是否必填 |
|---|---|---|
| 提交人 | 原始提出需求的个人或角色 | 必填 |
| 渠道 | 反馈进入的途径，如工单、客户群、销售转达、内部提出 | 必填 |
| 提交时间 | 原始反馈的时间 | 必填 |
| 原始描述 | 提交人原话或原始工单内容，不做改写 | 必填 |
| 客户或业务标识 | 关联的客户、项目、业务线等，用于判断影响范围 | 按实际情况填写 |
挂载方式有两种常见做法。一种是把每条来源作为主需求下的独立记录，字段按上表填写；另一种是在主需求描述中维护来源汇总表，每行对应一条来源。前者便于单条追溯和筛选，后者便于快速浏览全貌。条件允许时两种可以并用：独立记录保证可追溯，汇总视图保证可读性。
汇总视图用于回答“这条需求有多少人在提、来自哪些渠道”，单条追溯用于回答“某位客户具体说了什么”。两个视角服务不同问题，不能互相替代。来源记录与主需求状态保持独立：主需求关闭后，来源记录仍然保留，作为需求历史的一部分。
在 ONES 中，可以用工单收集来自各方的反馈，处理后将工单转化为需求并整理进需求池；需求本身支持自定义状态与多种属性，来源字段可以作为需求属性或关联记录维护。具体字段配置和工单转化后的信息保留方式，以实际产品配置为准。
角色分工与交付物
重复需求处理涉及三类角色，各自的动作和交付物需要提前约定，避免判定和关联都落在一个人身上却无人复核。
| 角色 | 主要动作 | 交付物 | 交接时点 |
|---|---|---|---|
| 需求池维护人 | 识别候选重复、执行判定、建立关联、维护来源记录 | 判定记录、关联关系、来源字段 | 判定完成后交给提交人或业务方确认 |
| 提交人与业务方 | 确认原始诉求未被曲解，补充场景信息 | 确认意见或补充说明 | 关联建立后、主需求进入评审前 |
| 评审角色 | 复核合并结果是否合理，检查来源是否完整 | 复核结论 | 主需求进入方案评审时 |
需求池维护人负责日常判定与关联，是这套机制的主要执行者。提交人和业务方的确认环节容易被省略，但对场景重复类需求尤其重要：只有原始提出者能判断方案是否覆盖了他的实际场景。评审角色不必参与每条需求的合并，但应在主需求评审时抽查关联记录和来源完整性。
交接时点建议固定下来：判定完成后立即通知相关提交人，主需求进入评审前完成确认，评审时一并查看关联清单。这样每个环节都有明确的输入和输出，不会出现关联做了但没人确认、或者确认了但没有记录的情况。
示例：三条渠道反馈合并为一条主需求
以下为演示情景，用于说明流程，不代表真实客户案例。
某产品团队在一个月内收到三条反馈：客户 A 通过工单提出“订单列表加载太慢，翻页要等好几秒”；销售在客户群转达客户 B 的说法“查订单的时候页面一直转圈”；内部运营同事提出“后台订单查询响应太慢，影响处理效率”。三条反馈分别来自工单、客户群和内部提出三个渠道。
需求池维护人按三要素核对：用户问题都是订单查询响应慢，业务对象都是订单列表或订单查询页面，期望结果都是缩短等待时间。三条属于表述重复，判定为重复需求。维护人选择客户 A 的工单作为主需求，理由是描述包含具体现象和操作路径，且工单中已有初步的环境信息。
关联建立后，主需求下保留三条来源记录：客户 A 的工单原文、客户 B 经销售转达的描述及转达时间、运营同事的原始说明。每条记录标注提交人、渠道、时间和客户或业务标识。主需求描述中增加一张来源汇总表，显示三个渠道各一条反馈。
主需求进入开发后，提交人回看自己的条目时，能看到关联到的主需求及其当前状态。产品经理评估影响范围时，通过汇总视图确认该问题涉及两个外部客户和一个内部团队，据此调整方案说明。主需求关闭时，三条来源记录仍然保留，后续做需求复盘时可以追溯最初的反馈来源。
关联前后的对照可以概括为：关联前是三条独立需求，各自有提交人和描述，但无法看出彼此关系；关联后是一条主需求加三条来源记录，方案和状态集中在一处，来源信息完整保留。
完成检查：关联是否做对
每次完成一批重复需求处理后，可以按以下清单逐项核对。检查项应指定负责人并留下证据，避免检查流于形式。
| 检查项 | 合格标准 | 负责人 | 证据 |
|---|---|---|---|
| 关联指向明确 | 每条被合并需求都能找到对应的主需求 | 需求池维护人 | 关联关系记录 |
| 来源字段完整 | 提交人、渠道、提交时间、原始描述齐全 | 需求池维护人 | 来源记录或汇总表 |
| 可追溯到原始提交 | 通过来源记录能回到原始工单或原始描述 | 需求池维护人 | 原文链接或原始内容 |
| 主需求唯一且状态清晰 | 同一组重复需求只有一个主需求，状态为当前实际进展 | 评审角色 | 主需求状态与关联清单 |
| 判定记录可复核 | 判定人、判定时间、判定依据均已填写 | 需求池维护人 | 判定记录 |
| 误合并可回退 | 发现误合并时，能解除关联并恢复原需求独立状态，来源记录不受影响 | 需求池维护人 | 解除关联的操作记录 |
误合并的回退方式需要在机制建立时就明确：解除关联关系，把原需求恢复为独立条目，保留其来源字段和原文，并在判定记录中注明回退原因。回退不是失败，而是判定口径需要调整的信号，可以据此补充判定标准的说明。
检查频率可以与需求池整理节奏一致，例如每次批量整理后抽查一批关联记录。检查发现的问题应回到判定口径或操作步骤中修正，而不是只改单条记录。这样这套机制才能随着使用逐步稳定，重复需求既不会丢失来源，也不会因为合并而偏离真实诉求。
常见问题
两条需求描述很像，但来自不同客户的不同使用场景，应该合并吗？
先按三要素核对：用户问题、业务对象、期望结果是否一致。三要素一致、只是场景不同，属于场景重复，需要先判断主需求方案能否覆盖全部场景。能覆盖的可以合并，并在主需求下补充各场景说明；不能覆盖的保留为独立需求，互相标注引用关系，避免后续方案只照顾到其中一方。
合并后原始提交人还能看到自己那条反馈的进展吗？
可以，前提是原条目保留为关联状态而不是删除。关联项上应能看到主需求的当前状态或进展说明，提交人回看自己的条目时即可了解推进情况。主需求状态变化时，关联项不必跟随改状态，但进展信息需要同步可见，否则提交人仍需另行询问。
来源记录应该单独建条目，还是直接写进主需求描述里？
两种方式服务不同问题。独立记录便于单条追溯和按渠道、提交人筛选；主需求描述中的来源汇总表便于快速浏览全貌。条件允许时并用：独立记录保证可追溯，汇总视图保证可读性。只保留汇总表而丢掉原始记录，后续就无法还原某位客户的原话。
发现误合并之后怎么处理？
解除关联关系，把原需求恢复为独立条目，保留其来源字段和原文，并在判定记录中注明回退原因。回退后应回看判定口径：是三要素核对不充分，还是场景覆盖判断有误，据此补充判定标准说明，避免同类误合并重复出现。
用 ONES 落地这套机制时，来源字段可以怎么维护？
ONES 支持用工单收集来自各方的反馈，处理后将工单转化为需求并整理进需求池；需求支持自定义状态与多种属性，来源字段可以作为需求属性或关联记录维护（F1、F2）。工单转化后来源信息的具体保留与展示方式，以及关联项状态联动，需以实际产品配置为准，建议在正式推行前用一批真实需求做小范围验证。
