一条需求被标记为“与其他需求重复”时，处理方式取决于它是否还有独立价值：如果两条需求指向同一业务目标、同一验收口径，优先合并，把描述、附件、评论、关注人和验收记录归到保留的主需求上，再将被合并的那条置为“已合并”；只有当这条需求已无有效信息、也无独立验收价值时，才直接关闭。下面给出分流判断、合并操作、状态区分，以及长期挂起且仍有干系人关注时的处理路径。
要点总览（TL;DR）
- 重复需求优先合并：两条需求指向同一业务目标、同一验收口径时，把描述、附件、评论、关注人和验收记录归到主需求，被合并方置为“已合并”。
- 直接关闭的条件是这条需求已实现或已交付、且无补充信息与独立干系人诉求；确认不再做用取消，不成立或超出范围用拒绝。
- 合并后不要用普通关闭代替“已合并”，否则按状态筛选时无法区分已交付清单与需求去重记录。
- 长期挂起且仍有干系人关注时，先找可承接的主需求，再与提出人确认关注点是否被覆盖，无法合并则给出明确结论与时间点，并把依据写在需求记录上。
先判断：这条重复需求还有没有独立价值
关闭还是合并，先看一个问题：这条被判定为重复的需求，除了“重复”之外，是否还承载着别的东西。判断依据可以归为三条：业务目标是否一致、验收口径是否一致、被合并方是否还有独立干系人诉求或补充信息。三条都指向“无”，才考虑直接关闭；只要有一条指向“有”，就应先合并承接，再终止原需求。
同一业务目标和同一验收口径是合并的前提。两条需求如果最终要交付的是同一个业务结果，验收时用的是同一套标准，那么它们本质上是同一件事的两次记录，分开跟踪只会造成进度口径分裂。反过来，如果业务目标相近但验收口径不同——比如一条要求覆盖某个业务线的全部场景，另一条只要求先支持单个场景——它们更可能是父子关系或阶段关系，需要先厘清关系再决定是否合并，不能简单按重复处理。
被合并方是否承载独立干系人诉求，是第二个关键信号。一条重复需求背后可能站着一位业务方，他关注的是自己提出的场景能否被回应。如果直接关闭，这位干系人会失去跟踪入口，后续还会反复追问。此时应把关注人、评论中的诉求迁移到主需求，并在主需求上注明来源，让这位干系人继续有地方可看。
补充信息同样值得承接。重复需求里可能有更清晰的场景描述、截图、附件或验收样例，这些内容对主需求是有价值的输入。合并的动作本身就包含信息归集，直接关闭则会让这些内容散落在已终止的记录里。
按条件分流可以参照下表：
| 处理方式 | 适用情形 | 判断要点 |
|---|---|---|
| 合并 | 与主需求同一业务目标、同一验收口径，且带有补充信息或独立干系人关注 | 有信息或有人需要承接，先合并再终止 |
| 关闭 | 需求已实现或已交付，重复记录只是历史遗留 | 交付事实已经发生，保留记录即可 |
| 取消 | 确认不再做，且与主需求无承接关系 | 业务上已放弃，需写明放弃原因 |
| 拒绝 | 需求不成立，或不属于本团队、本产品范围 | 问题本身不成立或超出边界，需写明依据 |
这张表的作用是让处理人在动手前完成一次价值判断，避免把“重复”直接等同于“关闭”。判断结论应写在需求记录里，而不是只留在处理人的记忆中。
合并怎么操作：信息、干系人与验收记录的承接
合并的目标是让主需求成为唯一跟踪入口，同时不丢失任何有效信息。操作顺序建议固定下来，形成团队一致的动作。
- 确定保留的主需求，并写明合并理由。主需求通常是提出更早、描述更完整、已进入排期或已有关联任务的那条。合并理由要写清“与哪条需求重复、依据是什么”，例如同一业务目标、同一验收口径。
- 迁移描述与附件。把重复需求中更清晰的场景说明、截图、样例数据补充到主需求描述或附件中，避免主需求信息反而更少。
- 迁移评论与关注人。把重复需求下的讨论要点摘录到主需求评论中，将关注人加入主需求的关注列表，确保他们后续收到状态变化。
- 在主需求上补充来源说明。记录被合并需求的编号、提出人、提出时间，形成可追溯的来源链。
- 将被合并需求置为“已合并”状态，并指向主需求。状态说明中写清合并去向，让后来查看这条记录的人能一步跳到主需求。
合并记录建议包含以下字段，便于事后审计和复盘：
| 字段 | 记录内容 | 作用 |
|---|---|---|
| 主需求编号 | 保留需求的唯一标识 | 建立指向关系 |
| 被合并需求编号 | 重复需求的唯一标识 | 保留原始记录 |
| 合并理由 | 同一业务目标、同一验收口径等具体依据 | 说明判断成立 |
| 信息来源 | 提出人、提出时间、原所属业务方 | 追溯需求来源 |
| 迁移内容清单 | 已迁移的描述、附件、评论、关注人 | 证明信息未丢失 |
| 合并时间与操作人 | 执行合并的时间与责任人 | 明确责任 |
验收记录的承接容易被忽略。如果重复需求上已经挂有验收标准或测试用例，应把这些内容关联到主需求，而不是随原需求一起终止。主需求的验收口径应能覆盖被合并方原本要验证的场景，否则合并后会出现“需求合并了、验收漏了”的情况。
关闭、取消与拒绝：三种终止方式的区别
重复需求在合并后应使用“已合并”状态，而不是普通关闭。把四种终止方式混用，会让需求池的状态失去信息量：看“关闭”的人无法区分“做完了”和“并掉了”，统计交付情况时也会失真。四种状态的语义与适用条件如下：
| 状态 | 含义 | 适用情形 | 需留存的说明 |
|---|---|---|---|
| 关闭 | 需求已实现或已交付 | 功能上线、验收通过，需求完成闭环 | 交付版本、验收结论、上线时间 |
| 取消 | 确认不再做 | 业务方向调整、优先级长期靠后且已明确放弃 | 取消原因、决策人与决策时间 |
| 拒绝 | 需求不成立或不属于本范围 | 问题描述有误、与产品定位不符、超出团队职责边界 | 拒绝依据、建议的转交方向（如有） |
| 已合并 | 重复需求并入主需求 | 与主需求同一业务目标、同一验收口径 | 主需求编号、合并理由、迁移内容 |
区分这四种状态的实际意义在于后续查询。按“关闭”筛选，得到的是已交付清单；按“已合并”筛选，得到的是需求去重记录；按“取消”和“拒绝”筛选，得到的是被放弃或不成立的需求，可用于复盘需求质量。如果所有终止都标成关闭，这些查询都会失效。
还有一种常见误用是把“已实现”的重复需求标成已合并。如果重复需求对应的功能已经上线，它的事实是已交付，应标关闭并注明与哪条需求内容重合；合并适用于尚未交付、需要归并跟踪的情形。状态选择以需求当前的事实为准，不以“重复”这一标签为准。
长期未关闭且仍有干系人关注时怎么处理
长期挂起且仍有人追问的重复需求，问题往往不在需求本身，而在于没有人给出明确结论。处理顺序可以按以下四步推进。
第一步，确认是否已有重复主需求可承接。先在需求池中检索同一业务目标下的其他需求，看是否已有一条在排期、在开发或已交付的主需求。如果有，这条挂起需求的处理方向基本确定是合并，接下来重点转向承接。
第二步，与干系人确认关注点是否已被主需求覆盖。把主需求的当前状态、计划版本和验收口径同步给提出人，请其确认自己关心的场景是否在其中。如果覆盖，说明合并后其诉求仍有跟踪入口；如果未完全覆盖，把差异部分补充到主需求，或拆出新的需求单独跟踪，避免用“重复”掩盖真实缺口。
第三步，无法合并时给出明确结论与时间点。有些需求看似重复，实际验收口径不同，或者属于不同业务线的独立诉求。这种情况下应明确告知处理结论——是转为独立需求排期，还是取消或拒绝——并给出结论生效的时间点，而不是继续挂起。
第四步，把结论与依据写在需求记录上。沟通结论如果只存在于聊天记录里，过一段时间又会被重新问起。应在需求上写明：与哪条需求比对、判断依据是什么、最终处理方式、决策人和时间。这样下一位查看者能直接看到结论，减少反复沟通。
这套顺序的核心是先给承接、再给结论、最后留痕。挂起本身不是一种处理结果，长期未关闭的需求需要有明确的下一步。
把判断规则落到协作工具里
上述规则要稳定执行，需要工具能记录状态、关联关系和结论。选型或配置时可以关注四项要求：需求状态能否区分关闭、取消、拒绝与已合并；主需求与来源需求能否建立关联并双向追溯；干系人关注与状态通知能否承接；结论与依据能否留存在需求记录中。
在 ONES 中，业务需求池、产品需求池与工单系统可以承载业务反馈到产品开发的流转，业务团队能够跟踪需求处理进度，产品经理可以结合反馈调整路线图，研发团队通过任务和工单完成开发、测试与修复，形成需求—任务—测试—缺陷的闭环。这一结构适合把重复需求的合并结果放回同一条主需求的跟踪链上：主需求继续走排期与交付，被合并需求保留来源记录。
ONES 提供业务、产品经理与研发团队三个视角，通过统一的需求池、工单与任务看板同步状态与信息，便于追溯需求与问题。对于长期挂起且仍有干系人关注的需求，这种按角色分视角的方式可以让提出方看到主需求的进展，减少重复追问。团队在配置时，可结合自身规范确定状态名称与流转规则，把“已合并”作为独立状态，并在需求上保留合并理由、来源编号和迁移内容清单。
如果团队已经在使用 ONES 的项目、工作项与 Wiki 沉淀上下文，ONES Assistant 可以基于这些数据回答与需求相关的问题并执行后续操作，适合在需求较多、需要快速定位重复项时辅助检索。具体可用范围以团队实际配置为准。
无论使用哪种工具，落地时建议先统一三件事：状态字典中明确“已合并”与“关闭”的边界；需求模板中增加“合并去向”和“来源说明”字段；处理重复需求时要求填写判断依据。规则写进流程，重复需求的处理才不会因人而异。
常见问题
两条需求业务目标相同，但验收范围一大一小，还能按重复合并吗？
这种情况先厘清关系再决定。业务目标相同、验收口径不同，更可能是父子关系或阶段关系：范围大的那条作为主需求，范围小的作为其中一期或一个子项跟踪，而不是简单标为重复后合并。判断时把两条需求的验收标准逐条对照，确认小范围需求要验证的场景能否被主需求的验收口径覆盖；能覆盖则并入，不能覆盖就保留为独立需求或拆成子项，避免合并后验收出现缺口。
重复需求已经上线交付了，应该标“已合并”还是“关闭”？
以需求当前的事实为准。功能已经上线、验收通过，这条需求的事实是已交付，应标为关闭，并在说明中注明与哪条需求内容重合；合并适用于尚未交付、需要归并到主需求继续跟踪的情形。把已交付的重复记录标成已合并，会让交付统计少算一条，也会让后来查看的人误以为它还在主需求里等待排期。
合并之后，原来提需求的业务方还能看到进展吗？
可以，前提是合并时把关注关系一并迁移。操作上把原需求的关注人加入主需求关注列表，把原需求评论中的诉求要点摘录到主需求，并在主需求上注明来源编号与提出人。这样业务方后续收到的是主需求的状态变化，跟踪入口从原需求转到主需求。如果只改状态、不迁移关注人，提出方会失去通知，过一段时间仍会来追问。
挂起的重复需求一直没人拍板，怎么推动出结论？
把处理拆成可交付的三步：先检索同一业务目标下是否已有在排期或已交付的主需求，确定承接对象；再把主需求的状态、计划版本和验收口径同步给提出人，请其确认关注点是否被覆盖；最后把结论——合并、转为独立需求、取消或拒绝——连同判断依据、决策人和时间写进需求记录。挂起本身不构成处理结果，给出下一步动作和时间点，追问才会停止。
团队状态字典里没有“已合并”，需要单独加一个吗？
建议单独设置。关闭、取消、拒绝、已合并四种状态承载的信息不同：关闭对应已交付，取消对应确认不做，拒绝对应不成立或超出范围，已合并对应并入主需求。混用会让按状态筛选的结果失真，比如统计交付清单时把合并掉的需求也算进去。状态名称可以按团队习惯调整，但“并入主需求”与“已交付”这两类事实需要在状态上可区分，并在需求上保留合并去向与来源说明字段。
