AI 生成的代码有 Bug 怎么办？我总结了 5 个排查技巧（附真实案例）

上一篇我让 5 款 AI 独立写了同一个 Vue3 项目，结果没有一款生成的代码是「零问题」的。这篇专门聊：AI 给你的代码跑不起来或者逻辑有问题，该怎么排查？5 个技巧，配真实案例，学完能少走一半弯路。

一、先搞清楚：AI 代码为什么会有 Bug？

AI 写代码出 Bug，不是「它不聪明」，而是有几个结构性原因：

原因 1：知识有截止日期 AI 的训练数据截止在某个时间点。 Vue 3.4 的新 API、Element Plus 2.x 的 breaking change—— 如果这些在截止日期之后发版，AI 可能不知道。 原因 2：不知道你的项目上下文 AI 看不到你完整的项目，它只知道你告诉它的部分。 你 Pinia store 里的状态它不知道，你自定义的 hooks 它看不到， 你的路由结构它不清楚——它写的代码，当然可能和你现有代码对不上。 原因 3：「幻觉式自信」 AI 不会说「我不确定」，它会给你一个看起来完整的答案。 即使它其实不知道，也会生成一段能过代码检查、但逻辑有问题的代码。 原因 4：跨文件一致性差 让 AI 一次性生成整个项目，不同文件之间可能互不一致—— A 文件里 store 的变量叫 userInfo，B 文件里却访问 user。

搞清楚了原因，排查就有方向了。

二、5 个排查技巧（真实案例 + 操作步骤）

技巧一：先跑起来，看错误栈，别乱猜

很多人拿到 AI 的代码，看一眼感觉哪里不对，就开始改。

这是最低效的做法。

正确的姿势：

第一步：直接 npm run dev 第二步：看终端/浏览器 Console 的报错 第三步：把完整的报错信息喂给 AI 第四步：AI 给方案，你判断后执行

听起来简单，但关键在第三步——要把完整报错给 AI，不是复述，是原文复制。

真实案例：

上一篇测试中，Cursor 生成的代码跑起来后有 TypeScript 报错：

报错原文： Type '{ id: number; title: string; status: string; }' is not assignable to type 'Article'. Property 'createdAt' is missing in type '{ id: number; title: string; status: string; }' but required in type 'Article'.

看起来很复杂，但把这段原文丢给 AI：

我的提示词： "帮我看这个 TypeScript 报错，并给出修复方案： [粘贴完整报错]" AI 的回答（3 秒）： "你的 Article 类型定义了 createdAt 字段，但你在创建测试数据时 漏掉了这个字段。有两种修复方案： 1. 把 createdAt 改为可选字段：createdAt?: string 2. 补全测试数据：加上 createdAt: '2024-01-01'"

两分钟解决。关键是给了完整的错误原文，AI 不需要猜，直接给方案。

技巧二：版本问题单独处理，不要让 AI 猜

这是 AI 代码最常见的 Bug 类型，而且最难靠 AI 自己修。

AI 不知道你项目里装的依赖版本。它只能猜，猜出来的可能是旧版 API。

识别版本 Bug 的特征：

特征 1：方法名报 undefined，但 API 文档上明明存在 → 可能是新版把这个方法移除或改名了 特征 2：Import 某个组件/函数报错，但名字拼写没问题 → 可能是新版调整了导出方式 特征 3：类型报错说「属性不存在」，但文档上有 → 可能新版修改了类型定义 特征 4：某段代码以前能用，升级依赖后报错 → 典型的 breaking change

正确的处理方式：

不要只告诉 AI「这段代码报错了」，要连同版本号一起告诉它：

❌ 低效的提示词： "这段 Element Plus 代码报错了，帮我修" ✅ 高效的提示词： "我用的是 Element Plus 2.7.3 + Vue 3.4.21， 下面这段代码报了 xxx 错误，请按照 Element Plus 2.x 的语法帮我修： [代码]"

真实案例（通义灵码的坑）：

通义生成的代码里，路由跳转写的是：

// 通义生成的（Vue Router 3 写法）this.$router.push('/dashboard')

但我用的是 Vue Router 4，正确写法是：

// Vue Router 4 写法import{useRouter}from'vue-router'constrouter=useRouter()router.push('/dashboard')

遇到这种问题，直接告诉 AI：

"这段代码是 Vue Router 3 的写法，我用的是 Vue Router 4， 请用 Vue Router 4 的 Composition API 写法重写"

技巧三：「分段验证」，不要一次生成完再测

这个技巧可以把调试时间减少 70%。

反例（大多数人的做法）：

1. 让 AI 生成整个登录模块（前端 + 接口 + 路由 + 权限） 2. 全部粘贴进项目 3. 跑起来，一片报错 4. 不知道哪里出了问题 5. 花 1 小时挨个排查

正例（分段验证）：

阶段 1：只生成登录表单 UI → 跑起来看页面 ✅ 阶段 2：加上 Form 验证逻辑 → 提交触发验证 ✅ 阶段 3：加上接口调用（先用 Mock 数据）→ 验证流程 ✅ 阶段 4：换成真实接口 → 测试登录成功和失败 ✅ 阶段 5：加上 Token 存储和路由跳转 → 完整流程 ✅

每一阶段跑通了再进下一阶段。哪里报错，就是哪里的问题，范围精确。

这个方法听起来麻烦，实际上反而更快。5 个阶段每个 5 分钟，25 分钟搞定；一次性生成然后排查，可能要 60 分钟。

技巧四：「反向提问」让 AI 给自己挑 Bug

这是我用起来效果最惊喜的一个技巧。

生成代码之后，不要直接问「这段代码有什么问题」（AI 会倾向于说「这段代码看起来没有问题」），而是用更强硬的措辞：

✅ 效果更好的提示词： "请假设这段代码存在 Bug，从以下几个角度主动找问题： 1. 边界条件（空值、空数组、极端参数） 2. 异步/竞态条件（Promise 没有 catch、多个请求同时发） 3. 内存泄漏（组件卸载时没有清除定时器/订阅） 4. 类型安全（是否有隐式 any、类型断言不当） 5. 错误处理（接口失败时用户看到的是什么） 代码如下：[粘贴代码]"

真实案例：

我让 Claude 审查一段它自己生成的文章列表代码：

// AI 自己生成的代码constfetchArticles=async()=>{loading.value=trueconstres=awaitgetArticleList(page.value,pageSize.value)articles.value=res.data total.value=res.total loading.value=false}

用反向提问之后，AI 自己发现了两个问题：

问题 1：没有 try/catch 如果 getArticleList 请求失败，loading 会永远是 true， 用户看到一直在转的 loading 图标。 问题 2：快速翻页的竞态问题 用户快速点击第 1、2、3 页，三个请求同时发出。 如果第 3 页的请求先回来，然后第 1 页的回来了， 页面会显示第 1 页的数据，但分页器显示第 3 页——数据对不上。

两个真实存在的、会影响生产体验的 Bug。用「假设存在 Bug」而不是「检查是否有 Bug」这个措辞，效果差很多。

修复后的代码：

constfetchArticles=async()=>{constcurrentPage=page.value// 记录发起请求时的页码loading.value=truetry{constres=awaitgetArticleList(currentPage,pageSize.value)// 只有当前页码和请求发起时一致，才更新数据if(currentPage===page.value){articles.value=res.data total.value=res.total}}catch(error){ElMessage.error('获取文章列表失败，请稍后重试')}finally{loading.value=false}}

技巧五：学会区分「AI 的问题」和「你的问题」

这条是最重要的一条，很多人用 AI 写代码总觉得「AI 不行」，实际上有一半问题是自己的提示词有问题。

分辨方法：看报错的性质

如果报错是「语法错误」或「API 不存在」 → 通常是 AI 的问题（版本问题、幻觉） → 解决方案：把版本信息加到提示词里，或者换更新的模型 如果报错是「类型不匹配」或「接口返回结构和预期不符」 → 通常是你的问题（你没告诉 AI 你的接口长什么样） → 解决方案：把你的接口文档/类型定义给 AI 如果报错是「undefined」或「null」相关 → 大概率是「AI 不知道你的数据流」 → 解决方案：把调用链、数据结构给 AI 如果功能逻辑不对（跑起来没报错，但行为不符合预期） → 大概率是你的提示词不够精确 → 解决方案：把「预期的行为」描述得更具体

真实案例——我自己的教训：

我让 ChatGPT 生成一个「删除文章后自动跳回列表首页」的逻辑。它生成的代码，删除后确实跳转了，但跳到了/articles而不是我项目里的/content/articles。

一开始我以为是 AI 的 Bug。后来才发现——我的提示词根本没有提到路由路径，它只能猜，猜了一个最通用的路径。

我在提示词里补上了：

"删除后跳转到文章列表页，我项目的路由路径是 /content/articles"

重新生成，一次就对了。

这不是 AI 的 Bug，是我给的信息不够。

三、一个实用的调试 SOP（标准操作流程）

把上面五个技巧整合成一个流程图，方便收藏：

拿到 AI 代码 │ ▼ 直接跑，看报错（技巧一） │ ├── 有报错？ │ │ │ ├── 是版本/API 问题？→ 在提示词里补充版本号，重新问（技巧二） │ │ │ └── 是类型/逻辑问题？→ 给 AI 完整错误栈 + 上下文（技巧一） │ └── 没报错？ │ ▼ 分段验证每个功能模块（技巧三） │ ▼ 用「反向提问」让 AI 挑自己的 Bug（技巧四） │ ▼ 如果还有问题，判断是 AI 的锅还是提示词的锅（技巧五） │ ▼ ✅ 搞定，上线

四、额外送你一个「万能报错提示词」

把这个模板收藏起来，下次遇到 AI 代码报错直接套用：

我在使用 [项目技术栈，如 Vue3 + Vite + TypeScript] 开发时遇到报错。 报错信息（完整复制）： [粘贴完整报错] 出错的代码： [粘贴出错的代码片段] 上下文信息： - 这段代码的作用：[简短描述功能] - 依赖版本：[如 vue: 3.4.21, vue-router: 4.3.0] - 调用时机：[如 组件挂载时 / 用户点击按钮时] 请分析报错原因并给出修复方案。如果有多种修复方案，请说明各自的优缺点。

这个模板能覆盖 90% 的 AI 代码报错场景。信息越完整，AI 给出的答案越精准。

五、写在最后

用 AI 写代码有一段时间了，我最深的感受是：

AI 不会让你不犯错，但它能帮你更快地找到错误。

一个熟练使用 AI 的开发者，不是那个把 AI 的代码直接 Ctrl+C / Ctrl+V 的人。而是那个能快速判断「这里可能有问题」、能精准描述上下文、能看懂报错并向 AI 问到正确答案的人。

排查 Bug 这件事，永远需要你自己有基本的判断力。AI 是你的搭档，不是你的替代品。

下一篇预告

《AI 辅助 Code Review：我用了这套提示词，每次发现至少 3 个隐患》

AI 不只能写代码，它做 Code Review 的效果出乎意料地好。下一篇分享我实测的 Code Review 提示词套装，以及它发现了哪些人工 Review 容易忽视的问题。

觉得有帮助？欢迎分享给需要的朋友。你遇到过哪些 AI 代码的 Bug？欢迎留言分享你的排查思路。