Codex桌面版接入DeepSeek V4保姆级教程，零基础提升AI编程效率

想用 Codex 桌面版，但又想用性价比更高的 DeepSeek V4 模型？这个需求听起来很直接，但实际操作起来，很多开发者都会卡在接口不兼容的问题上。Codex 新版默认走的是 Responses API，而 DeepSeek 官方接口是 Chat Completions 格式，直接改个 base_url 根本行不通，最终只会换来一堆 400 报错。

如果你也遇到了这个问题，别急着回退 Codex 版本。这篇 Codex 桌面版接入 DeepSeek V4 保姆级教程，会带你从零开始，通过一个本地桥接服务，把两者无缝打通。整个过程不需要修改 Codex 客户端，也不需要复杂的网络配置，跟着步骤走就行。

为什么不能直接连接 DeepSeek？先搞懂接口差异

很多人的第一反应是：既然 DeepSeek 兼容 OpenAI 的 API 格式，那把 Codex 的 base_url 改成 DeepSeek 的地址不就行了？这个想法很朴素，但现实很骨感。

核心问题在于 Codex 新版（尤其是桌面版和 CLI）默认使用的是 Responses API，而 DeepSeek 官方接口主要接收的是 Chat Completions。两者在请求结构、消息格式、工具调用字段上都有明显差异。

所以，Codex 桌面版怎么用 DeepSeek V4 这个问题的标准答案，不是修改配置，而是搭建一个本地协议转换层。

核心方案：本地桥接服务的工作原理

这个方案的核心思路很简单：在本机启动一个轻量级的 Node.js 服务，它充当“翻译官”的角色。

Codex 桌面版/CLI 发出的所有请求，都指向这个本地服务（127.0.0.1:4000）。
本地服务收到 Codex 的 Responses API 请求后，将其转换为 DeepSeek 能识别的 Chat Completions 格式。
转换后的请求被发送到 DeepSeek 的官方 API。
DeepSeek 返回结果后，本地服务再将结果包装回 Codex 能读取的 Responses API 格式。

这样一来，Codex 和 DeepSeek 都不需要做任何修改，它们各自只跟自己“熟悉”的接口对话，中间的翻译工作由桥接服务完成。

零基础实操：Codex 接入 DeepSeek V4 完整步骤

下面就是详细的 Codex 工具使用教程，请确保你的电脑已经安装了 Node.js 18 或更高版本，以及 Codex 桌面版和 CLI。

第一步：准备工作与环境检查

在开始之前，先确认你的环境是否就绪。

检查 Node.js 版本：打开终端（Windows 用 PowerShell 或 CMD，macOS/Linux 用 Terminal），输入 node --version，确保版本号不低于 v18.0.0。
检查 Codex CLI：输入 codex --version。如果提示找不到命令，说明 Codex CLI 没有正确安装或环境变量未配置。
准备 DeepSeek API Key：确保你有一个有效的 DeepSeek API Key，并且账户内有余额。

第二步：安装本地桥接服务

这里我们以 codex-bridge 项目为例，它是一个专门用于转换 Codex Responses API 和 Chat Completions API 的 Node.js 代理。

创建目录：在终端执行 mkdir -p ~/.codex，创建一个用于存放 Codex 配置和桥接服务的文件夹。
克隆项目：进入该目录并克隆桥接服务项目。

PR0

> 进阶技巧：如果 GitHub 访问不稳定，可以使用可信的镜像源，但务必确认代码与原仓库一致，避免 API Key 泄露风险。

第三步：配置 DeepSeek 访问参数

在桥接服务目录 ~/.codex/codex-bridge 下，创建一个名为 .env 的文件（注意文件名前面有个点），并填入以下内容：

PR1

DEEPSEEK_API_KEY：替换成你的真实密钥。
DEEPSEEK_MODELS：这里定义了桥接服务会暴露给 Codex 的模型名称。推荐使用 deepseek-v4-pro 和 deepseek-v4-flash。
PROXY_HOST 和 PROXY_PORT：定义了本地服务的监听地址和端口，保持默认即可。

> 使用误区：不要把多个配置挤在一行，.env 文件必须逐行书写。API Key 不要加引号。这个文件是明文存储密钥的，绝对不要上传到 GitHub 或任何公开仓库。

第四步：配置 Codex

Codex 的配置文件位于 ~/.codex/config.toml。用文本编辑器打开它，写入或合并以下内容：

PR2

这里最关键的一行是 wire_api = "responses"。千万不要写成 wire_api = "chat"，否则新版 Codex 会报错。

第五步：启动桥接服务

回到终端，确保你在 ~/.codex/codex-bridge 目录下，然后执行启动命令：

PR3

如果看到类似 Listening on http://127.0.0.1:4000 的输出，说明服务启动成功。这个终端窗口必须保持开启，关闭后桥接服务就会停止。

第六步：验证链路是否打通

验证 DeepSeek API：先确保 DeepSeek 官方接口本身是通的。

PR4

如果返回包含“好”字的 JSON，说明 DeepSeek 接口正常。

验证本地桥接服务：测试桥接服务是否能正确转换请求。

PR5

如果返回“好”，说明桥接服务工作正常。

验证 Codex CLI：最后，用 Codex CLI 测试整个链路。

PR6

如果输出“好”，恭喜你，Codex 桌面版接入 DeepSeek V4 的链路已经全线打通！

在 Codex Desktop 中使用 DeepSeek 模型

确认 CLI 能正常工作后，打开 Codex Desktop 应用。在对话界面中，你可以通过 /model 命令切换模型：

/model deepseek-v4-pro：适合复杂代码分析、架构调整、长上下文任务。
/model deepseek-v4-flash：适合快速问答、轻量修改、短代码补全。

> 个人判断：对于日常的代码生成和重构，deepseek-v4-pro 的表现更稳定，理解能力更强。deepseek-v4-flash 则适合在需要快速响应、对精度要求不高的场景下使用，比如写一些简单的脚本或注释。

常见问题与解决方案

Q1: 提示 `wire_api = chat is no longer supported`

原因：Codex 新版已经弃用了 chat 类型的 API 配置。
解决：检查 ~/.codex/config.toml，确保 wire_api = "responses"。

Q2: Codex Desktop 仍然弹出登录窗口

原因：桌面端的认证逻辑可能和 CLI 不同步。
解决：

先确认 CLI 能正常使用（codex exec 命令有效）。
重启 Codex Desktop。
检查 config.toml 中 cli_auth_credentials_store = "file" 是否写在顶层。

Q3: `/model` 找不到 DeepSeek 模型

原因：桥接服务没有正确返回模型列表。
解决：

在终端执行 curl http://127.0.0.1:4000/v1/models，检查返回结果。
如果列表为空，检查 .env 文件中的 DEEPSEEK_MODELS 配置是否正确。
修改 .env 后，需要重启桥接服务。

Q4: 普通聊天正常，但改代码不稳定

原因：桥接服务可能没有完整处理 Codex 的工具调用（tool call）流程。这是最复杂的一环，涉及到文件读写、代码补丁等操作。
解决：这通常是桥接项目本身的功能限制。一个稳定的编程代理桥接至少需要支持 tools、tool_calls、tool result、stream events 和 response output items 的完整转换。如果问题频繁出现，可以尝试寻找功能更完善的桥接项目，或者等待其更新。