任务实际已经做完，系统里的状态却还停在“进行中”，这类问题看似只是点一下“关闭”，处理不当却会让进度统计失真、下游误判依赖关系。本文聚焦单项任务的执行闭环，先帮你判断属于哪种“已完成未关闭”，再按证据核对、分情形纠正、验证恢复与防复发的顺序给出可执行步骤。
要点总览（TL;DR）
- “已完成未关闭”至少分三种：实际已交付验收仅漏改状态、交付物完成但验收未走完、执行人标记完成但存在遗留项，先归类再动手。
- 核对按交付物、验收记录、下游确认、状态变更历史的顺序逐层查，执行人自述只作线索，不作结论。
- 纠正遵循“先补前置条件、再改状态、最后留痕通知”：情形一补状态变更并注明原因，情形二先补验收再关闭，情形三拆出遗留项后再关闭或退回。
- 验证看四项：状态与证据一致、下游无遗留、对账清单归零、变更记录可追溯；防复发靠完成必填字段、状态流转限制和定期对账。
- 规则过严导致绕行时，优先简化必填项、明确验收时限，避免用取消规则的方式回到原点。
先分清三种“已完成未关闭”
“状态没关”是一个笼统描述，背后至少对应三种不同成因。处置动作差别很大：有的只需补一次状态变更，有的必须先补验收记录，有的则要把遗留工作拆出去。先归类，再动手，能避免把“验收未走完”的任务直接关掉，也能避免把“还有遗留项”的任务误判为漏改状态。
判断入口建议从两个问题入手：交付物是否已经产出并被接收？验收或评审环节是否已经形成结论？围绕这两个问题，可以分出下表三种情形。
| 情形 | 判断入口 | 典型表现 | 影响范围 |
|---|---|---|---|
| 情形一：实际已交付并验收，仅状态漏改 | 交付物存在，验收结论已明确，下游已使用 | 执行人忙于下一个任务，忘记改状态；验收人在聊天里口头确认过 | 影响进度统计与报表口径，任务本身无遗留 |
| 情形二：交付物已完成，验收或评审未走完 | 交付物已提交，但验收记录为空或评审尚未安排 | 任务停在“待验收”，执行人认为自己做完了 | 关闭条件不成立，直接改状态会掩盖验收缺口 |
| 情形三：执行人标记完成，但存在遗留项或下游未确认 | 完成标记由执行人自行操作，遗留清单或下游依赖未核实 | 主体功能上线，边缘问题、文档、数据迁移仍待处理 | 可能影响下游任务启动，关闭后问题容易被遗忘 |
三种情形的共同点是“执行人认为已完成”，分歧点在于完成是否被证据支持、验收是否闭环、遗留是否清零。归类时以客观记录为准，执行人的自述只作为线索，不作为结论。
核对：用证据确认任务是否真的完成
核对的目的是把“假设已完成”变成“有证据支持已完成”。建议按交付物、验收记录、下游使用方确认、状态变更历史的顺序逐层查，前一层证据不足时，不急着往后走。
核对顺序与每类证据的证明力
| 顺序 | 证据项 | 能证明什么 | 不能证明什么 |
|---|---|---|---|
| 1 | 交付物（文档、代码、设计稿、数据结果等） | 工作产物确实存在，内容与任务要求基本对应 | 产物是否被接收、是否满足验收标准 |
| 2 | 验收记录或评审结论 | 验收人已按标准确认通过，关闭条件成立 | 下游是否已实际使用、是否存在使用中暴露的问题 |
| 3 | 下游使用方确认 | 依赖该任务的工作已正常开展，无阻塞 | 任务本身的验收质量 |
| 4 | 状态变更历史与操作记录 | 状态何时被谁改过、是否发生过回退 | 任务内容是否真正完成 |
这四类证据的证明力依次互补：交付物证明“做了”，验收记录证明“被认可”，下游确认证明“被用上了”，变更历史帮助还原“为什么没关”。任何一类缺失，都说明核对尚未完成。
自述与记录的取舍，以及证据不足时的回退
执行人说“早做完了”，验收人说“我记得通过了”，这类自述可以作为排查起点，用来定位该找哪份记录，但不能替代记录本身。核对时优先查系统内的验收结论、评审意见和交付物版本，口头确认尽量补成书面记录再采信。
发现证据不足时，按缺口回退到对应环节：交付物找不到，回退到执行环节确认产物位置与版本；验收记录为空，回退到验收环节补做验收；下游反馈有阻塞，回退到情形三，先梳理遗留项。回退不是否定执行人的工作，而是把关闭条件补齐后再改状态。
在任务工作项中，交付物附件、验收意见、状态变更记录通常集中在一处，核对时按时间线对照即可。以ONES为例，任务工作项可以承载交付物与验收信息，状态变更会留下操作记录，核对时能直接看到谁在什么时间改过状态，减少来回询问。
纠正：按情形补动作再改状态
纠正的总原则是“先补前置条件，再改状态，最后留痕通知”。三种情形的动作不同，但都要求在改状态前确认关闭条件已经成立，避免用改状态代替补流程。
情形一：补状态变更并注明原因与时间
确认交付物与验收记录齐全后，由有权限的角色将状态改为已完成，并在变更说明中写明“实际完成时间、漏改原因、核对依据”。如果系统支持记录实际完成时间，填写真实完成日期而非操作当天，避免统计口径偏差。改完后通知任务相关人，尤其是依赖该任务的下游负责人。
情形二：先补验收或评审记录，再关闭
这类任务的前置条件是验收结论。先推动验收人按既定标准完成验收，把验收意见、通过结论写入任务记录；若验收未通过，任务应退回执行环节处理问题，不能直接关闭。验收记录补齐后，再执行状态变更。需要提醒的是，补验收应由原验收人或其授权人完成，执行人自行代填会削弱验收的独立性。
情形三：拆出遗留项，原任务按实际关闭或退回
先列出遗留项清单，逐项判断是否属于原任务范围。属于原任务范围的，原任务退回处理；属于后续优化或独立工作的，拆成新的任务并明确负责人与时间，原任务在遗留项有归属后再关闭。拆分的停止点是：每一条遗留项都有明确承接任务或明确取消理由，没有悬空事项。
批量纠正的抽样核对与停止点
当同类问题成批出现时，不建议逐条凭印象关闭。可先按情形分类，对每类抽取一定比例核对证据，确认分类判断准确后再批量处理；抽样中发现分类错误比例偏高，应停止批量操作，回到逐条核对。批量操作同样要保留变更说明，便于事后追溯。
变更留痕与通知可以合并执行：在任务中记录变更原因与依据，通过评论或通知告知执行人、验收人和下游负责人。留痕的价值在于，后续对账或审计时能解释“为什么这个任务在完成日期之后才关闭”。在ONES中，状态流转可以配置为按规则推进，变更记录随工作项保留，通知可借助工作项的关注人或评论完成，减少口头传达的遗漏。
验证恢复与防复发规则
纠正完成后，需要确认问题真的解决了，再把个案经验转成规则，降低再次发生的概率。
验证项清单
- 状态与证据一致：任务状态为已完成，且交付物、验收记录、完成时间三者能相互对应。
- 下游确认无遗留：依赖该任务的下游负责人确认可以正常开展，没有因状态问题产生的阻塞。
- 对账结果归零：按项目或时间范围导出“已完成未关闭”清单，核对后数量归零，或剩余条目均有明确处置计划。
- 变更记录可追溯：每条纠正都有原因说明和操作人，抽查若干条能还原处置过程。
防复发规则草案
规则的作用是让“完成”与“关闭”之间的条件变得明确，减少依赖个人记忆。可以从三个方向设计：
- 完成必填字段：状态改为已完成时，要求填写交付物链接或说明、验收人、实际完成时间，缺项无法提交。
- 状态流转限制：限定只有验收角色可以将任务从“待验收”推进到“已完成”，执行人完成工作后进入待验收，而不是直接关闭。
- 定期对账机制：按周或按迭代导出状态停留异常的任务清单，由任务负责人逐条确认，形成固定节奏。
规则上线后，观察两类指标：一是“已完成未关闭”任务的数量与停留时长，二是状态变更被退回或补填字段的次数。前者下降说明漏关减少，后者过高则可能说明必填项设计过重。建议在规则上线后一个月左右做一次复查，结合数据调整字段和流转条件。
如果规则过严导致执行人绕行，例如把任务拆得很碎以规避验收，或把状态停在“待验收”不推进，应优先简化必填项、明确验收时限，而不是直接取消规则。规则的目标是让关闭动作有据可依，执行顺畅比条款数量更重要。在ONES中，可以通过工作项类型配置必填字段与状态流转条件，把上述规则落到具体任务类型上，再用筛选视图定期查看异常状态的任务，形成对账入口。
常见问题
任务实际已完成，但验收人已经离职或长期无法联系，还能直接关闭吗？
不建议由执行人自行代填验收结论后关闭。可行路径是先确认该任务的验收标准是否仍然适用，再由验收人的上级或原验收角色的授权人补做验收，把验收意见和通过结论写入任务记录，然后执行状态变更。如果验收标准本身已失效，应在变更说明中写明替代判断依据和授权人，保留可追溯的记录。核心是让关闭条件有独立于执行人的证据支持。
批量纠正历史遗留的“已完成未关闭”任务，抽多少比例核对比较合适？
没有统一比例，可按任务数量和风险程度确定。数量较少时逐条核对；数量较多时先按三种情形分类，每类抽取一部分核对证据，确认分类判断准确后再批量处理。抽样中若发现分类错误比例偏高，应停止批量操作，回到逐条核对。批量操作同样要保留变更说明，便于事后追溯和抽查。
补填的实际完成时间和系统操作时间不一致，统计时以哪个为准？
以有证据支持的实际完成时间为准，例如交付物提交时间、验收通过时间，并在变更说明中注明补录原因。操作时间只反映关闭动作发生的时点，不能代表工作完成时点。如果团队报表按状态变更时间统计周期产出，需要同步说明补录规则，避免历史数据被误读。建议在防复发规则中要求状态改为已完成时填写实际完成时间，减少事后补录。
状态流转限制上线后，执行人把任务长期停在“待验收”不推进，怎么处理？
这通常说明验收环节缺少时限或责任人。可以先明确验收时限和默认验收人，超期未验收的任务进入提醒或升级流程；同时检查必填项是否过重，简化不必要的字段。对账时把“待验收停留过长”与“已完成未关闭”一起纳入异常清单，由任务负责人逐条确认。规则调整的方向是让验收动作可预期，而不是取消流转限制。
下游任务已经基于这个未关闭的任务启动了，纠正状态会影响下游吗？
一般不会影响下游已开展的工作，但需要主动通知下游负责人。纠正前先确认下游是否已实际使用交付物、是否存在因状态未关闭产生的误判；纠正后在任务中记录变更原因，并通过评论或通知告知相关人。如果下游曾因状态问题重复跟进或另建任务，应一并核对并合并重复记录，避免对账时出现两套口径。
