编程开发 编辑复核
Stack Trace 错误定位计划
把异常堆栈、触发条件和最近改动整理成最小复现与定位路径，不凭错误关键词直接下结论。
PROMPT WORKBENCH
复制后替换变量
保留结构，先填真实信息，再把结果交给模型运行。
你是一名故障定位工程师。请只基于日志和代码上下文提出可验证的定位步骤，不要因为堆栈顶部看起来熟悉就断言根因。
先区分已知事实、合理假设和待核验信息；没有依据的内容写“待验证”，不要为了完整而猜测。
请按以下结构输出：
1. 提取异常类型、首个业务相关帧和触发条件
2. 按可能性、影响和验证成本排列根因假设
3. 设计最小复现、日志补充和读写边界检查
4. 给出修复前后测试、监控和回滚动作
输入变量：
- 错误堆栈（{{stack}}）：提供脱敏堆栈、时间和请求标识。
- 运行上下文（{{context}}）：说明版本、环境、输入和最近改动。
- 期望行为（{{expected}}）：描述用户应该看到的结果。
- 排查限制（{{constraints}}）：说明不能做的操作和可用权限。
约束：保留用户的真实语气和业务边界；把事实、推断与建议分开；涉及日期、价格、版本、法规或安全的内容写明来源和采集时间。HOW TO USE
使用说明
- 先保护隐私和生产数据，再补充最小日志。
- 每个假设都保留验证结果，避免修复后无法解释为什么有效。
WHEN IT FITS
适用判断
适合这些情况
- 拿到了完整的错误堆栈，但不确定该从哪一层查起。
- 堆栈涉及框架和第三方库，自己的代码淹没在里面。
- 错误偶发，需要先排出排查顺序再动手。
换个做法更好
- 你要分析的是日志而非堆栈：用《日志事件分析与排查顺序》。
- 堆栈直接指向你自己代码的一行且原因明显：直接改。
- 你只有错误信息没有堆栈：先想办法拿到完整堆栈。
FAILURE MODES
常见翻车与修正
- 模型直接断言根因是某某问题。
堆栈只说明了失败位置，不等于根因。要求列出候选原因并按可能性排序，每条给出验证方法。
- 排查建议是「加日志看看」，没说加在哪、看什么。
要求每步排查都写明具体位置、要打印什么变量、什么样的输出说明这条假设成立。
- 把第三方库内部的堆栈帧当成你的代码来分析。
要求先区分堆栈中哪些帧属于你的代码、哪些属于依赖，并说明为什么从某一帧开始查。
ACCEPTANCE
怎么判断输出合格
- 候选原因不止一个，并按可能性排了序。
- 每步排查都有具体位置和判断标准。
- 区分了自有代码和依赖代码的堆栈帧。
- 没有在证据不足时下根因结论。
SAFETY BOUNDARY
使用边界
- 堆栈里常带有文件路径、内网主机名和请求参数，粘贴前删掉敏感部分。
- 模型给的定位方向是猜测，按它的建议改代码前先用日志或断点验证，避免改错地方引入新问题。