Debug Mode：用运行时日志淘汰错误假设

先说结论

难调 bug 的突破口通常不是更大胆地猜，而是让多个竞争假设接受同一次真实运行的检验。Debug Mode 的价值在于把 Agent 从“看静态代码给修法”切换到“插桩、等人走原路径、读日志、做定向修改、再走一遍”的闭环。

原文解决什么

竞态、时序问题、性能退化和“以前正常、现在失败”的回归，经常无法仅凭代码确定根因。Cursor 介绍的 Debug Mode 先提出多个可能原因，再添加日志收集运行时数据，由开发者复现后让 Agent 用观测结果收窄范围。

核心机制

1. 把用户症状改写成可复现条件与可观察结果，同时列出互相竞争的假设。
2. 为每个假设选择能区分真假的最小日志点，记录状态、顺序和必要标识，不先改业务语义。
3. 由人按原入口、原步骤触发问题；Agent 不能用自造调用代替真实路径。
4. 用日志淘汰假设，定位最小根因层，再做定向修复。
5. 用完全相同的入口与观察点再次复现，确认症状消失且相邻行为未退化。
6. 删除临时插桩；只保留确有长期诊断价值、符合隐私与性能约束的日志。

和 Zero-to-AI 及日常开发如何接上

本站本身以静态内容为主，但构建失败、客户端交互或异步脚本仍可能出现“源码看起来没问题”的情况。可以先保存命令、退出码和最小日志，再让 Agent 基于运行结果修改。对于 iOS 或 Web 交互，人工原路径中的点击顺序、前后台切换、网络状态和可见结果应作为复现合同。

要单独保留证据层级：日志证明某次运行发生了什么，代码解释可能机制，修复后的再复现才支持“当前路径已恢复”。其中任一层都不能替代另外两层。

一个低成本实验

输入： 一个可稳定复现、但静态阅读无法区分两个原因的小 bug；准备无敏感数据的本地环境。

步骤：

1. 写下假设 A、B，以及分别会出现的关键事件顺序。
2. 只在能区分 A、B 的边界加结构化日志，给本次运行加同一关联 ID。
3. 人工走一次原路径，保存日志和可见结果；根据证据只修被支持的根因。
4. 再走同一路径一次，并检查相邻正常路径，随后清掉临时插桩。

成功证据： 修复前日志能排除至少一个假设；修复后同一路径不再出现原症状，预期事件顺序成立，临时日志已从最终 diff 移除。

停止线： bug 不能稳定复现、日志点无法区分假设，或插桩会采集凭证、个人信息与内部敏感数据；停止自动修复，先补复现条件或改用安全观测手段。

常见误区

• 只有一个假设就开始插桩：日志容易变成证明先入为主的装饰。
• 看到异常日志就宣布根因：相关性还需要控制流、状态变化或对照复现支持。
• 修完只跑测试不走原路径：测试可能没有覆盖真实时序和环境。
• 把调试日志永久留下：临时高频日志可能引入性能、隐私和噪声成本。

原文与证据边界

多假设、日志插桩和运行时分析的产品流程来自 Cursor 官方介绍；本站未独立复现 Debug Mode 的具体 UI、日志采集能力或修复成功率。上述实验验证的是通用调试闭环，不证明 Cursor 能自动定位任意运行时问题。

本文是原创中文实践解读，不是逐句译文。阅读英文原文。