AI 编程怎么利用运行时信息：把堆栈、日志与性能数据喂给模型的定位闭环

AI 编程定位 bug 的准确率，取决于你喂进去的是「代码」还是「证据」。只贴一行报错，模型只能猜；把堆栈、关联日志和性能数据按时间轴拼成一条证据链，模型才能给出按可能性排序的根因清单。下面这套流程把「翻日志、猜原因」从人肉劳动，变成可复用的三步闭环。

三类运行时信号，各自解决不同的问题

很多人的做法是复制最后一行报错丢给模型，这等于只给了结论不给过程。运行时信号至少要分三类收集：

三类信号缺一类，模型的推理就会出现系统性偏差：只有堆栈，它会把偶发问题当成必现逻辑错误；只有日志，它找不到出错代码行；没有性能数据，它对「高并发才复现」这类条件完全无解。

第一步：把日志裁成证据链，而不是整段粘贴

生产日志一屏几十行，直接全贴有两个坏处：噪声淹没关键行，以及很快把上下文窗口撑满。正确做法是先做裁剪：

1. 按 trace 对齐：同一个 request_id 的请求日志、依赖调用、 DB 查询拼成一段。
2. 按时间截断：只保留异常发生前 30 秒到后 30 秒。
3. 脱敏：token 、手机号、身份证、内网 IP 一律替换成占位符，这既是合规要求，也能避免模型把注意力放在无关字段上。
4. 标注已知事实：在日志上方写一句「这个接口昨天上线过一次改动，改动内容是 xxx 」，把人类已知的上下文显式补上。

第二步：先要失败模式清单，再要排序根因

一次提问就想要「正确答案」是最常见的错误用法。 Anthropic 官方给出的调试路径是两段式：先让模型枚举可能触发该错误的失败模式，再让它对根因按可能性排序。

下面是 checkout 接口在 10:23–10:31 的错误日志与堆栈（已脱敏，trace_id 已对齐）。
已知事实：该接口昨天上线过一次改动，改动内容是 session 过期时间从 24h 改为 15m 。

请分两步回答：
1. 列出所有可能触发该错误的失败模式（含超时、限流、字段缺失、竞态等）；
2. 给出 probable root causes ranked by likelihood，每条注明对应的代码路径与验证方法。

这样问的价值在于：第一步把搜索空间摊开，避免模型一头扎进最显眼的那条线索；第二步的排序把「去查 API 故障」这种泛泛结论，变成「去查 auth 服务的限流配置」这种可执行动作。

第三步：让模型自己写复现测试，而不是人肉搭环境

生产问题往往依赖真实负载、第三方行为和真实数据，本地复现成本极高。更省事的做法是把复现转化成测试：

• Write a test that reproduces this bug —— 让模型根据堆栈写出最小复现用例。
• Run the test suite and show me what changed —— 验证修复有没有波及周边行为。
• 确认修复后再让它提交 PR：Commit these changes and open a PR。

四条裁剪规则，防止上下文被撑爆

1. 大文件按行区间喂：让它读 src/order/service.ts:120-260 而不是整个文件。
2. 大输出移进子智能体：把日志分析这种高 token 任务丢给子智能体，只回传结论。
3. 定期压缩：终端里跑 /compact，重点保留 plan 和 diff 。
4. 分阶段开新会话：定位阶段和修复阶段分开，定位结论写成一段摘要带过去。

什么情况下别用这套流程

• 涉及资金、权限、删除操作的修复：模型可以定位，但不要让它直接改，人工复核不可省。
• 日志本身可能不可信：如果日志采集链路有问题，喂进去的证据链就是错的，先修采集。
• 错误信息来自第三方 SDK 且无源码：此时模型只能猜，优先去查官方 issue 与版本变更。

顺带一提，如果你想系统性地防止模型在定位过程中「编造」代码路径，可以配合一份验证清单来收口，参考 AI 编程幻觉怎么防：四类高频幻觉与验证清单；代码检索环节则建议先看 AI 编程的代码检索怎么做。拿到修复补丁后，别急着合并，按 AI 代码评审清单 过一遍更稳妥。