1. 前言最近 DeepSeek 火得一塌糊涂无论是推理能力还是性价比都让人忍不住想把它集成到自己的开发工作流里。而我日常写代码最依赖的工具就是 Codex——OpenAI 推出的那个终端里的 AI 编程助手。一个想法冒了出来能不能让 Codex 背后调用 DeepSeek 的模型既保留 Codex 的交互体验又享受 DeepSeek 的强大能力说干就干结果这一折腾就是整整一个下午。踩坑、翻文档、改配置、反复试错……好在最后终于跑通了。这篇文章就把整个过程记录下来希望能帮到有同样想法的朋友。下面是整个改造方案的架构图先让你对整体流程有个直观印象渲染错误:Mermaid 渲染失败: Parse error on line 12: ...K[CODEX_MODEL]## 2. 准备工作在开始之前你需要准备 ----------------------^ Expecting SEMI, NEWLINE, EOF, AMP, START_LINK, LINK, LINK_ID, got NUM然后安装依赖npminstall这一步一般不会出问题但如果你的 Node 版本太低可能会报错。建议用nvm切换到 v20 以上。 小贴士如果你在中国大陆npm install可能会因为网络问题卡住。建议先配置 npm 镜像源npmconfigsetregistry https://registry.npmmirror.com安装完成后可以用ls看看项目结构重点关注src/目录下的文件lssrc/# 你应该能看到 llm.ts、config.ts、cli.ts 等核心文件下面是 Codex 项目的核心文件结构方便你后续定位要修改的文件渲染错误:Mermaid 渲染失败: Parse error on line 13: ...- J H -- J## 5. 第二步找到模型配置Codex ---------------------^ Expecting SEMI, NEWLINE, EOF, AMP, START_LINK, LINK, LINK_ID, got NUM这里就是突破口。我们只需要把baseURL改成 DeepSeek 的地址即可。但注意Codex 可能有多处初始化 OpenAI 客户端的地方要全部改掉。我采用的方式是直接设置环境变量这样不用改源码升级时也方便exportOPENAI_BASE_URLhttps://api.deepseek.com/v1exportOPENAI_API_KEYsk-your-deepseek-api-key-here⚠️ 重要OPENAI_API_KEY这个环境变量名是 Codex 内部写死的虽然我们改的是 DeepSeek 的地址但变量名不用改DeepSeek 的 API Key 填进去就行。DeepSeek 兼容 OpenAI 的认证格式。为了确保所有地方都改到了建议用 grep 全局搜索一下grep-rnnew OpenAI(src/# 检查输出结果确保每一处都通过环境变量覆盖了 baseURL下面是修改 API 端点前后的对比流程图渲染错误:Mermaid 渲染失败: Parse error on line 16: ...eek 响应] end## 7. 第四步修改模型名称光改端点还 ---------------------^ Expecting SEMI, NEWLINE, EOF, AMP, START_LINK, LINK, LINK_ID, got NUM然后在启动时exportCODEX_MODELdeepseek-chat8. 第五步处理兼容性问题改完之后启动 Codex结果报错了。错误信息大概是说 DeepSeek 返回的响应格式和 OpenAI SDK 期望的不完全一致。具体来说DeepSeek 的流式响应中某些字段的命名或结构略有不同。我翻了一下 DeepSeek 的官方文档发现它确实宣称兼容 OpenAI 的 API 格式但在一些细节上比如usage字段的返回时机有差异。解决办法是给 Codex 打一个小补丁在解析响应时做一层适配。或者更简单——升级到最新版的 OpenAI SDK因为新版 SDK 对非标准响应的容错性更好。npminstallopenailatest这一步花了我最多时间因为要反复改、重启、测试。下面是我排查兼容性问题时梳理的流程图帮你快速定位问题根源渲染错误:Mermaid 渲染失败: Parse error on line 21: ... N --|否| B## 9. 第六步测试运行一切就绪后在 ----------------------^ Expecting SEMI, NEWLINE, EOF, AMP, START_LINK, LINK, LINK_ID, got NUM然后随便问一个问题 用 Python 写一个斐波那契数列生成器Codex 开始思考然后……真的返回了代码而且推理速度比 GPT-4o 还快token 成本更是低了一个数量级。那一刻整个下午的折腾都值了。10. 踩坑总结把这一下午踩的坑总结一下方便你避雷坑原因解决办法模型名不匹配Codex 硬编码了 OpenAI 模型名用环境变量覆盖模型名参数API 端点不对只改了部分客户端初始化全局搜索new OpenAI(全部替换流式响应解析失败DeepSeek 响应格式有细微差异升级 OpenAI SDK 到最新版请求超时DeepSeek 首次推理较慢调大timeout参数Token 统计报错usage字段返回时机不同在解析处加空值判断11. 最终效果现在我的 Codex 已经稳定运行在 DeepSeek 之上了。日常开发中Codex 的交互体验一点没变——还是在终端里用自然语言描述需求AI 直接生成代码并应用到文件。但背后的大脑已经从 GPT-4o 换成了 DeepSeek。感受最深的几点速度快DeepSeek 的推理延迟比 GPT-4o 低不少尤其是简单任务几乎秒回。成本低同样的使用量API 费用只有原来的十分之一不到。代码质量在线DeepSeek 在代码生成上的表现完全不输 GPT-4o甚至在某些场景下更优。12. 写在最后如果你也在用 Codex或者想找一个高性价比的 AI 编程方案强烈推荐试试这个组合。虽然配置过程有点折腾但一旦跑通回报是巨大的。如果你在配置过程中遇到问题欢迎在评论区留言我会尽力帮你排查。毕竟这个坑我已经替你踩过了。Happy coding
