很多开发者会使用 Codex 修复报错、重构模块和补充新功能。

在任务比较简单时，Codex 往往可以快速给出可运行的修改。但项目规模扩大后，开发者可能遇到一种常见情况：

• 原来的报错修复了，另一个页面却出现异常；

• 登录模块可以运行，退出登录却失效；

• 单个测试通过，完整测试集出现失败；

• 为了优化一个函数，公共组件行为发生变化；

• Codex 修改了任务范围之外的文件；

• 代码看起来更简洁，却遗漏了边界条件；

• 提交后才发现配置、类型或接口字段被一起改动。

这类问题并不一定说明 Codex 不能用于正式项目，而是 AI 生成代码仍然需要经过审查。

真正稳定的开发流程，不是让 Codex 修改完成后直接提交，而是建立一套“分析、修改、审查、测试、提交”的完整闭环。

一、为什么修复一个问题会引入另一个问题？

开发者提出任务时，通常只会描述当前看到的现象。

例如：

用户刷新页面后登录状态丢失，请帮我修复。

为了完成目标，Codex 可能修改：

• 用户状态初始化；

• Token读取逻辑；

• 请求拦截器；

• 路由守卫；

• 登录页面；

• 退出登录逻辑；

• 本地存储封装。

这些模块之间存在关联。

如果只验证“刷新后保持登录”，却没有检查Token失效、主动退出和多账号切换，新代码就可能解决当前问题，同时引入新的异常。

所以，AI代码审查不能只看目标功能是否正常，还要检查受影响的关联流程。

二、修改前先让Codex说明影响范围

面对正式项目，不建议直接输入：

修复这个问题并提交代码。

更稳妥的方式是先让 Codex 分析：

当前问题：

用户登录后刷新页面会丢失状态。

请先不要修改代码，先输出：

1. 问题可能涉及哪些文件；
2. 当前调用链是怎样的；
3. 计划修改哪些逻辑；
4. 哪些旧功能可能受到影响；
5. 需要运行哪些测试；
6. 是否需要修改公共模块。

这一步相当于一次修改前审查。

如果计划中出现订单、支付、数据库等无关模块，可以提前缩小范围，避免代码修改完成后再大面积回退。

三、使用Git分支隔离Codex任务

让Codex修改正式项目之前，建议先创建独立分支：

git switch -c codex/fix-login-state

也可以先检查当前工作区：

git status

如果存在尚未保存的修改，应先提交或暂存，避免人工代码与Codex修改混在一起。

建议遵循：

一个明确任务
=
一个独立分支
=
一组相关提交

这样做有几个好处：

• 修改失败时容易撤销；

• Git Diff更清晰；

• 不会污染稳定分支；

• 方便单独运行测试；

• 代码审查时容易理解修改目标。

四、第一遍审查：先看它改了哪些文件

Codex完成修改后，不要立即阅读每一行代码，先检查文件范围。

可以执行：

git status
git diff --stat

假设当前任务只涉及登录状态，但结果显示：

src/store/user.ts
src/api/auth.ts
src/router/index.ts
src/components/Header.vue
src/pages/Order.vue
package.json

那么就需要重点询问：

• 为什么修改订单页面？

• 为什么调整package.json？

• 是否新增了依赖？

• Header组件变化是否必要？

• 有没有更小的实现范围？

文件数量异常增多，通常是修改边界失控的信号。

五、第二遍审查：重点看Git Diff

查看完整差异：

git diff

不要只检查新增代码，还要看删除了什么。

Codex有时会为了让新逻辑更加简洁，删除旧有判断，但旧判断可能承担了兼容、安全或异常处理作用。

建议重点检查以下内容。

是否删除了原有校验？

例如：

if (!token) {
  redirectToLogin();
}

被新逻辑直接覆盖后，未登录场景是否仍然正确？

是否修改公共函数的默认行为？

公共函数可能被几十个模块引用。当前任务能够运行，不代表其他调用位置仍然兼容。

是否改变接口字段？

例如将：

user_name

改为：

username

需要确认前端、后端、测试和文档是否同步调整。

是否新增第三方依赖？

新增依赖需要确认：

• 项目现有能力是否已经可以完成；

• 新依赖是否真的必要；

• 版本是否兼容；

• 是否影响镜像和构建体积；

• 锁文件为什么发生变化。

是否出现无关格式化？

如果功能修改只涉及三行逻辑，Git Diff却包含数百行缩进和换行变化，代码审查会变得非常困难。

功能调整与全局格式化应分开提交。

六、第三遍审查：检查业务逻辑是否完整

代码能够编译，不代表业务逻辑正确。

可以根据四类场景审查。

正常流程

目标功能是否能够按预期完成？

例如：

• 用户正常登录；

• 页面刷新后保持状态；

• 接口返回正确数据。

边界场景

例如：

• Token为空；

• 返回数据缺少字段；

• 数组为空；

• 输入达到最大长度；

• 请求被重复提交。

异常场景

例如：

• 接口超时；

• 数据库连接失败；

• 权限不足；

• 缓存不可用；

• 依赖服务异常。

回归场景

例如：

• 主动退出是否仍然正常；

• 旧账号是否兼容；

• 原有接口是否受影响；

• 公共组件其他页面是否正常。

可以要求Codex生成审查矩阵：

请根据本轮Git Diff，列出：

1. 正常场景；
2. 边界场景；
3. 异常场景；
4. 可能受影响的旧功能；
5. 每个场景对应的验证方式。

七、不要只运行Codex新增的测试

Codex修复一个Bug时，通常会为当前问题补充测试。

但只运行新测试存在风险：

• 新测试可能只覆盖理想情况；

• 旧测试可能因修改而失败；

• Codex可能调整测试以适配新实现；

• 公共模块变化可能影响其他功能。

更合理的顺序是：

npm run lint
npm run type-check
npm run test
npm run build

如果项目规模较大，可以先执行相关模块测试，再执行完整测试集。

测试失败时，不要第一时间降低断言或删除测试。应先判断失败代表：

• 新代码确实引入回归；

• 测试依赖旧行为；

• 环境配置不一致；

• 测试本身不稳定；

• 修改范围超过预期。

八、警惕“为了通过测试而修改测试”

以下行为需要特别关注：

• 删除失败测试；

• 将严格相等改成模糊判断；

• 减少必要断言；

• 跳过异常场景；

• 使用 any 绕过类型错误；

• 直接关闭Lint规则；

• 将失败用例标记为跳过。

例如原测试要求：

expect(response.status).toBe(401);

Codex为了让测试通过，改成：

expect(response.status).toBeDefined();

虽然测试变绿了，但原有业务要求已经被削弱。

测试的目标是验证业务，而不是配合当前实现。

九、给Codex建立代码审查清单

可以在项目根目录建立 AGENTS.md，加入：

# 代码审查规则

- 修改前先列出影响文件
- 不修改任务范围之外的模块
- 修改公共函数前必须检查所有引用
- 不删除已有测试来通过构建
- 不使用any掩盖类型问题
- 不新增依赖，除非说明必要性
- 不进行与任务无关的全局格式化
- 修改后必须运行lint、类型检查和测试
- 必须列出可能受影响的旧功能
- 任务完成后输出Git Diff摘要

长期使用Codex时，固定规则比每次重新提醒更加稳定。

十、让Codex自己做一次反向审查

修改完成后，可以让Codex切换角色，从“实现者”变成“审查者”。

例如：

请不要继续修改代码。

现在以代码审查者身份检查本轮Git Diff：

1. 找出可能引入的新Bug；
2. 检查空值、并发和异常情况；
3. 检查是否修改了无关文件；
4. 检查是否改变公共行为；
5. 检查测试是否覆盖风险；
6. 按高、中、低风险输出问题。

反向审查无法替代人工Review，但可以帮助发现第一次生成时忽略的问题。

尤其是多文件修改中，重新从风险角度阅读代码，通常能找到更多潜在问题。

十一、复杂修改要分成小提交

一个大任务可能包含：

• 调整类型；

• 修改接口；

• 重构状态管理；

• 增加测试；

• 更新文档。

不建议全部放在一个提交中。

可以拆分为：

提交一：补充测试，复现原问题
提交二：修复核心逻辑
提交三：增加异常处理
提交四：更新文档与类型

小提交具有以下优势：

• 每一步变化更容易理解；

• 某个阶段失败可以单独回退；

• Review人员容易发现问题；

• 可以通过Git Bisect定位引入Bug的提交；

• Codex后续继续任务时更清楚当前进度。

十二、代码审查需要关注安全问题

除了功能正确性，还要检查：

• 是否将Token写入日志；

• 是否拼接SQL；

• 是否绕过权限校验；

• 是否信任前端输入；

• 是否新增危险文件操作；

• 是否使用不安全的默认配置；

• 是否上传真实环境变量；

• 是否暴露内部错误堆栈。

例如Codex为了快速修复权限问题，可能暂时放宽校验：

if (user) {
  allowAccess();
}

但真实业务可能要求管理员角色。

这种修改能够让页面恢复访问，却引入越权风险。

十三、建立提交前固定验证流程

建议将Codex任务固定为：

读取项目规则
→ 分析问题
→ 输出修改计划
→ 创建独立分支
→ 限定文件范围
→ 执行修改
→ 检查Git Diff
→ 运行自动测试
→ 进行反向审查
→ 人工确认
→ 提交代码

如果其中某一步失败，就不要继续扩大修改范围。

稳定的AI开发流程，通常不是一次完成所有工作，而是在每一个阶段设置可检查的结果。

十四、Plus适合哪些代码审查任务？

如果日常主要使用Codex完成：

• 单文件Bug修复；

• 简单Git Diff分析；

• 增加单元测试；

• 检查类型与Lint问题；

• 审查中小型模块；

• 输出代码修改摘要；

Plus通常可以满足大部分需求。

通过限制文件范围和拆分任务，可以减少上下文消耗，也能提高代码审查质量。

十五、哪些情况可以评估Pro？

如果开发工作长期包含：

• 每天审查多个完整仓库；

• 经常进行跨模块重构；

• 需要连续分析大量Git Diff；

• 修改后必须运行多轮测试；

• 同时维护多个项目；

• Codex已进入正式开发流程；

• 当前使用空间经常打断审查和验证；

可以在后续ChatGPT充值或订阅周期中评估Pro。

Pro更适合高频、长任务和多文件工程场景，其价值主要体现在减少任务中断，让代码分析、修改、测试和审查更容易连续完成。

但更高的版本不能替代Review流程。如果修改完成后仍然直接提交，新的Bug依然可能进入主分支。

总结

ChatGPT充值后，Codex修改代码经常引入新Bug，通常不是因为AI完全无法编程，而是项目缺少明确修改边界和代码审查步骤。

通过修改前分析影响范围、使用独立Git分支、检查Git Diff、运行完整测试、执行反向审查和拆分小提交，可以显著降低回归风险。

对于单文件和中小型任务，Plus通常已经够用。对于完整仓库、跨模块重构和需要连续完成审查验证的高频工程场景，Pro更符合长任务需求。

真正可靠的AI编程，不是Codex回答“修改已完成”，而是每一次修改都能够说明原因、控制范围、通过测试，并经得起开发者再次审查。

CSDN文章描述

本文介绍ChatGPT充值后使用Codex时，如何通过Git分支、Git Diff、代码审查清单、自动测试和AGENTS.md规则，降低AI修改代码引入新Bug的风险，并分析ChatGPT Plus与Pro的适用场景。