Codex 在 VS Code 中的使用教程

在 VS Code 里用 Codex，最常见的卡点不是“插件装不上”，而是 API Key、base_url、模型名和网络代理没配对。遇到连不上、一直转圈、提示 401/404/timeout 时，先不要急着换插件，按顺序检查配置会快很多。

下面按实际开发环境来走一遍：准备接口参数、在 VS Code 插件里填写配置、发起测试请求、处理常见报错，最后再补几个稳定性优化建议。

一、准备 API 参数

不管你用的是 Codex 类接口，还是兼容 OpenAI 格式的代码模型，通常都需要这几个参数：

• API Key：鉴权用，通常是 sk- 开头或平台自定义格式。
• base_url：接口基础地址，例如 https://api.example.com/v1 这类格式。
• model：模型名，例如 codex、gpt-5.5-codex、code-model，以服务商实际提供为准。
• proxy：公司网络或本地代理环境下可能需要。
• timeout：代码生成通常比普通聊天慢，建议不要设太短。

如果你只是想在 VS Code 里稳定调试 Codex 类接口，不想每次都折腾网络和额度，我一般建议准备一个 OpenAI 兼容格式的中转接口。比如 token 云桥 AI 中转站 0029.org，重点看它是否提供清晰的 base_url、模型名和 Key 管理，这样接到 VS Code 插件时排查成本会低很多。

二、选择 VS Code 插件

VS Code 里能接 Codex 类接口的插件不少，常见选择有两类：

• 聊天/代码助手插件：支持侧边栏对话、解释代码、生成函数、重构代码。
• OpenAI Compatible 插件：允许自定义 base_url、apiKey、model，更适合接第三方兼容接口。

安装时建议优先选可以手动配置接口地址的插件。只支持官方固定地址的插件，后面接中转接口或私有网关会比较麻烦。

打开 VS Code 扩展市场，搜索关键字：

### token云桥中转 0029.org ###
OpenAI Compatible
Code Assistant
Codex
AI Chat

安装后进入插件设置，重点找这几项：

• API Key
• Base URL 或 Endpoint
• Model
• Request Timeout
• HTTP Proxy

三、在 VS Code 中填写配置

1. 通过图形界面配置

按 Ctrl + , 打开设置，搜索插件名称或直接搜索 OpenAI、API Key。假设你的插件支持 OpenAI 兼容接口，可以按下面思路填写：

• API Key：填写你的密钥，不要带多余空格。
• Base URL：填写到 /v1，不要写到 /chat/completions。
• Model：填写服务商给出的模型名，大小写要一致。
• Timeout：建议设置为 60000 到 120000 毫秒。

一个常见错误是 base_url 写多了一段路径。正确示例：

https://api.example.com/v1

错误示例：

https://api.example.com/v1/chat/completions

2. 通过 settings.json 配置

有些插件的图形界面不好找，直接改 settings.json 更清楚。按 Ctrl + Shift + P，输入：

Preferences: Open User Settings (JSON)

示例配置如下，字段名需要按你安装的插件文档调整：

{
  "codex.apiKey": "sk-your-api-key",
  "codex.baseUrl": "https://api.example.com/v1",
  "codex.model": "gpt-5.5-codex",
  "codex.timeout": 90000,
  "codex.temperature": 0.2
}

写代码辅助时，temperature 不建议太高。生成业务代码、SQL、脚本时，我通常放在 0.1 到 0.3，更稳一点；如果是写注释、文档，可以适当调高。

四、先用 curl 测试接口

插件里测试失败时，不要一上来怀疑 VS Code。先在终端用 curl 请求一次，能排除 Key、base_url、模型名的问题。

curl https://api.example.com/v1/chat/completions \
  -H "Authorization: Bearer sk-your-api-key" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "gpt-5.5-codex",
    "messages": [
      {
        "role": "user",
        "content": "写一个 JavaScript 函数，判断字符串是否为回文"
      }
    ],
    "temperature": 0.2
  }'

如果这里能返回结果，说明接口本身没问题，接下来再查 VS Code 插件字段名、代理和超时设置。如果 curl 都失败，优先看状态码。

五、配置代理和网络

公司网络、海外接口、本地代理混用时，VS Code 很容易出现插件请求失败，但浏览器正常的情况。可以先检查本机代理：

echo $HTTP_PROXY
echo $HTTPS_PROXY

Windows PowerShell 可以用：

echo $env:HTTP_PROXY
echo $env:HTTPS_PROXY

如果插件支持单独配置代理，示例格式一般是：

http://127.0.0.1:7890

也可以在 VS Code 设置里配置全局代理：

{
  "http.proxy": "http://127.0.0.1:7890",
  "http.proxyStrictSSL": false
}

http.proxyStrictSSL 不建议长期关闭，只适合排查证书链问题。确认网络正常后，最好恢复默认，避免把证书问题掩盖掉。

六、常见报错排查

1. 401 Unauthorized

通常是 API Key 不对、Key 复制时带了空格、插件没有保存成功。排查顺序：

• 重新复制 API Key，注意前后不要有空格。
• 确认请求头是 Authorization: Bearer xxx。
• 检查 Key 是否属于当前 base_url 对应的平台。

2. 404 Not Found

多半是 base_url 或模型名错了。尤其是 base_url 不要写到具体接口路径。模型名也要完全匹配，不能自己猜。

{
  "model": "gpt-5.5-codex"
}

如果服务商给的是 codex-pro，你写成 Codex-Pro，有些接口会直接返回 404 或 model not found。

3. 429 Too Many Requests

请求频率太高或额度不足。VS Code 插件有时会在补全、聊天、解释代码之间连续发请求，容易触发限制。可以关闭自动补全，只保留手动触发。

4. timeout 或一直转圈

先把 timeout 调到 90000 或 120000，再测试短 prompt。如果短 prompt 正常，长文件分析超时，说明上下文太大，可以选中局部代码再提问，不要整文件塞进去。

七、实际使用建议

• 先选中代码再提问：让 Codex 只看必要上下文，速度和准确度都会更好。
• 明确语言和框架：比如“按 Spring Boot 3 写 Controller”，不要只说“帮我写接口”。
• 让它先解释再修改：复杂重构前，先让插件说明改动点，再让它生成补丁。
• 不要直接覆盖核心代码：建议使用 Git 分支，确认 diff 后再提交。
• 控制上下文长度：日志、依赖文件、压缩后的前端代码不要整段丢进去。

八、一个推荐的测试流程

新接一个 Codex 类接口时，我一般按这个顺序测：

1. curl 测 /v1/chat/completions 是否正常
2. VS Code 插件填 API Key、base_url、model
3. 用一句短 prompt 测响应
4. 测选中代码解释
5. 测生成小函数
6. 测项目内重构
7. 再打开自动补全或更长上下文

这样做的好处是每一步都有明确边界。出了问题，能知道是接口、插件、代理、模型名，还是上下文太大导致的。

总结

Codex 在 VS Code 中使用，关键不在插件名字，而在接口参数是否填对：API Key 要匹配平台，base_url 通常写到 /v1，模型名按服务商提供的来，代理和 timeout 要结合本地网络调整。先用 curl 测通，再接 VS Code 插件，排查效率会高很多。日常开发中，建议从小范围代码开始使用，确认结果后再做大规模重构。