构建验收怎么做

何时用

• 某构建号要提测或对外演示前做实机核对
• 配置表/内容补丁与客户端版本是否匹配不清
• 已知缺陷是否挡主路径需要实测判定
• 需要带病项 Owner 与复审构建

怎么做

1. 锁定构建与输入

1. 锁定构建号、表版本、内容补丁号、分支/SHA、包哈希/签名与 CI 产物路径；热更记组合版本；缺任一则先补齐再测。
2. 取本版 ci-smoke 结果与缺陷列表作输入；没有则先跑核心批；可参考 build-gate-checklist 的 blockers.md。
3. 确认安装包来源（CI 产物路径/商店内测轨）与签名一致；表版本读法（UI 或启动日志关键字）写进脚本。
4. 写验收脚本版本（步骤文件路径）与本构建绑定；验收目录命名含构建号防覆盖。

做到：构建号/表版本/补丁号三号一致可核；输入来源路径可见。

2. 跑主路径验收

1. 按约定验收脚本走完 start→核心循环→存档；每段记通过/失败与耗时（异常慢也记）。
2. 进游戏后读版本 UI 或日志核对表/补丁；不一致即停并标阻断。
3. 关键失败态抽测（断网提示、存档失败）是否仍可读。
4. 演示向构建：扫调试 HUD/作弊菜单/隐藏手势/命令行残留。
5. 失败写最短复现（≤5 步）并截图；证据进 builds/<sha>/acceptance/。

做到：主路径逐步结果有 PASS/FAIL；版本不一致已暴露并阻断后续项。

3. 核对阻断缺陷

1. 对列表中「可能挡主路径」项逐条用原复现步骤复测：仍在/已消/无法验。
2. 挡路标准=无法完成核心循环或必现崩溃；仍在的阻断项写清现象与证据路径。
3. 非阻断项移出挡路清单并写降级理由（有绕过/仅边缘）。
4. 无法验：写缺环境/缺账号，不得默认为已消；汇总挡路集合给构建决策人。

做到：挡路缺陷集合已按本构建实测；每条有复现结论。

4. 清点已知问题处置

1. 可带项写：严重度、复现一步、Owner、目标复审构建号；缺 Owner/复审号的留在阻断集。
2. 可带项同步进 regression-pack，下一构建必回扫。
3. 写构建结论枚举：可提测/不可提测/有条件提测（条件可复查；有条件必须附复审构建号）。
4. 保存验收记录与构建号绑定的目录；结论依据实测与挡路集合，不用口头「应该没事」。

做到：每条带病项有 Owner+复审构建号；否则留在阻断集。

做到

• 构建/表/补丁号对齐；主路径验收脚本跑完有结果
• 挡路缺陷已复测；带病项均有 Owner 与复审构建；失败有最短复现一句

失败回哪一步

• 三号不齐、测错包轨、无冒烟输入 → 回步骤 1
• 主路径未跑完、版本不一致却继续 → 回步骤 2（先对齐版本）
• 挡路项未用原步骤复测、无法验当已消 → 回步骤 3
• 可带项无 Owner/复审号 → 回步骤 4

下一步常接：失败 bug-report-write；包回归 regression-pack。