内测修复的逐项审计闭环

适用场景：拿到一份 bug 修复清单，需要逐项确认、补完、提交、验证。

问题

修复清单列出 12 项，其中 10 项已经在未提交改动中实现、2 项需要补代码。如果不做审计直接从头写，会重复劳动；如果盲目信任「已经修了」，可能漏项。

方法：七步审计闭环

修复清单 → ① 逐项读清单理解问题
         → ② git diff 逐文件审计，确认哪些已实现
         → ③ 补完未实现的项
         → ④ 逐文件 diff 审查，确认无遗漏
         → ⑤ git commit（含清晰 commit message）
         → ⑥ 本地部署验证
         → ⑦ curl + grep 确认前端/后端关键标记命中

关键细节

• 第②步的 grep 验证：不是人工目视 diff，而是用关键标记确认。例如确认 BUG-03 修复：grep -c "myVoteSubmissionId" app.js 返回 3 次命中，确认服务端 buildBattle() + 前端 initializeBattle() + selectVote() 三处都有。
• 第⑦步的 marker 清单：每一项修复都应有一个可 grep 的关键标记。如果一个修复没有这样的标记，说明改动不够明确。
• commit 策略：当前阶段改动量不大、团队只有自己，单 commit 可接受。多 domain 改动建议拆 commit。

边界

• 本方法适合「中间接手」场景——你不是第一个动手的人，但需要确认改动是否正确。
• 如果修复项之间有强依赖（比如改了同一个函数的签名），拆 commit 需要额外注意顺序。
• 验证阶段只做 marker 级别确认，不等同于功能测试。理想情况应补上全流程回归。

来源

PB Arena commit 1b0a90e，2026-08-11 内测修复 12 项。

关联文档

• ⚠️ 公屏下线只删了界面_删界面不等于关链路_v1 —— 同族不同轴(2026-08-18):本篇的轴是「清单里哪些已在未提交改动中实现」,防重复劳动;那篇的轴是**「反馈日期与当前 HEAD 之间的时间漂移」,防按过期描述修出新问题——16 条反馈隔了 20 个提交,2 条已被修掉、1 条按字面修会把「显示错」变成「静默失败」;两篇的共同前提都是动手前先审计**
• 09_平台工程索引 —— 平台工程区入口