用户发来一张截图，说页面不对。开发打开同一页面，刷新几次，一切正常。于是对话陷入僵局：用户觉得问题明明摆在眼前，开发觉得无从下手。多数时候，问题不在截图本身，而在截图之外的环境、步骤和输入数据没有被记录下来。截图只保留了某一瞬间的视觉结果，却丢掉了产生这个结果的全部条件。
先要弄清楚截图能证明什么。它能证明某个界面在某一刻呈现了某种状态，但不能证明这个状态由什么操作触发，也不能证明当时使用的是哪份数据。因此拿到截图后，第一步不是急着复现，而是判断现象属于哪一类。界面异常表现为布局错位、文字截断、按钮消失，通常与浏览器、分辨率、样式加载有关。数据异常表现为数字不对、列表缺项、状态标签错误，通常与账号权限、数据来源、缓存有关。操作时序异常表现为刷新后恢复、重复点击才出现、切换页面才触发，通常与请求顺序和状态保存有关。三类现象的排查方向完全不同，混在一起问，只会得到模糊的回答。
接下来按清单补齐信息。第一项是操作路径，从登录后的哪个入口进入，经过哪几个页面，点击了哪些按钮，要能一步步走通。第二项是账号角色，同一个页面不同角色看到的菜单和数据范围可能不同，需要说明截图所用账号的权限类型。第三项是浏览器与版本，以及是否安装了插件、是否开启了翻译或广告拦截。第四项是输入数据样本，涉及哪条记录、哪个文件、哪次提交，最好能指明可定位的标识。第五项是发生时间点，精确到分钟，便于对照日志。第六项是前后操作顺序，出问题之前做了什么，出问题之后又做了什么。这六项齐全，复现概率会明显提高。
口头描述往往含糊，需要转成编号步骤。可以这样记录：第一步，用某角色账号登录；第二步，进入某个列表页；第三步，筛选某个条件；第四步，点击某条记录的详情。每一步后面标注预期结果与实际结果。预期结果是“应显示完整金额”，实际结果是“金额显示为零”。编号的好处是顺序明确，任何一步对不上，就能立刻发现差异出在哪里。描述时避免使用“有时候”“偶尔”“感觉不对”这类词，换成可观察的具体现象。
如果仍然复现不了，就用对照法缩小范围。换一台设备，看是否与硬件或系统有关。换一个账号，看是否与权限或数据绑定有关。换一份数据，看是否与特定记录有关。换一种网络环境，看是否与缓存或代理有关。每次只改变一个条件，记录变化前后的结果，形成对照表。对照记录比反复描述更有价值，它能直接指向差异所在。
最后，可以把这套信息整理成反馈模板，让用户提交问题时自带关键信息。模板不必复杂，包含现象描述、操作步骤、账号角色、浏览器版本、数据标识、发生时间和截图即可。日常维护协作中，it数运更倾向于把这类信息整理成固定字段，减少来回追问，让每一次反馈都能落到可核查的步骤上。信息补齐了，复现就不再靠运气。
