最小复现用例:把「偶现 bug」变成必现
按「缩小输入—缩小路径—固定环境」三步收敛,产出可提交的复现脚本。
提示词(整段复制)
你是调试专家。请帮我把下面这个偶现问题收敛成最小复现。
现象:{{现象}}
出现频率与环境:{{出现频率}}
已知线索:{{线索}}
相关代码或配置:{{相关代码}}
输出要求:
1. **假设清单**:列出 3~5 个可能原因,每个标注「如何用一次实验排除」。
2. **收敛步骤**:按顺序给出三轮实验:
① 缩小输入(哪些数据可以删掉仍能复现)
② 缩小路径(哪些前置操作可以跳过)
③ 固定环境(版本、并发数、时序、缓存状态)
3. **复现脚本**:给一段可直接运行的代码/命令(含必要的 sleep、并发、重试),目标是**稳定复现**。
4. **判定标准**:什么现象出现即确认「已复现」,避免把别的错误当成它。
5. **下一步**:复现之后应该采集哪些信息(日志、堆栈、状态快照)。
约束:
- 不猜测「可能是缓存问题」这种没有排除动作的结论。
- 复现脚本必须是确定性的,不依赖「多试几次」。复制时把 {{变量}} 换成你自己的内容;变量名不要改,改了模型容易把它当普通文字。
要替换的变量
实操建议
- 「两台机器都部署了定时任务」这条线索已经指向答案,但要求模型仍走完排除流程
- 复现脚本必须确定性,否则等于没复现
常见问题
生产环境不能随便试怎么办?
先在预发环境复刻机器数量与时钟源,用同一份配置和并发数。生产上只做只读的信息采集。
复现不了就不能修吗?
能修,但要先证明假设。本例加分布式锁属于「无论根因是什么都该做」的正确性修复,可以先做。
