整改完成后迟迟没有复验，卡点往往不在整改动作本身，而在复验的触发、责任和状态流转：整改完成没有交接给复验人，复验人未指定或不在岗，复验结论没有回写需求状态，复验不通过后缺少退回整改的回路。本文只讨论单项需求整改后的复验环节，产品整体效果评估和项目整体验收不在范围内，排查思路是先定位断点，再补规则，最后用积压需求验证闭环。
要点总览（TL;DR）
- 整改后未复验，断点通常集中在四个环节：整改完成没有交接给复验人、复验人未指定或不在岗、复验结论没有回写需求状态、复验不通过后缺少退回整改的回路。
- 排查顺序建议先查触发与状态字段，再查复验责任人与退回回路，最后查通知与提醒；触发和状态属于流程结构问题，缺失时后续环节无从谈起。
- 排查时抽取一批积压需求，逐条还原“整改完成—复验触发—复验结论—状态关闭”四个节点的时间与操作人，按环节归类断点，判断是单点缺失还是多环节叠加。
- 处置按断点补规则：补复验触发与指派、细分待复验与复验通过状态、设置不通过退回整改；批量改状态前先备份、设停止点、分批处理并留痕。
- 修复后用积压数量、复验平均等待时长、复验记录完整率三项指标验证，并把复验结论设为需求关闭的必经检查项，配合超期提醒与定期盘点防止再次积压。
整改后未复验的典型症状与影响范围
先要区分两种表面相似、性质不同的情况。整改未完成，指的是整改动作还在进行，责任人仍在处理，这类问题属于整改进度管理；整改完成但未复验，指的是整改单已经标记完成，复验环节却没有启动或没有结论，这才是本文要处理的对象。把两者混在一起统计，积压数字会失真，排查方向也会跑偏。
整改完成但未复验，通常有以下几类可观察的症状：
| 症状 | 具体表现 | 说明的问题 |
|---|---|---|
| 状态长期停留 | 整改单已标记完成，需求状态长期停在“待复验”或类似节点 | 复验没有被触发，或触发后无人推进 |
| 复验记录为空 | 需求下查不到复验人、复验时间、复验结论 | 复验动作没有留下可追溯的记录 |
| 积压随时间上升 | 待复验数量按周递增，整改完成量同步增长 | 整改产出持续进入，复验消化能力不足 |
| 关闭依据缺失 | 需求已关闭，但找不到对应的复验结论 | 关闭动作绕过了复验环节 |
范围上，本文聚焦单项需求从“整改完成”到“复验通过并关闭”这一段。产品上线后的整体效果评估、项目层面的整体验收与收尾，涉及不同的角色和判断标准，不在本文讨论之列。明确这个边界，排查时才能把精力集中在复验这一段流程上。
复验卡点的常见原因假设与排除证据
面对积压，容易直接下结论说“大家不重视复验”。这类判断缺少证据支撑，也无法指导修复。更稳妥的做法是先列出可能的原因假设，再为每个假设找到能证实或排除它的数据，按顺序逐项验证。
| 原因假设 | 验证证据与取数方式 | 排查顺序 |
|---|---|---|
| 复验触发缺失：整改完成没有生成复验任务 | 抽取整改完成的需求，查看完成后是否产生新的待办或任务；统计“整改完成时间”与“复验记录创建时间”之间是否存在空档 | 第一步 |
| 状态字段未区分整改完成与复验通过 | 查看状态字段的取值集合，确认是否存在独立的“待复验”“复验通过”“复验不通过”；统计停留在中间状态的需求数量 | 第一步 |
| 复验责任人未定义或不在岗 | 逐条查看待复验需求的复验人字段是否为空；对照人员在职与排班情况，识别长期无人处理的责任人 | 第二步 |
| 复验不通过后无回路 | 筛选复验结论为“不通过”的需求，查看是否退回整改、是否产生新的整改任务、是否长期停滞 | 第二步 |
| 通知与提醒缺失 | 查看系统是否存在复验待办提醒、超期提醒；对比提醒开启前后待复验时长的变化 | 第三步 |
排查顺序上，先查触发与状态，再查责任人与回路，最后查通知与提醒。原因是触发和状态属于流程结构问题，一旦缺失，后面所有环节都无从谈起；责任人和回路属于执行配置问题；提醒属于辅助手段，前两类问题没解决时，加提醒只能缓解表面现象。
还需要单独区分“未复验”和“复验不通过后停滞”。前者是复验从未发生，证据是复验记录为空；后者是复验已经发生并给出不通过结论，但退回整改的回路断了，证据是有复验结论、无后续整改任务。两类情形的修复动作不同，统计时分开计数，避免把回路问题误判为触发问题。
按环节排查整改复验流程的操作步骤
假设列清楚后，进入具体排查。建议抽取一批积压需求作为样本，数量以能覆盖近几个月的整改完成为宜，逐条还原流程节点，记录断点位置。
- 抽取样本并还原四个节点。对每条需求记录“整改完成时间—复验触发时间—复验结论时间—状态关闭时间”，同时记录每个节点的操作人。四个时间点齐全且顺序合理，说明该条需求闭环正常；出现空缺或倒挂，即为断点候选。
- 检查整改完成是否有明确的复验交接动作。查看整改完成时是否伴随指派复验人、生成复验任务、变更状态等动作。如果整改完成只是一个状态标记，没有任何交接动作，断点就在触发环节。
- 检查复验人是否被指定、待办是否进入其工作列表。查看复验人字段是否为空，以及被指定的复验人能否在自己的待办中看到这条需求。字段有值但待办不可见，说明指派没有转化为可执行的工作项。
- 检查复验结论是否回写需求状态。查看复验完成后状态是否随之变化，通过时是否触发关闭，不通过时是否触发再整改。结论存在但状态未变，断点在状态流转环节。
- 记录断点分布。把样本的断点按环节归类计数，形成断点记录表。若断点集中在单一环节，按单点缺失处理；若多个环节同时出现断点，说明流程结构需要整体调整。
| 需求编号 | 整改完成时间 | 复验触发 | 复验人 | 复验结论 | 状态关闭 | 断点环节 |
|---|---|---|---|---|---|---|
| 示例-001 | 有 | 无 | 空 | 无 | 未关闭 | 触发缺失 |
| 示例-002 | 有 | 有 | 已指定 | 不通过 | 未关闭 | 退回回路缺失 |
| 示例-003 | 有 | 有 | 已指定 | 通过 | 未关闭 | 状态回写缺失 |
表中为演示情景，用于说明断点记录表的填写方式。实际排查时按真实样本逐条填写，断点分布统计出来后，修复方向就明确了。
修复卡点的处置动作与风险边界
定位到断点后，按环节补规则。触发缺失的，补上“整改完成即生成复验任务并指派复验人”的规则，让整改完成成为一个有交接动作的节点，而不是一个孤立的状态标记。责任与状态缺失的，明确复验人角色，把状态细分为待复验、复验通过、复验不通过，使每个状态对应明确的下一步动作。回路缺失的，设置复验不通过自动退回整改，并保留原复验结论和退回记录，便于追溯。
在工具层面，这类规则需要流程配置能力来承载。ONES 通过模板、权限和流程配置支撑管理方式落地，需求、任务、测试与缺陷可以在统一的需求池和工单体系中流转，状态与信息实时同步，便于追溯每条需求当前处在哪个环节。复验任务的具体触发方式、状态字段的细分粒度以及退回回路如何配置，需以实际产品版本核验，配置前建议先在少量需求上试运行。
批量处理积压时，风险主要来自状态被一次性改动而缺少留痕。处置时应遵守以下边界：
- 批量修改状态前，先导出或备份当前状态数据，保留修改前的快照。
- 设置停止点，例如每批处理固定数量后暂停，核对结果无误再继续。
- 分批处理，按整改完成时间或责任团队分组推进，避免全量操作。
- 每次批量操作留下操作记录，注明操作人、时间、范围和依据。
- 对已关闭但缺少复验结论的需求单独列出，补做复验或补充说明，不直接批量关闭。
复验闭环的验证方法与复发预防
修复动作完成后，需要用数据确认复验环节真正运转起来。可观察的验证指标包括：待复验积压数量是否逐周下降；复验平均等待时长，即整改完成到复验结论之间的时间，是否缩短并稳定在可接受范围；复验记录完整率，即带有复验人、复验时间和结论的需求占比，是否接近全部。三项指标同时改善，才说明闭环生效；只有积压下降而记录完整率不变，可能只是批量关闭造成的假象。
指标之外还要做抽样复核。从已关闭的需求中抽取一批，确认复验结论存在、复验证据齐全、关闭动作发生在复验通过之后。抽样能发现指标掩盖的问题，例如状态被手工跳过、结论填写敷衍等。
防止再次积压，可以建立几项常态机制：
- 超期未复验提醒：复验任务生成后超过约定时限仍未处理，自动提醒复验人及其上级。
- 定期积压盘点：按周或按月统计待复验数量与等待时长，在例会上通报并明确清理责任。
- 复验人替补机制：复验人休假或离岗时，由替补人接手，避免任务停在无人处理的状态。
- 关闭必经检查：把复验结论作为需求关闭的必经检查项，缺少结论的需求无法进入关闭状态。
这些机制中，关闭必经检查是最直接的一道防线，它把复验从“应该做”变成“关闭前必须做”。配合超期提醒和定期盘点，复验环节就能从依赖个人自觉转为由流程保障，积压问题也会在形成规模之前被发现和处理。
常见问题
整改单已经标记完成，但复验一直没人做，最先应该查什么？
先查触发和状态，不要先追人。抽取一批整改已完成的需求，看整改完成时是否伴随生成复验任务、指派复验人、变更状态等动作。如果整改完成只是一个状态标记，没有任何交接动作，断点就在触发环节，此时追问复验人为什么不处理没有意义。同时查看状态字段是否存在独立的“待复验”节点，状态不区分整改完成与复验通过，复验就没有可停留的位置。
复验人字段有值，但复验还是长期没人处理，可能是什么原因？
字段有值只说明指派动作发生过，不代表任务进入了复验人的工作视野。需要确认被指定的复验人能否在自己的待办或工作列表中看到这条需求；字段有值而待办不可见，说明指派没有转化为可执行的工作项。另一种情况是复验人长期休假、离岗或已转岗，字段保留但实际无人处理，需要对照人员在职与排班情况识别这类责任人，并建立替补机制。
复验不通过后需求一直停着，和从未复验是一类问题吗？
两类情形要分开统计。从未复验的证据是复验记录为空，属于触发或责任缺失；复验不通过后停滞的证据是有复验结论、但没有后续整改任务，属于退回回路缺失。修复动作也不同：前者补触发规则和责任人，后者设置复验不通过自动退回整改并保留原结论与退回记录。混在一起统计，容易把回路问题误判为触发问题，修复方向就会跑偏。
批量清理积压的待复验需求时，有哪些操作风险需要提前控制？
主要风险是状态被一次性改动而缺少留痕。操作前先导出或备份当前状态数据，保留修改前快照；按整改完成时间或责任团队分批推进，每批处理固定数量后暂停核对，设置明确的停止点；每次批量操作记录操作人、时间、范围和依据。对已关闭但缺少复验结论的需求单独列出，补做复验或补充说明，不直接批量关闭，否则积压数字下降但闭环并未真正建立。
修复后怎么判断复验环节真的运转起来了，而不是数字好看？
看三项指标是否同时改善：待复验积压数量逐周下降、复验平均等待时长缩短并稳定、复验记录完整率接近全部。只有积压下降而记录完整率不变，可能只是批量关闭造成的假象。指标之外还要抽样复核，从已关闭需求中抽取一批，确认复验结论存在、证据齐全、关闭动作发生在复验通过之后，抽样能发现状态被手工跳过、结论填写敷衍等指标掩盖的问题。
