meng shao@shao__meng · XCursor 推出 Debug Mode，解决传统 AI Agent 依赖静态推理易产生“假修复”的问题。其核心是通过添加临时日志、让用户复现 Bug，收集运行时证据进行诊断，再自动清除日志。Cursor 团队内部案例显示，该模式能高效定位概率性竞态条件、内存泄漏、C++ 原生崩溃及 SSR 渲染等难以静态分析的 Bug，将“猜测”转为“基于证据的诊断”。
Cursor Debug Mode 有什么用？
核心问题：AI Agent 修复 Bug 的局限性 @ericzakariasson 指出，传统的 AI Agent 在处理 Bug 时通常依赖静态推理： · 阅读代码 → 形成理论假设 → 直接修改代码 → 期望修复成功 · 这种方式经常产生"看起来自信但实际掩盖了真正 Bug"的假修复
这反映了当前 AI 编码工具的普遍痛点：缺少运行时真实证据，只能靠模型的先验知识和代码上下文"猜"。
Debug Mode 的解决方案与工作原理 Debug Mode 的核心理念是：让 Agent 通过运行时日志获取证据，而不是纯猜测。
具体循环流程： · Agent 对 Bug 提出多个假设，并优先处理最合理的那个。 不直接修改实现代码，而是先添加临时日志来验证假设。 · 通过一个轻量级的调试服务器，将程序运行时的输出收集到 .cursor/debug.log 文件中。 · 用户手动复现 Bug，Agent 随后读取日志，基于真实运行数据理解问题根源。 · Agent 定位根因后，进行真正修复，并自动移除之前添加的临时日志。
这个过程将"猜测"转变为"基于证据的诊断"，显著提升了修复的可靠性和透明度。
帖中附带了一个真实 Bug 的演示视频，直观展示了整个流程：Agent 添加日志 → 用户复现 → 读取日志 → 精准修复。
实际应用案例（Cursor 团队内部使用） · 概率性 Race Condition（1/20 概率出现，破坏 Git 元数据）：传统方式极难复现，Debug Mode 在不到一小时内定位。 · 内存泄漏：通过日志一次追踪到前端框架误用，修复仅需一行代码。 · C++ 原生崩溃（Electron 崩溃）：原本大家倾向于绕过，日志让问题变得可定位。 · SSR 闪烁/渲染 Bug：长期被放弃的顽疾，通过运行时页面行为观察得以修复。