AI写的代码总编造不存在的函数，多数时候不是你的环境配错了，而是模型在按命名规律猜接口：它写代码时并没有实时去翻你用的那个库的文档，某个方法名听起来合理，就顺手写出来了，语气还和写真接口一模一样。
处理顺序别反。先把代码原样跑一遍，拿到真实报错；再去官方文档逐个核对函数名和参数；确认是编造的，把报错原文和文档里的真实签名一起贴回去让它重写。适合正在用 ChatGPT、Claude、Cursor 这类工具写代码的人，尤其是照着 AI 给的代码调了半天环境的：先怀疑接口，再怀疑自己。
为什么它编得一本正经
模型生成代码靠的是文字接龙的统计规律，不是查询。它见过大量真实代码，知道函数名通常长什么样：读写文件爱用 read、load、fetch，处理文本爱用 parse、extract、clean。需求一具体到某个小众库、某个新版本，它手边没有可靠记忆，就会按这套命名习惯现编一个，拼写工整、参数齐全，看起来比真接口还标准。
编造一般有三种形态。第一种是整个函数或方法不存在，调用就报 AttributeError 或 ImportError。第二种是函数真实存在，但参数和返回值是另一个版本的，甚至是另一个语言同名库的用法，代码能跑一半才出错，最耗时间。第三种是连 import 的包名都是编的：2025 年 USENIX Security 的一项研究测了 16 个代码模型生成的 57.6 万份样本，约 19.7% 推荐的软件包在仓库里根本不存在。更麻烦的是，已经有人专门抢注这类被反复编造的包名并塞入恶意代码，等开发者照着 AI 的话去安装。所以陌生包名不要直接装，先去 PyPI、npm 这类官方仓库页核对发布时间、维护者和下载量，刚注册、没人维护的同名包尤其要绕开。
先跑再查：三步确认它是不是编的
第一步，原样跑一遍再说。报错类型本身就是线索：提示模块或属性不存在，基本就是接口不存在；提示参数个数不对，多半是版本对不上或者参数是编的。很多人第一反应是升级、重装、换环境，折腾半天，其实问题在那一行代码本身。
第二步，去官方文档和源码里搜这个函数名。文档站内搜索不到、IDE 里点不进定义、自动补全列表里没有，三个信号占两个，就可以按不存在处理。注意别拿博客和问答帖子当判据：现在不少技术帖本身就是 AI 生成的，可能和你手里的代码编了同款错误，互相印证反而更误事。实在拿不准，把项目里同类文件的既有写法翻出来对照，项目里从没出现过的调用方式，先默认可疑。
第三步，让它当场自证。要求它逐个说明用到的外部函数分别出自哪个库、哪个版本、文档哪一页，并给出处链接。真接口它通常能说个大概，编造的则会含糊其辞，或者给一个打不开、对不上内容的链接。这一步适合在代码还没跑之前做，能提前拦下一部分。
确认是编造的，这样让它改
把完整报错原文贴回去，不要只写一句“运行报错了”。报错里包含它编的函数名和调用位置，模型看到原文，修正的命中率比听你转述高得多。
同时把官方文档里真实的函数签名贴给它，明确要求只用这些接口重写，其他写法一律不许自创。再补一句约束：优先用标准库和项目已经装好的依赖实现，不许新增没核实过的包。很多编造来自它想调用一个“更方便”的库，你把依赖边界划死，它就只能回到真实接口上想办法。
改完必须再跑一遍。AI 修这类问题时可能二次编造：换个新函数名把报错糊过去。所以每轮都以运行结果验收，跑通、输出对得上预期，才算这一段代码交付。连续两轮还在编，就换思路：让它先只写实现思路和要用的函数清单，你逐个核对完再让它写代码。
下次提问，先交代清三件事
把编造挡在生成之前，比事后排查省事。提问时先给版本：编程语言版本、用到的库和版本号，最好附上项目依赖清单的相关片段。版本一明确，它套用其他版本接口的概率明显下降。
再给它项目里的真实样本：贴一小段项目中已有的同类代码，让它模仿现成的调用风格和导入方式。它有了可参照的真代码，就不容易另起炉灶编接口。
最后把规则说在前面：不确定的接口先停下来问，不要编造函数名；用到的每个外部函数先列成清单。任务大时拆成小步，每一步先跑通再往下写。把 AI 写的代码当成“出活快、但必须验收的草稿”，而不是能直接上线的成品，编造函数就只是一个会被流程拦下的小问题，而不是让你怀疑自己环境的那种坑。
