一句“页面有问题”很难进入修复流程。缺陷记录要让没有看过现场的人也能重现同一现象。
本文使用Java Web 小项目的演示工程与协作场景。初入团队时，重要的不只是写出功能，还包括让别人能够复现、审查和接手。本文使用匿名任务说明工作方法，不指代某家公司的内部流程或真实交付成绩。
1. 从现象推到机制
把输入、环境、操作顺序、实际结果和期望结果分开。截图能说明界面，却未必包含请求参数与服务端错误；错误日志也不自动说明用户刚刚做了什么。复现步骤越短，越容易排除无关变量。
图中的四个节点分别表示用户步骤、请求证据、服务日志、复现结果。顺着实线检查输入如何变成输出，再沿虚线核对反馈条件。图示表达的是本文讨论的关系，不是实测曲线或现场截图。
2. 最小实现与输入条件
用一个订单查询问题练习：固定账号权限类别和匿名数据，记录过滤条件，再补充同条件下的网络响应。避免把账号密码直接贴进任务。
1
2
3
4
5
version: demo-r17
input: status=PAID, page=2
steps: open -> filter -> next page
expected: only PAID orders
actual: unpaid records appear
示例命令需要在独立演示工程中执行，路径和服务均由读者准备。操作前保留当前版本与输入，修改后对照原来的问题验证，而不是只证明新代码能够编译。
3. 用对照区分原因
下表列出需要主动改变的条件。预期行为来自机制分析，复现时还需记录运行环境和原始输出，不能将预期当作已经测得的结果。
| 改变的条件 | 需要验证的行为 |
|---|---|
| 清空过滤条件后恢复正常 | 问题可能与筛选状态有关 |
| 相同请求在另一入口失败 | 继续比较入口和会话条件 |
| 只有一句错误描述 | 接手者无法稳定重现 |
对照 1：清空过滤条件后恢复正常
问题可能与筛选状态有关。观察时记录有无过滤时的实际请求参数。把这个条件与基准情形分开，有助于判断变化来自哪一层；若得到相反结果，应先核对前提，再修改实现。
对照 2：相同请求在另一入口失败
继续比较入口和会话条件。观察时记录响应状态码与服务端关联日志。把这个条件与基准情形分开，有助于判断变化来自哪一层；若得到相反结果，应先核对前提，再修改实现。
对照 3：只有一句错误描述
接手者无法稳定重现。观察时记录环境版本与最短操作序列。把这个条件与基准情形分开，有助于判断变化来自哪一层；若得到相反结果，应先核对前提，再修改实现。
4. 适用条件与取舍
复现不了时先收集差异，不应反复随机改代码。缺陷单中的期望行为也需要产品约定支持，不能把个人使用习惯直接当成系统规则。
一次正常运行只覆盖了这组输入。继续扩展前，应把上面的异常对照保留下来，尤其关注“只有一句错误描述”这一分支。后续方案若改变了图中任意一处依赖，原来的判断就要重新验证，不能仅凭界面相似或返回值相同沿用结论。
