把一大段报错整理成最小复现

一千行日志往往不如三步稳定复现有用。先保存原始记录，再截取与第一次失败相关的部分，让编程助手分析一个明确问题，而不是猜测整个系统发生了什么。

准备这些输入

• 失败操作：从正常起点到失败的最短步骤。
• 必要环境：语言或运行环境版本、相关依赖和操作系统。
• 错误片段：第一处错误及相邻调用信息，去除密钥和个人资料。
• 预期结果：同样输入正常时应该发生什么。

1. 确定失败发生的边界

区分安装、启动、请求处理和结果展示。记录最近一次正常条件与当前条件的差异，但不要把时间接近当成因果。偶发问题注明频率与已知条件。

2. 逐步减去无关部分

在单独样本中只保留触发问题的输入与代码。每减少一部分都再次确认错误仍出现；不能为了“最小”删除关键条件。保留原始问题和缩小后的例子之间的对应关系。

3. 写成可执行的问题说明

按环境、步骤、实际结果、预期结果、已尝试方法的顺序组织。让助手先提出可检验的假设，每次只改变一个相关条件，记录变化，避免同时改多个地方后不知道原因。

可调整的操作模板

请根据以下最小复现提出诊断假设，先不要大规模改代码。
环境：[填写]
复现步骤：[1、2、3]
实际结果与错误：[填写]
预期结果：[填写]
已尝试：[动作和结果]
每个假设给出最小验证动作与判断依据。

这段模板只用于组织你提供的材料。使用前确认资料可以交给所选工具，工具不支持附件时可以粘贴必要的脱敏文字。

交付物与人工检查

完成后保留：最小复现样本＋错误摘要＋验证记录。交付前逐项确认：

• 其他人能否按步骤得到相同现象。
• 错误信息是否脱敏且保留关键调用关系。
• 环境版本是否来自实际环境。
• 每次验证是否只改变必要条件。

遇到卡点怎么办

无法稳定复现时，保留失败时的输入范围与环境差异，先补观测信息。不要把一次未再出现写成问题已修复。

继续从问题复现专题查看本类任务，或在工具目录了解具体工具的用途与使用条件。