Cursor 的 Debug模式的核心理念和使用流程

传统的AI代码修复往往基于代码静态分析就直接给出修复方案，但常常因为缺乏运行时信息而失败。Debug模式强制要求先获取运行时证据，再进行修复，避免盲目猜测。

使用流程

Debug模式遵循一个系统化的工作流程：

生成假设阶段
- 针对bug生成3-5个精确的假设
- 每个假设都要详细说明可能的根因
插桩收集证据
- 在代码的关键位置插入日志（instrumentation）
- 日志会自动发送到：http://127.0.0.1:7243/ingest/0fc3ea5d-6e07-48ff-823d-2a041d2001cc
- 并写入到：/Users/oker/meili/qiang.wang1_dacs_at_okg.com/108/Documents/WorkSpace/devops/.cursor/debug.log
- 典型的日志插入点包括
  - 函数入口和出口
  - 关键操作前后的值
  - 分支执行路径
  - 可疑的边界情况
  - 状态变化
重现问题
- 要求用户按照给定步骤重现bug
- UI会提供"Proceed"按钮，无需手动回复
分析日志
- 读取日志文件中的NDJSON格式数据
- 逐一评估每个假设：CONFIRMED（确认）/ REJECTED（拒绝）/ INCONCLUSIVE（不确定）
- 基于日志证据找到根因
实施修复
- 仅在有100%把握时修复
- 保留日志插桩（不移除）
验证修复
- 要求用户再次运行
- 对比修复前后的日志
- 必须有日志证据证明修复成功
清理
- 只有在验证成功且用户确认后，才移除日志插桩
- 提供问题总结和修复说明

适用场景

Debug模式特别适合以下场景：

✅ 运行时行为问题
- 程序执行流程不符合预期
- 状态变化追踪
- 异步操作时序问题
✅ 难以复现的Bug
- 间歇性出现的问题
- 特定条件下才触发的bug
- 多组件交互导致的问题
✅ 复杂逻辑问题
- 多层条件判断
- 复杂的数据处理流程
- 状态机问题
✅ 性能问题
- 追踪函数调用次数
- 监控数据变化频率
- 定位性能瓶颈
✅ 数据流追踪
- Props传递问题
- 状态更新不生效
- 数据转换错误

能解决什么问题

🎯 避免盲目修复
- 传统方式：看到报错 → 猜测原因 → 直接改代码 → 可能引入新bug
- Debug模式：插桩 → 收集证据 → 分析根因 → 精准修复
🎯 提供可追溯的证据链
- 每个修复决策都有日志证据支撑
- 可以回溯到具体的执行路径
- 避免"看起来应该能修好"的主观判断
🎯 确保修复有效性
- 修复后的验证基于实际运行数据
- 对比前后日志确认问题已解决
- 避免假阳性（看似修好实则未修好）
🎯 系统化定位问题
- 通过多个假设并行测试
- 即使第一轮假设全部被拒绝，也能根据日志生成新假设
- 迭代式逼近真正的根因

典型的日志示例

JavaScript/TypeScript中的插桩示例：

js 复制代码

// #region agent log
fetch('http://127.0.0.1:7243/ingest/0fc3ea5d-6e07-48ff-823d-2a041d2001cc',{method:'POST',headers:{'Content-Type':'application/json'},body:JSON.stringify({location:'PageLayout.tsx:176',message:'headerConfig value',data:{headerConfig},timestamp:Date.now(),sessionId:'debug-session',hypothesisId:'H1'})}).catch(()=>{});
// #endregion

日志会以NDJSON格式记录：

json 复制代码

{"id":"log_123","timestamp":1733456789000,"location":"PageLayout.tsx:176","message":"headerConfig value","data":{"headerConfig":{...}},"sessionId":"debug-session","hypothesisId":"H1"}

与传统调试的区别

传统调试
- 手动打断点
- 需要开发环境
- 单次运行
- 依赖经验猜测
- 修复后难以验证
Debug模式
- 自动插桩收集日志
- 可在生产环境收集数据
- 可多次对比分析
- 基于证据系统分析
- 强制验证修复有效性

总结

Debug模式的核心价值在于：用运行时证据代替静态猜测，用系统化流程代替经验主义，确保每一次修复都有可靠的数据支撑。这种方法虽然可能需要更多轮次的迭代，但能显著提高修复的准确性和可靠性。