最小复现问题一周内推到哪算合格，先答三个问题

先给一条能当场核对的最小周内判断标准：周五下班前，如果另一个人拿到你写下的复现复现步骤，能在自己的问题问题机器上稳定看到同一个错误现象，并且你能指出问题发生在哪一层、算合下一步该找谁，格先这一周就算合格。最小周内不是复现修好才算，也不是问题问题提交了多少行代码才算。边界说清楚：涉及资金、算合生产环境、格先合规数据的最小周内故障，合格线以上还得走正式流程，复现不能靠个人判断收尾。问题问题

这条标准的算合好处是当天可查。打开文档，格先找一位没参与排查的同事，让他照着步骤走一遍，中途不许你插话提示。他卡住的地方，就是你这一周还没推到位的部分。很多人把“我本地跑通了”当成果，可换个人连环境都搭不起来，等于问题还锁在你脑子里。

动手前先答：这事一定要买吗

排查到一半，最容易冲动消费：买一个调试代理授权、买一台备用机器、买一份商业日志服务。先停三秒问自己：不买会怎样？如果答案是“多花两小时手工比对”，那就别买，把两小时写进计划表，比走采购流程快得多。

反过来，什么时候买算合理？只有当这个付费项直接决定“能不能稳定复现”，并且免费替代方案你已经试过一次并记录了失败原因。比如抓包工具对某个加密协议的解析，开源版本只能看到密文长度，你需要看到字段边界才能确认是发送端还是接收端的问题，这时试用版或短期授权就是推进器，不是逃避。

还有一个容易被忽略的判断点：买的是“信息”还是“心理安慰”。把购物车放半天再看，多数临时采购的冲动会自己消退。省下的钱不是重点，重点是不让采购流程拖散你的排查节奏。

改配置文件之前，先确认改的是哪一层

最小复现最怕一边改代码一边猜。合格的推进方式是：动手改之前，先写下你怀疑的层——是输入数据不对、中间件配置不对、依赖版本不对，还是运行时资源不够。写不出这一行，就说明还没到改的时候。

举个反例。有人遇到接口偶发超时，第一反应是调大连接池、加长超时时间，现象确实少了，但换个时段又出现。原因是他改的是“症状出现的门槛”，不是“资源为什么被占住”。后来他把复现步骤缩到只发一个请求，发现某条慢查询在特定参数下会扫全表，才算把问题按到具体一层。这个例子里，前两天的改动不是白费，但只能在记录里标注“已排除”，不能算推进到合格。

该不该改，还有一个信号：如果改动需要动生产环境或共享配置，而你手上还没有人能复核，先改本地副本。把 diff 留下来，写清改了哪一行、预期现象是什么、实际现象是什么。这三行字比一堆截图有用，交接时对方一眼能看懂你走到哪。

装新工具前，先看它替换掉哪一步手工操作

一周时间很短，装东西的隐性成本常被低估：下载、配环境、读文档、处理权限，半天就没了。判断标准很朴素——这个工具能不能替掉你当前手工重复三次以上的动作。能，就装；不能，先记在待办里。

比如你每天要手动把日志里的时间戳对齐、筛出同一个请求编号的行，那就值得装一个轻量的日志过滤工具，因为重复动作明确。反过来，只为了看一眼某个变量的值去装整套监控栈，就不划算，多数情况下打印一行输出更快。

装完立刻做一次“回退演练”：记下卸载步骤或还原点位置。这一条不是多余，排查中途环境被改乱、复现不出来的情况并不少见。你需要能随时回到干净状态，才能证明现象是问题本身，而不是你装的东西带来的。

周五收尾的核对表

把下面几条逐项打勾，比凭感觉判断靠谱：

一，复现步骤从干净环境开始，不依赖你电脑上的私人配置；二，错误现象有一句客观描述，包含触发条件和出现频率，不写“有时候会挂”；三，已排除的方向各有记录，写清试过什么、为什么排除；四，问题落在哪一层有明确说法，并指名下一站找谁——是找数据提供方、找运维、还是找上游依赖的维护者；五，如果你已经改过东西，diff 和回退方式都在文档里。

五项里缺两项以上，说明这周还在“摸”，不算合格，但也不丢人，关键是别把没推到位的部分说成已解决。相反，五项都齐了，哪怕问题还没修好，接手的人也能顺着你的记录继续走。这就是一周内把最小复现问题推进到合格线的样子：不追求修完，追求可交接、可复核、可继续。

最后补一句边界：如果你的排查碰到权限之外的数据、涉及用户隐私或线上计费，别自己绕过去验证，走正式渠道申请。合格的标准里包含“知道哪里该停”，这一点比多推进一步更重要。