AI 生成的代码跑不起来，多数情况下模型能力够用，问题出在排查顺序上。拿到一段报错就慌着重写、乱改，反而把原本的小问题搅成大问题。按固定顺序走四步——读完整报错、核对运行环境、最小化复现、带着上下文追问——绝大多数报错能在十几分钟内定位。先把顺序立住，再逐个展开。
先分清环境错还是代码错
报错分两大类，处理路径完全不同。环境类报错的典型特征是提示找不到模块、命令不存在、版本不兼容，比如 ModuleNotFoundError、pip 装完仍然 import 失败，这类问题出在运行条件上，代码本身可能没有错。代码类报错则直接指向语法或逻辑，比如语法错误、变量未定义、运算结果与预期不符。动手前先做这个分类：把报错关键词输进去搜一眼，判断它是环境问题还是代码问题，分类对了，后面三步才不会白花力气。新手最常见的浪费，就是拿环境问题当代码问题反复改。
| 报错类别 | 典型提示 | 先做什么 |
|---|---|---|
| 环境类 | ModuleNotFoundError、命令不存在、版本不兼容 | 查运行条件，别急着改代码 |
| 环境类（依赖） | pip 装完仍然 import 失败 | 核对包版本与虚拟环境 |
| 代码类 | 语法错误、变量未定义 | 读调用栈，定位到自己那个文件 |
| 代码类（逻辑） | 运算结果与预期不符 | 裁剪复现，锁定到具体行 |
第一步：把报错读完整再动手
报错信息是按倒序排的，最后一行是错误类型和一句话说明，往上是调用栈，标明错误发生时程序经过了哪些文件和行号。很多人只看第一行，或者只复制半截去搜索，丢掉了最关键的信息。正确做法是从最后一行往上读，重点找指向你自己代码文件的那一行，那才是出问题的入口。复制报错去提问时，把完整的错误类型、调用栈、相关代码段一起带上。报错信息里的文件路径、行号、变量名都是线索，删掉任何一项，帮你判断的人都得多问一轮。
第二步：核对运行环境与依赖版本
环境类报错十有八九出在三处：语言版本、依赖包版本、操作系统差异。AI 写代码时通常按某个默认版本或者它训练数据里的常见版本来写，而你本地的版本可能不同，同名函数的行为已经变了。假设一段代码用到了某个库 2.0 版本的写法，你本地装的还是 1.x，运行必然报错，这种错代码里看不出来，只能靠核对版本。把 pip list 的输出或者项目的依赖清单跟 AI 交代清楚，让它按你的环境写；更省事的做法是要求它先列依赖清单再写代码。装依赖时优先用虚拟环境，避免不同项目之间互相污染。
第三步：最小化复现定位问题行
报错很长的代码，不要整段盯着看，用裁剪法缩小范围：注释掉一半跑一次，能跑就说明问题在注释掉的那半；再把可疑的那半裁一半，反复对半切，几轮下来就能锁定具体的函数甚至具体的行。裁剪过程中还可以把读文件、联网请求这类外部输入换成写死的示例数据，排除环境干扰。裁到最短仍然复现，问题在核心逻辑；裁完就正常，问题在被裁掉的那部分。这个方法比逐行通读快得多，也是很多有经验的开发者排查的第一反应。
第四步：带着上下文追问 AI
轮到追问时，一次给全三样东西：完整报错信息、裁剪出来的最小复现代码、你已经试过哪些办法。挤牙膏式的一问一答，AI 只能反复猜。工具层面也有省力选项，像 CodeBuddy 这类直接接入工作区的编程助手，能读到项目里的其他文件，追问时不用粘贴上下文，给出的修改也会考虑整个工程结构，比单聊窗口里只看一段代码更贴合实际。追问两轮如果报错依旧，别继续打补丁，直接让它换个思路重写这个函数，或者把问题拆小再问。排查结束后，把这次的报错和修法记进自己的笔记，同类问题第二次出现时基本不用查。
延伸阅读：复制 AI 代码前看四处、编程工具按规模怎么选、AI 编程能到什么程度。
报错排查的四步固定链
- 从最后一行往上读，找到自己的文件
- 版本、依赖、系统三处逐一核对
- 对半注释跑几次，锁定问题行
- 追问给全报错、最小复现、已试办法
最容易被跳过的是核对版本，代码看着没错时问题往往在环境。
排查 AI 代码报错时最容易跳过哪一步？
- 报错提示文件不存在，可我确认文件就在那里，问题出在哪？：多数是相对路径与工作目录不一致，代码从哪个目录启动，相对路径就从哪里算起。把文件改成绝对路径跑一次验证，确认后再决定怎么改回相对路径。
- 让 AI 改了三四轮还是同一个报错，还要继续问吗？：先停。同样的错误反复出现，说明它掌握的信息不够或者一直在猜，把完整报错、依赖版本和已试过的修改一次给全；仍然无效就换重写，别在补丁上叠加补丁。
- 新手应该先练熟哪类报错？：优先练环境与依赖类，这类出现频率高、修法固定，积累十来个典型处理之后，排查速度会有明显提升，代码逻辑类的问题反而可以在项目中慢慢补。
