把报错和堆栈，理成一份排查顺序
实测于 2026-11-14 · 数字来自一次真实运行
这一页的运行记录来自一次真实运行，不是估计值。token用量没采集到就写「未采集」，不填数字。
适用场景
程序炸了，有一堆报错和堆栈，但不知道从哪条开始查。
准备
- 宿主版本
- 0.1.2-alpha.5
- 模型
- 待填
- 模式 / 权限
- --profile headless / workspace-write / Windows 11
- 需装插件
- 无（如用到插件，在实测后补齐名称与版本）
- 输入材料
- 自造19行日志，含3类错误：上游超时→502（两次）、连接池耗尽、worker空值解引用
完整指令
根据下面的【报错原文 + 堆栈 + 相关代码片段】，做故障分诊，不要直接改代码。
输出：
1. 最可能的根因（前 3 个假设），每个写 为什么这么怀疑、怎么验证。
2. 排查顺序：先查什么、再查什么，每步用什么命令 / 看什么日志。
3. 如果是依赖或版本问题，给出具体核对命令。
4. 标出你无法判断、需要我补充的信息（如复现步骤、环境版本）。
要求：不确定就明说，不要给一个听起来很对但没依据的定论。运行记录
| 项目 | 数值 | 备注 |
|---|---|---|
| 耗时 | 1分25秒 | 2026-11-14 |
| 结果 | 识别出3类错误；按「反复发生 / 偶发」分开判定并给了判断依据；19行原文逐字比对全部匹配 | |
| 输入 / 输出token | 未采集 | |
| 残留 | 无残留。 |
实测发现
- 它没有按时间罗列——这是配方里明确要求的「按错误类型分组」，效果是产物从「日志搬运」变成了「可检索的索引」。
- 最有价值的一段是它指出日志本身不自洽：attempt=1到attempt=2只隔15秒，装不下声明的30000ms超时；14:02那次缺了attempt=2/3与retry行。它把这条写进「日志缺陷」一节而不是替日志圆场。
- 「反复发生vs偶发」的判定给了可核对的依据：E1出现6次、跨4小时48分且中间夹着一条成功请求；E2集中在39秒窗口内（waiter 37→52是同一场）；E3全部属于同一个job 4471。
- 它主动说明了样本局限：19行太小，「偶发」只在本日志范围成立；也明确写了三类错误之间「日志内无跨类因果证据」，没有硬凑一个根因。
这条配方真正的产出不是「错误清单」，而是最后一节那句建议：日志缺host/实例、请求体积、DNS/TLS耗时，导致「两次E1是否同一节点」这个最该先答的问题答不了。补字段比继续分析更值。
产物
跑通后在这里给出文件清单与截图，并说明原始文件有没有被改动。
验收清单
点一下可勾选，用来逐条核对。
- 给出了前3个假设及各自验证方式
- 排查步骤有具体命令 / 日志
- 标出了需要补充的信息
- 未给出无依据的结论
失败与边界
- 分诊不等于修复，修复要人确认
- 缺少环境信息时结论会不准