写一份别人真正能用的 Bug 报告

用一个可观察的现象做标题

“刷新后购物车数量恢复旧值”告诉读者需要观察什么；“数据库坏了”则直接跳到尚未证实的原因。标题应描述受影响行为，而不是你怀疑的子系统。除非已有共同触发条件的证据，否则不同问题分开记录。

区分步骤与结果

步骤描述别人可以重复执行的动作：加入两件商品、修改数量、刷新。预期和实际结果放在独立字段里。时间顺序可能很重要：保存完成前刷新与成功提示后刷新不是一回事。原始记录没说明，就将时序标记为未知，不要挑选一个方便的解释。

让证据与结论相匹配

同一报告者观察到两次是有用信息，但不能说明全体用户的失败率。截图展示状态，网络响应则可能说明保存是否被确认。保留能回答下一个问题的最小证据，并移除令牌和用户标识。不要因为语气急迫就直接标记“严重”。

用待补信息结束报告

列出浏览器与构建版本、账号状态、保存响应，以及全新会话是否还能复现。好的报告可以不完整，但应让缺口清晰可见。AI 工具只整理你提供的记录。只有实际执行步骤并记录结果，才能更新复现状态。

拆解一个具体例子

Bug 报告整理

编写示例：这份固定结果仅对应示例原文，不是实时 AI 回复。

原始内容

在测试环境商店里，我把两本笔记本加入购物车，将数量改为 3，然后刷新页面。数量恢复为 2，预期应该保留 3。在 Chrome 中遇到两次，没有记录版本，暂时没有网络日志。

解析结果

标题
刷新页面后购物车数量恢复为旧值

环境
测试商店；Chrome，版本未知。账号状态和操作系统未知。

用户报告的步骤
1. 将两本笔记本加入购物车。
2. 将数量改成三本。
3. 刷新页面。

预期／实际
预期保留三本；用户报告实际恢复成两本。

证据
报告者观察到两次，尚无独立复现或网络追踪。

下一步补充
记录浏览器和构建版本；保存数量更新请求的响应；检查界面是否等待保存完成。暂不指定严重级别。