用 Codex 修改项目时，经常会出现一种很典型的情况：

代码看起来已经改好了，但真正运行项目时却报错。

比如：

• Codex提示任务已经完成，项目却启动失败；
• 新功能代码已经生成，但提示缺少依赖；
• 本地可以运行，换一个终端就报错；
• 修改一个文件后，测试突然大面积失败；
• 代码语法看起来没问题，却一直提示环境变量不存在；
• Codex反复修改同一个错误，始终解决不了。

这种情况下，问题往往已经不只是“代码写得对不对”。

因为一个项目真正能够运行，需要同时满足：

代码 + 依赖 + 环境 + 配置 + 测试

其中任何一环出现问题，都可能导致最终运行失败。

一、先不要继续改代码，先拿到真正的报错

这是最重要的一步。

很多人看到项目运行失败以后，会直接告诉 Codex：

项目还是跑不起来，继续修。

这个信息其实太少了。

Codex只能根据已有代码猜原因，很容易修改错地方。

更好的方法是先执行项目，然后把真正的错误信息交给它。

例如：

npm run dev

或者：

npm test

运行失败以后，让 Codex重点分析：

请先不要修改代码。

分析下面这段完整报错，
判断问题属于代码、依赖、环境变量还是配置，
然后告诉我最可能的原因。

先定位，再修改。

通常比让它直接“继续修”有效很多。

二、最常见的问题之一：依赖没有安装

假设 Codex为了实现一个新功能，在代码中加入：

import axios from "axios";

代码本身可能没有问题。

但是你的项目并没有安装：

axios

运行时就可能直接报模块不存在。

类似问题在 Python 项目里也非常常见。

例如 Codex加入：

import pandas

但当前环境没有安装 pandas。

这时候真正要解决的并不是重写代码，而是检查项目依赖。

可以让 Codex先查看：

package.json

Python项目则查看：

requirements.txt
pyproject.toml

然后确认：

代码使用的依赖，是否真的已经出现在项目依赖配置中。

如果没有，再决定是否需要安装。

三、检查依赖版本，而不只是“有没有安装”

还有一种更隐蔽的问题：

依赖已经安装，但版本不兼容。

例如 Codex参考了某个新版库的 API：

某个函数在 v5 中存在

但你的项目实际上还停留在：

v3

于是代码看起来完全合理，运行起来却报：

function is not defined

或者：

module has no exported member

这时候不要立刻升级所有依赖。

先让 Codex检查：

1. 当前实际安装版本；
2. package.json 或其他依赖文件声明的版本；
3. 新代码使用的是哪个版本的 API；
4. 项目其他代码是否依赖旧版本。

很多老项目最怕的就是：

为了修一个小问题，把整个依赖树升级了。

最后原来的错误没解决，又产生了一批新的兼容问题。

四、代码没错，也可能是环境变量缺失

这是 AI 编程里非常高频的报错来源。

比如代码里出现：

OPENAI_API_KEY
DATABASE_URL
JWT_SECRET

Codex能够理解这些变量应该怎么使用，但它不代表你的本地环境里真的存在这些值。

于是可能出现：

undefined

或者：

environment variable not found

这时候应该检查：

.env
.env.local
.env.example

以及启动脚本有没有正确加载环境变量。

比较稳妥的做法是让 Codex：

检查当前代码依赖哪些环境变量，只列出变量名称，不要输出或读取真实密钥。

这样既能够排查问题，也能避免不必要地暴露敏感信息。

五、“能编译”不等于“能运行”

很多项目至少有三层验证：

第一层：语法是否正确。

第二层：能否成功构建。

第三层：业务逻辑是否正常。

例如 TypeScript 编译通过，只说明类型和语法没有明显问题。

它并不能证明：

数据库能连接；

接口返回正确；

登录流程正常；

文件路径正确；

真实业务没有异常。

所以 Codex改完代码以后，不要只看它说：

Implementation completed.

真正有意义的是让它执行项目已有的验证流程。

例如：

npm run lint
npm run build
npm test

项目有什么测试，就优先使用什么测试。

六、测试失败时，不要让Codex一次修改所有文件

假设修改以后出现：

12 tests failed

很多人的第一反应是：

把这些全部修好。

大型项目里这样做风险比较大。

因为12个测试失败，可能实际上只有一个根因。

例如你修改了一个公共函数，导致下游12个测试同时失败。

如果让 Codex逐个改测试，很可能把原本正确的测试一起改坏。

更合理的方式是：

分析全部失败测试，
先找它们是否存在共同根因，
暂时不要修改测试文件。

先找最上游的问题。

解决一个根因以后，可能10个测试会自动恢复。

七、特别注意“为了通过测试而修改测试”

这是使用 AI 编程时值得注意的一点。

假设原本有一个测试：

用户密码错误时应该返回401

Codex修改登录逻辑以后，结果返回了200。

测试失败。

正确做法通常应该是检查登录逻辑为什么错了。

但如果直接要求：

把测试修到通过。

AI有可能把预期结果从：

401

改成：

200

测试确实绿了。

但业务逻辑已经错了。

因此最好明确告诉 Codex：

优先修复实现代码，不要为了通过测试而改变原有测试预期，除非能够证明测试本身已经过时。

这一条非常实用。

八、环境不一致也会造成“Codex明明修好了”

还有一种情况是：

Codex所在环境与真正运行项目的环境不完全一致。

例如：

本地：Node.js 20
服务器：Node.js 18

或者：

本地：Python 3.12
线上：Python 3.10

甚至开发电脑是 Windows，部署环境却是 Linux。

这种情况下：

本地测试通过，并不一定代表部署以后还能正常运行。

所以涉及真实项目时，最好确认：

• Node/Python版本；
• 操作系统；
• 包管理器版本；
• 数据库版本；
• 构建环境；
• Docker配置。

特别是出现：

“我这里正常，服务器报错”

这种情况时，第一反应应该是比较环境，而不是重新改业务代码。

九、推荐一套Codex修改后的检查流程

以后让 Codex改完一个功能，可以固定按照下面的顺序走：

第一步：检查实际修改了哪些文件。

先确认修改范围有没有超出预期。

第二步：检查依赖变化。

有没有新增包、升级包或者修改锁文件。

第三步：检查环境变量。

新功能有没有新增配置要求。

第四步：执行Lint或静态检查。

先处理最基础的语法和类型问题。

第五步：执行构建。

确认项目能够正常编译。

第六步：运行相关测试。

不要一开始就跑所有测试，可以先跑和本次修改相关的测试。

第七步：再运行完整测试。

确认修改没有影响其他模块。

这套流程比：

“写完代码 → 直接启动 → 报错 → 继续让AI乱改”

稳定得多。

最后

Codex把代码写出来，只代表整个开发任务完成了一部分。

真正可靠的修改应该形成一个闭环：

理解需求 → 修改代码 → 检查依赖 → 验证环境 → 执行测试 → 根据真实报错继续修复。

如果Codex改完代码以后运行失败，不要第一时间怀疑它“代码能力不行”。

先判断问题到底属于：

代码、依赖、环境变量、配置还是测试。

把故障范围缩小以后，再让 Codex继续处理，成功率通常会高很多。

持续更新 Codex、大模型开发与 AI 编程实战内容，整理 ChatGPT Plus/Pro、AI会员订阅及常见使用问题。更多深度内容，欢迎搜索关注「仙逆GPT」。