一份有用的 Bug 报告，必须让研发知道在什么环境、按什么步骤、实际出现了什么，以及本来应该怎样。AI 可以把零散反馈、截图与日志整理成缺陷单，但不能从“点了没反应”自动补出真实复现步骤或故障原因。先补齐关键事实，再生成报告，通常比让 AI 写一段更专业的描述更有效。
不是所有反馈都应该建成 Bug
用户描述的是感受，缺陷单描述的是可核对的行为偏差。先确定反馈属于哪类，才能把它交给正确的人。否则 AI 可能把“不喜欢这个颜色”写成严重缺陷，把“暂不支持导出”写成接口故障。
| 反馈 | 先归到哪里 | 需要补的依据 |
|---|---|---|
| 按已支持流程操作，结果与确认规则不符 | 疑似软件缺陷 | 版本、步骤、预期与实际、证据 |
| 希望增加一个目前不存在的功能 | 功能需求 | 用户目标与现有替代办法 |
| 页面能用，但入口难找 | 体验问题 | 任务、观察行为与影响，可进入设计改进 |
| 原型按钮点击后没有跳转 | 原型制作或评审问题 | 该路径是否计划实现；不等同线上系统故障 |
| 只说“系统很慢” | 待澄清反馈 | 哪项操作、等待多久、发生频率、环境与时间 |
不清楚当前预期行为时，先找已确认规则或向负责人补问。测试环境里的缺陷也要说明环境，不能直接当作线上所有用户都受影响。原型意见可按原型评审清单整理，避免混进软件缺陷队列。
把“点了没反应”拆成四个补问
下面用一条练习反馈说明如何补问：客服收到“筛选成员时点了没反应”，附一张停在成员列表的截图。单凭截图无法知道按钮是否收到点击、列表是否本来没有变化，也无法确认故障来自页面还是接口。
| 先问什么 | 为什么问 | 记录示例 |
|---|---|---|
| 在哪个版本、环境和账号角色下？ | 界定范围，便于复现 | 测试环境 v1.8-rc2；管理员；Chrome 129 |
| 从哪个页面开始，依次做了什么？ | 区分操作路径与主观感受 | 进入成员管理，角色选“成员”，状态选“停用”，点查询 |
| 实际看到什么，预计应看到什么？ | 把“没反应”变成可对照结果 | 列表仍有启用成员；预期只显示停用成员 |
| 多久发生一次，有什么证据？ | 区分稳定复现、偶发与尚未验证 | 同一数据下 3 次均出现；截图和脱敏请求记录已提供 |
这些示例是填写格式，不应替真实用户预填。还没有答案的字段写“待补充”；一次完整补问优先覆盖复现必需信息，不必先收集与问题无关的所有设备参数。
先让 AI 做证据表，再写缺陷单
在本地项目中建立 feedback/、evidence/ 和 reports/。保留反馈原话，截图与日志用编号关联。若文件多，可先按本地项目整理方法区分原始材料和工作输出。用户标识与请求中的敏感字段应按团队要求处理后再提供。
任务：把反馈整理成缺陷单草稿，不修改代码。
请只读取我指定的反馈、截图说明和脱敏日志。
先输出三栏：已知事实 / 合理猜测 / 缺失信息。
事实必须附来源；截图看不出的点击过程不得补写。
没有实际操作记录时，不把猜测写成复现步骤。
若缺少预期行为，先列补问，不自定业务规则。
资料齐全后按“标题、环境、前置条件、步骤、预期、实际、复现频率、证据、影响、待确认”输出。
根因只能写已确认或待排查，不根据 HTTP 状态码直接下结论。
结果写入 reports/bug-draft.md，不自动创建工单或发送。| 类别 | 本次练习中的内容 | 报告写法 |
|---|---|---|
| 事实 | 选择角色“成员”和状态“停用”后，列表仍出现启用成员 | 可进入实际结果；附步骤和截图编号 |
| 事实 | 脱敏请求记录显示请求携带 role=member 与 status=disabled | 可作为排查线索，不代表服务端一定正确解析 |
| 猜测 | 可能是角色与状态被按“或”组合 | 列为待排查假设，不写“已定位根因” |
| 缺失 | 其他浏览器、角色及生产环境是否同样出现 | 保留未验证范围，不能扩成所有用户受影响 |
一份可以直接改写的 Bug 报告
补充了操作记录后，可以把报告写到以下程度。标题说明条件和现象，不用“严重 Bug”“功能异常”等缺少定位信息的词。
# [成员管理] 同时筛选成员角色和停用状态时，列表仍包含启用成员
## 环境
测试环境；版本 v1.8-rc2；浏览器 Chrome 129；管理员账号。
以上为练习记录，实际提交请替换为真实环境。
## 前置条件
列表中同时存在：成员/启用、成员/停用、管理员/启用三类数据。
## 复现步骤
1. 从首页进入成员管理。
2. 角色选择“成员”，状态选择“停用”。
3. 点击查询，等待本次请求返回。
## 预期结果
仅显示同时满足“成员”和“停用”的记录。
依据：已确认筛选规则 R-07，多个条件同时生效。
## 实际结果
列表仍出现“成员/启用”的记录。
## 复现频率
同一测试数据下 3 次操作均出现；其他环境未验证。
## 证据
E-01：筛选条件与结果同屏截图。
E-02：脱敏请求记录，包含本次 role/status 参数与时间。
## 影响
管理员无法依赖该组合筛选区分停用成员；影响范围待进一步确认。
## 待排查
检查请求参数解析、组合条件和返回结果；当前没有确认根因。正式提交时，删除练习提示，填写真实版本、规则来源、证据和频率。不要把“本例 3 次”复制成自己的复现统计。Atlassian 的 Bug 报告模板也将复现步骤、预期与实际行为、环境等作为核心内容；工具中的字段名称可以不同，信息不能缺。
严重性和优先级，由不同问题决定
严重性回答“问题造成什么损害”，优先级回答“团队先处理哪个”。AI 可以根据事实整理影响，但不应只根据“无法完成”四个字就自动判最高级。例如无法导出一份临时测试数据，与线上关键业务完全中断，处理等级可能不同。
| 判断维度 | 需要哪些事实 |
|---|---|
| 是否阻断任务 | 有没有替代路径，关键操作是否能继续 |
| 是否影响数据或结果正确性 | 是否丢失、错误写入、重复执行或产生错误业务结果 |
| 范围多大 | 受影响版本、角色、账号与环境；未知范围明确写未知 |
| 发生多频繁 | 稳定复现、偶发、只出现一次；说明观察次数 |
| 为何要优先处理 | 发布窗口、用户影响、业务依赖或其他明确约束 |
按照团队既有等级定义填写，不临时创造一套“AI 评分”。涉及权限或敏感数据的证据应通过团队规定渠道交接，避免为证明问题而把完整用户资料放进可公开的截图。
偶发问题也能写成有用的报告
不是每个 Bug 都能稳定复现。此时报告的目标是缩小排查范围：保留发生时间及其时区、操作前后的状态、环境、关联请求标识和已尝试步骤。写“按以下步骤有时出现”，不要把尚未证明有效的步骤写成必现路径。
当两条反馈看起来相同时，先对比版本、条件与实际结果。相同现象可能来自不同原因；不同措辞也可能是同一个缺陷。AI 可以建议合并候选，工单是否合并应在证据对齐后决定。
修复以后，报告还要补哪一行
补上修复版本、验证环境和原步骤的回测结果。如果原报告写得具体，修复后的确认也会具体：相同条件下是否只返回停用成员，清空一个条件时是否仍正常。更完整的边界检查可以进入AI 测试用例整理流程；缺陷单本身不需要塞进整套测试计划。
墨刀 AI 客户端可帮助把本地反馈、记录与证据说明整理成结构化草稿。使用客户端时，先要求它列缺口再写报告：少补一句没有来源的话，往往比多写一段技术推断更能帮助研发。
