Bug 修复交付前检查清单

Bug 修复完成后，最容易被忽略的是交付前检查。新手常常把代码改到“看起来好了”就发给客户，但没有说明原问题、验证方式和未覆盖范围。这样一来，客户后续遇到相邻问题时，很容易认为你没有修好。

这份清单用于交付前最后过一遍。它不替代测试，但能帮你把测试和沟通整理成客户看得懂的说明。建议搭配 Bug 修复交付说明模板、/tools/error-explainer 和 /templates 使用。

适合谁

适合已经完成一个小型修复，准备给客户发交付消息的新手。任务可以是页面按钮异常、表单提交错误、部署失败、接口报错、样式错位、环境变量缺失等低风险问题。

也适合在练习项目里训练交付习惯的人。即使没有真实客户，也可以按客户项目的标准写修复说明。这个习惯会让你的作品集更可信。

不适合谁

不适合还没有复现问题的人。如果你没有看过原始错误，也没有测试过修复结果，就不应该进入交付环节。

也不适合高风险系统的最终验收。涉及生产数据、支付、隐私、密钥、安全漏洞或客户核心业务时，需要更正式的授权、测试和复核，而不是只靠一份普通清单。

具体步骤

1. 原问题是否记录清楚？包括客户原话、截图、错误码、触发路径和出现环境。
2. 是否能复现原问题？如果不能复现，是否已经向客户说明诊断限制？
3. 修改范围是否明确？写清改了什么文件、什么逻辑、什么配置。
4. 是否没有误改无关内容？检查 git diff，避免把无关改动一起交付。
5. 是否跑过必要测试？可以是本地手测、构建、lint、单元测试或页面验证。
6. 是否保留测试证据？终端输出、截图、链接、测试输入和输出都可以作为证据。
7. 是否写清未覆盖范围？例如不包含新功能、不包含生产数据验证、不包含长期监控。
8. 是否检查敏感信息？截图和日志中不能出现完整密钥、账号、客户数据和私密链接。
9. 是否准备客户验收步骤？客户按什么路径、用什么数据、看到什么结果算通过。
10. 是否准备后续说明？如果再次出现问题，客户应该提供什么信息。

交付消息模板

本次 bug 已完成修复，并按以下方式验证：

- 原问题：
- 修改内容：
- 测试结果：
- 本次未包含：
- 建议你按以下步骤验收：

如果验收时仍能复现，请把触发步骤、截图和时间发给我，我会基于本次范围继续确认。

风险提醒

交付前不要为了展示工作量而贴出大量日志。日志里可能包含路径、账号、密钥片段、客户信息或内部链接。需要提供证据时，先脱敏，再截取必要部分。

也不要把相邻问题自动纳入本次修复。客户可能在验收时发现另一个问题，你可以协助判断，但要区分“原 bug 未修复”和“新增范围”。这不是斤斤计较，而是保护双方对交付的理解。

复盘建议

交付后记录一次复盘：这个 bug 最初为什么出现？排查时哪一步最有效？有没有遗漏客户沟通？下次能否把同类问题做成模板？如果你连续复盘几次，会很快形成自己的排错流程。

对新手来说，交付清单的价值不只是减少纠纷，也是在训练职业节奏。客户看到你有清楚记录，会更容易相信你不是随便改了一下。

验收边界示例

交付说明里可以写得具体一点：本次已在本地开发环境验证通过，线上部署由客户确认；本次只验证测试账号，不接触真实用户数据；本次只修复提交失败，不包含新增字段；本次只修改前端展示，不包含后端接口重构。

这些句子看似细碎，但能减少很多误会。客户验收时如果发现另一个问题，你可以根据这些边界判断它是否属于本次范围。边界清楚，沟通会更快，也更容易保护新手的时间。

交付前自问

最后再问自己三件事：客户能不能按我的说明复现验收？如果客户明天再问，我能不能从记录里找回当时改了什么？如果这份交付说明被第三个人看到，他能不能理解本次修复的范围？

如果答案是否定的，就先别急着发送。补一张截图、补一个测试输入、补一句未覆盖范围，通常就能让交付质量提升一大截。

免责声明

本文仅供学习和交付流程参考，不构成法律、安全、财务或平台合规建议。不同项目和平台规则不同，发布前需要人工复核。处理客户项目时，请遵守授权范围、最小权限原则和平台规则。

CTA：交付前，把这份清单复制到你的项目笔记里；需要模板时去 /templates，需要解释报错时用 /tools/error-explainer，最后人工补充真实测试结果。