Appearance
最后更新时间：2026 年 10 月 24 日
Codex VS Code 扩展怎么用？安装、项目协作与代码审查教程
Codex VS Code 扩展把 OpenAI 的编程智能体放进代码编辑器。它适合已经用 VS Code 打开项目、希望在编辑器里讨论代码和检查修改的用户。扩展可以帮助你理解项目、生成或修改代码，并根据当前产品能力执行相关操作；具体权限和功能会随版本变化。安装之后仍需要明确任务范围，审查文件差异并运行测试。
国内中文入口：AIMI 和 AIBox
如果你还没安装编辑器扩展，可以先在 AIMI 或 AIBox 里用中文整理需求、讨论代码方案或解释报错。这两个入口由第三方平台提供，不是 OpenAI Codex 扩展，也不能默认具备 VS Code 工作区访问、终端执行或本地代码修改能力。可用模型、上传功能、隐私和收费规则以平台当前说明为准。公司代码和密钥应先确认是否允许发送到外部服务。
从官方 Marketplace 安装
OpenAI 的 Codex 扩展在 Visual Studio Marketplace 上发布。建议从 Codex 扩展官方 Marketplace 页面打开，再点击安装或在 VS Code 中查看。安装时核对 OpenAI 发布者和扩展标识，不要只凭图标或名称相似来判断身份。编辑器市场和扩展支持的平台可能调整，最终以 Marketplace 当前信息为准。
在 VS Code 中也可以打开 Extensions 面板，搜索 Codex，点开结果查看发布者、标识、更新记录和权限说明。若搜索结果有多个近似名称，逐一核对，不要选择评价数量多但发布者不明的项目。组织设备可能限制扩展安装，应遵守管理员策略，而不是绕开限制安装 VSIX 文件。
安装后按 VS Code 提示重新加载窗口。第一次启动扩展，按照当前界面登录 OpenAI 或 ChatGPT 账号。计划、地区、组织策略会影响 Codex 的可用性和额度；登录前可查看 Codex 与 ChatGPT 计划说明。不要向他人发送验证码、登录 URL 或令牌。
打开正确的工作区
扩展能否理解项目，首先取决于 VS Code 当前打开的文件夹。通过 File > Open Folder 打开项目根目录，确认 Explorer 显示的是预期仓库。若只打开了单个文件，模型可能看不到项目配置、相关组件和测试。多根工作区、Remote SSH、Dev Container 和 WSL 也会影响文件实际所在环境，先确认扩展连接的是你希望操作的那个工作区。
开始前在终端或 Source Control 面板查看 Git 状态。确认当前分支、未提交修改和项目运行命令。涉及重要仓库时先创建分支或提交稳定版本。不要把数据库凭据、生产环境变量、真实客户信息放在项目上下文中；需要模型分析时，先制作匿名化的小样本。
第一条消息可以让它只读：
请检查当前工作区的项目说明和主要目录，概括应用入口、测试方式以及与登录设置相关的文件。先不要修改代码；如果找不到测试命令，请列出你检查过的配置文件。
检查它提到的路径是否真实。模型如果引用了不存在的函数或配置，就指出错误并让它重新查证。这个步骤也能确认扩展是否看到了预期的项目，而不是另一个窗口或仓库。
提出适合编辑器协作的任务
IDE 扩展最适合围绕当前文件和仓库做小步任务。一个好的请求包含现象、目标、约束和验证标准：
现象：商品列表筛选后，空结果区域没有提示文字。
目标：增加空结果提示，并保持页面现有视觉样式。
范围：检查列表组件和相关测试；不改 API 和数据结构。
验收：有结果时列表显示不变，无结果时展示提示；更新或新增组件测试。请先说明计划，再修改。
VS Code 中的审查节奏
收到扩展提出的计划后，先检查它列出的文件是否覆盖真正的调用链。一个组件的显示问题可能还涉及数据请求、类型定义、路由和测试夹具；如果计划只改样式文件，就要求它说明为什么不需要修改数据层。实现完成后，在 Source Control 面板查看每个文件的差异，确认没有把格式化、无关重命名或调试输出混进补丁。
测试应从最接近用户行为的命令开始，再根据失败信息扩大范围。前端项目可以先运行相关组件测试和类型检查，再执行构建；后端项目可以先跑单元测试，再验证接口或集成测试。扩展显示“已完成”时，仍要确认命令确实执行过，失败的测试没有被跳过，截图或报告中的路径属于当前工作区。对于视觉变化，打开开发服务器进行手工检查，不能只看快照。
Remote、容器和多根工作区
VS Code 的 Remote SSH、Dev Container、WSL 和多根工作区会改变文件所在位置。扩展可能连接到远程环境，也可能仍在本地窗口中运行；开始任务前可让它报告当前工作区路径、操作系统和项目根目录。依赖安装、测试命令和环境变量应在实际运行代码的环境中执行。不要把本地密钥复制到容器或远程主机，也不要把远程生产目录误当成测试目录。
如果多人共享一个远程工作区，先确认分支和未提交修改。扩展生成补丁后，保留一个可回滚提交，并把任务拆成小块。出现连接中断时，不要立即重做全部操作，先检查 Git 状态、文件修改时间和终端输出，确认哪些步骤已经完成。对无法确认的文件，优先恢复到可审查状态，再继续。
扩展安全和组织规则
扩展安装后可能请求读取工作区、访问网络或运行任务所需命令。公司项目应遵守组织的扩展白名单、代码外发和日志保留规定。把客户数据、私钥、令牌和生产配置排除在上下文之外；需要分析真实数据时，制作匿名化样本。若扩展建议安装额外依赖或下载脚本，先核对来源、版本和许可证，再决定是否执行。
一个前端修复案例的验收清单
以“筛选后空列表没有提示”为例，先记录复现步骤、浏览器和数据条件，再让扩展找出组件、状态来源和已有测试。实现后分别验证有结果、无结果、加载中、请求失败和清空筛选五种状态，确认提示不会遮挡重试按钮，也不会改变原有列表布局。最后运行类型检查、相关测试和生产构建，并在浏览器中手动点击一次。只有这些证据都与需求对应，才适合把改动交给评审；如果只改了文案却没有验证状态流转，应继续补充测试或明确限制。
如果你选中了代码再提问，要说明选择部分是完整上下文还是一个片段。编辑器里的选择能提供线索，但不能替代你说清楚预期行为。需要同时修改多个文件时，可以让 Codex 先列出文件与原因；等你确认后再执行，减少无关改动。
任务边界最好写成可核验条件，例如不添加依赖、不更改导出接口、不移动目录、不改格式化配置。不要叠加太多无关目标，比如同一轮既重构组件、升级框架、改主题色又修复错误提示。每个变更都有单独验收方法时，排错更容易。
检查 diff 和运行测试
扩展完成任务后，查看 Source Control 或 Codex 提供的改动视图，逐文件检查：
- 修改是否只涉及任务相关文件；
- 是否出现大段无关格式化或文件重命名；
- 是否新增依赖、改配置或更改 API；
- 测试是否验证用户能观察到的行为；
- 终端命令是否真实执行，输出是否对应当前工作区。
不要仅根据模型摘要判断任务成功。启动项目实际操作页面，查看错误和正常场景。测试没跑时，应把状态当作尚未验证，而不是通过。测试失败时把完整日志交给 Codex 分析，并确认修复没有删除测试断言或放宽校验来掩盖问题。
如果扩展给出运行终端命令或联网的审批提示，先检查完整命令、参数和当前目录。安装软件包、删除文件、写入系统路径、上传数据和访问生产环境都有不同影响。无法判断时拒绝执行并让它解释替代方式。审批是你理解变更边界的机会。
VS Code 扩展与其他 Codex 入口的区别
VS Code 扩展把任务放在编辑器和工作区旁边，适合频繁查看源文件、边改边测；CLI 更适合终端脚本、批处理和命令行习惯；桌面 App 面向图形化任务管理；云端 Codex 面向连接仓库后的远程工作。不同入口的文件访问、执行环境和审批方式不完全相同。
如果你已经通过 VS Code 扩展操作某个仓库，不要再同时让 CLI 或另一桌面会话改同一分支。多个会话可能看到不同上下文，结果造成覆盖或冲突。确需并行时，使用独立分支或工作区，完成后分别审查差异，再按 Git 正常流程合并。
扩展不等于 VS Code 自带的补全功能，也不等于浏览器里的一般 ChatGPT 对话。它面向项目级编程协作。对于只需解释一段函数或讨论概念的简单问题，普通聊天可能更直接；需要跨文件理解、改动和测试时，IDE 上下文才更有价值。
常见问题与排查
Marketplace 找不到扩展怎么办？
从官方 Marketplace 页面进入，核对网络、编辑器版本和组织策略。如果使用兼容编辑器，扩展可用性未必相同；不要随意下载非官方打包文件。
扩展登录失败怎么办？
检查账号资格、组织策略和官方服务状态。确认登录页面属于 OpenAI 相关域名，并使用自己控制的账号。不要把验证码或授权链接发送给别人代操作。
扩展看不到相关文件怎么办？
确认 VS Code 打开的是项目根目录而不是单文件，检查文件是否排除在工作区之外，并确认 Remote、WSL 或容器位置正确。让它先列出读取到的相关路径，再开始修改。
Codex 改动后怎么撤销？
在提交前通过编辑器的 diff 和 Git 状态确认涉及文件，再用 VS Code 源代码管理功能逐项丢弃或保留修改。不要对整个仓库执行重置，除非确认所有未提交内容都可以删除。
AIMI 或 AIBox 能直接使用这个 VS Code 扩展吗？
不能把第三方网页入口和 OpenAI 官方扩展等同起来。只有明确支持的集成方式才可以连接编辑器，且要分别评估授权、数据流和权限。
官方资料
VS Code 扩展能省去在编辑器与聊天窗口间反复切换的步骤，但不会自动知道项目的业务规则。打开正确工作区、写清任务条件、审阅每个文件差异、运行适当测试，才是把 Codex 纳入日常开发的可靠方式。