cursor debug mode 怎么用 先假设再加日志
cursor debug mode 怎么用？讲清假设、打日志、看 runtime 再定点修的三步，与 Agent 分工及贴 stack 的用法。
程序红了，最糟的做法是让 Agent 一口气改十个文件碰运气。cursor debug mode 怎么用：先列假设、加日志或探针、看 runtime 证据，再定点修；Shift+Tab 切到 Debug，把报错和 stack 贴进去。
Debug Mode 在解决什么问题
Cursor Debug Mode 说明 针对的是「知道结果错了，不知道哪一步错」。它鼓励模型先提出可检验的假设，再通过日志、断点信息或最小复现步骤收集 runtime 事实，最后才改代码。与「直接给补丁」相比，这条路径更慢，但能避免把症状当根因。
典型输入：测试失败信息、浏览器 console、API 500 响应体、Node/Python stack trace。你贴得越完整，假设越可验证。只有一句「不工作」时，Debug 会先追问复现步骤，这是预期行为，不是模型在推脱。
Debug 适合 intermittent bug：官方强调看 runtime 再修，而不是先改十处「可能相关」的代码。你若已有最小复现仓库或单测，先告诉 Debug「跑 pnpm test path/to.spec.ts 必红」，比描述现象快一轮。
性能类问题也适用：贴 p95 延迟数字、慢查询 log、或 Chrome Performance 里某段 long task 的栈，Debug 会倾向加计时探针而不是盲目改算法。数据库 migration 失败时，把 migration 文件名、数据库方言和完整 SQL 错误码贴全，比只说「migrate 挂了」省一轮来回。
和 Agent 的分工差在哪
官方文档的对比很简短：Agent 管「你要建什么、改什么」；Debug 管「已经坏了，为什么坏」。Agent 会按目标直接改文件；Debug 默认不先大面积 refactor，而是缩小故障面。
| 你手里的情况 | 更合适的模式 |
|---|---|
| 新功能从零实现 | Agent |
| 现有功能突然失败 | Debug |
| 读懂模块再小改 | 先 Ask，再 Agent |
| PR 上机器审查 | 另见 Bugbot，不是 Debug 模式 |
Debug 改代码时往往是小范围、可回滚的改动（加日志、改条件、修空指针），而不是重写架构。若 bug 修完还要做大 feature，修完切回 Agent 继续。Side Chat 里的普通问答也不能替代 Debug：没有假设—验证—定点修这套约束，容易又回到「盲改」。
怎么开启并喂给模型
Cmd+I或Ctrl+I打开 Agent 面板。Shift+Tab或模式下拉切到 Debug。- 第一条消息贴完整报错：异常类型、消息、stack 前十几帧、相关环境（OS、Node 版本、分支名）。
- 若有稳定复现步骤，用编号列出（点哪、输入啥、期望 vs 实际）。
Stack 里带 node_modules 帧时，说明哪一层是你业务代码入口，能减少模型盯错文件。若是 flaky 测试，写清「第几次跑必现」或「只在 CI 现」，避免 Debug 在本地假绿上浪费时间。前端 bug 可附 Network 面板里失败请求的 response body；后端可附相关 log 行号，不必整文件粘贴。
三步工作流：假设、日志、定点修
官方描述的工作流可以拆成三节，也是本文的可复制框架：
第一步，假设。模型根据报错列出 2–4 个可能原因，并标哪个最容易用一条日志或断言验证。你此时应确认复现路径一致，别在已改过的脏工作区上测。
第二步，打日志或探针。Debug 会提议在关键分支加 console.log、临时断言或最小测试，跑一遍把输出贴回对话。目的是用 runtime 否定错误假设，不是永久留一堆 log。测完应删掉或改成正式观测。
第三步，定点修。证据对齐后再改业务代码，并跑同一复现路径验证。若仍失败，带着新 stack 继续 Debug，别切 Agent 做大范围「顺便优化」。
若 Debug 第一轮就给出大 diff 而没要任何 runtime 输出，你可以明确要求「先加日志验证假设 X」，把流程拉回官方设计。每轮只验证一个假设，比同时改三处更易 review。
TypeScript 项目里，把 tsc --noEmit 或 ESLint 报错贴进 Debug，模型会区分「类型层面」与「runtime 层面」假设。Go 的 panic stack、Rust 的 backtrace 同样适用：帧里第一个非标准库路径通常就是该加探针的文件。移动端 React Native 可附 Metro 或 Xcode 控制台节选，Web 端附 hydration mismatch 的组件栈。
容易踩的三类误用
第一类：该 Debug 却用 Agent 盲改。现象是测试红一片，Agent 连改五个文件，本地更乱。先 Debug 收窄到单点，再 Agent 做清理或 refactor。
第二类：该 Agent 却卡在 Debug。需求是「加一个导出 CSV 按钮」，没有 bug，Debug 不会比 Agent 更合适。
第三类：不报文只报情绪。「登录坏了」没有 HTTP 状态码、没有后端 log，Debug 只能猜。至少贴一条网络请求或服务器栈。
修完后的预防：把根因写进测试或类型约束，比留在聊天历史里可靠。团队若用 PR 自动审查，可另配 Cursor Bugbot 怎么开 抓回归，与 Debug 模式互补。Regression 测试绿了再删临时 log，避免把调试输出 merge 进 main。
多服务联调时，把各服务的 request id 或 trace id 对齐贴进 Debug，模型更容易串起跨 repo 的调用链。若 bug 只在 staging 现、本地无法复现，贴 staging 日志片段并说明环境变量差异，Debug 仍会先提假设，但你可以要求「只给可在本地 mock 的验证步骤」，避免它在本地瞎改生产配置。