借助 AI 拆解一条错误信息并建立一套诊断方法，而不是乞求一个你根本看不懂的修复方案。
在 Kodokon 中打开本课遇到 bug 时，主流的本能反应就是把调用栈粘进对话框，再加一句“帮我修好”。它常常奏效——而这恰恰是问题所在。你带走了一个自己从未理解的修复方案，而它所属的这一类 bug 下个月会换个形式卷土重来。bug 是一次难得的学习机会：它揭示了你的心智模型与系统实际行为之间的落差。直接要修复方案就把这份信息扔掉了。正确的做法是：让 AI 解释这条错误信息并给出一套诊断方法——然后由你自己去开展排查。
你是一位帮助我提升调试能力的资深开发者。你的任务是解释，而不是替我修复。
背景：[语言 + 版本、框架、这段代码本应做什么]。
完整的错误信息，包括调用栈：
[粘贴错误信息]
相关代码片段（10 到 30 行）：
[粘贴代码]
你的任务：
1. 逐段解释这条错误信息：它到底在说什么，又没有在说什么？
2. 结合我的具体背景，列出 2 到 3 个最可能的原因，从最可能到最不可能排序。
3. 针对每个原因，给出一个我可以自己动手的具体检查（有针对性的日志、断点、隔离测试）。
硬性约束：不要给我修复方案。如果你能确定原因，只需告诉我该去哪里查看。这条提示词有三个特性，让它与众不同。第一，精简而完整的背景：版本、代码意图、完整的错误信息——一个靠猜测你背景的 AI 会臆造出原因。第二，要求按可能性排序的原因：你学会用假设而非确信去推理。第三，明令禁止给出修复方案：没有这一条，模型几乎总会滑向解决方案，因为它被训练成乐于助人。锁定框架，得靠你自己。
你是我的调试教练。严格采用苏格拉底式方法：你从不直接给出答案，你只提问。
我的 bug：[观察到的现象]，而我期望的是 [预期行为]。
我已经检查过的：[清单]。
运作方式：
- 每次只问我一个问题，帮我逐步锁定原因。
- 每个问题要么排除一个假设，要么加强一个假设。
- 当我回答后，先说明我的回答排除了哪条线索，再问下一个问题。
- 如果我提出一个假设，帮我设计出确认或推翻它的最快测试。
禁令：绝不直接说出原因，哪怕它对你来说显而易见。这第二条提示词覆盖了最棘手的情形：沉默的 bug，没有异常，程序只是做了预期之外的事。AI 应该带你反复演练的方法，正是每位老练的调试者都在用的那套：可靠地复现，通过缩小范围（对代码或数据做二分）来隔离，提出一个可证伪的假设，再用尽可能廉价的检查去验证这个假设。在这里，AI 扮演的是一只会回话的小黄鸭——一只能阻止你跳步的小黄鸭。