问题反馈这样写，技术人员才能少来回问

先做一个小而完整的尝试

• 记录准确时间。

• 说明使用哪个页面。

• 列出触发步骤。

• 写出预期与实际差别。

• 提供不含敏感信息的截图。

• 说明影响哪些工作。

容易忽略的地方

不要在公开群发密码、验证码或完整用户资料。暂时恢复也要记录用了什么办法，便于确认问题是否真正解决。

做完以后，看什么

问题单至少有负责人和下一次反馈节点。进度描述要区分已确认事实、正在排查和仍需补充的信息。

验收时别漏掉边界

写一个可复现的问题样例：在文章列表点击搜索，预期只出现标题含某个词的记录，实际列表没有变化。补上发生时间、浏览器、页面入口和是否每次都出现。截图保留按钮与异常位置，隐藏账号和私人资料；不要只发一张没有上下文的局部图片。

把下一步写到纸上

技术人员给出处理结果后，由反馈人按原步骤重试，记录问题消失、仍存在或换成了另一种现象。临时绕行和根因修复分别说明；如果无法再复现，保留已有时间与步骤信息，不把“这次没出现”直接等同于所有场景已经修好。

继续了解

报故障时，一张截图之外还要补什么

软件上线不是交付终点：这六项要有人接手

定制软件报价之前，把需求写成一次真实操作