AI Code With · Codex VS Code 与 Windows 实战教程
第一次在 VS Code 里用 Codex，最不建议的开场是：“把这个项目整体优化一下。”
问题不是 Codex 一定做不好，而是当安装、登录、上下文、模型、网络和代码修改同时发生时，你根本不知道哪一层出了问题。更稳的第一次应该很小：确认官方扩展能打开、登录链路正常、Codex 能读到你选中的代码，然后只改一个函数、跑一个测试、看一遍 Diff。
Windows 用户还多一层变量：浏览器能联网，不代表 VS Code 里的 Codex 进程一定走同一套代理和证书；独立 PowerShell 能访问，也不代表已经打开的 IDE 继承了最新环境。
先把“能登录、能读上下文、能改一个小地方、能审查 Diff”跑成闭环，再扩大任务。
1. 先明确这篇教程要跑通什么
这篇不是教你堆一大堆配置，而是跑通一个最小可验收闭环：
安装官方 Codex 扩展
↓
登录并确认当前认证方式
↓
打开一个 Git 项目
↓
把选中的代码作为上下文
↓
让 Codex 做一个小改动
↓
检查 Diff 与测试
↓
如果失败，再分层排查 Windows 网络 / Provider
只要这条链路能稳定复现，后面换模型、接第三方 Provider、扩大任务范围都会容易很多。
2. 安装：先确认你装的是官方 Codex IDE 扩展
当前 OpenAI 文档确认，VS Code、Cursor 和 Windsurf 使用 Codex extension。安装时最好从 OpenAI Codex IDE 官方文档进入 Marketplace，再核对发布者，避免装到同名或过期扩展。
安装后重新加载 VS Code，打开一个有 Git 的小项目。第一次不要同时做这四件事：更新扩展、改 CLI 配置、切换登录方式、换模型。一次只引入一个变量，出现问题时才有办法定位。
3. 登录：ChatGPT 和 API Key 是两条不同路径
当前 Codex IDE 支持两种常用登录方式：Sign in with ChatGPT，以及 Use API Key。两条都能让本地 Codex 工作，但计费、可用能力和后续 Provider 逻辑不同。
| 登录方式 | 适合场景 | 你首先该看什么 |
| Sign in with ChatGPT | 已经有 ChatGPT 计划，主要使用官方 Codex 工作流 | 当前账户、工作区、计划内可用能力 |
| Use API Key | 希望按 API 计费，或进入自定义 Provider / 自动化场景 | Key 所属账户、API 计费和模型权限 |
CLI 和 IDE 会共享本地登录缓存
OpenAI 当前认证文档明确说明，CLI 和 IDE extension 会复用同一份本地缓存登录信息。也就是说，你在 CLI 或 IDE 其中一个退出后，另一边下次启动也可能需要重新登录。
codex login status
这条命令适合确认 CLI 当前认证方式，但不要把它当成“IDE 当前 Provider 一定和 CLI 完全相同”的证明。认证缓存可以共享，运行时配置和 Provider 仍可能不同。
如果使用文件型凭证存储，~/.codex/auth.json 要按密码对待：不要提交到 Git，不要放进 README、截图、工单或聊天记录。
4. 第一次任务：只改一个能撤回的小地方
IDE 场景最大的优势，是代码和上下文就在你眼前。OpenAI 当前文档支持把打开的文件、选中的代码以及近期聊天直接带进 Composer。
第一次可以直接用这样的任务：
只修改我选中的这个函数：
1. 增加参数校验；
2. 补一个对应单元测试；
3. 不修改公共 API；
4. 不新增依赖；
5. 完成后先给我看 Diff；
6. 不要继续扩大修改范围。
这个 Prompt 的好处是每一条都能验收。相比“帮我优化项目”，你可以明确知道它有没有改错范围、有没有偷偷引入新依赖、测试是否真的覆盖新分支。
5. 用编辑器上下文，而不是把整个仓库一股脑塞给模型
Codex IDE 可以直接利用你当前打开的文件和选中代码。对于局部修改，先把上下文缩到相关文件，通常比一句“看看整个项目”更容易得到可检查的结果。
一个实用原则是：
• Bug 很明确：先选中报错函数和对应测试。
• 需要理解调用链：再补充直接调用方和相关类型定义。
• 确实需要跨模块修改：先让 Codex 列计划，再逐步扩大读取范围。
• 不要为了“保险”把整个仓库、历史日志和长会话都同时塞进去。
这样做不仅更容易审查，也能减少无关上下文带来的 Token 消耗。
6. 先看 Diff，再决定要不要接受
OpenAI IDE 文档明确把“在代码旁审查 Diff”作为核心工作方式之一。真正需要检查的不是一句“修改完成”，而是改动本身。
| 审查项 | 具体看什么 |
| 范围 | 有没有修改目标之外的文件 |
| 依赖 | 有没有新增 package / library / config |
| 行为 | 边界条件、错误处理有没有改变 |
| 测试 | 测试是否覆盖这次新增分支，而不是只跑旧测试 |
| 风格 | 错误信息、命名和项目已有风格是否一致 |
看得懂就接受；看不懂就追问；范围明显跑偏就撤回。IDE 的价值就在于源代码、改动和理由放在同一个地方，不需要来回复制。
[真实截图待补：一次小修改前后 Diff + 测试结果]
7. CLI 正常、VS Code 不正常，先比较这 5 件事
• 当前登录方式是否一致。
• IDE extension 是否是当前版本。
• 当前工作区是否受信任。
• 需要引用的文件或代码是否真的处于打开 / 选中状态。
• CLI 和 IDE 是否读取了不同的配置、Provider 或环境。
不要因为 CLI 能跑，就默认 VS Code 一定走同一条第三方 Provider 路径。先用最小请求分别验证，再讨论更复杂的模型配置。
8. Windows 网络问题：别把系统、进程和 API 路由搅在一起
Windows 上最常见的误判是：浏览器能打开网页，所以 Codex 网络一定没问题。实际上至少要分三层：Windows 系统网络、启动 VS Code / Codex 的进程环境、API Provider 与路由。
第一层：系统网络能不能到真实目标主机
Resolve-DnsName <target-host>
Test-NetConnection <target-host> -Port 443
目标主机必须来自你真正使用的服务或已核实 Provider。DNS 正常、443 可连，只证明基础网络走通了一步，不代表认证、模型、Base URL 和 API 协议都正确。
第二层：VS Code 当前进程到底继承了什么
Get-ChildItem Env: | Where-Object { $_.Name -match 'PROXY|OPENAI|CODEX' }
这条命令不会修改系统。它的作用是看当前 PowerShell / IDE 进程拿到了哪些相关环境变量。输出可能包含敏感地址，分享前要脱敏。
尤其注意：环境变量通常在进程启动时继承。你改了系统代理以后，如果 VS Code 一直没重启，它可能继续使用旧环境。独立 PowerShell 正常、IDE 终端失败时，先从这里查，而不是先重装 Codex。
第三层：网络能到以后，再检查 Provider、Base URL、认证和模型
如果官方登录正常，只有 API Key / 自定义 Provider 失败，这时才进入 API 路由层。
Key 正确，不代表 Base URL 正确；Base URL 正确，也不代表 Model ID 和协议匹配。
9. 错误码其实在帮你分层
| 错误 / 现象 | 更接近哪一层 | 优先检查 |
| DNS 失败 | 系统网络 | 目标主机 / DNS |
| 超时 | 网络 / 代理 / TLS / 上游 | 可达性和进程环境 |
| 407 | 代理认证 | 企业代理凭证 |
| 401 | 登录 / API 认证 | Key、缓存凭证、当前账户 |
| 404 | 路径 / API 资源 | Base URL、Endpoint、错误体 |
| 502 | 网关 / 上游 | Provider / 渠道 / 上游状态 |
看到 401 就改系统代理，或者看到 502 就删 Key，往往会把问题带到更远的地方。每次保留完整错误、时间、目标主机和当前进程环境摘要。
10. 什么时候才需要把 AI Code With 加进排查链
如果你一直使用 ChatGPT 登录，这一节可以跳过。只有当你明确走 API Key / 自定义 Provider 时，AI Code With 才与 VS Code 的模型接入直接相关。
AI Code With 在这里不是 Windows 网络代理，而是模型 API、Key、渠道和调用记录的管理层。网络层已经可达以后，再核对 Provider、Model ID 和真实请求记录才有意义。
当前公开 Codex 接入文档使用的专用地址是：
https://api.aicodewith.ai/chatgpt/v1
如果你需要切换模型，不建议把文章里某个 Model ID 长期写死。更稳的是从实时模型页复制当前可用 ID，发一个最小请求，再回控制台核对这次请求是否由预期 Key 和模型产生。
这一步的验证标准不是“VS Code 界面显示某个模型名”，而是本地状态和后台真实调用记录能对应上。
11. 一个实际排错案例：浏览器正常，VS Code 一直超时
假设你刚在 Windows 上配置完 Codex，浏览器能访问目标站点，独立 PowerShell 里网络测试也通过，但 VS Code 内的 Codex 一直 timeout。
先不要改 Key。检查后发现系统代理是在 VS Code 启动以后才修改的，IDE 内置终端仍继承旧环境。完全退出 VS Code，重新打开，再做相同的最小请求，timeout 消失。
如果这时又出现 401 或 model not found，反而说明你已经前进了一层：网络请求至少到达了某个 API 层。此时再继续查认证或 Model ID，而不是回去继续折腾 Windows 代理。
错误变化不是坏事。它往往说明故障边界正在缩小。
12. 第一次使用完成后，用这份清单验收
□ 官方 Codex 扩展已经确认并能正常打开。
□ 我知道当前是 ChatGPT 登录还是 API Key。
□ CLI / IDE 的登录缓存关系已经理解，没有把 auth.json 当普通配置文件。
□ 第一次任务只改了一个可撤回的小范围。
□ 我看过 Diff，而不是只相信“修改成功”。
□ 测试结果是真实执行结果，不是模型口头描述。
□ Windows 网络排查按系统 → 进程 → Provider 顺序进行。
□ 每次只改一个变量，保留错误和时间。
□ 如果使用 AI Code With，已用真实调用记录验证 Provider / Key / 模型。
13. 最后：VS Code 里的 Codex 好不好用，关键不是第一次任务有多大
一个成熟的 IDE 工作流不是“让 Agent 一次改得越多越好”，而是你能快速判断上下文是否正确、Diff 是否可信、测试是否通过，失败时又能知道问题属于登录、网络还是 Provider。
先把一个小改动跑成可重复闭环，再扩大任务，比一上来追求全项目自动优化更稳，也更容易控制成本和风险。
资料来源与核对说明
OpenAI Codex IDE：https://developers.openai.com/codex/ide
OpenAI Authentication：https://developers.openai.com/codex/auth
AI Code With Codex：https://docs.aicodewith.ai/zh/docs/codex-app
AI Code With 模型列表：https://aicodewith.ai/zh/dashboard/pricing
