[Vibe Coder #5] 如何阅读错误信息，以及 AI 修不好 Bug、反复兜圈时的脱身方法

当红色错误信息铺满屏幕时，心里会猛地一沉。英文密密麻麻，满是从未见过的单词，看起来也没有告诉你到底哪里出了问题。因此，很多 vibe coder 不读错误信息就直接关掉，然后对 AI 说：“不行，帮我修好。”接着 AI 开始修改不相关的地方。

陷阱就在这里：错误信息其实是犯人留下的自白书。发生了什么、在哪里发生，里面早已写得清清楚楚。只要掌握阅读方法，就等于解决了一半；原样交给 AI，剩下的一半也会更快完成。本期将介绍如何阅读错误信息、如何正确传给 AI，以及 AI 修不好同一个 Bug、反复兜圈时的脱身方法。

错误信息的结构：只要找到三件事

任何错误的结构都一样。只要找到三个部分即可。

1. 发生了什么（错误名称和说明）：通常是第一行。例如TypeError: Cannot read properties of undefined。直译就是“试图从空的东西里取出某个值”。就像快递还没到，却想打开箱子一样。
2. 在哪里发生（文件和行号）：如果看到类似app/page.tsx:42的标记，就表示是app/page.tsx文件的第 42 行。这就是案发现场。
3. 通过什么路径发生（堆栈跟踪）：下面连续列出的清单，是到达事件现场之前的调用路径。不用害怕，只要知道最上面的几行是距离现场最近的记录即可。

不需要全部理解。只要弄清“发生了什么 + 在哪里”，你就已经比不读错误的人有利十倍。

错误存在于两个地方

第 1 期的区分在这里再次出现。错误会显示在两个地方，具体查看哪里取决于症状。

• 浏览器控制台（前端的尖叫）：屏幕一片空白、按钮没有反应，或部分界面显示异常时。在浏览器中按 F12（或右键 → 检查），查看 Console 标签页。
• 服务器日志（后端的尖叫）：保存、登录、支付或调用 AI 失败时。开发期间会显示在运行开发程序的终端窗口中；部署后则会显示在第 4 期介绍的部署服务控制台的 Logs 菜单中。

屏幕上可能只显示“出现问题”，但服务器日志中往往写着真正的原因。不要只看屏幕就说“没有错误信息”，请养成两边都打开查看的习惯。

传给 AI 的方法：完整内容加上上下文

找到错误后，按下面的方式传给 AI。

• **完整复制。**后半部分经常包含线索，所以不要只截取第一行。复制文本比发送截图更好。
• **同时写清上下文。**说明是在做什么时发生的，比如“点击注册按钮后”，以及原本期待的行为，比如“应该跳转到欢迎页面”。
• **写明在哪里找到的。**是在“浏览器控制台”还是“服务器日志”中？这一句话就能让 AI 需要排查的范围缩小一半。

坏问题和好问题的差别就有这么大。“保存不了，帮我修好”相当于让 AI 没有地图地搜索。“点击保存按钮后界面没有变化，但服务器日志中出现了这个错误：（粘贴完整错误）。原本应该在列表中看到新文章”则是把案发现场和自白书一起交给 AI。

AI 反复兜圈时：4 种脱身方法

如果 AI 连续三四次都修不好同一个 Bug，与其增加尝试次数，不如改变局面，这样更快。

**1. 开启新对话。**在堆满失败尝试的对话中，AI 会不断受到自己错误假设的影响。开启新对话，只重新清楚地传达当前症状和错误，意外地经常能一次解决。

**2. 回滚后从小处重新尝试。**第 3 期的保存点在这里派上用场。如果修改覆盖修改，导致代码变得像补丁拼成的旧衣服，就回到最后一次提交，让 AI 把刚才失败的修改拆成更小的单位逐个执行。

**3. 先让它调查原因。**不要说“帮我修好”，改成“先别修，请找出这个错误的 3 个可能原因，并告诉我分别如何验证”。让 AI 修复时，它会急着修改；让它调查时，反而会出奇地冷静。缩小原因范围后再让它修复，命中率会大幅提高。

**4. 搜索错误原文。**把错误信息的第一行原样输入搜索框。全世界很可能已经有人遇到并解决过这个问题。把搜索结果链接交给 AI，再说“帮我确认这个解决方案是否适合我的情况”，这种组合也很有效。

总结

• 错误信息就是自白书。只要找到“发生了什么（第一行）+ 在哪里（文件:行号）”，就解决了一半问题。
• 错误存在于两个地方：浏览器控制台（界面问题）和服务器日志（保存、登录、支付问题）。两边都打开看看。
• 传给 AI 时，把这三项一起提供：完整错误、发生时你正在做什么，以及在哪里找到的。
• AI 反复兜圈时，不要增加尝试次数，改变局面：新对话、回滚后拆小、先调查、搜索原文。

下一期将介绍一个看起来像谜团的经典问题：“昨天还好好的，今天却不行了。”即使没有改动代码，为什么会突然失效？我们会按顺序排查可能的犯人。

延伸阅读

• [Vibe Coder #8]接收用户前的 6 项安全检查清单