发布核对不通过时，先暂停发布，把每条不通过项转成带责任人、截止时间和验收人的修正任务，按遗漏补录、版本对齐、证据补齐分类处置；修正完成后用同一份核对清单和同一发布基线重新核对，全部条目有结论且有证据支撑，才解除阻断。下面按阻断、定位、修正、复核、恢复五个环节说明具体做法。
要点总览（TL;DR）
- 核对不通过时先暂停发布，把不通过项按内容遗漏、版本不一致、证据缺失、清单未确认四类记录，并圈定受影响的发布批次、制品、文档和下游依赖。
- 逐条把不通过项拆成原因假设，用构建记录、归档材料、审批状态等证据验证，区分已证实原因与待验证假设，避免把清单空白当成内容缺失。
- 每条不通过项转成带责任人、修正内容、截止时间和验收人的修正任务，重新打包或回滚前先备份、冻结并设定停止点。
- 修正完成后沿用同一份核对清单和同一发布基线重新核对，先验证修正项再回归未受影响项，全部条目有结论且有证据支撑才解除阻断。
- 解除阻断后确认实际发布版本与核对基线一致并留痕，把本次不通过项回写进清单和前置核对时点，用历史数据判断改进是否有效。
核对不通过时先界定症状与阻断范围
核对出现不通过，第一步是停止发布动作，把“不通过”从一句结论拆成可记录的症状。发布负责人应在核对现场完成三件事：记录不通过条目、判断是否构成阻断、圈定受影响范围。这一步的产物是一份症状分类与阻断范围确认记录，后续修正和复核都以它为起点。
典型症状可以归为四类。内容遗漏指发布说明、变更记录、配置项或交付文档中缺少应包含的内容；版本号或制品不一致指核对清单登记的版本与实际构建产物、部署包、文档标注的版本对不上；证据缺失指测试报告、评审记录、审批签字等支撑材料没有归档或无法追溯；清单项未确认指核对人尚未给出结论，条目处于空白或待定状态。四类症状的处置动作不同，记录时应逐条标注类型，避免笼统写成“核对未通过”。
阻断发布与可带条件放行需要划清边界。涉及对外交付内容错误、制品版本不可追溯、关键证据缺失且无法在发布窗口内补齐的，应判定为阻断，发布暂停。仅涉及文档措辞、非关键说明补充，且不影响交付物本身正确性和可追溯性的，可以由发布负责人评估后带条件放行，条件是明确补齐时限和责任人，并在发布记录中登记遗留项。边界判断应由发布负责人与质量或测试负责人共同确认，避免单方放宽。
受影响范围要具体到发布批次、制品、文档和下游依赖。同一批次中哪些制品需要重新核对，哪些文档需要同步修订，哪些下游系统或团队依赖本次发布、需要被告知延期，都应写入记录。范围确认后，由发布负责人宣布阻断，解除阻断的权限同样归发布负责人，解除依据是重新核对全部通过。权限集中在一处，可以避免修正过程中出现“边改边发”的失控情况。
逐条定位原因并收集排除证据
症状记录完成后，逐条把不通过项从结论拆成原因假设，再用证据验证。原因假设按四类建立：遗漏、版本不一致、证据缺失、流程未走完。每条假设都要对应可核查的证据来源和排查顺序，排查结果分为“已证实”和“待验证”，未证实的假设不能直接写进修正任务的原因栏。
| 原因假设 | 验证证据 | 排查顺序 |
|---|---|---|
| 内容遗漏 | 核对清单条目与发布说明、变更记录、配置清单逐项比对结果 | 先查清单条目是否覆盖本次变更，再查文档是否按清单编写 |
| 版本不一致 | 构建记录、制品仓库版本号、部署包与文档标注版本的一致性比对 | 先确认基线版本，再核对制品与文档是否指向同一版本 |
| 证据缺失 | 测试报告、评审记录、审批流的归档位置与时间戳 | 先查是否已产生，再查是否已归档到指定位置 |
| 流程未走完 | 评审、审批、会签节点的当前状态与待办人 | 先查节点状态，再确认卡在谁那里、缺什么输入 |
排查顺序遵循“先基线、后条目”的原则：先确认本次发布基线版本和核对清单版本是否正确，再逐条排查具体条目。基线本身有误时，后续条目排查会整体偏移，先固定基线能减少返工。
两类常见误判需要特别区分。清单未填不等于内容缺失，条目空白可能只是核对人尚未执行，应先确认核对动作是否发生，再判断内容是否存在。分支差异不等于版本错误，多分支并行开发时，发布分支与开发分支存在差异属于正常现象，判断版本是否错误应比对发布基线登记的版本与制品实际版本，而不是比对分支间代码差异。把这两类情况直接定性为内容问题或版本问题，会导致修正任务指向错误对象，浪费修正窗口。
每条不通过项最终形成一行记录：症状描述、原因假设、验证证据、结论（已证实或待验证）、待验证项的下一步验证动作。这份原因假设与证据对照表是修正任务分派的依据。
推动修正：任务分派、处置动作与风险边界
原因证实后，每条不通过项转成一条修正任务，任务至少包含四项信息：责任人、修正内容、截止时间、验收人。责任人负责执行修正，验收人负责在重新核对时确认该项已闭环，两者分开可以避免“自己改自己验”。截止时间应与发布窗口对齐，无法在窗口内完成的，由发布负责人决定延期发布或调整范围，并同步告知下游依赖方。
处置动作按类型区分。内容遗漏的，由文档或配置责任人补录缺失内容，补录后对照核对清单逐项确认覆盖；版本不一致的，先确认正确基线版本，再对齐制品、部署包与文档标注，涉及重新打包的按下一段的风险边界执行；证据缺失的，补齐测试报告、评审记录或审批材料并归档到指定位置，无法补做的证据应说明原因并由验收人确认替代证据；流程未走完的，推动对应评审或审批节点完成，明确卡点输入并催办。
涉及重新打包、覆盖制品或回滚的操作，必须先备份当前制品和配置，冻结相关制品的写入权限，并设定停止点：重新打包后版本号校验不通过、或覆盖后发现原制品仍被下游引用时，立即停止并回到冻结状态评估。回滚只在确认新制品不可用时执行，回滚前记录回滚原因和回滚目标版本，回滚后重新走核对流程，不能以回滚代替核对。
修正期间发布保持冻结，所有修正动作和范围变更同步到发布记录，参与核对的各方看到同一份状态。修正任务的分派、状态流转和证据归档如果分散在聊天工具和本地文件中，容易出现责任人和验收人对不上号的情况。ONES 的工作项可以承载每条修正任务的责任人、截止时间和状态流转，相关证据文档挂在对应工作项下，重新核对时按工作项逐条确认闭环，发布负责人据此判断是否具备解除阻断的条件。
重新核对的执行方式与通过判定
修正完成后，重新核对沿用同一份核对清单和同一发布基线。不换清单、不换基线是保证口径一致的关键：换清单会引入新的判断标准，换基线会让已通过的条目失去参照。若修正过程中确需调整基线，应作为一次基线变更单独记录，并对全部条目重新核对，不能只核对变更部分。
重新核对按两步执行。第一步验证修正项，逐条确认修正任务已完成、证据已归档、验收人已确认；第二步回归未受影响项，对本次未修改但属于同一发布批次的条目重新确认结论仍然有效，防止修正动作引入新的不一致。回归范围以阻断范围确认记录中的受影响范围为准，范围外的条目可抽样确认。
通过标准是全部条目有结论且有证据支撑。有结论指每条核对项明确标注通过或不通过，不存在空白和待定；有证据支撑指结论对应的材料可追溯，例如版本比对记录、测试报告、审批记录。仅口头确认或聊天记录不作为通过依据。全部条目满足标准后，由发布负责人宣布解除阻断，重新核对记录与通过判定结论一并归档。
重新核对仍未通过时，进入二次循环：未通过项重新走原因定位和修正任务分派，已通过项保持不变。出现以下情况应升级处理：同一项连续两次修正仍未通过，说明原因假设可能有误，需要重新定位；修正超出预定截止时间且影响发布窗口，由发布负责人上报并决定延期或缩范围；不通过项涉及对外交付内容的正确性且无法在窗口内确认，按阻断处理，不进入带条件放行。
验证恢复与复发预防
解除阻断后，发布恢复动作本身需要确认和留痕。确认内容包括：实际发布的制品版本与核对通过的基线一致，发布说明与最终交付内容一致，下游依赖方已收到恢复通知。留痕内容包括解除阻断的时间、依据、参与确认人，以及本次修正任务的闭环记录。发布恢复后短时间内出现与本次修正相关的问题，应回溯到对应的修正任务和核对记录，判断是修正不彻底还是核对遗漏。
减少同类不通过，靠把本次问题回写进核对机制。具体做法有四条。第一，把本次不通过项转化为核对清单的新增检查项或检查说明，例如某类文档容易遗漏的章节、某类制品版本标注的核对方法，写进清单模板。第二，在发布流程中前置核对时点，把内容完整性、版本一致性、证据归档的检查放到发布窗口之前，留出修正时间，而不是在发布当天集中核对。第三，为每类检查项明确责任人和核对时点，清单条目与角色对应，避免出现无人认领的空白项。第四，统计历史不通过项的类型分布和发生频次，按季度或按版本回顾，观察某类问题是否下降，以此判断清单修订和前置核对是否有效。改进是否有效以数据判断，不以“这次没出问题”作为结论。
复发预防措施应形成清单，逐条写明措施内容、责任人、生效版本和验证方式。验证方式可以是下一发布批次中该类不通过项的数量变化，也可以是抽查核对清单中新增检查项的执行记录。措施生效后持续观察一到两个发布周期，再决定保留、调整或撤销。
常见问题
核对不通过时，什么情况下可以带条件放行而不是阻断发布？
涉及对外交付内容错误、制品版本不可追溯、关键证据缺失且无法在发布窗口内补齐的，应判定为阻断，发布暂停。仅涉及文档措辞、非关键说明补充，且不影响交付物本身正确性和可追溯性的，可以由发布负责人评估后带条件放行。带条件放行需要明确补齐时限和责任人，并在发布记录中登记遗留项。边界判断由发布负责人与质量或测试负责人共同确认，避免单方放宽。
修正过程中需要重新打包或回滚制品，应该注意哪些停止点？
重新打包、覆盖制品或回滚前，先备份当前制品和配置，冻结相关制品的写入权限。设定停止点：重新打包后版本号校验不通过，或覆盖后发现原制品仍被下游引用时，立即停止并回到冻结状态评估。回滚只在确认新制品不可用时执行，回滚前记录原因和目标版本，回滚后重新走核对流程，不能用回滚代替核对。
重新核对时发现同一项连续两次修正仍未通过，该怎么处理？
同一项连续两次修正仍未通过，通常说明最初的原因假设有误，应重新定位原因，而不是继续在原有修正方向上追加动作。同时由发布负责人评估对发布窗口的影响，决定延期发布或缩小发布范围。若该项涉及对外交付内容的正确性且无法在窗口内确认，按阻断处理，不进入带条件放行。
修正期间基线版本需要调整，重新核对要全部重来吗？
需要。重新核对沿用同一份核对清单和同一发布基线是保证口径一致的前提。若修正过程中确需调整基线，应作为一次基线变更单独记录，并对全部条目重新核对，不能只核对变更部分。只核对变更部分会让已通过条目失去统一参照，后续难以判断结论是否仍然有效。
怎样判断复发预防措施是否真的有效？
以数据判断，不以单次发布没出问题作为结论。可以统计下一发布批次中该类不通过项的数量变化，或抽查核对清单中新增检查项的执行记录。措施生效后持续观察一到两个发布周期，再决定保留、调整或撤销。历史不通过项的类型分布和发生频次按季度或按版本回顾，用于观察某类问题是否下降。
