把“导入失败了”改成能核查的一件事
以下用一个示例贯穿：运营人员把三份门店订单表放入导入目录，点击“开始导入”，页面停在第二份文件。此时最有价值的问题是：第一份是否已经写入、第二份写了多少、第三份是否启动。只说“系统卡住了”，维护人员还得重新询问这些信息。
一条可用的反馈可以是：“本地时间周二09:16，批次B014，导入三份订单表；预期新增18条，页面显示已处理6条后无响应；订单查询能查到其中6条，另外12条尚未核实。我没有再次点击，保留了原文件。”没有查清的部分写“未核实”，不要猜成“全部失败”。
用五组信息把现场连起来
| 信息 | 示例填写 | 能帮助判断什么 |
|---|---|---|
| 时间与身份 | 周二09:16，门店运营账号，办公室电脑 | 对应哪次操作和哪组权限 |
| 工具与输入 | 工具版本1.4；批次B014；三份原表 | 代码、规则和文件是否一致 |
| 操作顺序 | 选目录→预览18条→开始导入→停在第二份 | 失败发生在哪一步 |
| 预期与实际 | 预期18条；界面停在6条；查询可见6条 | 界面提示与业务结果是否一致 |
| 影响与已做动作 | 当天汇总未发送；未重试；原表已保留 | 优先级、重复风险与可用证据 |
截图应包含报错文字、所在页面和批次号；长错误信息另存文本，便于搜索。工具没有批次号时，用操作时间、输入文件名和账号组合定位，并把“增加批次号”列为后续改进。
保留一个最小样本，别反复改现场
把原输入保留为只读副本，再制作脱敏的复现样本。例如问题疑似来自空日期，就保留一条正常行和一条空日期行，其余客户信息换成示例值。记录删减过程，避免删掉了触发条件却报告“问题消失”。
不要先改列名、重命名原文件、清理日志，再请求排查。确需继续工作时，另开新批次并标记与B014的关系。涉及新增记录、改名或发送通知的工具，在结果未知时先查业务记录，确认哪些动作完成后再决定重跑范围。
证据需要足够，也需要克制
故障单不需要密码、登录验证码或完整访问令牌。OWASP的日志指南也明确建议避免直接记录此类秘密，并限制日志读取权限。提供错误码、请求编号和脱敏字段通常更适合定位问题；必须检查原始数据时，应通过已约定的受控方式提供。
对外发送截图前，检查浏览器地址、账号区、侧边栏和表格内容。裁去无关页面，但保留错误发生位置。也不要在群聊里发送全部客户资料来“证明文件有问题”。
修复验收要回到原来的失败条件
维护人员说“已修复”后，用B014的脱敏复现样本验证空日期处理，再用正常样本确认没有连带影响。核查成功条数、异常条数以及重复记录，不能只看报错弹窗消失。最后在故障单补上原因、修复版本、验证人和结果；若仍有未恢复的数据，另列清单并指定处理人。