最近在实际开发中，我发现了一个令人困惑的现象。同样是 Codex 客户端，之前使用 GPT 或 Claude 模型时，体验非常流畅：修改代码、新建文件、重构项目，一气呵成。但自从将模型切换为 DeepSeek V4 之后，总感觉操作不太对劲——代码生成与编辑能力似乎明显下降，修改文件变得迟缓，操作逻辑也变得繁琐，整体体验甚至不如 OpenCode。
起初我还以为是模型本身的能力不足，折腾了许久才发现，问题其实出在工具调用环节——第三方 API 导致 Codex 的 Tools 功能无法正常运作。
现象一：Codex 不再直接修改文件
过去使用 GPT 时，让 Codex 帮忙修改一个文件，例如帮我修改 src/api/user.js，它会直接调用对应工具，并清晰展示：
修改文件：src/api/user.js 12-3新增了多少行、删除了多少行、改动了哪些内容，一目了然，整个操作流程如同 Cursor 一样直观高效。
接入 DeepSeek V4 后，情况发生了明显变化。它开始大量使用命令行操作，比如：
echo "xxxx" > temp.js或者：
cat > test.js再或者：
cp fileA fileB接着又是：
mv temp.js target.js表面上是在修改文件，但实际上操作逻辑变成了：创建一个临时文件 → 复制内容 → 删除原文件 → 替换为目标文件。整个流程绕得非常不顺畅，有时甚至会出现：创建 A 文件 → 修改 B 文件 → 读取 C 文件 → 再回头覆盖 A 文件这样的循环，让人看得一头雾水。
现象二：修改大文件时尤其容易出问题
举个例子，修改一个包含 1000 行的 Vue 页面。正常流程应该是：定位代码位置 → 修改指定区域 → 保存文件。但接入 DeepSeek 后，经常变成：读取整个文件 → 生成完整新文件 → 直接覆盖原文件。
这带来了两个直接问题：
Token 消耗显著增加。 原本只需读取 10 行、修改 10 行；现在却要读取 1000 行、重写 1000 行，使用成本直接翻倍。
容易误覆盖旧代码。 尤其在多人协作开发的项目中，经常出现刚写完的新逻辑被模型直接覆盖的情况，令人非常头疼。
一开始我也以为是 DeepSeek 能力不足
说实话，刚开始我真的认为 DeepSeek V4 的代码能力下降了，甚至还特意拿去和 OpenCode 做对比。结果发现 OpenCode 修改文件更加直接，而 Codex 反而绕来绕去。于是我开始怀疑：是不是 Codex 越来越不好用了？但越深入排查越觉得不对劲。
真正原因：第三方 API 无法调用 Codex 原生 Tools
研究到最后，终于找到了问题的症结所在。问题并不在于模型，而在于第三方中转 API。许多第三方接口实际上只兼容了 Chat Completion，也就是最基础的“发送消息 → 返回文本”能力。而 Codex 真正强大的地方，在于它的 Tools 能力，例如文件编辑、文件创建、文件搜索、终端执行、项目索引、差异对比（Diff）等。这些全部属于 Tool Calling 能力的范畴。
为什么 GPT 表现正常？
因为很多 GPT 接口（比如 gpt-5、gpt-5-mini、gpt-4.1）本身就支持 Tool Calling，官方接口能够返回{"tool_calls":[]}这样的结构。Codex 接收到后就知道：应该修改哪个文件、执行哪条命令、搜索项目的哪个部分。于是那些清晰直观的差异对比就能正常展现出来。
为什么 DeepSeek 第三方接口不行？
很多第三方平台虽然标注“兼容 OpenAI API”，但实际上兼容的仅仅是 Chat 接口，并不是 Responses API，更不是完整的 Tool Calling。因此模型只能返回纯文本，而无法返回工具调用指令。于是 Codex 就只能自行采取“笨办法”——读取文件 → 生成新内容 → 用 CMD 覆盖，走这种低效的替代方案。
为什么会感觉模型突然降智？
实际上是两种能力被混淆了。模型能力负责理解代码、生成代码、分析问题；Tools 能力负责修改文件、搜索项目、执行命令。当 Tools 能力缺失后，即使模型本身能力没有问题，用户感受到的体验也会变成“很笨、很慢、很绕”。于是很多人就会误以为是 DeepSeek 不行，但实际上真正缺失的是 Agent 层面的工具调用能力。
为什么 OpenCode 感觉更顺手？
很多人会发现，OpenCode、Claude Code、Cursor 这类工具，即便接入了第三方模型，有时依然能够直接修改文件。原因在于，这些工具很多会自行实现本地文件系统工具，比如 read_file、write_file、replace_text 等。这些工具由客户端直接提供，模型只负责输出调用格式，因此体验相对稳定可靠。
我的测试结论
经过这几天的深入测试，最终得出了一个比较明确的结论：
| 方案 | 文件编辑体验 | Tools 支持 | 推荐程度 |
|---|---|---|---|
| 官方 GPT 接口 | 非常好 | 完整支持 | ★★★★★ |
| 官方 Claude 接口 | 非常好 | 完整支持 | ★★★★★ |
| DeepSeek 官方支持 Tools 接口 | 较好 | 部分支持 | ★★★★ |
| 第三方 DeepSeek 中转 | 一般 | 经常缺失 | ★★ |
| 仅 Chat 兼容接口 | 较差 | 无 Tools | ★ |
解决方案
如果你发现 Codex 出现以下情况：不直接修改文件、频繁执行 CMD 命令、反复创建临时文件、直接覆盖整个文件、修改代码逻辑很绕，先不要急着怀疑模型能力。建议从以下几个方面逐一排查：
1. 是否使用了第三方中转？ 很多问题都出在这一环节。
2. 是否支持 Tool Calling？ 仔细查阅接口文档，确认是否明确写明了 Tool Calling、Function Calling、Responses API 等关键能力。
3. 优先使用官方接口。 如果是长期开发项目，强烈建议直接使用 GPT 或 Claude 的官方接口，体验差距会非常明显。
总结
最近我一直觉得 Codex 越来越难用了，后来才发现并不是 Codex 本身变差了，而是接入 DeepSeek V4 的第三方中转 API 后，许多原生 Tools 功能无法正常工作。结果导致文件修改能力下降、项目操作能力下降、Agent 能力下降、整体开发体验下降。表面上看像是模型降智了，实际上是“模型还能思考，但手脚被绑住了”。对于 Codex、Claude Code、Cursor 这类高度依赖工具调用的 AI 编程产品来说，模型能力固然重要，但 Tool Calling 能力同样至关重要。很多时候让你觉得 AI 变笨的，并不是模型本身，而是它失去了操作项目的能力。
