第一步：缺陷分级
按是否影响主流程、是否涉及数据与权限、是否有替代人工路径分三级。为什么先分级：不分级就无法决定哪些必须修完才能上线，现场容易陷入全都要修的僵局，项目被无限期拖住，分级标准要事先写进验收规则。
第二步：能否缩范围
若问题集中在某个非核心场景，可把该场景从本期范围移除，其余部分按原计划验收。怎么做：范围调整要书面化，并在上线时同步关闭对应入口，避免用户用到未验收的功能，也避免范围被反复解释。
第三步：有条件通过
只有缺陷有明确修复计划、有临时人工兜底、且业务方书面接受风险时才可放行。边界：涉及资金、个人信息与执业签章的功能不建议有条件通过，这类风险不可靠人盯兜底长期覆盖，建议列入下期。
第四步：退回重做
当问题源于方案本身而非实现细节，修补成本高于重做时，应退回方案阶段。怎么做：用评测结果说明哪类输入系统性失败，把结论写成需求变更输入，而不是简单归咎于开发不力，否则下一版还会重复。
记录与责任
无论哪种处置，都要记录决策人、依据、风险接受方与后续节点。为什么：验收争议往往在数月后爆发，当时的处置依据是唯一能说明为什么这样决定的材料，缺少记录就只能各说各话，也难以向审计解释。
适用与不适用
适合谁
- 验收未通过、需要决定下一步的项目组
- 客户与供应方对缺陷严重性判断不一致的交付
- 需要在不完美结果下做出上线决策的业务负责人
不适合谁
- 缺陷原因尚未定位就急于上线的场景
- 涉及法定签章与强制合规且无替代方案的功能
典型场景
某集团的人力资源助手验收时，薪酬查询场景出现越权回答。项目组判定为一级缺陷，将薪酬模块整体移出本期范围并关闭入口，其余入职与假期场景按期验收；一个月后权限模型改造完成，再单独验收该模块，其余场景按原计划继续。
可执行步骤
- 按是否影响主流程、是否涉及数据权限、有无替代路径给缺陷分级。
- 判断问题是否集中在可以剥离的非核心场景，并评估剥离的时间成本。
- 缩小范围时同步关闭对应功能入口，并提前告知使用方与一线客服。
- 有条件通过必须同时具备明确修复计划、人工兜底与书面风险接受。
- 方案性问题退回需求阶段，并用评测结果说明哪类输入系统性失败。
- 完整记录处置决策人、判断依据、风险接受方与后续复查的具体时间点。
常见坑
- 所有缺陷一律要求修完再上线，项目无限延期，业务方逐渐失去耐心与信任，最终草率放行。
- 口头同意有条件通过，没有书面风险接受记录，出问题后责任全部压向供应方，双方关系恶化。
- 缩小范围却没有关闭对应入口，用户仍能进入未验收功能并触发问题，等于范围没缩，责任仍在。
自检与验收清单
- 缺陷是否按统一口径分为三级并逐条标注责任
- 范围调整是否书面化并同步关闭对应功能入口
- 有条件通过是否同时具备修复计划、兜底与风险接受
- 处置决策人、判断依据与后续节点是否留存记录
- 资金、个人信息与签章类功能是否排除有条件通过
常见问题
验收不通过会影响付款吗？
取决于合同约定的里程碑与验收条款，属于商务与法务判断，不由技术方单方决定。建议在处置记录中区分未通过项与已通过项，避免整期款项因局部问题被全部冻结，也便于后续对账与说明。
客户坚持要上线怎么办？
把风险写清楚：哪些功能未验收、可能造成什么后果、由谁承担。客户仍要求上线时，应有书面确认并保留人工兜底安排。供应方不应在无记录的情况下默认承担全部后果，也不要口头承诺兜底。
有条件通过的期限怎么定？
给出明确日期与验证方式，到期未修复则自动关闭该功能或回退到旧版本。期限由业务方与供应方共同确认，并与缺陷修复排期对齐，避免有条件变成无限期拖延，让期限真正有约束力。