遇到偶发、难稳定复现的 Bug，先固定输入和环境，收集每次触发的运行时证据，再让 Cursor Debug Mode 帮助区分假设。它可以建议临时日志并根据复现日志定位问题；没有捕获到故障时，不应把猜测当成根因。
把复现输入说清楚
以“同一订单快速点两次提交，偶尔出现两条记录”为假设示例。给 Agent 的信息应包括：测试环境、入口页面、两次点击间隔、预期只建一条、偶发的实际结果、成功与失败时的时间及请求 ID。不要把真实客户密钥或完整个人资料贴进对话。按官方 Debug Mode 说明，在 Agent 的模式选择器切换到 Debug Mode，也可用 Shift+Tab 快速切换。
请先确认双击提交的复现步骤与可能的竞态路径。只在相关函数加必要的临时日志，记录请求标识、进入分支和写入结果；不要记录客户数据。等我按相同输入复现后，再根据日志指出根因和最小修复。修复后请跑相关测试，并移除临时日志。
按证据完成一次闭环
- 让 Agent 先列出两个以上可区分的假设，例如前端重复提交、服务端缺少幂等约束、队列重复消费；不要把假设写成结论。
- 检查新增日志的位置和字段，固定测试账号、环境、输入和点击间隔后重复触发。每轮都保存请求 ID、时间、是否重复写入；同时保留一次成功和一次失败的日志供对照。
- 捕获到故障后，按同一个请求 ID 串起前端、服务端和队列事件，确认哪一层出现重复。再修触发点或状态约束，用原来的输入和重复触发方法重新验证。
- 运行相关回归测试，确认不再重复写入，并核对临时日志或诊断代码已清理。
如果多轮仍无法捕获故障，记录触发次数、环境和观察窗口，保留最小诊断日志继续收集证据；此时只能说“尚未复现”，不能宣称修复。官方流程也强调复现、分析日志、修复与清理。本文示例未在真实订单系统实测，具体修复要按仓库业务契约与数据库约束决定。
Ai菜鸟网。发布者：AI小管家，转载请注明出处：https://www.alyyhw.com/31365.html
