AI Learn
Cursor · Practical Tutorial

Find the root cause of a hard bug with Cursor Debug Mode

Make Cursor form hypotheses, add instrumentation, capture runtime evidence, apply one targeted fix and then remove the debugging noise.

Reviewed September 20, 2026Independent tutorialFeatures may vary
Not official support. AI Learn is an independent education site. Check the provider’s current documentation for plan-specific limits, pricing and feature availability.
Before you start

Use Debug Mode when the failure is reproducible but the cause is not obvious from static code. It is especially useful for timing issues, regressions, performance problems and bugs where normal Agent mode keeps guessing.

1. Write exact reproduction steps plus expected and actual behavior

Record the smallest reproducible sequence, environment and expected versus actual behavior. If the bug cannot be reproduced consistently, note the frequency and conditions instead of asking the agent to “fix what looks wrong.”

2. Switch to Debug Mode and let Cursor enumerate competing hypotheses before editing

Ask Debug Mode to enumerate competing hypotheses before editing. A useful list names the observable signal that would support or falsify each hypothesis, so instrumentation has a purpose.

3. Allow narrow instrumentation and reproduce the problem exactly as instructed

Allow only targeted temporary instrumentation at decision points relevant to those hypotheses. Avoid broad logging that changes timing, leaks sensitive values or makes the evidence harder to interpret.

4. Inspect the captured runtime evidence and identify the hypothesis actually supported

Reproduce the bug exactly and compare the captured runtime evidence against the hypothesis list. Prefer the explanation that accounts for all observed signals, not simply the first suspicious line of code.

5. Apply the smallest fix, reproduce again, then remove all temporary instrumentation

Apply the smallest fix, rerun the original reproduction and related regression tests, then remove every temporary log/probe. The final diff should contain the fix and tests, not the investigation scaffolding.

Try this prompt

Use Debug Mode. Do not patch yet. Reproduction: [steps]. Expected: [expected]. Actual: [actual]. Generate 3–5 hypotheses, instrument only the minimum points needed to distinguish them, ask me to reproduce, then use the logs to choose the root cause before editing.

Common mistakes

Jumping straight to a fix; adding logs everywhere; changing behavior while measuring it; not reproducing after the patch; leaving instrumentation in production code.

Finish check

The chosen fix is supported by runtime evidence, the original reproduction no longer fails, and all temporary logging or probes have been removed.

开始之前

当问题可以复现,但仅靠看代码找不到原因时再用 Debug Mode。它特别适合时序问题、回归、性能问题,以及普通 Agent 一直在猜而不是基于运行证据判断的 Bug。

1. 写出精确复现步骤,以及预期结果和实际结果

先记录最小可复现步骤、运行环境以及“预期结果 vs 实际结果”。如果 Bug 不是每次出现,就写清出现频率和触发条件,不要只让 Agent 去“看看哪里不对”。

2. 切换到 Debug Mode,让 Cursor 在改代码前先列出多个竞争假设

修改代码前先让 Debug Mode 列出多个竞争假设。好的假设还要写出“看到什么现象支持它、看到什么现象可以否定它”,这样后面的埋点才有目的。

3. 只允许加入有限的调试观测点,并严格按步骤复现

只允许在能区分这些假设的关键位置增加临时埋点。避免全局疯狂打日志,因为这可能改变时序、泄露敏感值,还会让证据更难读。

4. 检查采集到的运行时证据,只保留真正被数据支持的假设

严格按原步骤复现问题,再把运行时证据逐条对照假设。优先选择能够解释全部观察结果的原因,而不是看到第一行可疑代码就开始修。

5. 做最小修复,再次复现验证,然后删掉所有临时调试代码

做最小修复后重新执行原始复现步骤和相关回归测试,再删除所有临时日志与探针。最终 Diff 应只留下修复和测试,不应留下调查脚手架。

可以直接套用的提示词

使用 Debug Mode,先不要改代码。复现步骤:[steps]。预期:[expected]。实际:[actual]。先提出 3–5 个假设,只在能区分这些假设的最小位置加入观测点,让我复现,再根据日志选择真正根因,然后才修改。

常见错误

直接跳到修复;到处加日志;测量问题时顺便改了行为;修复后不再复现验证;把临时观测代码留进生产。

完成检查

最终修复有运行时证据支撑,原来的复现步骤不再失败,而且所有临时日志和探针都已经移除。

開始之前

當問題可以復現,但僅靠看程式碼找不到原因時再用 Debug Mode。它特別適合時序問題、回歸、性能問題,以及普通 Agent 一直在猜而不是基於執行證據判斷的 Bug。

1. 寫出精確復現步驟,以及預期結果和實際結果

先記錄最小可復現步驟、運行環境以及“預期結果 vs 實際結果”。如果 Bug 不是每次出現,就寫清出現頻率和觸發條件,不要只讓 Agent 去“看看哪裡不對”。

2. 切換到 Debug Mode,讓 Cursor 在改程式碼前先列出多個競爭假設

修改代碼前先讓 Debug Mode 列出多個競爭假設。好的假設還要寫出“看到甚麼現象支持它、看到甚麼現象可以否定它”,這樣後面的埋點才有目的。

3. 只允許加入有限的調試觀測點,並嚴格按步驟復現

只允許在能區分這些假設的關鍵位置增加臨時埋點。避免全局瘋狂打日誌,因為這可能改變時序、洩露敏感值,還會讓證據更難讀。

4. 檢查採集到的執行階段證據,只保留真正被資料支援的假設

嚴格按原步驟復現問題,再把運行時證據逐條對照假設。優先選擇能夠解釋全部觀察結果的原因,而不是看到第一行可疑代碼就開始修。

5. 做最小修復,再次復現驗證,然後刪掉所有臨時調試程式碼

做最小修復後重新執行原始復現步驟和相關回歸測試,再刪除所有臨時日誌與探針。最終 Diff 應只留下修復和測試,不應留下調查腳手架。

可以直接套用的提示詞

使用 Debug Mode,先不要改程式碼。復現步驟:[steps]。預期:[expected]。實際:[actual]。先提出 3–5 個假設,只在能區分這些假設的最小位置加入觀測點,讓我復現,再根據記錄選擇真正根因,然後才修改。

常見錯誤

直接跳到修復;到處加記錄;測量問題時順便改了行為;修復後不再復現驗證;把臨時觀測程式碼留進生產。

完成檢查

最終修復有執行階段證據支撐,原來的復現步驟不再失敗,而且所有臨時記錄和探針都已經移除。

Official references

Check current product details at the source

Related practical tutorials

Continue with another single-task workflow.

All tutorials →