任务重复分配通常来自多个创建入口、负责人字段被同时修改、转派未确认，或模板与批量导入重复生成。处置时先锁定重复任务的范围和来源，再按“保留一条主任务、合并协办信息、关闭或关联其余副本”的顺序收敛，最后用负责人唯一性规则和接收确认机制验证是否复发。排查和确认过程中，ONES 的负责人字段与操作记录可以作为核对依据。
要点总览（TL;DR）
- 先分清症状：同一任务两个负责人、同一工作项被多次创建、任务在多处重复出现，处置动作各不相同；协办人与负责人并存属于正常协作。
- 原因排查把假设和证据分开：入口重复查创建记录，字段冲突查操作日志，批量重复查导入批次，交接缺失查转派与确认痕迹。
- 处置顺序固定为定主任务、合并信息、关闭或关联副本、明确唯一负责人并取得接收确认；删除只在内容已转移、无人引用且允许删除时执行。
- 处置后按记录层和人员层验证，并用负责人唯一、入口收敛、转派确认、导入查重四条规则预防复发，设置一到两周观察周期复查。
重复分配的表现与影响范围
重复分配先要分清是哪一种症状，因为不同症状对应的处置动作不同。把现象归错类，容易出现该合并的副本被删除、该关闭的重复任务被保留的情况。
三类常见表现
- 同一任务出现两个负责人。一个工作项上同时挂着两个“负责人”，或者负责人字段被改成另一个人，但原负责人仍在按自己的理解推进。
- 同一工作项被多次创建。同一件事在列表里出现两条或多条记录，标题相近、内容重复，各自有负责人和截止时间。
- 任务在多个列表或项目中重复出现。一条任务被复制或关联到多个位置，不同位置的负责人各自更新状态，进度口径不一致。
还有一种情况容易被误判：协办人与负责人并存。负责人承担结果责任，协办人提供配合，这是设计内的正常协作，不算重复分配。判断标准是责任是否唯一，而不是参与人数多少。
影响范围的判断方法
范围判断决定处置是逐条处理还是批量处理。可以从三个维度看：涉及的是单个任务、单个项目，还是一批由同一模板或同一次导入产生的任务；重复记录是否已经产生评论、附件、子任务等下游内容；是否有外部人员或外部系统引用了这些任务。
建议先做一份简单的范围清单：列出重复任务的标识、创建时间、当前负责人、是否已有评论或附件、是否被其他任务依赖。这份清单既是范围界定结果，也是后续处置时判断保留哪一条的依据。
可能原因与逐项排除证据
原因排查的关键是把假设和证据分开。下面几类原因都常见，但不能凭印象下结论，每一类都要找到对应的记录证据才能确认或排除。
| 原因假设 | 验证证据 | 排查顺序 |
|---|---|---|
| 入口重复：多个创建入口或表单导致同一任务被提交多次 | 创建记录、提交时间、创建人；同一内容在短时间内的多次提交记录 | 先查，因为入口问题往往一次产生多条重复 |
| 负责人字段冲突：多人同时编辑或转派未确认 | 操作日志、字段变更记录、变更时间与操作人 | 其次查，重点看重复记录出现前后的字段变更 |
| 模板与批量导入重复 | 导入批次记录、模板复用记录、导入文件与生成任务的对应关系 | 当重复集中在某一批任务时优先查 |
| 委派与交接信息缺失：接收方未确认，原负责人重复派发 | 沟通记录、转派记录、接收方确认痕迹 | 当重复表现为“同一件事被派了两次”时查 |
排查顺序建议从产生重复的规模入手：如果一次出现多条重复，先查入口和导入；如果重复是陆续出现的，先查负责人字段变更和转派记录。每排除一类假设，都要留下对应的证据说明，例如“查了该时段的创建记录，只有一次提交，排除入口重复”。这样排查结论才站得住，也方便后续复盘。
需要提醒的是，操作日志只能证明字段被改过，不能直接证明改动的意图。确认原因时，把日志时间和相关人的沟通记录对照起来看，比单看日志更可靠。
按情况处置：合并、关闭与责任确认
处置的目标是让每件事只有一个负责人、一条主记录。操作顺序建议固定为：先定主任务，再合并信息，然后处理副本，最后完成责任确认。顺序颠倒容易丢失评论和附件，或者让相关人以为任务已被取消。
第一步：确定保留哪一条主任务
判断依据按优先级排列：信息完整度最高的一条优先，包括描述、截止时间、附件、评论和子任务；信息相近时，保留创建时间最早的一条，因为它通常是原始记录，外部引用也多半指向它；如果某条已被外部人员或下游任务引用，优先保留该条，避免引用失效。
第二步：合并协办信息与历史记录
把副本上有价值的内容转移到主任务：评论中的关键结论、附件、子任务、协办人名单。转移时逐项核对，转移完成后在副本上留一条说明，写明内容已并入哪条主任务。这一步的作用是让后来查看副本的人知道去何处跟进，而不是面对一条空白记录。
第三步：关闭或关联副本
关闭副本前要确认三件事：没有进行中的依赖任务指向该副本；没有外部人员或外部系统引用该副本；没有其他人正在该副本上处理。三项都确认后，把副本状态改为已关闭或已取消，并在描述中注明关联的主任务。如果副本仍需保留可查，选择关联而非关闭，让两条记录之间保持指向关系。
第四步：删除类操作的前提与停止点
删除是不可逆操作，只在副本内容已全部转移、确认无人引用、且组织允许删除记录时才执行。执行前先备份或导出副本的记录，包括评论和附件清单。出现以下任一情况应停止删除：有人正在处理该副本、存在外部引用、无法确认内容是否已完整转移。此时改为关闭或关联，保留记录。
第五步：明确唯一负责人并取得确认
收敛记录之后，责任确认才算完成。指定唯一负责人，并把交接信息写清楚：任务范围、当前进展、截止时间、需要谁配合。接收方明确回复确认后，原负责人的派发动作才停止。只在系统里改了负责人字段、接收方并不知情，是重复派发反复出现的常见原因。
恢复验证与复发预防
处置完成后需要验证，否则重复可能在同一批任务里再次出现。验证分两层：记录层确认收敛结果，人员层确认相关人已知晓变更。
恢复验证清单
- 每个受影响的任务只有一个负责人，协办人名单与实际情况一致。
- 副本已关闭或已关联主任务，描述中有明确指向。
- 主任务汇集了原副本的评论、附件和子任务，无内容遗漏。
- 原负责人、新负责人和相关协办人都已知晓变更，接收方已确认。
- 依赖该任务的下游工作已按新的主任务更新指向。
复发预防规则
预防从四个动作入手。负责人字段保持唯一，一个任务只设一个负责人，需要多人参与时用协办人表达；创建入口收敛，同一类任务只保留一个提交入口，减少重复提交；转派要求接收确认，未确认前原负责人继续负责，确认后责任才转移；批量导入前先查重，按标题、负责人、时间等字段比对已有任务，确认无重复再导入。
在工具层面，ONES 的负责人字段和工作项状态可以帮助落实这些规则，操作记录则便于在复发时回查字段变更。是否支持负责人唯一性约束、转派确认和导入查重，建议在选型或配置时向产品方核实具体能力。
观察周期与复查方式
处置后设置一个观察周期，例如一到两周，在周期结束时复查三项内容：同类重复是否再次出现、负责人字段是否又被改成多人、导入批次是否产生新的重复。复查时抽取几条任务核对负责人和状态，比只看统计数字更能发现问题。如果同一原因再次出现，说明对应的预防规则没有落地，需要回到规则本身调整，而不是重复一遍处置动作。
常见问题
协办人算不算重复分配？多人参与的任务怎么设责任？
协办人不算重复分配。判断标准是结果责任是否唯一：负责人承担结果责任，协办人提供配合，一个任务可以有多名协办人，但负责人只应有一个。如果一件事需要两个人共同对结果负责，更稳妥的做法是拆成两条有明确交付物的任务，各自指定负责人，再用关联或依赖表达配合关系，避免两个负责人在进度和优先级上各说各话。
副本上已经有评论和附件，还能直接关闭或删除吗？
先转移再处理。把副本评论中的关键结论、附件、子任务和协办人名单逐项转移到主任务，转移完成后在副本上留一条说明，写明内容已并入哪条主任务。删除属于不可逆操作，只在内容全部转移、确认无人引用、组织允许删除记录时才执行，执行前备份或导出副本记录。只要有人正在处理该副本、存在外部引用或无法确认内容已完整转移，就改为关闭或关联，保留记录可查。
只在系统里改了负责人，为什么重复派发还会出现？
因为责任转移没有完成确认。接收方不知情时，原负责人可能仍按自己的理解推进，接收方也可能重复向他人派发。处置时要把交接信息写清楚：任务范围、当前进展、截止时间、需要谁配合，并取得接收方明确回复确认，原负责人的派发动作才停止。转派要求接收确认这条规则，正是针对这种情况设置的。
批量导入产生的重复任务，应该逐条处理还是批量处理？
先判断范围再决定。如果重复集中在同一导入批次，且副本尚未产生评论、附件和外部引用，可以按批次批量关闭或关联，保留信息最完整的一条作为主任务。如果部分副本已经有人跟进、产生了下游依赖，就逐条核对后再处理，避免批量操作误关正在使用的记录。处理完成后，在导入流程中加入查重步骤，按标题、负责人、时间等字段比对已有任务，减少下一批次再次产生重复。
观察周期内怎么判断预防规则是否真的生效？
抽取具体任务核对，而不是只看统计数字。周期结束时检查三项：同类重复是否再次出现、负责人字段是否又被改成多人、新导入批次是否产生重复。再随机抽几条任务，核对负责人是否唯一、副本是否已关闭或关联、相关人是否知晓变更。如果同一原因再次出现，说明对应的预防规则没有落地，需要回到规则本身调整，例如收敛创建入口或补上转派确认环节，而不是重复一遍处置动作。
