为什么格式比内容更容易被忽略
Bug 报告格式 = 10 个固定字段，按「标识 → 环境 → 现象 → 证据」四段排列。 顺序固定下来，开发扫一眼就知道该去哪里找什么，也不会再回头问你第二遍。下面给出完整字段清单、每个字段的书写规则与正反示例，以及 7 个把报告写废的格式错误。
同一批信息，换个格式写，处理效率差一倍。格式不统一通常带来三类代价：
格式的价值不在好看，而在于让同一个字段永远出现在同一个位置。
标准 Bug 报告格式：10 个字段
| # | 字段 | 作用 | 是否必填 | 一句话写法 |
|---|---|---|---|---|
| 1 | 标题 | 让开发在列表里判断要不要点开 | 必填 | 组件 + 操作 + 异常结果 + 条件（写法见 bug 标题示例） |
| 2 | 编号 | 让所有人能引用同一条记录 | 必填（系统生成） | BUG-0042，不要用"刚才说的那个" |
| 3 | 严重程度 / 优先级 | 排期依据 | 建议填 | 严重程度看影响面，优先级看业务节奏，两者分开 |
| 4 | 环境 | 决定这份报告能不能复现 | 必填 | URL、浏览器版本、操作系统、设备、分辨率、账号 |
| 5 | 前置条件 | 复现的起点状态 | 建议填 | "已登录企业账号，且购物车中已有 2 件商品" |
| 6 | 复现步骤 | 让别人走到同一个现场 | 必填 | 编号，一步一个动作（见 复现步骤怎么写） |
| 7 | 期望结果 | 判断"这算不算缺陷" | 必填 | 写应该发生什么，不写"没有正常工作" |
| 8 | 实际结果 | 事实描述 | 必填 | 现象 + 数字 + 报错原文，不含推测 |
| 9 | 证据 | 让开发不必重跑一遍 | 强烈建议 | 标注截图、录屏、控制台日志、失败请求 |
| 10 | 备注 | 补充上下文 | 选填 | 出现频率、临时方案、关联工单 |
每个字段怎么写
标识类：标题、编号、严重程度与优先级
- 标题：一行说清"在哪里、做了什么、结果错成什么样、什么条件下"。40 组好标题与差标题对照见 bug 标题示例。
- 编号：交给系统生成，不要手工编号——手工编号一定会重号。
- 严重程度 vs 优先级：这是最常被混为一谈的一组字段。
| 字段 | 回答的问题 | 由谁决定 | 示例 |
|---|---|---|---|
| 严重程度（Severity） | 这个缺陷本身破坏有多大？ | 测试 / 提出人 | 数据丢失 = 致命；文案错别字 = 轻微 |
| 优先级（Priority） | 我们什么时候修它？ | 产品 / 研发负责人 | 文案错别字若在首屏 = 高优先级 |
环境类：环境、前置条件
环境字段必须写全 6 项：URL、浏览器与版本、操作系统、设备、分辨率/视口、账号类型。只写"Chrome"等于没写——不同版本之间的行为差异在 Web 项目里非常常见。
前置条件最常漏的是数据状态，而不是登录状态："购物车中已有 2 件商品""账号处于试用期第 3 天""该订单已发起过一次退款"——这些才是把复现卡住的东西。
现象类：复现步骤、期望结果、实际结果
- 复现步骤：编号、一步一个动作、用真实数据。完整方法见 复现步骤怎么写。
- 期望结果：写"应该发生什么"，并尽量引用依据（需求文档条目、验收标准编号、行业常识）。写"没有正常工作"等于把判断责任推回给开发。
- 实际结果：只写观察到的事实，带上数字和报错原文。不要写推测——"应该是缓存问题"这类猜测请移到备注，并标明"疑似"。
证据类：截图 / 录屏 / 日志、备注
- 截图要标注：圈出问题区域、加箭头或文字，让开发不用在整屏里找。
- 录屏控制在 10–30 秒，只保留关键片段——一段 5 分钟的录屏通常没人看完。
- 日志给有用的部分：错误级控制台输出、失败的网络请求（HTTP ≥ 400）、关键接口的请求体与响应体。
- 备注写两件事：出现频率（必现 / 偶发 + 概率）、临时绕过方案。
三种载体的格式差异
| 载体 | 字段呈现方式 | 最容易踩的坑 |
|---|---|---|
| 缺陷跟踪系统（Jira / Linear / GitHub Issues） | 自定义字段 + 描述模板 | 把环境信息写在描述末尾，被长文本淹掉；应该用自定义字段 |
| 邮件 / 即时通讯（发给客户或外部协作方） | 纯文本分块 | 没有 TL;DR；附件命名随意，收件人要在十几个文件里找 |
| 表格台账（Excel / Google Sheets / 飞书多维表格） | 一行一条，列 = 字段 | 列顺序与上面的 10 字段不一致，筛选和排序都做不了 |
载体不同，字段不能省。信息缺失不会因为"发的是邮件"就被原谅。
7 个把报告写废的格式错误
screenshot-1.png，三天后连提交者自己都对不上。格式自检清单
提交前逐条确认：
- 10 个字段齐全，且顺序一致？
- 环境 6 项（URL / 浏览器 / 系统 / 设备 / 分辨率 / 账号）都写了？
- 期望结果与实际结果分开写？
- 复现步骤有编号，且一步一个动作？
- 截图有标注、录屏不超过 30 秒？
- 实际结果里没有任何未经证实的推测？
- 出现频率写清楚（必现 / 偶发 + 概率）？
常见问题（FAQ）
Bug 报告有"标准格式"吗？
没有全行业强制标准，但有事实上的共识：标题、环境、复现步骤、期望结果、实际结果、证据这 6 项几乎出现在所有体系里（IEEE 829、ISTQB、各家的缺陷单模板）。本文的 10 字段是在此基础上补齐了标识与备注字段。
字段顺序可以调整吗？
可以，但要在团队内统一且稳定。顺序固定的价值在于肌肉记忆——开发知道往哪个位置扫。频繁调整顺序比顺序本身好坏影响更大。
严重程度和优先级到底有什么区别？
严重程度描述缺陷的客观破坏力（由测试判断），优先级描述修复的紧急程度（由产品判断）。两者可以不一致：首屏文案错别字严重程度很低，但如果三天后要对外发布，优先级会很高。
很简单的 Bug 也要填 10 个字段吗？
不必。简单 Bug 可以只填标题、环境、实际结果三项，但不能省环境——省略环境是"无法复现"的头号来源。字段可选，位置不能变。
"格式"和"模板"有什么区别？
格式是字段规范：哪些字段、什么顺序、每个字段怎么写。模板是可直接复制填空的骨架文件。两者配合使用——先按格式定义字段，再用模板落地。需要可复制填空的骨架，见 Bug 报告模板（含 Word / Markdown 版本）。
格式可以自动执行，剩下的是你的判断
说清楚边界：BugCapturer 不替你判断什么是缺陷、也不替你写标题——那需要你对现象的理解。但最容易写漏、最耗费时间的那部分，它可以自动补齐：
- 自动技术信息：URL、浏览器、操作系统、屏幕分辨率与视口尺寸自动写入环境字段，不必手抄。
- 诊断数据：自动收集错误级控制台日志与失败的网络请求（HTTP ≥ 400），敏感参数（token、密码、API Key）自动脱敏。
- 标注截图：拖拽选区即可画箭头、方框、文字，把"错在哪"固定在图上。
- 录屏：录制当前标签页并裁剪片段，交给开发的是可验证的短视频。
- 分享或同步：生成外部协作方可免注册查看的分享链接，或把报告送进飞书多维表格 / 通用 Webhook。
你只需要保证字段判断准确，其余交给工具。
延伸阅读
- Bug 报告模板（完整字段与可复制骨架）
- bug 标题示例（40 组好标题与差标题对照）
- 复现步骤怎么写（5 个完整示例）
- 如何高效报告 Bug
- 网站上线前 QA 清单