📺 B站：博主个人介绍

📘 博主书籍-京东购买链接*：Yocto项目实战教程

📘 加博主微信，进技术交流群： jerrydev

Codex 在 VS Code 中的完整使用指南（安装、登录、工作流与最佳实践）

适用人群：希望在 VS Code 里“直接让 AI 帮你写、改、跑、验收代码”的开发者。本文面向实战：从安装登录，到可控工作流、配置与安全策略，给你一套能长期使用的打法。

0. 10 分钟上手路线（先跑通再优化）

  1. 安装 VS Code 扩展：Codex – OpenAI’s coding agent（发布者：OpenAI）。
  2. 打开 Codex 侧边栏 → Sign in with your ChatGPT account（浏览器授权）或选择 API Key。
  3. 打开你的工程目录（Workspace）→ 标记为 Trusted（可信工作区）。
  4. 在 Codex 输入框下方切到 Agent（默认）模式。
  5. 选中一段代码（或打开 2~3 个相关文件）→ 让它“先给计划，再提交补丁”。

跑通这 5 步，你就已经进入 Codex 的正确使用方式：工程上下文 + 可审查改动 + 可闭环验证。

在这里插入图片描述

1. Codex 到底是什么：它不是“聊天插件”，而是编码代理

很多人把 Codex 当作“IDE 里的 ChatGPT”。

更准确的定位：Codex 是一个编码代理（coding agent），目标是帮助你“写、评审、交付代码”。它的强项不是聊得多，而是：

  • 读懂你的工程上下文：利用你打开的文件、选中代码、工作区结构。
  • 以补丁（diff）方式产出改动：让你能审查、回滚、拆分提交。
  • 能跑命令形成闭环：构建、测试、格式化、lint、日志分析，然后继续修。
  • 可委托大任务到云端：把较大、较慢的任务交给 Codex Cloud 处理，再回到本地接棒验收。

一句话：把它当作“会提交补丁的同事”，你负责目标与验收，它负责执行与迭代。

2. 选哪个扩展：优先用 OpenAI 官方的 Codex

VS Code 市场里“GPT/ChatGPT”相关扩展很多。

如果你追求：

  • 更稳定的登录、更新与能力一致性
  • 更贴近官方工作流（Agent/Chat、审批与沙箱）

建议直接用 OpenAI 官方扩展：

  • Codex – OpenAI’s coding agent（发布者：OpenAI）

第三方扩展也能用，但通常需要额外配置多家 API Key、权限策略，且体验差异较大。

3. 安装与登录：两种方式，优先用 ChatGPT 账号

3.1 安装

  1. VS Code → Extensions（扩展）
  2. 搜索 Codex – OpenAI’s coding agent
  3. 安装后，左侧活动栏会出现 Codex 图标（有时在折叠区）

3.2 登录方式 A：ChatGPT 账号（推荐）

  1. 打开 Codex 面板
  2. 点击 Sign in with your ChatGPT account
  3. 浏览器打开授权页 → 登录 → Allow/Approve
  4. 回到 VS Code，Codex 显示已登录

多数 ChatGPT 订阅（如 Plus/Pro/Business/Edu/Enterprise）包含 Codex 能力。

3.3 登录方式 B：API Key（可选）

如果你需要：

  • 团队统一计费/配额
  • 企业网络限制无法走账号授权

可选择 API Key 登录（在 Codex 面板/设置中选择 API Key 方式）。

3.4 常见登录卡点（快速排查）

  • 点登录没反应：VS Code 命令面板 → Developer: Reload Window。
  • 浏览器授权成功但 VS Code 还没登录：退出重新登录；检查是否有拦截弹窗/第三方 cookie。
  • 企业网络：尝试切换网络/代理规则；确保登录域名不被拦截。

4. 三个最重要的概念：模式、沙箱、审批

Codex 好用的关键，是把“能力”变成“可控”。你必须理解这三件事：

4.1 模式（Mode）：Chat vs Agent vs Agent (Full Access)

  • Chat：只讨论与规划，适合“先想清楚再动手”。
  • Agent（默认）：在工作目录内读/改/跑命令；访问工作区外或网络通常需要你确认。
  • Agent (Full Access)：权限更大，适合确实需要网络/更广范围操作的场景；建议短期开启，用完即关。

实战建议：日常开发 Agent 足够。除非你明确需要网络访问，否则不要常开 Full Access。

4.2 沙箱（Sandbox）：它“技术上能做什么”

沙箱决定了 Codex 的可达范围，比如：

  • 可写哪些目录
  • 能不能访问网络
  • 能不能运行某些命令

4.3 审批策略（Approval policy）：它“什么时候必须问你”

审批策略决定它在执行动作前是否弹确认，例如：

  • 运行命令
  • 离开工作目录
  • 访问网络

实战建议：选择“更窄的批准范围”更安全。不确定时，先 approve once（仅一次），再观察它的行为。

5. Codex 的“上下文”怎么喂：越精准越强

Codex 不是读心术，它靠上下文做判断。你提供得越清晰，它越稳定。

5.1 三种最有效的上下文来源

  1. 打开相关文件（2~5 个足够）：入口文件、关键接口、调用点。

  2. 选中关键代码段：函数、结构体、配置块。

  3. 明确范围与约束：

    • “只改这些文件：@a.c @b.h”
    • “不要动 third_party/ vendor/ toolchain”

5.2 用 @文件 做精确引用

当工程大、路径深时，强烈建议用 @ 明确文件：

  • 请解释 @drivers/foo.c 的 probe 流程，并指出资源释放路径。
  • 请基于 @meta-layer/recipes-app/app.bb 修复 do_install 报错，给出最小补丁。

5.3 让它先“复述任务理解”

你可以强制它先对齐目标：

  • 在开始改动前，请用 5 行复述：你理解的目标、约束、验收标准。

这一步能显著减少“改偏了”。

6. 可复制的五类工作流（从简单到复杂）

6.1 工作流 1：读懂陌生仓库（建立心智地图）

目标：快速搞清入口、模块职责、关键数据结构、生命周期。

提示模板：

  • 以 @main.c 为入口，输出模块级流程（编号列表），并标注每一步对应的文件/函数。
  • 列出这个模块最容易失败的 5 条路径（错误处理/资源释放/并发）。

6.2 工作流 2：修 Bug（最小改动 + 可验证）

目标：只修问题，不顺手大改；补测试或检查点防回归。

提示模板：

  • 这是复现步骤与日志：...。请先定位根因，再提交“最小补丁”。不要重构。补一个回归测试或检查点。
  • 只允许改：@a.c @b.h。其它文件一律不改。

6.3 工作流 3：重构（先计划后补丁，分步提交）

目标：结构更清晰，但风险可控。

提示模板：

  • 先给 6 步重构计划（含风险点与回滚策略），我确认后再生成 patch。验收标准：行为不变/测试通过。

6.4 工作流 4：新增功能（用验收标准驱动实现）

提示模板：

  • 新增功能：X。验收标准：1)... 2)... 3)...。请拆成 3 个提交：接口/实现/测试与文档。

6.5 工作流 5：构建与日志闭环（非常适合 Yocto/内核/OTA）

提示模板：

  • 这是 bitbake 报错/编译日志/链接错误：...。请定位根因，给出可执行修复步骤 + 最小补丁，并说明为什么这样改。
  • 这是 dmesg/journalctl：...。请指出最可能的触发链路，并建议我先验证的 3 个观察点（命令/路径）。

7. Prompt Playbook：10 条高命中提示词（复制即用）

  1. 只解释不修改：请解释 @file 的职责、入口、关键数据结构、失败路径。
  2. 只改一个文件：只允许改 @foo.c，目标是修复这个崩溃点，给最小补丁。
  3. 先计划：先输出修改计划 + 风险点 + 验收项，通过后再生成 patch。
  4. 不要改变行为：只做重构（保持输出一致），并补充注释与边界检查。
  5. 补测试：为这个 bug 增加最小回归测试，确保未来能被捕获。
  6. 保持项目风格：不引入新依赖、不改命名风格、不做无关格式化。
  7. 解释构建失败：解析这段 gcc/ld/bitbake 输出，定位根因并给修复提交。
  8. 安全审查：检查是否有密钥泄漏、命令注入、不安全默认值，并给出修复建议。
  9. 性能约束：只优化热点路径，给出基准方法与预期收益，避免过度设计。
  10. 可回滚提交：拆成两次提交：功能 commit + 清理/文档 commit，便于回滚。

8. 最佳实践：让 Codex “稳、快、可控”的 8 条铁律

  1. 小步迭代：一次只解决一个目标（修 bug / 加日志 / 补测试）。
  2. 先计划后补丁：复杂任务必须先出计划与风险点。
  3. 写清验收标准：例如“编译通过、单测通过、行为不变”。
  4. 限制改动范围：明确“只改哪些文件/目录”。
  5. 所有改动必须 review diff：尤其是错误处理与资源释放。
  6. 先本地验证再合入：跑构建、跑测试、跑 lint。
  7. Git checkpoint：任务前后各一次提交，必要时用分支。
  8. 权限最小化：默认 Agent；只在必要时开 Full Access。

9. 配置：把 Codex 调成你的默认开发搭档

Codex 支持用户级与项目级配置，并且 CLI 与 IDE 扩展共享同一套配置层。

9.1 配置文件位置

  • 用户级：~/.codex/config.toml
  • 项目级：<repo>/.codex/config.toml

为安全起见，Codex 只会在项目被标记为 Trusted 时加载项目级 .codex/config.toml。

9.2 从 VS Code 直接打开配置

通常在 Codex 面板右上角齿轮（⚙️）里，能找到类似：

  • Codex Settings → Open config.toml

9.3 一个建议的“保守型默认配置”（可直接粘贴）

# ~/.codex/config.toml
# 目标：日常开发稳定、安全、可控

# 默认模型（按你账户可用情况选择）
model = "gpt-5.2"

# 审批策略：更保守更安全（具体可选值以官方参考为准）
approval_policy = "on-request"

# 沙箱模式：只在工作区内写入（减少误操作范围）
sandbox_mode = "workspace-write"

如果你遇到“每一步都在问是否批准”的情况，通常与审批策略、沙箱模式、工作区是否 Trusted 有关。优先确认：工作区已 Trust，然后再调审批策略。

10. 安全与隐私：把它当“能动手的工具”来管理

建议坚持 5 条底线：

  1. 不要把密钥/Token/证书私钥放进对话（能用占位符就占位符）。
  2. 尽量不让它访问工作区外目录（除非你明确需要）。
  3. 网络访问谨慎批准：不确定就只 approve once。
  4. Web 信息不等于正确：命令与配置必须可验证。
  5. 所有改动都要可回滚：Git 分支/提交点必须先建好。

11. 常见问题与排查（最常见的 12 个坑）

  1. 看不到 Codex 图标：扩展是否装对（发布者是否 OpenAI）；重启 VS Code。
  2. 无法登录：Reload Window；检查网络/代理/弹窗拦截；退出重登。
  3. Agent 不改代码：确认不是 Chat 模式；确认工作区 Trusted。
  4. 老是要批准：检查 approval_policy；确认沙箱模式；确认 Trusted。
  5. 不能跑命令：沙箱限制或审批未通过；先 approve once 验证流程。
  6. 工程很大它容易跑偏：用 @文件 + “只改这些文件”强制约束。
  7. 改动太大难 review：让它分 2~3 个 commit；或者拆任务。
  8. 它顺手重构导致引入风险：提示里写死“不要重构/不要改风格”。
  9. 构建失败反复循环：让它先列 3 个假设与验证点，再动手。
  10. 企业环境依赖私服：尽量本地跑命令并贴输出；不要强行开 Full Access。
  11. 混合系统（WSL/容器/远程）路径混乱：确保工作区在同一环境内，避免跨文件系统。
  12. 不确定它做了什么：要求它输出“改动摘要 + 文件清单 + 风险点”。

12. 嵌入式/Yocto/内核场景：Codex 的高价值用法

你做嵌入式与系统工程，Codex 最能省时间的地方通常在：

  • 解析 bitbake 日志：do_compile/do_install 失败、依赖缺失、路径错误。
  • 写/改 Yocto 菜谱与 bbappend：systemd service、安装路径、FILESEXTRAPATHS。
  • 写启动脚本与 systemd unit：开机自启、依赖顺序、日志采集。
  • 读 dmesg/journalctl：驱动 probe 失败、DT 匹配、资源申请失败。
  • OTA 脚本与回滚策略：小步改动 + 明确验收。

示例提示（非常实用）：

  • 这是 do_install 报错（粘贴日志）。请指出是哪一步安装路径不对，并给最小补丁修复 @xxx.bb。
  • 这是 dmesg 中 i2c probe fail 的片段。请从 @driver.c 与设备树节点匹配关系推断最可能原因，并给我 3 个验证命令。

13. 30 分钟练习计划：把它用“顺手”

第 1 轮（10 分钟）：

  • 让它解释一个文件：入口、职责、失败路径。

第 2 轮（10 分钟）：

  • 选中一个小函数：让它只做“增加错误处理/日志”，不重构。

第 3 轮（10 分钟）：

  • 给一个真实构建/日志片段：让它先列根因假设与验证点，再给最小补丁。

只要你完成这 30 分钟，Codex 基本就能融入你的日常工程节奏。

结语

Codex 的正确打开方式不是“让 AI 替你写完一切”，而是：

  • 你提供目标、约束、验收标准
  • 它输出计划与补丁
  • 你审查 diff、跑构建与测试

这样你获得的是稳定可控的工程效率提升，而不是不可预测的“自动化惊喜”。

📺 B站：博主个人介绍

📘 博主书籍-京东购买链接*：Yocto项目实战教程

📘 加博主微信，进技术交流群： jerrydev

# 安全 # 算法 # 数据库 # 开发语言
Logo
2048 AI社区

有“AI”的1024 = 2048，欢迎大家加入2048 AI社区

更多推荐

cover

什么是GEO？为什么中国出海企业必须重视AI搜索优化？

avatar 2048 AI社区
cover

简历模板哪些平台的排名比较靠前？

avatar 2048 AI社区
cover

Vscode插件：Markdown Preview Mermaid Support介绍（Mermaid布局语法classDef）

avatar 2048 AI社区