将 LLMs 连接到我的调试流程以修复内存崩溃

Source: Dev.to

Introduction

每个工程师都有一段“神秘案例”的故事。我的服务曾经连续数周运行良好，随后在最意想不到的时刻，内存被暴力消耗并崩溃。我尝试了日志、代码优化，甚至一次“假胜利”修复——它让崩溃停了一周后又回来了。手动调查几乎不可能，因为海量数据掩盖了关键事实。

Exporting Metrics & Pattern Matching

我导出了原始指标数据，并把 AI 当作模式匹配器来使用。

Prompt

Analyze this dataset. Find the exact timestamps where memory allocation spikes > 20% in under 60 seconds.

Result
AI 确定了两个出现峰值的具体秒数。

Correlating Spikes with Logs

利用这些时间戳，我让 AI 为我们的日志聚合器（它有自己的代理）生成针对性的查询。日志瞬间亮起：每一次内存峰值都与特定的 System Refresh Event 完全对应。在拥有数百万行代码的代码库中，这个“显而易见”的关联之所以能被看到，正是因为我们准确知道去哪里找。

Deep Dive with a Conversational Profiler

崩溃发生在我们核心基础设施的深层——经过实战检验的逻辑，需要外科手术般的精确修改。与其手动筛选堆快照，我使用 Model Context Protocol (MCP) 把分析器变成对话伙伴。

AI: I detect a high volume of duplicate objects on the heap.
Me: That’s impossible, those should be cached and reused.
AI: The cache references are unique. They are not being reused.

引导 AI 并过滤幻觉，使它显现出我多次检查却从未真正看到的竞争条件。

Root Cause: The “Stampede”

问题本质是经典的stampede：在新数据准备好之前就清除了旧数据。修复思路是采用“接力赛”模式——确保缓存数据的不同版本之间安全交接。

Implementing the Fix with AI Assistance

Prompt

Refactor this cache logic to support a “Versioned Handoff”. Ensure thread safety during the swap between Version 1 and Version 2.

Result
AI 生成了原子交换机制的样板代码。我并没有盲目复制粘贴，而是搭建了一个“AI Tribunal”（GitHub Copilot 负责逻辑，Claude 负责代码，Gemini 负责架构），并在任何阶段部署前进行严格的人为代码审查，以验证锁机制的正确性。

Lessons Learned

• Multiply, don’t replace: 使用 AI 完成粗活——解析数据、生成样板——而你专注于语义层面。
• Orchestrate, don’t just chat: 将你的工具串联起来。让指标与日志对话，让分析器与代码对话。
• Respect the “boring” solution: 修复并非华丽的新框架，而是一个简单、可靠的接力赛模式。

Conclusion

案件终于结案。火已熄灭，生产环境再次安静——正是一个精心构建的系统应有的感觉。