代码报错别只会问"哪里错了"：AI 调试代码技巧

代码一报错，很多人的下意识是把那句 "哪里错了？" 抛给 AI，再贴半段代码。结果 AI 要么答得驴唇不对马嘴，要么给一个改了也不好的补丁。

AI 调试能不能准，八成取决于你喂给它的信息。这篇用一个具体的报错场景，从头到尾推演一遍该怎么问、怎么给、怎么验证。

先给完整报错，别自己"翻译"

报错信息是调试的原始证据，但很多人只贴一句"它报错了"，或者凭自己理解转述一下，反而把关键信息弄丢了。

正确做法：把完整的堆栈、错误码、出错行号原样贴过去。像

TypeError: Cannot read properties of undefined (reading 'price')
    at cart.js:42:11

这种报错，本身就点名了三件事——类型是空引用、错在读 `price`、位置在 `cart.js` 第 42 行。你贴全，AI 才有据可查；你只贴"读属性报错"，它只能瞎猜。

再补上下文：输入、预期、实际

光有报错还不够，得让 AI 知道"代码想干什么、实际发生了什么"。

补三样：出错那段代码（前后多贴几行）、运行时传了什么输入、你期望得到什么结果。比如"这个接口本该返回购物车总价，结果第 42 行报空，入参里 items 可能是空数组"。把"预期 vs 实际"讲清楚，AI 就能从"报错现象"往"逻辑为什么错"推，而不是停在表面。

让 AI 先猜根因，别急着要补丁

常见的错误用法是张口就"帮我改成对的"。可没定位根因就改，往往头痛医头，按下这个错、冒出下一个错。

正确做法：先让 AI 分析"为什么"——"这个报错可能的根因有哪几个？各怎么确认？"让它列几个假设，你挑符合现场的那一个。定位准了，改法自然浮出来；定位偏了，改多少遍都是白忙。

缩小范围：二分法和日志一起上

报错指向模糊时，别让 AI 硬猜，用它帮你缩小范围。

可以请 AI 在可疑节点加几条临时日志，或者把代码一分为二、逐段排除。像"帮我在 cart.js 的循环前打印一下 items 的长度和结构"，跑一次就知道数据在哪一步变空。二分定位 + 日志取证，是把"玄幻 bug"变"确定 bug"的组合拳。

要解释，不要只收代码

AI 给出一段修复代码，不代表你搞懂了。直接贴进去，下次同类的错你还得再问。

正确做法：追一句"为什么这样改能修好？原来错在哪儿？"让 AI 把因果讲明白。你理解了机制，代码才算真正是你的，也能顺手判断这个改法有没有引入新问题。

改完要验证，再让它补测试防回归

定位修复只是中场，不是终场。改完先自己跑一遍出错的路径，确认现象消失、结果符合预期。

接着让 AI 针对这个 bug 补一个回归测试——"给这个修复写个测试，覆盖 items 为空的场景"。有了测试，下次别人（或 AI）再改到这里，同样的坑就有守门员拦着。修一个 bug 留下一个测试，是调试里性价比很高的一步。

小结

把 AI 调试收一下：完整贴报错、补输入与预期、让 AI 先猜根因再给方案、用二分和日志缩范围、要解释别只收代码、改完验证并补测试。这套下来，AI 从一个"猜谜机器人"变成"有据可查的排查搭档"。

报错不可怕，可怕的是只会问"哪里错了"却不会给线索。线索给够了，AI 才能帮你把坑挖到底。