深度揭秘Codex集成DeepSeek V4模型后变笨：Tools工具能力失效是性能下降主要原因

在实际开发中，我发现一个令人费解的现象：同样是 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 等。这些工具由客户端提供，模型只需输出调用格式即可，因此体验相对稳定。

我的测试结论

经过几天的横向比对，最终得出清晰的结论：

解决建议

如果你遇到 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 变笨的，并不是模型，而是它失去了操作项目的能力。