报告先帮助别人复现
使用 Claude 整理缺陷报告时，目标不是把错误写得严重，而是让接手的人看到相同问题。准备环境、输入、操作顺序和完整现象，避免一句“系统坏了”就要求模型判断根因。本文例子虚构，没有执行真实故障测试。
先保留原始记录
保留准确报错、发生时间和相关操作，脱敏账号、请求参数中的秘密与用户数据。截图只展示必要范围，文字报错另行复制，避免图片文字无法检索。没有收集到的环境字段写待补充，不让模型猜版本或浏览器。
虚构案例：导出按钮无响应
材料是“测试环境，浏览器版本待补；选中三条记录后点击导出，页面持续转圈；等待两分钟仍无文件”。这能描述现象，却不能证明数据库超时或服务器宕机。把观察和原因假设分开，有助于后续定位。
拆成从起点开始的步骤
写清楚进入哪个页面、需要什么权限、选择哪些虚构记录、点击哪个操作。若需要已有数据，将前置条件列出。步骤中不要省略触发条件，也不写无法重现的“正常操作一下”。每一步尽量只包含一个动作。
比较期望与实际结果
期望来自需求或原有约定，例如应该得到三条选中记录；实际则是转圈且未下载。如果文件类型未定义，不要擅自写应生成Excel。对需求不明确的部分列待确认，避免把个人偏好当成缺陷。
区分影响与优先级
记录已知影响，例如测试账号无法导出；不要推断全部用户受到影响。严重程度应依据团队规则，模型只能辅助整理依据。若错误偶发，记录成功和失败各自的输入与条件，比单纯提高措辞强度更有用。
验收报告本身
请同事按步骤尝试，确认材料足以理解。根因未定位时保持待调查，临时绕过也不等于永久修复。后续将有效证据与修复验证追加到同一条记录，保留版本，而不是每次重新生成没有上下文的报告。
继续排查
完成缺陷记录后，可参考《用 Claude 排查代码：从最小复现开始》准备代码与日志。需要测试修复是否覆盖边界，可阅读《Claude 测试用例教程：覆盖边界、权限和失败路径》。