报故障前，先留下这些线索

反馈前，先确定问题发生在哪里

记录发生时间、使用终端和进入的页面。

准备入口、操作步骤和必要截图

准备出错页面的地址、发生时间、使用终端、所用角色和按顺序发生的操作，分别写出原本期待什么与实际出现什么。截图或日志只保留定位需要的线索，先去掉口令及无关个人资料；涉及付款、删除或重复提交的操作，不为重现问题反复执行。

顺序不能漏，预期和实际分开写

• 按顺序写出出错前的操作，注明输入与角色。

• 分别写预期结果和实际结果，保存必要截图。

一条失败操作，怎样说明白

问题说明可以写成：进入文章列表，搜索一个名称，打开详情，返回后关键词消失。预期是保留关键词，实际是显示全部文章。这样的描述把触发步骤和判断标准分开，修正后也能按相同步骤复测，而不只问现在还出不出问题。

不需要密码或完整数据库来说明问题

日志和截图应先去掉口令、个人资料等无关敏感信息；问题说明不需要暴露完整数据库。

修正后重走原步骤与正常流程

修正后按原步骤复测，并检查相关正常流程。

把待验证问题和复测结论交接清楚

将已完成、待补充和待确认分开标记；需要补充的项目写明缺少什么、由谁负责。

问题单保留时间、环境、步骤、预期、实际及复测结论。

继续了解

问题反馈怎么写，才容易修好？

服务支持，先分清紧急与普通问题

发布后别急着结束，走完一次流程