最近我折腾了一件事：

我用 CCX 这个工具，把 Codex 后面的模型换成了 DeepSeek V4 Flash。

表面上看，这只是一次模型替换。
但我觉得它背后真正有意思的地方是：

AI 编程工具正在从“绑定某一个模型”，变成“前端工具 + 代理网关 + 任意模型”的组合。

过去你用 Codex，基本默认走它原来的模型和接口。

目前不一样了。

你可以让 Codex 继续负责终端交互、读取项目、修改代码、执行命令；
但真正负责生成代码和推理的模型，可以通过 CCX 转接到 DeepSeek V4 Flash。

简单理解就是：

Codex 是方向盘。
CCX 是变速箱。
DeepSeek V4 Flash 是发动机。

普通人真正要学的，不是记一堆参数，而是看懂这套结构。

01

这套方案适合谁？

这套方案主要适合三类人。

第一类，想继续用 Codex 终端体验，但又想试试 DeepSeek 新模型的人。

第二类，想降低 AI 编程成本的人。

第三类，想搭一套自己可控 AI 工具链的人。

由于 CCX 本质上是一个 AI API 代理和协议转换工具。

它可以把 Codex 的请求，转发到其他兼容模型上。

这样一来，前端工具和后端模型就被拆开了。

这才是重点。

以前我们用 AI 工具，是平台给什么，我们就用什么。

目前慢慢变成：

工具可以自己选。
模型可以自己换。
中间路由也可以自己搭。

02

第一步：安装 Codex

先安装 Codex CLI：

npm i -g @openai/codex

安装完成后，进入你的项目目录：

codex

如果能正常进入终端交互界面，说明 Codex 已经装好了。

但这时候，它还没有接 DeepSeek。

接下来要做的，就是让 Codex 的请求先打到 CCX，再由 CCX 转发给 DeepSeek V4 Flash。

03

第二步：启动 CCX

最简单的方式是用 Docker 启动：

docker run -d 
  --name ccx 
  -p 3000:3000 
  -e PROXY_ACCESS_KEY=your-proxy-access-key 
  -e APP_UI_LANGUAGE=zh-CN 
  -v $(pwd)/.config:/app/.config 
  crpi-i19l8zl0ugidq97v.cn-hangzhou.personal.cr.aliyuncs.com/bene/ccx:latest

这里最关键的是：

PROXY_ACCESS_KEY

它不是 DeepSeek 的 API Key。
它是你访问 CCX 代理服务时用的密码。

启动后，打开：

http://localhost:3000

能看到 CCX 后台，就说明服务跑起来了。

04

第三步：添加 DeepSeek 渠道

进入 CCX 后台，添加一个给 Codex 用的模型渠道。

核心配置大致是：

Base URL：https://api.deepseek.com
API Key：你的 DeepSeek API Key
模型名：deepseek-v4-flash

注意，模型名不要写中文，也不要随意加空格。

正确写法是：

deepseek-v4-flash

这里的逻辑是：

Codex 走自己的 Responses 请求格式。
DeepSeek 提供 OpenAI 兼容接口。
CCX 负责中间协议转换。

所以你不用让 Codex 直接访问 DeepSeek，而是让它访问 CCX。

05

第四步：修改 Codex 配置

打开 Codex 配置文件：

mkdir -p ~/.codex
nano ~/.codex/config.toml

写入：

model = "deepseek-v4-flash"
model_provider = "ccx"

approval_policy = "on-request"
sandbox_mode = "workspace-write"

[model_providers.ccx]
name = "CCX"
base_url = "http://127.0.0.1:3000/v1"
env_key = "CCX_PROXY_KEY"
wire_api = "responses"

然后设置环境变量。

macOS / Linux：

export CCX_PROXY_KEY="your-proxy-access-key"

Windows PowerShell：

$env:CCX_PROXY_KEY="your-proxy-access-key"

这里再强调一次：

DeepSeek API Key 填在 CCX 后台。
CCX_PROXY_KEY 填的是你启动 CCX 时设置的 PROXY_ACCESS_KEY。

这两个不要搞混。

06

第五步：测试

进入一个项目目录，运行：

codex

然后输入：

帮我看一下这个项目的目录结构，并说明它是什么技术栈。

如果 Codex 能正常分析项目，就说明链路打通了。

这时候你用的还是 Codex 的终端体验。
但背后跑的模型，已经换成了 DeepSeek V4 Flash。

07

常见问题

第一个坑：Base URL 写错

Codex 配置里不要直接写 DeepSeek 地址，而是写 CCX 地址：

http://127.0.0.1:3000/v1

第二个坑：Key 填错

DeepSeek Key 放在 CCX 渠道里。
CCX 的代理 Key 放在 Codex 环境变量里。

第三个坑：WSL 访问不到 localhost

如果你在 Windows 上跑 CCX，在 WSL 里跑 Codex，可能要把 127.0.0.1 换成 Windows 主机 IP。

列如：

http://192.168.1.23:3000/v1

08

最后说两句

我为什么觉得这件事值得折腾？

由于它代表了一个趋势：

AI 工具正在模块化。

Codex 不必定非要绑定某一个模型。
DeepSeek 也不必定只能在网页里用。

CCX 这种工具的价值，就是把不同工具重新拼起来。

谁负责交互？
谁负责路由？
谁负责模型？
谁负责成本？

当你能把这些拆开，再重新组合，你就不只是一个 AI 工具用户了。

你开始有自己的 AI 工作流。

AI 时代普通人真正需要的，不只是会用某一个工具，而是能把工具、模型和流程，组装成自己的生产力系统。

我是华子社长。
关注我，继续拆解 AI 时代普通人的实战机会。