摘要

ChatGPT和Codex生成代码后，不建议未经检查就直接运行或提交。本文整理依赖版本、接口真实性、异常处理、安全配置和测试验证5个重点，帮助减少代码报错、安全隐患和上线返工。

使用ChatGPT或Codex写代码，最大的优势是速度快。

以前需要半小时完成的接口、脚本或页面，现在几分钟就能生成。但代码能够生成，不代表可以不检查就直接运行，更不代表可以直接合并到正式项目。

OpenAI对Codex的定位也包括生成代码、修复问题和提出待审查的Pull Request，而不是完全跳过开发者审查。

生成代码后，至少要人工检查下面5个地方。

一、依赖和版本是否匹配

GPT生成代码时，通常会根据常见写法选择依赖库，但它不一定知道当前项目实际使用的版本。

例如，项目使用的是旧版本框架，生成的代码却调用了新版本才提供的方法，就可能出现：

Module not found 方法不存在 参数类型不匹配 依赖版本冲突

检查时重点确认：

• 项目使用的语言版本；
• 框架和组件库版本；
• 新代码是否增加了依赖；
• 导入路径是否正确；
• 安装命令是否适合当前环境。

不要看到代码语法正确，就默认它能在现有项目中运行。

如果需要新增依赖，还要确认这个依赖是否真的必要。为了实现一个简单功能，引入体积较大的第三方库，可能反而增加维护成本。

二、接口、方法和字段是否真实存在

GPT生成的代码看起来通常比较完整，但其中可能包含项目里不存在的接口、函数或数据字段。

例如：

const result = await userService.getCurrentUser();

代码本身没有明显语法问题，但当前项目可能根本没有getCurrentUser这个方法。

类似问题还包括：

• 调用了不存在的后端接口；
• 使用了错误的请求地址；
• 数据字段名称与接口返回不一致；
• 引用了不存在的组件；
• 数据库表名或字段名写错；
• 把示例代码当成真实业务代码。

运行前应结合项目实际代码进行确认，不要只看生成结果是否“像真的”。

比较稳妥的方式是先让GPT分析现有接口和目录，再根据真实内容生成修改方案。

三、是否泄露密钥和敏感配置

有些生成代码为了方便演示，会直接在代码中填写：

• API Key；
• 数据库密码；
• Token；
• 云服务访问密钥；
• 测试账号；
• 内部接口地址。

例如：

const apiKey = "sk-xxxxxxxx";

这种写法在本地测试时可能可以运行，但一旦提交到公开仓库，就可能造成密钥泄露。

OWASP建议对密钥进行统一存储、授权、审计和轮换，避免密钥直接泄露在应用代码或共享环境中。

检查代码时，需要确认：

• 密钥是否写进源代码；
• 环境变量文件是否被提交；
• 日志是否输出了Token；
• 接口返回是否包含敏感信息；
• 示例账号是否仍然有效；
• 配置文件是否进入Git记录。

即使发现后立即删除，密钥也可能已经保留在Git历史记录中。遇到这种情况，应及时更换密钥，而不只是删除代码中的字符串。

四、异常处理和权限判断是否完整

GPT生成的代码往往更关注“正常情况下如何运行”，但真实项目还要考虑失败情况。

例如调用接口时，可能遇到：

• 网络超时；
• 返回空数据；
• 参数格式错误；
• 用户没有权限；
• 数据库连接失败；
• 文件不存在；
• 第三方服务不可用。

如果代码只处理成功结果，没有异常处理，一旦环境发生变化，程序可能直接崩溃。

此外，还要检查权限边界。

例如一个删除接口能够正常执行，并不代表所有登录用户都应该拥有删除权限。权限验证必须放在可信的服务端逻辑中，不能只依赖前端隐藏按钮。

OWASP 2025版常见应用安全风险包括访问控制失效、安全配置错误、供应链问题、注入、身份验证失败和异常处理不当等。

因此，人工检查时至少要覆盖：

1. 参数为空时怎么处理；
2. 接口失败时是否有提示；
3. 用户是否拥有操作权限；
4. 输入内容是否经过校验；
5. 错误日志是否包含足够信息；
6. 异常信息是否泄露系统细节。

五、测试通过后再提交代码

代码能够启动，只能说明最基础的语法和运行环境没有立即报错，并不能说明功能完全正确。

提交前建议完成以下检查：

git status git diff

先确认修改了哪些文件，再检查是否出现：

• 修改范围超出任务要求；
• 原有代码被意外删除；
• 整个文件被重新格式化；
• 配置文件被改变；
• 自动生成文件被提交；
• 添加了不需要的依赖。

然后再运行项目已有的检查命令，例如：

npm run lint npm run test npm run build

具体命令应以当前项目为准。

GitHub的Pull Request审查机制允许审查者在合并前查看改动、提出修改意见、批准或拒绝代码，是团队控制代码质量的重要环节。

OWASP也指出，人工安全代码审查可以发现自动化工具容易遗漏的业务逻辑、数据流和实现问题。

因此，即使代码已经经过AI检查，也不能完全代替开发者确认。

一个简单的检查顺序

以后使用ChatGPT或Codex生成代码，可以按照下面的顺序检查：

第一步，确认只修改了指定目录和文件。

第二步，检查依赖、版本和导入路径。

第三步，确认接口、函数和字段真实存在。

第四步，检查密钥、权限、输入校验和异常处理。

第五步，运行测试、构建和代码差异检查。

如果是登录、支付、用户数据、文件上传和后台权限等功能，还应进行更严格的安全测试。

总结

ChatGPT生成的代码并不是不能使用，而是不能跳过检查直接使用。

提交代码前，至少要检查以下5项：

1. 依赖和版本是否匹配；
2. 接口、方法和字段是否真实存在；
3. 是否泄露密钥和敏感配置；
4. 异常处理和权限判断是否完整；
5. 是否经过测试、构建和代码审查。

AI可以提高写代码的速度，但最终决定代码能否进入真实项目的，仍然是测试结果、项目规范和人工审查。