AI 编程调试提示词与沟通策略专业手册
05/1849 浏览开发心得
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
前言：为什么需要专业提示词？
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
AI 在调试时最常见的失败模式有三种：
1. 「盲猜修复」—— 没有读取足够信息就直接改代码，导致修了一个 BUG 引入三个
2. 「表层修复」—— 处理了报错信息，但没有定位根本原因，BUG 换个形式复现
3. 「上下文丢失」—— 多轮对话后 AI 遗忘早期关键细节，重复做无效的尝试
本手册的核心思想：
- 强迫 AI 先诊断、后治疗（Read before Write）
- 给 AI 提供「完整的犯罪现场」，而非只有「尸体」
- 使用结构化语言减少歧义，让 AI 的推理路径可预期
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
第一章：黄金原则——提问前的信息准备
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
【原则 1】"给犯罪现场，不只给尸体"
差的提问：「我的代码崩溃了，帮我修一下」
好的提问：「以下是完整报错栈、触发条件、最近一次修改的 diff，帮我诊断根本原因」
信息清单（提问前对照检查）：
┌─────────────────────────────────────────────────────────────────┐
│ □ 完整错误信息（含行号、堆栈，不要截断） │
│ □ 触发该 BUG 的最小复现步骤 AI 编程调试提示词与沟通策略专业手册 │
│ □ 期望行为 vs 实际行为 │
│ □ 相关代码片段（不是整个文件，但要包含上下文） │
│ □ 最近一次改动了什么（修改时间线） │
│ □ 已经尝试过的方案及结果 │
└─────────────────────────────────────────────────────────────────┘
【原则 2】"一次只解决一个问题"
把复合 BUG 拆开：
「这里有两个问题：A 问题是……，B 问题是……，先帮我解决 A」
不要同时要求修 BUG + 加功能 + 重构，这会分散 AI 注意力。
【原则 3】"声明约束，防止过度修改"
「只修改 foo() 函数内部，不要改函数签名和调用方」
「最小化改动，不要重构无关代码」
「不要引入新的依赖库」
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
第二章：强制诊断优先——让 AI 先分析再动手
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
这一章的句式都有一个共同目的：阻止 AI 直接写代码，强制它先做分析。
────────────────────────────────────────────────────────────────────────────────
2.1 「先诊断，不要修」系列
────────────────────────────────────────────────────────────────────────────────
► 「先不要修改任何代码。请阅读相关文件，告诉我你认为 BUG 的根本原因是什么，
以及你的推理过程。等我确认后再动手。」
► 「在写任何代码之前，先列出你需要检查的文件和函数，说明为什么要检查这些地方。」
► 「分两步走：第一步只做分析，输出你的诊断报告；第二步我说"开始修复"后再改代码。」
► 「你现在的假设是什么？请用"假设 → 验证方法 → 预期结果"的格式列出你打算
如何排查这个问题。」
────────────────────────────────────────────────────────────────────────────────
2.2 「假设驱动排查」系列
────────────────────────────────────────────────────────────────────────────────
► 「请列出导致这个 BUG 的所有可能假设，按可能性从高到低排序，
并说明每个假设的证据和反证。」
► 「用"排除法"帮我分析：哪些原因可以首先排除？剩下的候选原因是什么？」
► 「对于你的假设 X，如果它是正确的，代码里应该还会有什么其他症状？
帮我检查一下是否有这些佐证。」
► 「我认为问题可能出在 A 或 B，你认为哪个更可能？给我你的理由，
然后告诉我如何用最小代价验证。」
────────────────────────────────────────────────────────────────────────────────
2.3 「追问根因」系列（五个为什么）
────────────────────────────────────────────────────────────────────────────────
► 「你说问题在 line 42，但 line 42 为什么会出错？它的上游数据从哪里来？」
► 「这是现象还是根本原因？如果是现象，根本原因是什么？」
► 「用"五个为什么"帮我追溯这个 BUG 的根源：
为什么出现症状 X？因为 Y。为什么 Y？……直到找到可以修改的根本原因。」
► 「你的修复方案能防止这类 BUG 再次出现吗？还是只修了这一个实例？」
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
第三章：精准定位——缩小问题范围的提示词
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
────────────────────────────────────────────────────────────────────────────────
3.1 「二分法定位」系列
────────────────────────────────────────────────────────────────────────────────
► 「用二分法帮我缩小范围：如果我把代码从第 100 行截断，BUG 还会出现吗？
帮我设计一个最小复现案例。」
► 「请帮我识别：这个 BUG 是在数据进入模块时就错了，
还是在模块内部处理时才出错？」
► 「我们已知 A 是正确的，B 是错的，中间经过了 C、D、E 三步。
请帮我判断错误最可能发生在哪一步，以及如何验证。」
────────────────────────────────────────────────────────────────────────────────
3.2 「边界条件排查」系列
────────────────────────────────────────────────────────────────────────────────
► 「这个 BUG 是否只在特定条件下触发？
帮我分析：空输入/极大值/并发/首次调用/重复调用时，行为是否一致？」
► 「请专门检查边界条件：null/undefined/空数组/零/负数/最大整数，
哪种情况会导致这段逻辑走错分支？」
► 「这段代码有没有隐含的前置条件？如果调用方没有满足这些前置条件，
会出现什么情况？」
────────────────────────────────────────────────────────────────────────────────
3.3 「数据流追踪」系列
────────────────────────────────────────────────────────────────────────────────
► 「请从数据入口开始，逐步追踪这个变量的值变化路径，
找出它在哪一步变成了错误的值。」
► 「帮我画出（用文字描述）这段逻辑的数据流图：
输入 → 变换 1 → 变换 2 → … → 输出。每步的预期值是什么？」
► 「这个函数的返回值来自哪里？调用链是什么？
请从报错点向上追溯调用栈，找出最初错误的起点。」
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
第四章：高质量修复——避免引入新 BUG 的提示词
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
────────────────────────────────────────────────────────────────────────────────
4.1 「修复前的影响评估」
────────────────────────────────────────────────────────────────────────────────
► 「在修改 X 之前，告诉我有哪些地方调用了它、依赖它，
这次改动会影响到哪些地方？」
► 「你打算修改哪些行？请先列出来，说明每一处修改的理由，
以及这处修改不会破坏的断言是什么。」
► 「这个修复方案有没有副作用？在什么情况下它会造成新的问题？」
► 「如果这个修复方案是错的，最坏的情况是什么？
我们怎么快速检测出这个修复方案本身有问题？」
────────────────────────────────────────────────────────────────────────────────
4.2 「最小化改动」
────────────────────────────────────────────────────────────────────────────────
► 「给我最小化的 diff，只改真正需要改的行，不要顺手重构其他代码。」
► 「不要改变代码风格、变量命名和结构，只修复逻辑错误本身。」
► 「如果有两种修复方案，一种改 5 行、一种改 50 行，
优先用改 5 行的方案，除非你能证明它不够安全。」
────────────────────────────────────────────────────────────────────────────────
4.3 「修复后验证」
────────────────────────────────────────────────────────────────────────────────
► 「修改完后，请告诉我：如何手动验证这个修复是正确的？
给我一个具体的测试步骤。」
► 「为这个修复写一个测试用例，能够在未来检测同类回归。」
► 「现在用之前的报错信息重新走一遍逻辑，告诉我为什么修复后不会再出现那个错误。」
► 「除了修复这个 BUG，你有没有发现代码中其他潜在的类似问题？
列出来但先不要修，等我决定是否处理。」
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
第五章：对话控制——管理多轮调试会话
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
────────────────────────────────────────────────────────────────────────────────
5.1 「保持上下文」
────────────────────────────────────────────────────────────────────────────────
► 「在我们继续之前，请先总结一下目前我们已经确认的事实：
已知原因是什么，已尝试的方案有哪些，当前的状态是什么。」
► 「我们已经排除了哪些假设？把已排除的列出来，
这样我们不会重复走弯路。」
► 「现在的问题焦点是什么？用一句话描述我们正在解决的具体子问题。」
────────────────────────────────────────────────────────────────────────────────
5.2 「拒绝无效循环」
────────────────────────────────────────────────────────────────────────────────
► 「这是你第三次修改同一个地方了，但问题还在。
说明我们的方向可能根本就错了，请退一步，重新提出不同的假设。」
► 「不要再往这个方向试了。假设我们之前的所有假设都是错的，
从零开始告诉我还有哪些可能性我们没有考虑到。」
► 「如果你不确定，就说不确定，不要给我一个看起来自信但你没把握的修复方案。
我宁愿知道你不知道，也不要反复试错。」
────────────────────────────────────────────────────────────────────────────────
5.3 「阶段性确认」
────────────────────────────────────────────────────────────────────────────────
► 「我们现在处于排查的哪个阶段？还缺少哪些关键信息？」
► 「告诉我你的置信度：对这个诊断你有多少把握（用百分比），
以及置信度不是 100% 的原因是什么。」
► 「在我们进入修复阶段之前，需要我提供哪些额外信息？」
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
第六章：特殊场景提示词
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
────────────────────────────────────────────────────────────────────────────────
6.1 「偶现/难以复现的 BUG」
────────────────────────────────────────────────────────────────────────────────
► 「这个 BUG 不是每次都出现，大约 1/5 的概率触发。
请帮我分析哪些非确定性因素（时序、随机数、网络、缓存状态）可能导致它。」
► 「我无法稳定复现这个 BUG，但有一份崩溃日志。
请从日志中提取所有可能相关的异常信号，帮我建立复现假设。」
► 「帮我在代码中添加防御性日志，覆盖这个 BUG 可能经过的所有路径，
以便下次出现时能捕获完整的现场信息。」
────────────────────────────────────────────────────────────────────────────────
6.2 「性能 BUG」
────────────────────────────────────────────────────────────────────────────────
► 「不要猜测性能瓶颈，帮我设计一个最简单的性能剖析方案，
先测量再优化。」
► 「给我一个 O(n) 复杂度分析：这段代码在输入规模 N 下，
最坏情况做了多少次操作？」
► 「有没有我没意识到的隐藏计算开销？例如隐式类型转换、GC 压力、
重复计算、不必要的内存分配？」
────────────────────────────────────────────────────────────────────────────────
6.3 「看不懂的遗留代码」
────────────────────────────────────────────────────────────────────────────────
► 「先不要修改这段代码。帮我理解它的意图：
这段代码试图做什么？有哪些隐含的假设？」
► 「这段代码写得很奇怪，可能是有意为之（规避某个已知问题），
也可能是 BUG。帮我分析这两种可能性的证据。」
► 「在修改这段遗留代码之前，帮我列出它所有的调用路径和依赖，
确保我们理解"不小心破坏什么"的风险。」
────────────────────────────────────────────────────────────────────────────────
6.4 「多文件/大型项目」
────────────────────────────────────────────────────────────────────────────────
► 「先告诉我你需要读哪些文件才能理解这个问题，
不要先写代码，先读完再说。」
► 「从报错的文件出发，找出它直接依赖的所有模块，
告诉我哪些地方可能是 BUG 的来源。」
► 「这个修复会跨越多个文件，请先列出所有需要修改的文件和修改原因，
我确认后你再开始逐个修改。」
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
第七章：元认知提示词——让 AI 检查自己的推理
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
这一章的提示词让 AI 对自己的推理过程进行反思，效果远超直接要求"正确"。
► 「用"橡皮鸭调试法"：假装向一个完全不懂这个项目的人解释这段代码，
在解释过程中找出逻辑矛盾。」
► 「扮演一个持怀疑态度的代码审查者，指出你刚才给出的修复方案的潜在问题。」
► 「如果你的修复是错的，最可能的原因是什么？哪个假设最有可能是错误的？」
► 「在你确认这个修复方案之前，检查一下：
你有没有跳过某个步骤？有没有做了假设但没有验证的地方？」
► 「站在"红队"的角度：如果你的任务是证明这个修复方案不完整，你会怎么做？」
► 「重新审视你的推理链，找出最薄弱的一环，并告诉我如何验证那一环是否成立。」
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
第八章：结构化请求模板
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
直接复制使用，填入具体内容即可。
────────────────────────────────────────────────────────────────────────────────
【模板 A】标准 BUG 报告请求
────────────────────────────────────────────────────────────────────────────────
我遇到了一个 BUG，请帮我诊断。
**环境信息**
- 语言/框架版本：[填写]
- 操作系统：[填写]
**错误信息**（完整，未截断）
```
[粘贴完整错误信息]
```
**复现步骤**
1. [步骤1]
2. [步骤2]
3. [步骤3]
**期望行为**：[描述应该发生什么]
**实际行为**：[描述实际发生了什么]
**相关代码**
```
[粘贴相关代码，包含上下文]
```
**已尝试方案**：[描述已经试过什么，以及结果]
请先进行诊断分析，不要立即修改代码。列出可能的根本原因和你的推理过程，
等我确认后再给出修复方案。
────────────────────────────────────────────────────────────────────────────────
【模板 B】深度分析请求
────────────────────────────────────────────────────────────────────────────────
请对以下问题进行深度分析，按照以下格式输出：
1. **现象描述**：用你自己的语言复述这个问题
2. **可能原因列表**：按可能性从高到低排列（每条附理由）
3. **排除法**：哪些原因可以直接排除，为什么
4. **验证方案**：如何以最小代价验证剩余假设
5. **推荐修复方案**：基于分析给出建议（此时再给修复方案）
6. **风险提示**：这个修复可能的副作用
问题描述：[你的问题]
────────────────────────────────────────────────────────────────────────────────
【模板 C】修复前确认请求
────────────────────────────────────────────────────────────────────────────────
在你修改代码之前，请先回答以下问题：
1. 你要修改哪些文件的哪些行？（列出具体位置）
2. 每处修改的目的是什么？
3. 这些修改会影响哪些其他功能？
4. 有哪些你没有把握的地方？
5. 如何快速验证修复是否有效？
等我确认你的分析没有遗漏后，再开始修改。
────────────────────────────────────────────────────────────────────────────────
【模板 D】反复修复失败后的重置请求
────────────────────────────────────────────────────────────────────────────────
我们已经尝试了 [N] 次修复但都没有成功，说明我们的方向有根本性的偏差。
请完全忽略我们之前的所有尝试，从零开始思考：
1. 重新阅读原始报错信息
2. 列出你在之前的尝试中可能做出的错误假设
3. 提出 3 个全新的、与之前完全不同的假设
4. 对每个假设说明：如果它是正确的，我们应该看到什么症状？
不要受之前对话的影响。
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
第九章：常见反模式——这些提示词会让效果变差
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
以下是用户常用但效果差的提示词，以及更好的替代方案。
✗ 差：「帮我修一下这个 BUG」
✓ 好：「诊断这个 BUG 的根本原因，然后给出最小化修复方案」
✗ 差：「代码跑不通，看看哪里有问题」
✓ 好：「以下是完整报错信息，请从报错点追踪问题根源」
✗ 差：「为什么不行？」（没有上下文）
✓ 好：「为什么在条件 X 下，函数 Y 返回 Z 而不是期望的 W？」
✗ 差：「你改的还是不对」（没有具体说明哪里不对）
✓ 好：「你的修复解决了报错，但在 [具体条件] 下行为仍然不正确，
具体现象是 [描述]」
✗ 差：「全部重写一遍」（核弹式解决方案）
✓ 好：「只修改产生问题的最小范围，其他代码不要动」
✗ 差：「你是对的」（盲目认同）
✓ 好：「你的分析中第 2 点让我有疑问，[指出具体疑问]」
✗ 差：「继续」（无方向的推进）
✓ 好：「基于当前诊断，下一步最高优先级应该验证哪个假设？」
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
第十章：高阶技巧——让 AI 真正"思考"而非"生成"
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
────────────────────────────────────────────────────────────────────────────────
10.1 约束输出格式，强迫结构化思维
────────────────────────────────────────────────────────────────────────────────
「用以下格式回复，每一节都必须填写，不允许跳过：
[观察] 你从代码/日志中观察到的事实（不包含推断）
[假设] 基于观察提出的假设
[验证] 如何验证每个假设
[结论] 目前最可信的根本原因
[方案] 修复建议（如果结论足够确定）」
────────────────────────────────────────────────────────────────────────────────
10.2 要求解释推理过程
────────────────────────────────────────────────────────────────────────────────
「不仅要告诉我修改什么，还要用'因为 A，所以 B，因此修改 C'
的格式解释每一步的逻辑。」
「把你的推理过程完整写出来，即使有些步骤显而易见，
我需要验证你的推理链条是否有断层。」
────────────────────────────────────────────────────────────────────────────────
10.3 主动要求 AI 承认不确定性
────────────────────────────────────────────────────────────────────────────────
「如果有任何你不确定的地方，明确标注'[不确定]'，
并说明还需要哪些信息才能确定。」
「区分"我确定这个修复是正确的"和"这个修复可能有效，但我无法完全确认"，
诚实地告诉我你的把握程度。」
────────────────────────────────────────────────────────────────────────────────
10.4 利用对比分析
────────────────────────────────────────────────────────────────────────────────
「对比正常情况和异常情况：在 BUG 出现前代码路径是什么？
出现后路径在哪里分叉了？」
「这段代码在版本 A 里是好的，版本 B 里坏了，
帮我对比两个版本的关键差异，定位引入 BUG 的具体改动。」
────────────────────────────────────────────────────────────────────────────────
10.5 利用类比和反例
────────────────────────────────────────────────────────────────────────────────
「写一段能正常工作的最小示例代码，它和我的问题代码的结构相同，
然后对比两者的差异。」
「给我一个这种 BUG 的教科书案例（不使用我的代码），
然后告诉我我的代码如何对应到这个模式。」
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
附录：快速参考卡片
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
开始调试时的三句话：
┌─────────────────────────────────────────────────────────────────┐
│ 1. 「先不要修代码，告诉我你认为的根本原因」 │
│ 2. 「你的推理依据是什么？有没有你没验证的假设？」 │
│ 3. 「修改前，告诉我这处改动会影响哪些地方」 │
└─────────────────────────────────────────────────────────────────┘
修复循环失败时的重置句：
┌─────────────────────────────────────────────────────────────────┐
│ 「忘掉之前所有尝试，重新从原始症状出发，提出全新假设」 │
└─────────────────────────────────────────────────────────────────┘
验收修复时的检查句：
┌─────────────────────────────────────────────────────────────────┐
│ 「用一句话告诉我：为什么修复后这个 BUG 不会再出现？」 │
└─────────────────────────────────────────────────────────────────┘
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
本手册核心理念总结
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
【诊断优先于修复】 先确认病因，再开处方
【完整信息优于简洁】 宁可多提供，不要让 AI 猜测
【约束比自由更有效】 告诉 AI 不能做什么，往往比告诉它做什么更重要
【显式优于隐式】 把你的假设说出来，而不是期望 AI 自动理解
【追问优于接受】 收到分析后继续追问，直到推理链条完整
【承认不确定性】 要求 AI 标注不确定的部分，比盲目自信的答案更有价值