晚上 11 点,你的错误追踪系统一直跳警报,你盯着一个 8 个月没碰过的服务的 stack trace。写程序教程里那种「跟模型聊天、迭代提示词」的文化假设你有时间慢慢来。你没有。你有一个客户在等、一个 Sentry 警报一直 ping。
这篇谈真实生产环境的调试,不是绿地写新东西。pattern 不一样。速度比优雅重要。目标是「理解 → 修 → 验证 → ship」,不是「写最漂亮的代码」。
最有用的单一工作流:把 trace 喂给它
最大的杠杆动作也最没人在用:把实际的 stack trace、实际的错误信息、实际相关的代码一次贴给 LLM。不要说「我有 TypeError 你能帮忙吗」 — 整段 trace 全文,加上 trace 指到的文件。
Claude 4.5 / 4.6 Sonnet 和 GPT-5 在常见的 production case(off-by-one、null 处理、类型混淆、race condition 信号、async 计时、regex bug)能可靠地从中找到 bug,命中率 60-80%。即使没直接修好,也会大幅缩小搜索空间。
关键洞察:LLM 读 stack trace 比读你的项目厉害很多。所以你给的失败具体 context(log、trace、错误文字)越多越好。给太少,它会编出听起来合理的胡说。
四种生产环境 bug,LLM 各自处理得如何
纯逻辑 bug(off-by-one、null deref、类型混淆)。LLM 找得很快。贴上函数加失败输入加错误,大多数情况几分钟内解决。
分布式 / 并发 bug(race condition、deadlock、最终一致性问题)。LLM 在这方面普通。它能建议 pattern 去找,但很少能从你的特定代码里诊断出真正原因,没有 runtime instrumentation 不行。用它来产出假设,再每个测。不要相信第一个「看起来是这个问题」的答案。
性能 bug(慢 query、N+1、memory leak)。给它 profiler 输出、慢 query log、或 memory snapshot,LLM 处理得很好。只说「这个很慢」就处理得很烂。永远要贴数字。
环境 bug(本地 work、production 烂掉)。LLM 在这方面弱,因为差异通常在它看不到的地方 — 你特定的 Docker image、你的环境变量、你的 DNS、你的 IAM policy。用它来列出可能原因(「本地跟 production 对 S3 SignatureDoesNotMatch 错误可能差在哪些地方?」),然后一个个检查。
LLM 错的时候,错得很有自信
这是 production 用法最重要的教训。LLM 调试有时会很有自信地指出一个 bug,但那不是真正的 bug。它会写出看起来合理的修法。你 deploy 下去。错误继续发生,因为真正的 bug 在别的地方。
对策:在 deploy 修法之前,一定要在本地或 staging 重现 bug。修法只有在「坏掉的案例变成 work 的案例」这个重现流程里才算验证。「看起来对」不是验证。
本地重现不出来(间歇性 / 数据相关 / 负载相关的 bug)就先加观测性,再修。把失败函数的输入 log 起来。加一个你可以在 log 里 grep 的结构化事件。等它再次失败、拿到数据、有数据在手再修。跳过这步你会修错三次才修对。
真正在事故中有效的提示词 pattern
**「先怀疑最简单的。」**加这句到你的提示词里。LLM 默认会建议精致的 root cause。叫它先怀疑最简单的(打字错误、刚 deploy、配置),会更快接近真相。
**「给我三个可能,不要只给一个。」**原因不明的时候,要求三个有严重度排序的鉴别假设,比要求「答案」有用。你想要的是清单去检查,不是有自信但错的宣称。
**「先不要写修法 — 只解释发生什么事。」**资深调试 pattern:把诊断跟修法分开。叫 LLM 走过调用路径、先解释失败。常常你会比它先发现真正问题。
**「你会加什么 log 来确认这个假设?」**比修法更好的是「修之前先验证的方法」。让模型建议能证明或推翻它理论的最小 logging 或 instrumentation。
真的有帮助的工具 vs 只是宣称有帮助的工具
Cursor 和载入你 repo 的 Claude Code 对「找调用点」/「这个函数还用在哪」这类问题很强。当 codebase 大的时候比 grep 省真实时间。
Sentry 的 AI 建议和类似的错误追踪 AI 功能是中等。它们倾向建议防御性代码,不修 root cause。当作「提示去查」而不是「套用这个修法」。
GitHub Copilot Chat 在 IDE 里对「修这个小东西」够用,但 production 级调试需要的 context 不够,除非你贴 trace 进去。
纯终端 LLM CLI 工具(Aider、Claude Code、Codex CLI)出乎意料的强,因为你可以直接 pipe log、trace、命令输出。事故时 kubectl logs ... | claude 是个 power move。
什么时候不适合用 LLM 调生产 bug
**真有时间压力、而你本来就不会这种调试,就不要用。**客户在尖叫、你从没调过这类 bug 的话,LLM 可能带你走错路而你评估不出来。让资深 on-call 处理。
安全事故不要用,除非是你公司核可的 sandboxed 模型。在事故中把 auth token、客户数据、敏感 log 贴到第三方 API 是另外一个合规事件,坏处比好处大。
**事后检讨不要用 LLM 写。**post-incident write-up 必须是你诚实的推理,不是模型的合理重建。用它整理 log 或时间线可以,不要用它起草「为什么会发生」。
下一步
- 怎么挑 coding agent — Cursor vs Claude Code vs 其他,特别考虑调试
- LLM observability — 把观测性建进你的 LLM 系统,以后调试更容易
- 幻觉 — 模型有自信地说错原因的时候在发生什么