让 AI 先验证报错原因，再动手修代码

把报错贴给 AI，得到一个补丁，运行失败，再换一个补丁。这种循环的问题，往往出在第一步：原因还没查清，就开始改代码。作者给出的办法是拆开诊断与修复，先列假设、设计验证实验，再讨论怎么改。

原文提供了两套调试提示词，分别应对「刚拿到报错」和「已经卡了很久」。值得借鉴的不是某句神奇指令，而是让 AI 的每个判断都对应一个可以执行的检查。

先让 AI 解释报错，再让它提出修复

「修复这个 TypeError」看似明确，实际缺少很多信息：语言版本是什么，预期结果是什么，已经试过哪些办法？作者认为，直接索要修复，会促使模型在信息不足时也交出一个答案。

他的第一套提示词，把回答顺序固定为：解释错误、定位出错行、列出最可能的 3 个原因、分别设计最小验证实验。

下面保留原文模板，它解决的是「模型跳过诊断，直接给补丁」的问题：

Actúa como desarrollador senior de [LENGUAJE]. Te paso un error y su stack trace:
[ERROR_Y_STACK_TRACE]
Y el código relevante:
[CÓDIGO]
Explica en orden: 1) qué significa el error, 2) la línea exacta donde se origina
y por qué, 3) las 3 causas más probables ordenadas por probabilidad, 4) cómo
confirmar cada una con un experimento mínimo. No propongas el arreglo hasta
haber razonado la causa.

最后一句是关键约束：在分析原因之前，不要提出修复。但真正能检验回答的，是前面要求的实验。一个 print、一条 assert，或者一个最小 test，都能帮助你判断某个解释是否成立。

假设可以由 AI 提出，结论要由运行结果支撑。

输入也得配合：作者要求提供完整的堆栈跟踪（stack trace），不能只贴最后一行；代码则应包含调用栈中涉及的函数。否则，要求模型指出「确切位置」，很容易得到一个看似精确、实际缺少依据的答案。

卡了很久，就把尝试记录变成排查计划

第二套提示词针对另一种情况：你已经反复折腾，开始失去排查顺序。此时继续问「还有什么办法」，很容易收到已经试过的建议。

下面的模板要求模型根据已有尝试，整理带验证步骤的排查计划：

Llevo [TIEMPO] atascado con este problema: [DESCRIPCIÓN]. Ya probé:
[LO_QUE_YA_PROBÉ]. No me des la solución directamente: ayúdame a construir un
plan de depuración con hipótesis numeradas, el experimento que confirma o
descarta cada una y el orden óptimo para ejecutarlos.

这里最该认真填写的是 [LO_QUE_YA_PROBÉ]，也就是「已经做过哪些尝试」。作者认为，这能减少重复建议；要求给出执行顺序，则有助于优先安排成本低的实验。

实际使用时，尝试记录最好带上结果。例如，别只写「检查过参数」，而要交代检查了哪里、观察到了什么。这样模型才有材料判断某条路径是否真的被排除。

原文还列出几项适用于所有调试请求的输入要求：提供语言、框架和操作系统版本；交代预期行为与实际结果；把代码缩减到能复现问题的最小范围；用虚构值替换 token、密码和真实环境变量。最后，亲自运行验证实验，不能因为解释顺耳就接受它。

我的判断

我赞同把「提出假设」和「验证假设」分开。相比连续索要补丁，这种方式更容易留下排查依据；相比只让 AI 解释报错，它又多了一步可执行的检查。

但原文没有展示具体 bug 的完整排查过程，也没有成功率、耗时或对照数据。作者说这是自己使用的两套提示词，因此它们属于个人经验，不能据此断言换个问法就能解决大多数调试问题。

几个要求也需要留余地。「最可能的 3 个原因」只是组织答案的方式，模型给出的排序不等于经过校准的概率；「最优执行顺序」也不保证真是最优。缺少调用上下文或复现条件时，模型应该先指出信息不足，而不是为了满足格式凑出精确结论。

这套方法和传统调试并不冲突。它把列假设、做最小实验、根据证据排除原因的流程写进了提示词。原文结尾推广了包含这两套模板的《100 Prompts para Programadores》，自定价格、最低 2 USD；这个商品信息不能充当方法有效性的证据。

能拿来做什么

• 遇到前端或 Node 的 TypeError 时，把完整调用栈、相关函数、运行版本和预期结果一起提交，先要求诊断及验证步骤，再根据实验结果讨论修改。
• 排查迟迟没有进展时，整理「尝试动作与实际结果」，让 AI 为剩余假设编号，并按验证成本安排执行顺序。
• 把 AI 的每个原因判断改写成一个可检查的问题，再用日志、断言或最小测试回答它。提供复现代码前，先替换其中的真实凭据。