使用 Codex 修改真实项目时，经常会遇到一种情况：

代码没有报错，测试也可能通过，但实际功能还是不符合预期。

例如：

• 页面按钮能点击，但结果没有变化；

• 接口返回正常，但前端显示错误；

• 修改了某个文件，运行后却没有效果；

• AI认为问题已经解决，实际使用仍然存在问题；

• 单独看每段代码都合理，组合起来却出现异常。

这类问题通常不是简单的语法错误。

更多时候需要检查：

代码修改是否真的影响到了实际运行链路。

---

一、先确认修改的代码是否真的被执行

很多开发者第一反应是继续修改代码。

但有一种情况非常常见：

改的是对的地方，但程序根本没有运行这部分代码。

例如项目中存在：

src/service/user.ts
src/legacy/user.ts
src/api/user.ts

你让 Codex 修改用户逻辑。

它修改了：

src/service/user.ts

但实际接口调用的是：

src/api/user.ts

最终效果当然不会变化。

所以遇到：

修改后完全没效果。

第一步应该确认：

• 当前运行入口是什么；

• 这个文件是否被调用；

• 修改后的代码是否进入执行路径。

---

二、不要只看函数内部，要看完整调用链

很多代码问题不是出在某一个函数。

而是在：

数据从哪里来，经过什么处理，最后到哪里。

例如：

用户操作
↓
页面组件
↓
状态管理
↓
API请求
↓
后端服务
↓
数据库

任何一层都可能影响最终结果。

假设：

后端返回数据已经正确。

但是前端状态没有更新。

用户看到的仍然是旧内容。

这时候继续修改后端代码没有意义。

所以排查功能问题时，要沿着完整链路检查。

---

三、确认输入和实际数据是否符合预期

很多时候代码逻辑没有问题。

问题出在：

实际进入程序的数据和开发者想象的不一样。

例如：

代码判断：

if status === "active"

但是实际数据：

status = "ACTIVE"

或者：

status = 1

结果自然不会进入预期分支。

AI分析代码时，通常看到的是：

变量定义；

类型；

函数逻辑。

但真实运行时，数据可能来自：

• 用户输入；

• 数据库；

• 第三方接口；

• 历史数据。

所以功能异常时，要先确认：

实际收到的数据是什么。

---

四、缓存可能让修改看起来没有生效

这是开发中非常常见的问题。

例如修改了：

• 接口逻辑；

• 页面数据；

• 配置文件。

但是运行结果还是旧版本。

原因可能是：

• 浏览器缓存；

• 前端构建缓存；

• 服务缓存；

• Redis缓存；

• Docker旧镜像。

这时候代码可能已经正确修改。

只是：

运行环境还在使用旧数据。

所以遇到：

明明改了，为什么还是一样？

需要检查：

• 服务是否重新启动；

• 构建是否重新执行；

• 缓存是否清理；

• 当前运行版本是否最新。

---

五、AI容易关注“代码正确”，但用户关注“结果正确”

这是使用 Coding Agent 时容易出现的差异。

例如：

需求：

用户提交表单后显示成功。

AI可能关注：

• 请求有没有发送；

• 返回值有没有处理；

• 函数有没有报错。

但用户真正关心：

• 页面有没有变化；

• 数据有没有保存；

• 后续流程能不能继续。

也就是说：

代码层面的正确：

≠

业务流程正确。

所以让 Codex 修改功能时，不要只描述：

修改这个函数。

最好描述：

用户完成什么操作，希望看到什么结果。

让它围绕完整行为分析。

---

六、检查是不是修改范围太小

有时候 Codex修改了一处代码，但实际问题涉及多个地方。

例如：

增加一个用户字段：

只修改：

User.ts

但遗漏：

数据库Schema
API返回类型
前端展示组件
测试数据

单个文件没有问题。

整个流程却不完整。

所以涉及功能修改时，可以要求：

检查这个改动涉及的所有调用方和依赖文件。

不要只让AI盯着当前文件。

---

七、日志比猜代码更有效

功能不符合预期时，不要马上继续修改。

先增加或者查看关键日志。

例如：

收到什么参数？
进入哪个函数？
返回什么结果？
哪个判断没有通过？

很多时候，一条清晰日志就能说明：

问题发生在输入；

处理中；

还是输出。

对于复杂项目：

靠猜代码。

不如：

观察真实运行过程。

---

八、一个稳定的排查顺序

Codex修改后功能仍然异常，可以按照：

第一步：确认代码是否真的执行

检查入口和调用关系。

第二步：检查真实输入数据

确认程序收到的信息。

第三步：检查完整调用链

不要只看一个函数。

第四步：检查缓存和运行环境

确认使用的是最新代码。

第五步：检查遗漏文件

确认相关模块同步修改。

第六步：通过日志验证

定位真实问题位置。

---

九、可以这样让Codex辅助排查

相比：

功能还是不对，继续修改。

更好的描述：

请不要直接修改代码。

先分析：
1. 当前功能完整调用链；
2. 实际执行入口；
3. 可能没有生效的修改位置；
4. 需要验证的关键数据。

确认原因后再提出修改方案。

这样可以避免AI不断尝试修改，导致范围越来越大。

---

最后

Codex修改代码后功能还是不对，并不一定代表：

AI写错了代码。

很多时候问题在于：

• 修改的位置不是实际执行路径；

• 调用链中还有其他逻辑；

• 数据和预期不同；

• 缓存仍然使用旧结果；

• 某个关联模块没有同步。

项目开发和单文件写代码最大的区别就是：

代码正确，只是第一步。

真正重要的是：

修改是否进入完整运行流程，并最终产生正确结果。

当使用 Codex处理大型项目时，排查问题的重点也会逐渐从：

“哪一行代码错了”

变成：

“整个系统为什么没有按照预期运行”。

---

持续更新 Codex、大模型开发与 AI 编程实战内容，更多技术内容和稳定订阅渠道欢迎搜索关注「仙逆GPT」。