需要设定一个合理的推进测试机制，如果不是非常严格的金融系统项目，可以适当放宽测试通过的标准。

1. C 线不再“一处失败，全线停止”
   今后发现问题后按以下方式处理：
   P0/P1：停止受影响的业务链路，但其他无关 UAT 继续；
   P2/P3：登记缺陷，当前用例标记 CONDITIONAL_PASS，继续后续任务；
   环境或测试数据问题：标记 BLOCKED，不算业务 FAIL，也不阻塞其他模块；
   只有会污染全局数据、破坏权限基线或影响公共环境的问题，才停止整条 C 线。
   也就是说，即使财务文件预览被阻塞，人才、客户、招聘任务、推荐、公共组件等不依赖该问题的 UAT 仍可继续。
2. 把串行 C-UAT 改成三条测试流
   建议拆成：
   测试流
   范围
   推进方式
   C-Core
   登录、权限、核心业务闭环、财务、数据完整性
   严格串行，P0/P1 阻塞
   C-Module
   客户、人才、项目、任务、推荐、供应商等模块功能
   可并行，P2/P3 不阻塞
   C-Experience
   UI、交互、提示、兼容性、非关键边界
   批量检查，全部进入缺陷池
   三条测试流使用独立账号和独立数据编号，避免互相覆盖。
   涉及 Backend 重启、数据库恢复、公共配置修改的用例，单独安排维护窗口，不与其他测试并行。
3. B 线退出“产品扫雷”
   B 线以后只负责：
   Git 基线和变更范围；
   构建、镜像、Migration；
   备份和回滚；
   部署健康；
   与本次变更直接相关的 Smoke。
   B 线不再负责：
   开放式全项目审查；
   每次 RC 都重新跑全部产品功能；
   主动寻找 P2/P3；
   替代 C 线进行完整 UAT。
   否则每一个 RC 都会演变成一次新的全项目测试。
4. D 线改成“缺陷批处理”
   除 P0 外，不要发现一个问题就马上修一个。
   建议每天固定一到两个收口时间：
   上午：C线集中测试和登记
   下午：统一评审缺陷等级
   当天：D线集中修复一批真正的P1
   次日：B线生成一个候选版本
   这样可以从：
   发现1个问题 → 修复 → RC → 部署 → 又发现1个问题
   改成：
   集中发现问题 → 一次分级 → D线批量修P1 → 一次RC
   5、减少重复测试
   每个用例都要标记“已通过基线”和“受哪些文件影响”。
   新的 Hotfix 只回归：
   直接修改功能

• 直接调用方
• 安全/权限边界
• 一条核心冒烟链路
  只有出现以下情况，才重新完整回归：
  Migration 变化；
  权限模型变化；
  公共认证或请求封装变化；
  核心领域模型变化；
  数据修复或存储结构变化；
  多个模块的大规模合版。
  当前 RC5 虽然会涉及认证请求链路，但如果只是复用已有认证 fetch，并没有修改全局认证机制，就不需要重新跑全部权限和业务模块。
  6、建议采用“有限上线”标准
  Win Hunt v1.0 首次上线可以定义为：
  仅内部及指定业务人员使用；
  控制首批账号和业务量；
  不开放大规模外部注册；
  保留快速回滚；
  每日检查错误日志和核心数据；
  P2/P3 在上线后分批修复。
  这样上线判断就不是“系统是否完美”，而是：
  是否足够安全地让一小批真实用户开始使用，并且发现问题时能够控制影响和快速回退。