准备客户端校招的项目讲解，写到“定位了一个偶发问题”时，怎样说明定位过程？先把结论放在一边：别人拿到你的记录，能否知道问题在哪里出现、哪些步骤已经确认、哪些范围还没有证据？
下面以“本地Demo的按钮偶尔点了没反应”为假设案例，整理一份排查记录的写法。它是准备练习，不是已完成的项目测试。
先定义现象，暂时不替它命名原因
“点击失效”容易把观察和解释混在一起。更具体的描述可以包括：在哪个界面点击了哪个按钮，预期出现什么，画面实际如何变化，是否还能操作其他控件。
画面没有变化，可能发生在输入接收、业务条件判断、执行过程或界面反馈中的某个环节。这里列的是可能的检查方向，不能凭描述直接确定是哪一层出错。
为问题约定一个可观察的判断条件，也能避免后续比较的是不同现象。例如“目标面板未打开”与“面板已经打开但被遮挡”，需要分别保留。
给每次尝试一个能重建的起点
记录应包含真正影响当前问题的环境和前置条件，而不是堆一张与问题无关的设备清单。
| 部分 | 可以记录什么 | 容易遗漏什么 |
|---|---|---|
| 版本与运行方式 | 工程或构建版本、编辑器或发布包、启动入口 | 本地改动未进入构建，版本名称相同但内容不同 |
| 初始状态 | 初始场景、配置、存档与进入路径 | 在已有状态上继续点，无法重建第一次进入 |
| 操作顺序 | 每一步操作、等待条件、发生位置 | 只写最后一次点击，漏掉之前的切换 |
| 可见结果 | 预期、实际、录屏定位 | 用“正常/异常”代替具体表现 |
| 关联证据 | 同次操作的日志、状态记录及其标识 | 把上一次操作的输出接到本次录屏上 |
涉及存档、账号或访问凭据的材料，只保留排查确实需要的内容；向他人提供示例时移除不相关的个人信息和密钥。
按同一次操作对齐记录
录屏帮助看见用户操作和画面；日志或调试状态帮助检查系统内部发生了什么。二者需要有可对应的时间点或操作标识，不能只因为时间接近就认定属于同一条过程。
时间戳也不是自动可靠的因果关系。如果来自不同设备或时钟，需先确认能否对齐；异步写出的日志顺序也未必等于业务发生顺序。对于本地练习，可以先采用当前工具确实支持的关联方式，不必为了一张图假装具备全链路追踪。
“日志里没看到”也需要解释：日志点是否覆盖这个环节？是否启用？输出是否丢失或被过滤？没有这些前提，缺少记录只能作为待确认信息。
让下一次尝试回答一个小问题
当现象能在一组条件下复现，可以保留这组条件作为对照，再改变一个与假设有关的因素，例如进入路径或初始配置。
每次记录改了什么、保留什么、是否仍然出现同一个现象。修改后暂时没出现，先写“本次条件下未复现”；恢复原条件复查，才能继续判断这项变化是否值得追踪。偶发问题需要记录尝试条件与次数，但不能拿少量尝试直接断言根因已经找到。
同时改动多个因素有时是工程上必要的临时处理，但记录中要保留这件事，不把它包装成单因素证明。
最后区分排查进展与修复结果
排查记录可以得出“问题更可能集中在某条路径”这样的阶段判断。修复记录还需要说明实际改动、原问题复查及相关路径是否受影响。这两部分不要合并成一句“已解决”。
准备项目介绍时，从一个自己实际做过的问题出发，讲清证据如何影响下一步选择。还没有真实案例，可以先按本文模板进行练习，再如实记录结果；本文没有提供代码、运行成绩或性能改善数据。
相关岗位：米哈游2027届校招“游戏研发-游戏客户端开发”8938，上海全职，毕业时间2026.9—2027.8。免费内推码QG566： 米哈游官网：游戏客户端开发校招岗位
岗位要求及开放状态以官网为准，内推不保证面试或录用。本文含个人内推信息与AI辅助整理。愿意反馈来源可留言“排查掘金晚间03”。
