缺陷报告怎么写

何时用

• 新缺陷要入库或转交修复
• 复现步骤含糊，他人照做不了
• 验证/关闭需要可对照的原步骤
• 需要区分严重度与优先级

怎么做

1. 解析现象与标题

1. 从描述抽出：破什么、在哪、怎么触发、期望；用检索（Grep 系统名/UI 文案）补可能系统/文件。
2. 标题写成「具体动作 + 可观察结果」（例：打开背包第二页崩溃）；约 15～40 字，含系统关键词。
3. 分类：玩法/UI/音频/表现/性能/崩溃/网络；填系统字段与可疑路径。
4. 若像需求争议：标题前标「需求争议?」，与纯缺陷分列。
5. 用缺陷库搜索：标题关键词 + 系统字段；命中则链旧单并追加「新环境：构建/机型」。
6. 从堆栈顶帧或 UI 文案 Grep 仓库，把可疑路径写进「相关文件」；写「疑似」不写「根因已定」。

做到：标题含系统+症状可检索；分类/系统字段已填；重复单已链或标新建理由。

2. 写可执行复现块

1. 前置条件：存档/进度/开关/账号态；缺一可能不复现的要写明。
2. 逐步操作：每步一个动作；步后写观察；总步数尽量 ≤8，超出先按 client-bugfix 缩路径；步骤用可执行动词。
3. 成对写期望 vs 实际。
4. 频率：总是/常见/偶发；偶发附：已尝试次数、成功复现次数、可疑变量（多人对战/弱网/特定存档）。
5. 环境块：构建号、平台、场景、关键背包/进度态；可修单必须含构建号。
6. 偶发缺陷附「最小日志包」指引给复现人。

做到：复现步骤第三人可照做；环境块含构建号/平台/画质。

3. 补证据与技术上下文

1. 证据包路径约定 bugs/<id>/：repro_steps.md、log.txt、stack.txt、shot_*.png；大录像只存链接；贴日志摘录（首个异常前后）并说明「看哪一块」。
2. 列出可能文件与相关系统（检索所得）；写「疑似」而非断定根因。
3. 严重度锚：必现崩溃/丢档/付费失败=最高；挡主流程无法绕过=次高；有绕过=中；文案/轻微=低；优先级另栏写排期。
4. 性能类附 Profiler 尖峰帧号或帧时数字，并写对比机型/档位；无则写「缺采样」。
5. 安全/丢档类标高严重度并链 anti-cheat / save-schema 相关同事。

做到：证据路径可点开或「缺什么才能验」显式；严重度与优先级分栏未混写。

4. 去模糊词并标验证方式

1. 全文搜「有时/好像/可能/大概」；能改成条件就改，不能则标 CANNOT VERIFY 缺项清单。
2. 验证区预留：验证人、验证构建号、结论 FIXED/STILL PRESENT/CANNOT VERIFY。
3. 需求争议：列「设计期望来源」（GDD 节/口述），与程序实现分列。
4. 提交前自读一遍：陌生人能否不提问直接复现；提交后把单号回填到相关 PR/提交说明。

做到：步骤无不可执行模糊词；缺口显式；验证方式（构建号+步骤）清楚。

做到

• 标题具体可检索；复现步骤可照做；期望/实际成对
• 环境含构建号与平台；证据或明确缺失项；严重度与优先级分写

失败回哪一步

• 标题不可检索、重复单未链 → 回步骤 1
• 步骤含「随便」、缺构建号、期望缺失 → 回步骤 2
• 证据路径空、严重度优先级混写 → 回步骤 3
• 模糊词未清、验证区空 → 回步骤 4

下一步常接：client-bugfix；验证时对照原步骤。