Codex为什么会写出不存在的接口？这5类代码幻觉最常见
摘要：Codex可以读取项目、修改文件和运行代码，但仍可能生成不存在的接口、错误依赖或不符合业务规则的实现。本文整理5类常见代码幻觉，以及开发者应该如何检查。
使用Codex修改项目时，有时会遇到一种情况：
代码结构看起来完整，函数名也很专业，但实际运行后才发现，某个接口、配置项或依赖根本不存在。
这类问题通常被称为“代码幻觉”。
OpenAI也明确指出，即使模型能力不断提升，语言模型仍可能自信地生成错误内容，因此开发者不能把生成结果直接当成事实。
一、虚构不存在的接口
最常见的问题，是Codex根据函数名称和项目结构，推测出一个“看起来应该存在”的接口。
例如：
- 调用了项目中没有的方法；
- 使用了后端并未提供的接口；
- 猜错请求参数；
- 编造返回字段；
- 混用旧版本接口。
如果项目资料不完整，模型更容易根据常见写法自行补全。
处理接口任务时，最好同时提供接口文档、实际返回数据和已有调用代码。
二、使用错误版本的依赖
第三方SDK、框架和组件库更新较快。
Codex可能生成：
- 已经废弃的方法；
- 新版本才支持的参数；
- 旧版本的初始化方式；
- 不存在的配置项；
- 不兼容的依赖组合。
代码看起来没有明显语法问题，但安装或运行时会直接报错。
因此，使用第三方依赖时，要明确告诉Codex：
- 当前版本号；
- 包管理文件；
- 官方文档范围；
- 是否允许升级依赖。
三、误判项目已有能力
Codex读取项目后，可能看到相似名称，就判断某项能力已经存在。
例如项目里有一个普通用户查询函数，它可能误以为已经实现管理员权限查询；看到日志模块，就默认已经支持审计日志。
这会导致它调用错误模块，或者跳过本应补充的逻辑。
OpenAI的Codex最佳实践建议，复杂任务应先让Codex分析项目、确认修改计划，再开始执行，而不是直接要求它完成大范围修改。
四、自行补全业务规则
技术代码可以根据通用模式生成，但真实业务规则通常具有很强的项目特殊性。
例如：
- 哪种订单允许退款；
- 哪些用户可以修改数据；
- 库存什么时候扣减；
- 审批失败后如何回退；
- 重复提交如何处理。
如果没有提供完整规则，Codex可能按照常见系统经验自行补全。
生成出来的代码可能很规范，但业务逻辑完全不符合实际要求。
因此，涉及状态流转、权限和资金的数据，必须由业务负责人确认。
五、修复一个问题却制造新问题
Codex有时会为了修复当前报错，扩大修改范围。
例如：
- 改变公共函数参数；
- 删除原有兼容逻辑；
- 新增不必要的依赖；
- 重写多个调用文件；
- 修改原本正常的配置。
所以不能只看“报错是否消失”，还要检查是否影响其他功能。
Codex桌面应用提供代码差异审查功能，OpenAI也建议开发者在Review面板中检查修改，并在必要时手动调整。
怎么降低代码幻觉？
可以按下面流程使用Codex：
- 先让它分析项目，不要直接改代码；
- 明确允许修改的文件；
- 提供依赖版本和接口文档；
- 要求它列出不确定的信息；
- 修改后查看完整Diff；
- 运行测试、构建和静态检查；
- 人工确认后再合并。
涉及网络访问、命令执行和文件修改时，还应合理配置沙箱和人工审批，避免智能体执行超出预期的操作。
总结
Codex写出不存在的接口，通常不是单纯“模型变笨了”，而是项目上下文、版本信息或业务规则不完整。
最常见的5类问题是：
- 虚构接口和字段；
- 使用错误版本依赖；
- 误判项目已有能力；
- 自行补全业务规则；
- 修复旧问题时引入新问题。
Codex适合提高代码修改效率，但不能替代文档、测试和人工Review。
越是接近真实业务和线上环境，验证就越重要。