在使用 Cursor 进行代码调试时，最令人困扰的往往并非问题本身，而是花了大量时间才发现一开始的思路就偏离了方向。如果能够掌握一套系统化的排查方法，逐步缩小范围并锁定根源，调试效率将显著提升。下面提供的这份提示词正是为此而设计——它能够帮助 AI（同时也间接帮助你）以结构化的方式思考，逐一排除干扰项，直达问题核心。

先说结论：这套调试提示词的核心逻辑，是要求 AI 先进行充分诊断，再着手修复。它将调试过程清晰地拆解为几个阶段：识别错误来源、筛选可能性、验证假设。你可以直接复制使用，文末也附带了英文版本。

Cursor 中使用 Debug

在 Cursor 中调试时遇到复杂问题？不妨试试这个提示，文末附有英文原版。

Prompt:

思考 5-7 种可能导致问题的来源，并根据可能性、对功能的影响以及在类似问题中的出现频率进行优先排序。仅考虑与错误日志、最近代码变更和系统约束相匹配的来源。忽略外部依赖，除非日志明确指向它们。

一旦缩小到 1-2 个最可能的来源，将其与历史错误日志、相关系统状态和预期行为进行交叉验证。如果发现不一致，调整你的假设。

在添加日志时，确保它们被策略性地放置，以便同时确认或排除多个潜在原因。如果日志不支持你的假设，请先提出替代的调试策略，再继续深入分析。

在实施修复之前，先总结问题现象、经过验证的假设，以及预期的日志输出，以确认问题是否真正得到解决。

为什么这个提示很有效？

这个提示之所以行之有效，是因为它巧妙地将结构化推理、迭代式问题解决和验证驱动的方法融为一体，契合了 Pattern Language 框架中的多个高效模式。换句话说，它并非让 AI 盲目猜测，而是提供了一套可执行、可追踪的逻辑流程。下面来逐一拆解其设计精髓。

1. 情境设定（Contextual Anchoring）

提示一开始便明确了任务目标：不是立刻编写代码，而是先思考可能的根源，然后确定最可能的来源，再通过日志验证假设，最后才进行修复。这样一来，AI 便不会陷入“先改了再说”的误区。目标清晰，约束明确，极大降低了试错成本。

2. 组织思维（Organized Thought）

任务被拆分为三个层次分明的步骤：
- 识别多个可能的错误来源（探索性推理）。
- 筛选出最可能的原因（优先级排序 + 精炼）。
- 通过日志验证假设（确认环节）。

这种逐层分解的方式，能有效降低调试的复杂度，避免从一开始就钻入牛角尖。提示要求 AI 严格按照顺序执行：先广泛列举（5-7 个可能原因），再缩小到 1-2 个，最后进行验证。每一步都有明确的输出要求，确保思维不会随意跳跃。

3. 逐步澄清问题（Incremental Clarity）

这里运用了分层提示的技巧：先发散（列出所有可能），再聚焦（缩小范围），最后确认（通过日志验证）。这种设计保证了 AI 不会一次性给出答案，而是逐步收敛，直到最可能的那个原因浮现出来。

更关键的是，提示内置了一个迭代修正机制——要求 AI 在修复代码之前先添加日志。这相当于一道自我检查的阀门：如果日志不支持当前假设，AI 必须先提出替代策略，不能强行继续修复。整个流程形成了闭环，有效避免了“修错地方”的尴尬局面。

4. 保持逻辑一致性（Consistency & Coherence）

提示强制规定：在找到最可能的原因之前，不能直接修改代码。这一策略至关重要，它阻止了 AI 过早做出武断假设，或者跳过问题识别阶段直接动手。整个调试逻辑链条是完整的：从问题识别到原因筛选，再到验证，最后才是修复，一步都不能省略。

此外，“添加日志来验证假设”这一指令，相当于给调试过程增加了数据支撑。任何修复行为都必须有日志证据作为后盾，而不是依赖 AI 的“直觉”。

5. 自我思考 & 反思（Meta-Thinking & Self-Reflection）

提示让 AI 先评估假设、再采取行动。这种内置的自我修正机制，能有效避免因误判而浪费调试时间。通过日志验证，AI 需要在继续修复之前先确认自己的假设是否可靠，相当于在过程中进行了一次“信心审核”。

总结：这个提示语有哪些强大之处？

如果还想让调试流程更加严谨，可以考虑增加明确的优先级标准（比如根据日志出现的频率来排序），或者添加一个验证后的总结步骤（在修复代码前，先总结日志确认了什么）。不过，当前版本已经足够强大，完全可以拿来直接使用。

优化后的英文版本：

Reflect on 5-7 different possible sources of the problem, prioritizing them based on likelihood, impact on functionality, and frequency in similar issues. Only consider sources that align with the error logs, recent code changes, and system constraints. Ignore external dependencies unless logs indicate otherwise.

Once you've narrowed it down to 1-2 most likely sources, cross-check them against previous error logs, relevant system state, and expected beha viors. If inconsistencies arise, refine your hypothesis.

When adding logs, ensure they are strategically placed to confirm or eliminate multiple causes. If the logs do not support your assumptions, suggest an alternative debugging strategy before proceeding.

Before implementing a fix, summarize the issue, validated assumptions, and expected log outputs that would confirm the problem is solved.

最早的中英文版本：

英文版本：

Reflect on 5-7 different possible sources of the problem, distill those down to 1-2 most likely sources, and then add logs to validate your assumptions before we move onto implementing the actual code fix

中文版本：

思考 5-7 种可能导致问题的原因，将它们缩小到 1-2 个最有可能的来源，然后添加日志来验证你的假设，再继续实现代码修复