第一阶段：骨架完整

• 建立 VuePress + Theme Hope 文档站。
• 建立 README、贡献指南、行为准则和安全政策。
• 搭建入门、进阶、团队和案例目录。
• 添加官方资料索引。
• 补充第一批截图和命令输出。
• 给每篇教程增加“适用版本”和“最后核对日期”。

第二阶段：指南成型

• 完成 CLI 从安装到日常使用的完整教程。
• 完成 AGENTS.md 专题。
• 完成提示词模板库。
• 完成排障手册第一版。
• 补齐 Cloud、IDE、桌面 App 的使用差异。

第三阶段：案例驱动

• 收集 20 个真实工程案例。
• 每个案例包含任务说明、关键过程、验证方式和复盘。
• 建立案例标签：前端、后端、测试、重构、文档、CI、安全。
• 补充失败案例，说明 Codex 不适合直接处理的场景。

第四阶段：社区传播

• 设计更完整的首页和 Open Graph 图。
• 建立中英文关键词索引。
• 发布 GitHub Pages。
• 整理适合社媒传播的短链接和学习路线图。
• 邀请早期贡献者认领章节。

贡献入口

你可以从这些任务开始：

• 修正文档里的不准确表述。
• 新增一个你亲自跑过的 Codex 案例。
• 给排障手册补一个常见错误。
• 把官方文档的新变化同步到资料索引。

三种使用姿势

| 模式 | 适合任务 | 典型命令 |
|

配置文件放在哪里

通常位于：

~/.codex/config.toml

项目长期规则建议写到仓库内的 AGENTS.md，个人偏好放到本机 config.toml。这样团队成员能共享项目规则，又能保留自己的 CLI 使用习惯。

最小配置示例

下面是一个学习用示例，实际字段请以官方 config reference 和当前 CLI 版本为准：

model = "gpt-5.1-codex-max"
approval_policy = "on-request"
sandbox_mode = "workspace-write"

[profiles.readonly]
approval_policy = "on-request"
sandbox_mode = "read-only"

[profiles.build]
approval_policy = "on-request"
sandbox_mode = "workspace-write"

这个示例表达三件事：

• 默认允许在当前工作区写文件。
• 高风险命令仍需要审批。
• 额外保留一个只读 profile，适合新仓库分析。

常见配置项按用途理解

| 用途 | 你要决定什么 | 建议 |
|

先理解四层配置

| 层级 | 典型文件或入口 | 解决的问题 | 初学者建议 |
|

三个概念

| 能力 | 解决的问题 | 适合沉淀什么 |
|

先分清风险等级

| 风险等级 | 例子 | 建议策略 |
|

最后核对

官方资料最后核对日期：2026-06-12。核心来源包括 OpenAI Codex 产品页、Codex 文档入口、Codex CLI 官方仓库 与 Codex Help Center。

Codex 的产品形态

Codex 有桌面 App、命令行、编辑器插件和网页几种形态。

• 桌面 App：我们最熟悉的软件形态，第一次上手推荐用这个。选一个文件夹，让 Codex 读文件、改文档、整理内容，或者直接聊天。
• CLI：终端里的 Codex，在项目文件夹里读代码、改文件、跑命令。
• Cloud / Web / ChatGPT：任务交给云端处理，或在 ChatGPT 里跟进项目。
• IDE：在 VS Code 等编辑器里用 Codex 插件，喜欢集成开发环境的开发者适用。
• GitHub、Slack、Linear、MCP 等集成：偏团队和进阶场景。

第一次用 Codex，推荐从桌面 App 开始。界面直观，功能齐全，对新手友好。

快速开始

1. 下载安装 Codex 桌面 App，先把软件打开。
2. 按需了解 订阅 ChatGPT Plus，确认账号能不能用 Codex。OpenAI Help Center 说明 Codex 包含在符合条件的 ChatGPT 计划中，包括 Free 档；具体用量限制因计划而异。
3. 阅读 了解 Codex 基本组成，知道项目、对话、设置大概在哪里。
4. 跟着 用 Codex 完成第一个任务，选一件小任务开始练手。
5. 如果你常用手机，可以再看 手机端如何跟进桌面任务。
6. 如果你需要第三方 API，再看 连接第三方 API。

第一轮目标：装好 Codex，能跟它正常交流，让它读一个你指定的文件夹。之后结合真实需求，试着完成一个小任务。

使用 Codex 开发

用过 Claude Code 的话，Codex 很容易上手。没用过也没关系，像平时用 AI 一样自然地用就行。

推荐顺序：

1. 先看 入口地图，知道 CLI、桌面 App、Cloud 和 IDE 分别适合什么。
2. 阅读 CLI 安装与登录，确认命令能正常运行。
3. 跟着 第一次让 Codex 改代码，从文档、测试或一个小 bug 开始。
4. 阅读 任务执行机制，理解它会读哪些文件、运行哪些命令、怎么汇报结果。
5. 了解 AGENTS.md，把项目规则写给 Codex 看。
6. 阅读 沙盒与审批，知道哪些操作需要先确认。

在开发过程中，你会碰到许多专有名词，这里先记住几个词就够了：

• 仓库（repository / repo）：
  一个项目的“家”。代码、文档、配置文件通常放这里，一般用 Git 记录变化。

• diff：
  “改了哪里”的对比清单。告诉你文件修改前什么样，修改后变成什么样。

• PR（Pull Request）：
  理解为“我改好了，请你帮我看一下”。
  团队协作时先提交改动，让别人审核，通过后再合并进主项目。

• CI（Continuous Integration）：
  自动检查流程。
  提交代码后，系统自动跑测试、检查格式、尝试构建，确认改动有没有明显问题。

• AGENTS.md：
  给 AI 编程助手看的“项目说明书”。
  告诉 Codex / Agent 项目规则、怎么运行、怎么测试、写代码注意什么。每次对话时，Agent 通常把它作为重要上下文参考。

不用强记所有名词。碰到陌生的词，直接让 Codex 解释；用多了自然熟。

使用 Codex 完成日常任务

很多人以为 Codex 只能写代码。其实只要有文件、有目标、有结果可检查，它都能帮上忙。比如：

• 把旅游攻略、酒店链接和预算表放在一起，让 Codex 帮你整理成一份行程清单。
• 读几份课程资料或 PDF，提炼重点、整理复习提纲。
• 把会议录音转写稿、聊天记录或零散备忘，整理成待办事项。
• 检查一份报名表、活动通知或教程，看看有没有缺步骤、时间写错、链接没说清楚。
• 把每周报销、周报、资料归档的重复步骤写成模板，下次直接复用。
• 整理家庭账单、购物清单、搬家清单、活动分工表这类零散文件。

从最近实际需要处理的小事开始。任务说得越具体，Codex 解决得越快。

下一步从哪里点

• 还没安装？：从 桌面 App 下载与安装 开始。
• 已经装好了：直接做 第一个任务。
• 想先知道不同入口怎么选：看 入口地图。
• 准备改真实项目：看 CLI 安装与登录。

最后核对

官方资料最后核对日期：2026-06-13。下载地址与安装方式以 OpenAI Codex 产品页 和 chatgpt.com/codex/get-started 为准，不同地区和账号套餐下可用功能可能有所差异。

本教程里说的 Codex 桌面 App，是电脑上的客户端，不是手机 App。它由 OpenAI 官方发布，支持 macOS 和 Windows，安装后你可以在本地管理项目、发起任务、使用 Skills 和 Automations。

下载

打开 chatgpt.com/codex/get-started，页面中央会显示对应系统的下载按钮。

macOS：

点击「Download for macOS」下载 .dmg 安装包。

1. 打开下载好的 .dmg 文件
2. 把 Codex 图标拖进「Applications（应用程序）」文件夹
3. 首次启动时，macOS 可能弹出「无法验证开发者」——无需担心，打开「系统设置 → 隐私与安全性」，点击「仍要打开」即可

Windows：

Windows 用户点击对应的下载按钮，下载完成后运行安装程序，按提示完成安装。

登录

安装完成后打开 App，使用 ChatGPT / OpenAI 账号登录。

安装后验证

登录成功后，左侧栏会出现「Projects」和「Chats」两个入口，顶部显示当前账号信息。如果界面正常加载，说明安装成功。

下一步：订阅 ChatGPT Plus / Pro

最后核对

官方资料最后核对日期：2026-06-13。定价与套餐以 ChatGPT 定价页 和 Using Codex with your ChatGPT plan 为准。

为什么需要订阅

免费版 ChatGPT 可以体验基础对话，但 Codex 功能（包括桌面 App、Cloud 任务、多 agent 并行）需要付费套餐才能稳定使用。

| 套餐 | 月费（美元） | Codex 可用情况 |
|

最后核对

官方资料最后核对日期：2026-06-13。本章参考 Codex App docs、Settings、Agent approvals and security 等官方资料。界面说明以当前 Codex 桌面 App 实际版本为准，不同系统、地区、客户端版本和账号套餐下显示可能略有差异。

认识对话和项目

打开 Codex，左侧栏就两个入口：Chat（对话） 和 Project（项目）。

Chat 对话

和 ChatGPT 网页版差不多，随手问问题。各对话互不相干，也不共享文件夹。

Project 项目

需要动本地文件时用它——写代码、改文档、做 PPT 都可以。项目里的所有对话共用同一个文件夹，方便一起管理。

在项目里下达指令后，Codex 的修改会直接应用到你本地文件夹中的文件。

对话框功能说明

Codex 的对话框和 ChatGPT 网页版类似，支持：

1. 添加上下文：可以附加文件、截图或其他参考内容
2. 切换模型：在不同模型之间切换

并额外支持：

3. 控制权限：设定 Codex 在当前任务中的操作权限
4. 选择工作目录：指定 Codex 在哪个本地文件夹下执行任务

插件与技能

包括 OpenAI 官方定制或推荐的插件与技能。

Skills 默认包含 Skills Creator、Skills Installer、OpenAI Docs 等技能，用来创建、安装技能，或获取 OpenAI 官方最新文档。在对话框中使用 $ 即可调用 Skills：

插件是 OpenAI 定义的外部工具入口，也可能包含 Skills、MCP、脚本等能力。常见插件包括 Computer Use、Browser Use、PPT、Docs、Excel、Slack、GitHub 等。不同插件可能有额外配置。

自动化

Codex 支持自动化执行任务，包括使用 MCP 服务器、钩子和插件等。

自动化会执行你指定的命令，你可以指定工作树、项目地址和定时的间隔。在下图中输入你的指令，并且配置即可。

设置面板

点击左下角头像或设置图标可以打开设置面板。

左侧是设置菜单。里面包含丰富的配置选项，详情如下：

设置说明

大部分情况下都是保持默认配置即可。配置很多时候都是按需开启。

个人

集成

编码

已归档

下一步：用手机端 Codex 跟进桌面任务

最后核对

官方资料最后核对日期：2026-06-13。本文参考 OpenAI 官方文章 Work with Codex from anywhere。具体入口、可用地区、系统支持和界面名称会随客户端更新变化，请以当前 ChatGPT 手机 App 和 Codex 桌面 App 为准。

Codex 现在支持 Android 和 iOS 手机。在手机上发消息，就能操作电脑上的 Codex。

简单说：电脑上的 Codex 在跑，手机连过去，离开电脑时也能查看、回复、审批和调整任务。

把 ChatGPT App 更新到最新版，然后选择连接电脑上的 Codex。

连接桌面 Codex APP：

在 ChatGPT 里打开 Codex 就能用。

它能做什么

手机连上电脑后，你可以在以下场景派上用场：

• 查看正在进行的线程和任务状态。
• 阅读 Codex 的阶段性输出、终端输出、截图、diff 和测试结果。
• 回复 Codex 的进一步提问。
• 审批命令、网络访问或其他需要人工确认的操作。
• 改变任务方向、切换模型或补充新的上下文。
• 新建任务，让 Codex 从已连接的开发环境里开始工作。

任务实际还是在电脑上跑。文件、依赖、凭据、权限和本地配置不会因为连了手机就搬到手机上。

使用前提

使用前先确认：

• 手机上安装并更新 ChatGPT App。
• 电脑上安装并更新 Codex 桌面 App。
• 手机和电脑登录同一个 ChatGPT / OpenAI 账号，且处在支持 Codex 的地区和套餐范围内。
• 桌面 App 已经连接到对应项目，或 Codex 正在某台已授权机器、devbox、远程环境中运行。
• 如果任务会写文件、跑命令、访问网络，仍然需要理解并确认对应权限。

推荐使用场景

手机端适合「离开电脑但不想让任务停住」的场景：

• 通勤路上查看长任务进展。
• Codex 需要你选择方案时，快速给出方向。
• 任务卡在权限审批时，从手机上批准或拒绝。
• 会议前让 Codex 汇总最新代码、issue、文档或客户背景。
• 突然想到一个改动点，先发给 Codex 开始探索，回到电脑后再细看 diff。

不适合怎么用

手机端不能替代完整的本地审查。下面这些事情最好回电脑上做：

• 大范围代码合并前的最终 review。
• 涉及生产环境、密钥、账单、发布部署的高风险操作。
• 需要长时间阅读大量 diff 的任务。
• 需要你手动操作 IDE、调试器或本地 GUI 的任务。

毕竟电脑的大屏优势仍然是不可替代的。

一个典型流程

1. 在电脑上打开 Codex 桌面 App，进入对应项目。
2. 让 Codex 开始一个需要较长时间的任务，例如排查失败测试或整理文档。
3. 离开电脑，在 ChatGPT 手机 App 中进入 Codex。
4. 打开同一个正在运行的任务线程。
5. 查看 Codex 的输出、截图、终端日志、测试结果或 diff。
6. Codex 需要确认时，直接在手机上回复、审批或调整方向。
7. 回到电脑后，再做完整 diff review、运行验证命令和提交。

和 Codex Cloud 的区别

| 对比项 | 手机端连接桌面 App | Codex Cloud |
|

三种方案怎么选

| 方案 | 适合谁 | 优点 | 需要注意 |
|

最后核对

官方资料最后核对日期：2026-05-27。本章以开发一个简单网页为例，演示从创建工作目录到任务迭代的完整操作流程。

本章以"用 Codex 桌面 App 开发一个关于 AI 发展历史的简单网页"为例，走完一次完整的任务闭环，帮助你快速上手 Codex 桌面 App 的基本用法。

第一步：创建本地工作文件夹

在本地新建一个空文件夹，作为 Codex 的工作目录。Codex 生成的所有文件都会保存在这里。

第二步：选择对话还是项目

打开 Codex 桌面 App 后，你需要选择用"对话"还是"项目"来开始任务。

• 对话：适合一次性任务，操作简单，但多个对话之间不共享工作目录。
• 项目：支持在同一工作目录下创建多个对话，每个对话处理不同的子任务，管理更方便。

如果你不确定选哪个，优先选择项目——后续扩展任务时更灵活，工作目录也只需要配置一次。

第三步：添加工作目录

选择项目后，点击"使用现有文件夹"，选中刚才创建的文件夹。

选择完成后，对话框左下角会显示当前工作目录的路径，确认路径正确即可。

第四步：输入任务描述，开始执行

在对话框中输入你的需求，点击发送，Codex 就会开始执行任务。

任务完成后，Codex 会在对话中展示结果，同时将生成的文件写入工作目录。

如果生成的是网页文件，可以直接点击 Codex 弹出的"打开"按钮，在 App 内置浏览器中预览效果，无需手动打开文件夹。

第五步：逐步迭代

对结果不满意时，直接在当前对话框中继续描述修改需求，Codex 会在已有基础上进行调整。

随着对话轮次增加，上下文窗口会逐渐被填满。点击对话框右下角的小圆圈图标，可以查看当前上下文使用情况。

如果使用的是"对话"模式而非项目，新建对话时需要重新指定工作目录，两个对话之间也是相互隔离的，不方便统一管理。这也是推荐使用项目的主要原因之一。

我们使用codex开发obsidian新手教程网站作为示例：来说明任务的顺序执行管理和并行操作

1.顺序执行

选择本地项目/创建新的项目，该项目实际上就对应我们本地的一个文件夹，它存储在我们的本地。

然后点击创建新的对话。

我们向 CodeX 发送任务，让他帮我们设计一个网站，这个时候他就会开始执行。

在这个任务没有执行的过程中，如果我们去给他下达新的命令，就只能等待。显示的是下面这种情况：

这种相当于当前他正在执行一个任务，我们给他的另外两个命令就需要排队，必须等前面的任务执行完成之后才能执行。

但是如果我们想修改一下要求，比如想让他明确这个网站的背景风格为“手绘风格”，如果等他设计完成之后再去修改就会比较麻烦。我希望他在正在设计的时候就知道我的风格要求。

这时候，我们可以点击引导选项。这样操作后，他就会执行一个“插队”的操作：

1. 原本的任务顺序：
   (a) 执行网站设计
   (b) 介绍技术选型
   (c) 执行手绘风格要求（原定第三个任务）

2. 插队后的效果：
   我们想让“手绘风格”在设计过程中就发挥作用，通过点击引导提示，这个任务就会直接插队到当前正在执行的任务当中。

这实际上就是通过这样一个过程，演示如何对顺序执行的任务进行管理以及相关的插队操作。

2.如何并行

实际上就是一个项目（Project）里面，我们同时去执行多个任务。

这个时候，我们只需要在左侧边栏点击“新建对话”就可以了。这样的话，它的几个任务就会并行执行，互不干扰。

1. 聊天框下方的权限选择
2. 设置里的“配置”项

权限管理和沙盒（Sandbox）本质上是同一个概念。想深入可以看 OpenAI 官方文档 或者 沙盒与审批 以了解更多。

聊天框里的权限选项

权限入口在聊天框下方，官方叫它 permissions selector。四个常见选项：

1. Default permissions（默认权限）
2. Auto-review（自动审核）
3. Full access（完全访问）
4. Custom (config.toml)（自定义配置）

对于 CLI 而言，权限配置的细粒度和复杂度都会更高。这里不做展开。

默认权限

又称：请求批准。

默认权限是 Codex 的安全基线。Codex 运行在沙盒（Sandbox）内，只能读写当前工作区（即你打开的文件夹）里的文件、运行常规本地命令。一旦操作超出该文件夹范围、访问网络，或调用更敏感的能力（如读取系统环境变量、操作已登录的 CLI），Codex 会暂停并请求确认——通过对话询问，或弹出审批窗口。

这个“沙盒”本质上是一道围栏，将 Codex 的活动范围限制在当前项目内，防止误触外部文件。

官方文档里，这套默认配置对应：

• sandbox_mode = "workspace-write"
• approval_policy = "on-request"
• approvals_reviewer = "user"（即用户本人审批）。

适用场景：

• 修改文档、样式、测试或小范围代码。
• 安全性敏感的任务。

若任务步骤较多，频繁弹窗可能影响效率，此时可考虑切换至自动审核。

自动审核

又称：替我审批。

自动审核适合希望减少手动审批打断、但又不愿完全放开权限的场景。执行命令时，Codex 会将请求转给 reviewer agent（一个专门负责风险评估的助手）判断。低风险或中风险直接放行；高风险仍需要用户明确同意。

这是最推荐的权限机制。保证安全性的同时也能兼顾用户体验和工作效率。

适用场景：

• 项目经常需要访问当前文件夹以外的资源，如调用本机 CLI、联网查询，且风险可控。
• 本地开发任务步骤较多，不希望被频繁弹窗打断。
• 已信任当前项目目录，但仍希望拦截危险操作（如删除文件、修改配置、泄露凭据）。

完全访问权限

只在明确需要时临时开启。官方将 Full access 对应到 sandbox_mode = "danger-full-access" 和 approval_policy = "never"：沙盒限制被完全移除，Codex 不再触发审批弹窗，直接执行任何它打算执行的命令。

这是最高权限机制，务必考虑可能带来的风险。

适用场景：

• 调试特殊本机环境、Computer Use 或系统级操作。
• 任务必须高频访问工作区外的本机资源。
• 操作范围清晰，且项目有 Git 或备份机制可回滚。

自定义配置

选择 Custom (config.toml)，Codex 会按本地 config.toml 中的设置工作。例如同时开放多个可写目录、给特定网络域名放行、将审批交给自动审核，或通过 rules 对某些命令前缀设置“允许 / 询问 / 禁止”标识。

属于进阶配置，适合已熟悉沙盒和权限机制、希望按个人习惯定制权限边界的用户。

| 选项 | 大致含义 | App 里怎么理解 |
|

• Skill 是告诉 Codex 某类任务该怎么做的可复用流程说明。
• Plugin 则是安装和分发单元，能把 Skills、MCP、Hooks、App 集成和资源文件打包到一起。

如果你在 App 中看到了和技能、插件相关的入口，可以先用这张图定位它们：

三个核心概念

理解这三者最快的方式，是把 AGENTS.md、Skill、Plugin 放在一起看：

| 概念 | 解决什么问题 | 更像什么 |
|

当一个工作流已经足够稳定、而且会重复发生时，就可以考虑把它交给 Automation，在后台按计划触发，而不是每次都手动发起。

适合自动化的任务包括：

• 定期检查文档死链
• 每周整理一次 issue 或 PR 摘要
• 每天汇总 failing CI
• 在固定时间提醒补复盘或更新文档

可以怎么理解自动化

一个自动化任务通常至少会包含三部分：

1. 目标对象
   它对应哪个项目、仓库或线程。
2. 触发时机
   比如固定时间、固定间隔，或者稍后回到当前任务继续跟进。
3. 执行内容
   也就是让 Codex 到时具体去完成什么。

常见使用流程

在支持 Automations 的界面里，你通常会经历类似下面的流程：

1. 选择对应的项目、仓库或当前线程。
2. 设定执行时间或执行周期。
3. 写清楚自动化任务本身的目标、输出格式和边界。
4. 保存后观察第一次运行结果，再决定是否长期保留。

这里最容易被忽略的一点是：自动化 prompt 要尽量写成”自包含”的任务说明。不要默认它会记得你之前说过什么，最好把检查范围、输出格式和验证要求写完整。

❌ 不够自包含的写法：

请检查一下文档里的链接有没有问题。

✅ 推荐的写法：

请检查 docs/ 目录下所有 .md 文件中的外部链接是否有效。

检查范围：仅检查以 http:// 或 https:// 开头的链接，忽略锚点和相对路径。
输出格式：按”文件路径 | 行号 | 链接 | 状态”列出失效链接；全部正常时输出”全部链接正常”。
验证方式：对每个链接发起 HEAD 请求，超时 5 秒视为失效。
限制：不修改任何文件，不创建新文件。

两者的区别在于：第一种每次触发时 Codex 都要靠猜测来填补缺失的细节，结果容易不稳定；第二种把边界、格式、验证方式都写明白了，无论在哪次执行、哪个上下文里，行为都是一致可预期的。

使用时的提醒

• 不同工作区里的自动化能力可能并不完全一样，有些支持项目级任务，有些更偏向提醒和跟进。
• 第一次配置时，建议先从低风险、只读型任务开始。
• 如果自动化会写文件、访问外部系统或触发通知，最好先确认权限边界和人工复核方式。

这个宠物最大的价值在于状态的可视化：

1. 任务进度一目了然： 不用一直切换回 Codex 的界面，就能看到当前任务的进度。
2. 实时状态反馈：
   • 它会在 Codex 忙碌的时候显示忙碌的画面。
   • 在需要你确认的时候会发出提醒。
   • 任务完成之后，它也会让你知道可以去检查结果了。

安装前检查

官方仓库当前给出的 CLI 运行环境建议：

| 项目 | 建议 |
|

选择第一个任务

适合新手：

• 修复一个文案错别字。
• 给一个纯函数补测试。
• 更新 README 里的过期命令。
• 解释一个小模块，并补充必要注释。
• 修复一个已经有失败测试覆盖的 bug。
• 为文档站补一段截图占位说明。

暂时避开：

• 大规模架构重构。
• 跨多个服务的迁移。
• 没有测试的核心业务逻辑改动。
• 涉及生产凭据、账单、权限和删除数据的操作。
• 需要同时修改十几个文件的需求。

第一步：只读建图

先让 Codex 理解仓库：

请只读分析当前仓库，不要修改文件。

请输出：
1. 项目用途
2. 关键目录
3. 安装、测试、构建命令
4. 当前任务适合从哪里开始
5. 你建议我第一次交给你的低风险任务

第二步：给出小任务

推荐复制这个模板：

请修复当前仓库中最小范围的一个测试失败。

要求：
1. 先运行测试，确认失败信息。
2. 阅读相关代码和测试，不做无关重构。
3. 修改最少必要文件。
4. 修复后重新运行相关测试。
5. 最后总结：失败原因、改了哪些文件、验证命令和剩余风险。

如果任务是文档：

请更新 [文档文件] 中关于 [主题] 的说明。

要求：
1. 先读取相关官方资料和现有文档结构。
2. 保持中文教程风格，避免整段翻译官方原文。
3. 涉及操作步骤时添加截图占位。
4. 修改后运行文档站构建。
5. 最后列出来源链接和需要人工补图的位置。

第三步：观察过程

重点观察五件事：

| 观察点 | 说明 |
|

最后核对

官方资料最后核对日期：2026-05-27。本章以 VS Code 为例演示插件安装与基本用法，操作界面以实际版本为准。

本章介绍如何在 VS Code 代码编辑器中安装 Codex 插件，并通过插件完成开发任务。相比桌面 App，在 VS Code 中使用 Codex 可以更直接地看到文件目录结构和修改前后的对比，适合习惯在编辑器里工作的开发者。

安装 Codex 插件

打开 VS Code，点击左侧边栏的「扩展」图标，在搜索框中输入 Codex，选择第一个结果，点击「安装」即可。

打开插件对话窗口

安装完成后，在 VS Code 中打开任意一个项目文件，右上角会出现 ChatGPT 的图标。点击该图标，右侧边栏就会展开 Codex 的对话窗口。

开始使用

对话窗口打开后，直接输入需求，Codex 就会开始辅助完成开发任务，用法与 Codex 桌面 App 基本一致。

使用 @ 指定文件：

在对话框中输入 @ 后选择具体文件，Codex 会直接定位到该文件进行分析或修改，比让它全局搜索更快、更准确。建议在任务目标明确时优先使用 @ 指定相关文件。

App 与 VS Code 插件怎么选

| | Codex 桌面 App | VS Code 插件 |
|

最后核对

AGENTS.md 机制请以 Codex AGENTS.md 官方文档、AGENTS.md 标准网站 和 openai/codex GitHub repository 为准。最后核对日期：2026-06-19。

AGENTS.md

对于 Codex，每开启一个新的对话窗口，它都会进入一个全新的上下文。它不知道这个项目用什么命令、有哪些目录边界、哪些文件不能改，也不知道团队平时怎么验证结果。

AGENTS.md 正是为了解决这类问题而存在的项目级指令文件。它是一个简单、开放的 Markdown 约定，目标是给不同 coding agent 提供一个稳定、可预测的项目指令入口，把项目结构、开发命令、测试要求、代码风格和协作边界显式写下来，减少反复解释。

更准确地说，AGENTS.md 是面向 coding agent 的 README。README 主要给人看，讲项目是什么、怎么上手；AGENTS.md 给 Codex 和其他 coding agent 看，告诉它们改代码前应该遵守哪些项目规则。

可以把它理解为：

• 对个人用户：减少重复解释“项目怎么跑、怎么测、哪些地方不能碰”。
• 对团队项目：把团队共同认可的 agent 使用规则沉淀到仓库里。
• 对多工具环境：让 Codex、IDE agent、CLI agent 等工具尽量读取同一份项目说明。

本质上就是一份普通的 Markdown 文件。

另外需要注意，截至目前，Claude Code 并不遵守 AGENTS.md 约定，取而代之的是 CLAUDE.md 约定。

存放位置与读取机制

文件位置

对于普通项目，最推荐的做法是在项目根目录创建 AGENTS.md。Codex 在开始处理任务前会自动读取它，并把内容作为工作上下文带入新的对话。

若希望全局生效，可以撰写 Codex 的全局指令：

1. 在 Codex_Home 目录中创建 AGENTS.md。默认位置通常是 ~/.codex/AGENTS.md；如果设置了 CODEX_HOME，则以对应目录为准。
2. 在 Codex 桌面 App 里配置个人偏好或自定义指令。本质上也是写入 Codex_Home 的 AGENTS.md，与上述方法等价。

设置全局规则后，它会影响你打开的所有项目；项目级 AGENTS.md 只影响当前仓库。两者作用域不同，要分清。

请确保文件名始终为 AGENTS.md，并确认大小写是否正确。否则 Codex 不会自动识别。

读取顺序与合并规则

Codex 读取 AGENTS.md 遵循以下顺序：

1. 先读取全局规则：默认读取 ~/.codex/AGENTS.md。如果同一位置存在 AGENTS.override.md，则优先读取它，适合临时覆盖全局规则。
2. 然后读取项目规则：进入项目后，Codex 通常会从 Git 根目录开始，一路走到当前工作目录。沿途每一层目录，它会尝试读取项目指令文件。

项目指令文件的默认优先级是：

AGENTS.override.md
AGENTS.md

也就是说，同一目录里如果同时存在这两个文件，AGENTS.override.md 会覆盖 AGENTS.md。

Codex 会把读取到的指令从上到下合并。根目录的规则先出现，子目录的规则后出现。越靠近当前目录的规则越具体，因此也更适合写局部要求。

一个文件结构的示例：

AGENTS.md
apps/
  web/
    AGENTS.md
packages/
  database/
    AGENTS.md

上述示例中，根目录 AGENTS.md 写全仓库通用规则，apps/web/AGENTS.md 写前端规则，packages/database/AGENTS.md 写数据库迁移和测试要求。

注意事项：

1. 如果你的项目已经有其他规则文件，可以通过 Codex 配置里的 project_doc_fallback_filenames 添加备用文件名。Codex 会在找不到 AGENTS.override.md 和 AGENTS.md 时，再尝试这些 fallback 文件。
2. Codex 还会限制合并后的项目指令大小。官方默认值是 project_doc_max_bytes = 32768，也就是 32 KiB。规则文件太大时，后面的内容可能不会进入上下文，所以尽量保持 AGENTS.md 精简。

团队协作

多人协作时，AGENTS.md 适合保存团队共同认可的项目规则；个人路径、本机工具习惯、临时约束和私有工作流偏好，则更适合留在本地。这样团队规则保持稳定，个人习惯也不会被提交到仓库。

使用场景

下面这些内容适合放在本地私有规则里：

• 本机缓存、SDK、脚本或临时目录路径。
• 个人常用命令、别名、编辑器习惯。
• 只对自己有效的语言风格、回复格式、验证偏好。
• 不方便进入团队文档的临时限制，例如“今天先只做只读分析”。

文件分工

| 文件 | 作用 | 是否提交到 Git |
|

沙盒和审批就是这套边界。

对于绝大多数人而言，只需要把 Auto-Reivew 模式打开就够了。本文章旨在让你更好地理解 Codex 的沙盒机制和审批策略，同时补充一些进阶用法。

当你在利用沙盒和权限机制来约束 Codex 行为的时候，你已经在实践 Harness Engineering ，即“约束工程” 。

三个概念

想象 Codex 在你的电脑里工作，就像在一个有玻璃墙和门禁的实验室里操作。

• 沙盒就是实验室的墙和门禁：它规定 Codex 能碰哪些设备、能不能连外网、能不能写入项目外文件夹。墙内的常规操作，Codex 可以自己做；墙外的事情，需要先获得许可。
• 审批策略就是门禁的触发规则：是「沙盒外区域每次请求确认」，还是「只在 Codex 越过沙盒边界时请求确认」，还是「完全不请求，自行处理」。
• 审批人就是谁来回答门禁：你自己看门放行，还是让另一个智能门禁系统（Auto-review）先判断一下。

三者加在一起，决定 Codex 在你的电脑上到底能做什么、不能做什么。

默认推荐

Codex 启动时会根据目录状态自动推荐权限：

• 版本控制目录（带有.git文件夹）：Auto，也就是 workspace-write + on-request。
• 非版本控制目录（不带有.git文件夹）：read-only。
• 某些情况下，Codex 会先保持 read-only，直到你明确信任当前工作目录。

日常开发最常用的是

1. 沙盒设置：workspace write（工作区写入）
2. 批准机制：on-request（按请求）

旧版写法（仍可用）：

sandbox_mode = "workspace-write"
approval_policy = "on-request"
approvals_reviewer = "user"

新版 permission profiles 写法（beta）：

default_permissions = ":workspace"
approval_policy = "on-request"
approvals_reviewer = "user"

新旧配置不要混用。 这些配置通常写在 ~/.codex/config.toml。如果任意已加载配置里出现 sandbox_mode，或命令行传了 --sandbox，Codex 会使用旧版 sandbox 设置，而不是 default_permissions。

这段话什么意思？用上面的类比解释：

• Codex 可以在当前项目文件夹（workspace）里正常操作：读取文件、修改文件、运行常规的本地命令（比如 git、测试脚本、编译）。
• 如果需要联网、写到项目外面、或者做越界的事情，就会触发审批，暂停并请求确认。

这是官方推荐的默认设置。它不会每一步都要求交互确认，也不会让 Codex 获取整台电脑的权限。

沙盒模式

三种沙盒模式，对应不同的权限边界：

| 模式 | 对应英文 | 范围 | 审批触发条件 |
|

需要注意，Hooks是非常进阶的用法，一般推荐通过社区获取推荐的Hooks。也可以使用 Codex 撰写。

Hooks常见用途包括：

• 把对话或工具调用记录发送到团队日志系统。
• 检查用户提示词里是否误贴了 API key、token 或私密信息。
• 在会话开始时加载本地说明、项目约定或临时上下文。
• 在工具调用前拦截高风险命令，例如删除文件、发布、部署、数据库迁移。
• 在工具调用后检查输出，提醒 Codex 继续验证或修正。
• 在对话停止前要求 Codex 再跑一次测试、补充总结或生成交付说明。

Hooks 的优势在于确定性：脚本怎么写，就怎么执行。其边界也在于此：脚本本身必须安全、可审查、可维护。

默认开启

Codex 默认启用 Hooks。如果想在本机关闭，可以在 config.toml 中写：

[features]
hooks = false

官方推荐使用 hooks 这个 feature key。旧的 codex_hooks 仍可用，但已弃用。

团队或企业管理员也可以通过 requirements.toml 强制关闭或管理 Hooks。普通个人用户通常只需要理解本机和项目里的配置。

配置位置

Codex 会在激活的配置层旁边查找 Hooks。常见位置有四个：

~/.codex/hooks.json
~/.codex/config.toml
<repo>/.codex/hooks.json
<repo>/.codex/config.toml

也就是说，Hooks 可以单独写在 hooks.json，也可以写在项目目录的.codex/config.toml 的 [hooks] 表。

如果多个位置都有匹配的 Hook，Codex 会全部加载。为避免混淆，同一层里建议二选一：要么用 hooks.json，要么用 config.toml 内联写法。

项目内的 Hooks 只有在项目 .codex/ 配置层被信任后才会加载。未信任项目里，Codex 仍会加载用户级或系统级 Hooks。

基本结构

Hooks 配置包含三层：

1. 事件：什么时候触发，例如 SessionStart、PreToolUse、PostToolUse、Stop。
2. matcher：匹配哪些场景，例如只匹配 Bash，或只匹配 startup|resume。
3. handler：真正执行的命令。

一个最小 hooks.json 可以这样写：

{
  "hooks": {
    "SessionStart": [
      {
        "matcher": "startup|resume",
        "hooks": [
          {
            "type": "command",
            "command": "python3 ~/.codex/hooks/session_start.py",
            "statusMessage": "Loading session notes"
          }
        ]
      }
    ]
  }
}

当前实际执行的 handler 类型是 type: "command"。prompt 和 agent 这类 handler 目前会被解析，但不会执行。

事件与触发

Hooks 绑定在 Codex 的固定生命周期节点上，而不是随机触发。

生命周期

一次典型对话的生命周期如下：

会话启动
  -> SessionStart
用户提交提示词
  -> UserPromptSubmit
Codex 准备调用工具
  -> PreToolUse
如果工具需要额外权限
  -> PermissionRequest
工具执行完成
  -> PostToolUse
当前 turn 准备结束
  -> Stop

如果中途发生上下文压缩，会触发 PreCompact 和 PostCompact。如果 Codex 启动子代理，会触发 SubagentStart 和 SubagentStop。

匹配规则

事件触发后，Codex 会检查这个事件下配置的 matcher。matcher 命中，才会启动对应 command handler。

例如：

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "^Bash$",
        "hooks": [
          {
            "type": "command",
            "command": "python3 check_bash.py"
          }
        ]
      }
    ]
  }
}

这段配置只会在 Codex 准备调用 Bash 工具前触发。调用 apply_patch、MCP 工具或其他工具时不会触发这个 handler。

并发与冲突

如果多个配置层里都有匹配 Hook，Codex 会全部运行。高优先级配置层不会覆盖低优先级 Hooks。

同一个事件下如果有多个 matching command hooks，它们会并发启动。因此，一个 Hook 不能靠“先运行”来阻止另一个匹配 Hook 启动。

这会带来两个实践要求：

• Hook 之间不要依赖固定顺序。
• 如果多个 Hook 都可能做决定，要按官方事件规则理解冲突处理。例如 PermissionRequest 里任何一个 deny 都会优先。

事件能力

不同事件能改变 Codex 行为的程度不同：

| 事件 | 能否阻止或改变后续行为 |
|

Codex 找不到项目上下文

可能原因：

• 你不在项目根目录。
• 仓库缺少 README、测试命令或项目说明。
• monorepo 没有说明包边界。

处理方式：

• 先让 Codex 只读目录并总结项目结构。
• 添加或更新 AGENTS.md。
• 在任务说明里指定相关目录。

Codex 改动范围太大

处理方式：

• 明确“只修改这些文件”。
• 要求“先输出计划，不要动手”。
• 把任务拆成更小的步骤。
• 在 review 时拒绝无关重构。

测试跑不起来

处理方式：

• 让 Codex 先定位测试命令。
• 检查依赖是否安装。
• 区分环境问题和代码问题。
• 如果是环境问题，让 Codex 记录阻塞，而不是继续乱改。

生成内容不准确

处理方式：

• 要求 Codex 引用它依据的文件。
• 对官方事实要求附链接。
• 让它区分“已确认”和“推测”。
• 让它先读代码再写文档。

登录或权限问题

处理方式：

• 更新 Codex CLI 到最新版本。
• 重新运行登录流程。
• 检查当前账号计划和组织策略。
• 查看官方 Help Center 的 Codex 相关文章。

Windows 桌面 App / CLI 专项排障

如果问题发生在 Windows 桌面 App、Microsoft Store / winget 安装、Windows sandbox、Worktree、Browser / Computer Use 插件、WSL 混合路径或 PowerShell 环境，可以参考社区维护的 Windows 专项排障库：

• Community Codex Windows Troubleshooting
• Windows Codex Error Guide
• Dogfood Matrix

这个项目会把 Windows 报错按证据等级、复现等级和 workaround 状态整理，并提供只读诊断脚本。提交日志、截图或诊断输出前，请先脱敏用户名、路径、私有仓库名、token 和账号信息。

切换 provider 后旧会话不可见

可能原因：

• 修改过 config.toml 根级 model_provider。
• 旧会话文件还在，但会话 metadata、SQLite 状态或项目路径缓存仍指向旧 provider。
• CLI /resume 能看到旧会话，但 Codex Desktop 项目侧看不到，可能只是 Desktop 最近 50 条会话的首屏显示限制。

处理方式：

• 先确认 ~/.codex/sessions 或 ~/.codex/archived_sessions 里是否还存在旧会话文件。
• 如果只是 Desktop 项目侧不可见，先判断是否被最近 50 条显示限制挡住。
• 如果确认是切换 provider 后 metadata 不一致，再参考 config.toml 里的社区工具说明。
• 使用第三方工具前先备份 ~/.codex，不要把它当成官方认证或账号切换工具。

桌面 App 适合什么

• 本地仓库中的长任务和多阶段任务。
• 同时推进多个不互相阻塞的任务。
• 使用 Worktrees 隔离不同实现分支。
• 把重复流程写成 Skills。
• 用 Automations 做提醒、定期检查或后续跟进。
• 配合浏览器、文档、表格、演示文稿等插件做跨工具工作。

核心能力地图

| 能力 | 用途 | 学习重点 |
|

适用场景

• 连接 GitHub 仓库后发起任务。
• 让 Codex 阅读仓库并总结架构。
• 将 issue 转成可执行任务。
• 生成 PR 摘要或变更说明。
• 面向非开发者解释技术改动。
• 把复杂任务拆成阶段计划。

第一次任务怎么写

先让 Codex 只读分析：

请阅读这个仓库并帮我理解 [主题]。请先总结相关目录和关键文件，再给出执行建议。暂时不要修改代码。

进一步推进时：

请基于刚才的分析，完成第一步最小改动，并创建可审查的结果。请说明改动原因、验证方式和剩余风险。

适合非开发者的用法

| 场景 | 任务说明 |
|

CLI 能做什么

• 只读理解仓库结构、入口、测试命令和风险点。
• 修改代码、文档、配置和测试。
• 运行 lint、typecheck、unit test、build 等验证命令。
• 在终端里查看 diff、调整审批策略、恢复会话。
• 通过 codex exec 执行标准化的一次性任务。
• 配合 AGENTS.md、config.toml、Skills、MCP 构建长期工作流。

推荐学习顺序

1. 安装 CLI 并完成登录。
2. 在陌生仓库中做一次只读总结。
3. 学会交互模式中的常用 Slash Commands。
4. 完成一次低风险修改，并运行验证。
5. 学会 codex exec，把可重复任务脚本化。
6. 增加 AGENTS.md 和本地 config.toml。

交互模式

进入项目根目录：

cd path/to/project
codex

第一轮建议不要直接让 Codex 改代码。先让它建立地图：

请只读分析当前仓库，不要修改文件。

请输出：
1. 项目用途
2. 主要目录和入口文件
3. 安装、启动、测试、构建命令
4. 当前仓库对 Codex 来说最需要注意的风险
5. 适合第一次交给 Codex 的 5 个低风险任务

非交互模式

codex exec 更适合批处理和自动化：

codex exec "请只读分析当前仓库，输出安装、测试和构建命令。不要修改文件。"

建议让输出格式稳定：

请读取当前仓库，不要修改文件。

输出格式：
## 项目概览
## 本地运行
## 测试命令
## CI 风险
## 适合 Codex 处理的任务

适合脚本化的任务：

| 任务 | 产出 |
|

Cloud 适合什么

• 连接 GitHub 仓库后分派任务。
• 在后台处理长时间修复、迁移或分析。
• 基于 issue 或需求生成分支和 PR。
• 团队成员共同查看任务进度。
• 为大型仓库做结构分析和风险扫描。

提交任务前的清单

| 检查项 | 为什么重要 |
|

IDE 适合什么

• 解释当前文件或选中代码。
• 为一个函数补测试。
• 局部重构。
• 生成注释、文档或类型说明。
• 审查当前 diff。
• 快速理解错误信息和调用链。

选区任务写法

选区越准确，结果越稳定。推荐模板：

请只基于当前选中的代码解释：
1. 它在模块中的职责
2. 输入输出和副作用
3. 可能的边界情况
4. 如果要补测试，建议覆盖哪些场景

如果允许修改：

请只修改当前文件和对应测试文件。

目标：为当前函数补充边界测试。
要求：
1. 先解释测试场景。
2. 修改后运行相关测试。
3. 不做无关重构。

IDE 中的高频任务

| 任务 | 推荐输入 | 结果检查 |
|

入口对照表

| 入口 | 更适合 | 典型任务 | 学习优先级 |
|

方法地图

| 主题 | 解决什么问题 |
|

文档工作

适合任务：

• 把 README 改成新手友好的版本。
• 根据代码生成模块说明。
• 整理迁移指南。
• 生成发布说明。
• 把 issue、PR、commit 整理成周报。

任务模板：

请阅读当前仓库的 README、docs 和 package 配置，帮我整理一份新手上手指南。

要求：
1. 不修改代码。
2. 命令必须来自仓库真实配置。
3. 不确定的步骤标注为“待确认”。
4. 输出目录结构、安装步骤、开发命令、测试命令和常见问题。

学习工作

适合任务：

• 让 Codex 按学习顺序解释代码库。
• 生成“从入口到核心模块”的阅读路线。
• 把复杂模块讲成产品、设计或运营也能理解的语言。
• 把陌生技术栈拆成学习清单。

任务模板：

请把这个仓库当成学习材料。请按初学者阅读顺序讲解：
1. 先看哪些文件
2. 每个目录承担什么职责
3. 关键数据流或调用链
4. 学完后可以做的 3 个练习

产品与运营工作

适合任务：

• 把 PR 改动翻译成用户影响。
• 生成发布公告草稿。
• 检查文案和功能说明是否一致。
• 从 issue 中提取用户痛点。

任务模板：

请阅读当前 diff，把技术改动整理成产品发布说明。请包含：
1. 用户能感知到的变化
2. 管理后台或配置变化
3. 可能影响旧用户的地方
4. 需要客服或运营同步的话术

知识管理

Codex 很适合把零散经验沉淀成模板：

• 排障记录。
• FAQ。
• 任务模板。
• 团队规范。
• 案例复盘。

最终目标是把“每次临时问一次”变成“下一次直接复用”。

任务六要素

| 要素 | 写法 | 示例 |
|

团队接入清单

| 项目 | 建议 |
|

本篇介绍如何将安卓手机与 Codex 配对连接。

适用场景

• 让 Codex 帮你在网页里搜索资料。
• 让 Codex 打开某个站点并完成简单点击流程。
• 在不离开当前工作区的前提下，把浏览器操作接入任务链路。

使用前先理解一件事

这里说的“控制浏览器”，更准确地说，是让 Codex 借助浏览器或浏览器插件能力去完成网页交互。不同工作区里，入口可能叫 Chrome、Browser，也可能表现为浏览器插件或内置浏览能力。

因此，更稳妥的理解方式是：

1. 在当前工作区确认是否已经启用了相关浏览器能力。
2. 如果是第一次使用，按界面引导完成浏览器侧安装或授权。
3. 安装完成后，再在任务里明确告诉 Codex 你想让它做什么。

一个常见流程

如果你的客户端提供了 Chrome 相关插件或浏览器能力，常见流程通常类似这样：

1. 在 Codex 桌面 App 中找到对应的浏览器能力并启用。
2. 按引导完成浏览器侧的插件安装或连接配置。
3. 回到任务中，明确描述目标网页、搜索词和预期输出。

第一次点击后会跳转到浏览器插件安装页，点击添加扩展即可

任务示例

你可以像下面这样给出一个明确任务：

请使用浏览器能力打开 Bilibili，搜索“RAG 知识库 教程”，找一个适合新手入门的视频，并把标题和链接返回给我。

一个类似任务完成后，Codex 可能会：

1. 打开目标站点。
2. 搜索你提供的关键词。
3. 进入相关结果页。
4. 把它认为最合适的结果链接返回给你。

你要重点检查什么

• 它打开的网站是不是你指定的那个站点。
• 搜索词有没有被错误改写。
• 点击结果后返回的是不是你真正需要的页面，而不是广告页或无关页。
• 如果涉及登录态、个人数据或付费后台，是否会超出你愿意授权的范围。

风险提醒

• 浏览器相关能力通常比纯文本任务权限更高，第一次使用时建议从只读、低风险页面开始。
• 不要直接让 Codex 操作带有支付、删除、发帖、提交表单等高风险页面，除非你准备全程复核。
• 如果教程依赖插件安装，未来界面名称或入口位置可能变化，因此文档里应优先描述“能力和流程”，而不是把某个按钮位置写死。

这篇案例面向医护人员、研究生、规培医生和医学科研初学者，演示如何让 Codex 帮你把一个医学研究问题整理成可复核的文献工作台。它不替你诊断患者，也不替你下治疗决策；它只帮助你做研究辅助、资料整理和写作准备。

适合什么场景

• 准备综述、开题报告或课题背景。
• 想把几篇论文整理成证据表。
• 想检查文献总结里有没有过度推断。
• 想把医学问题转成 PICO 或 PICOS 框架。
• 想给团队留下可追踪的文献阅读记录。

不适合的场景：

• 让 Codex 直接给某个患者诊断或治疗方案。
• 让 Codex 编造 PMID、DOI、指南或随机对照试验。
• 让 Codex 处理未脱敏的真实病历。
• 把模型输出当成最终医学结论。

推荐目录结构

先在本地建一个小型资料夹，例如：

literature-review-demo/
├─ question.md
├─ papers/
│  ├─ paper-01.md
│  ├─ paper-02.md
│  └─ paper-03.md
├─ evidence-table.md
├─ gaps-and-risks.md
└─ summary-draft.md

每篇论文可以先放结构化笔记，不需要一开始就很完美：

# Paper 01

Title:
Year:
Study type:
Population:
Intervention or exposure:
Comparator:
Outcome:
Key result:
Limitations:
PMID or DOI:

第一步：把问题拆成 PICO

先在 question.md 写下研究问题：

# Research question

在成人 2 型糖尿病患者中，连续葡萄糖监测是否能改善血糖控制和低血糖风险？

然后让 Codex 帮你拆解：

请只读取 question.md。

任务：
1. 把这个医学研究问题拆成 PICO。
2. 标出哪些信息还不明确。
3. 不要给临床建议。
4. 输出到 question.md 的 “PICO draft” 小节。

比较好的输出应该像这样：

| 元素 | 内容 | 需要补充 |
|

所有案例截图均为作者本人实际操作所得，文字内容在参考基础上重新整理与二次创作。如有侵权，请联系删除。

对有编程经验的人来说，解决方法有很多——GitHub Pages、Vercel、Cloudflare Pages——但这些工具对普通用户并不友好：什么是分支？什么是部署？什么是域名解析？

本篇介绍一个对新手极其友好的工具：DKFile。

Draw.io 就是一个非常好的工具。它可以用来绘制：

1. 流程图
2. 架构图
3. 思维导图
4. 系统设计图
5. 业务流程图
6. 技术路线图

很多程序员、产品经理、架构师都会用它来表达复杂系统之间的关系。前段时间，Draw.io 官方发布了自己的 MCP。

GitHub 地址：https://github.com/jgraph/drawio-mcp

本章节介绍如何使用 Codex 安装、使用 Draw.io 的 MCP 工具，去绘制信息图或架构图。

如果你的团队或个人经常使用飞书，那么接入飞书 CLI 之后，你就拥有了一种全新的使用方式——在 Codex 里一句话处理飞书里的所有信息和数据。

本篇介绍如何把 Codex 和飞书 CLI 结合，直接通过自然语言操作飞书中存储的数据和内容。

演示用的是一个购物车项目。

你不仅可以从现有宠物中选择，还可以用一张照片生成专属动画宠物，让编程时有一只独一无二的电子宠物。

本篇介绍如何用 Codex 的 Hatch Pet 功能，快速制作自定义宠物。

1. Remotion：使用 React 写视频
2. HyperFrames：使用 HTML、CSS 或 JS 做视频

如果你想做一些轻量化的视频，比如网页转视频、文档转视频等，那么使用 HyperFrames 就是一个非常不错的选择。

当前案例概览

| 类型 | 已收录案例 | 适合学习什么 |
|

前段时间，AI 领域的著名研究者 Andrej Karpathy 提出了一个新想法。他认为 RAG 的主要问题在于：每一次提问，模型都要从零开始重新发现知识。如果你问了一个需要综合五篇文档的问题，RAG 会检索、拼接、生成；如果你明天再问同样的问题，它会重复整个过程，没有任何积累，也没有任何记忆。本来可以建立关联的知识，却在一次又一次的反复查询中被浪费掉了。

Karpathy 给出的解决方案是 LLM Wiki。他描述的系统分为三层：

1. 原始资料层 — 负责收集论文、文章、播客、网页等素材。大模型对这一层只读不改。
2. Wiki 层 — 大模型拥有这一层的完整所有权。它负责编写 Markdown 文件、目录、摘要、实体概念、比较分析和综述，创建页面、更新页面，并维护交叉引用。我们只需要负责阅读。
3. Schema 层 — 一个配置文件，例如对于 Codex 来说就是 AGENTS.md，对于 Cursor 来说就是 .cursorrules。告诉大模型这个 Wiki 的结构规范、命名约定和工作流程，并在使用过程中共同迭代这份文件。

本篇介绍如何参考 Karpathy 的理念，在 Obsidian 里借助 Codex 搭建一套 LLM Wiki 知识库。

内容创作者以前有一件很头疼的事：给文章配图。但自从 Codex 命令行可以直接调用 ChatGPT 最新的生图模型 gpt-image-2 之后，我们就可以在 Obsidian 里让 Codex 根据文章内容自动生成配图。

前提条件：

1. 了解 Obsidian 的基本操作
2. 熟悉 Codex 命令行的使用方式（参见本教程第二部分）

像 Codex 这类编程类的 Agent，不仅能够编写和修改代码，还能够打开网页，像人一样检查页面是否跑通。

本章节使用命令行的方式，来学习 MCP 的安装和使用。

适用场景

• 你已经找到一个想用的社区 Skill。
• 你想让 Codex 帮你完成安装，而不是手动整理目录和文件。
• 你希望安装后立刻用一个真实任务验证它是否可用。

准备一个 Skill 来源

首先要有这个 Skill 的来源地址。很多开发者会把自己做好的 Skill 放在 GitHub 仓库里，供其他人安装和复用。

这个案例里使用的是一个社区 PPT Skill：

guizang-ppt-skill

第一步：安装

你可以把 Skill 仓库地址交给 Codex，请它协助识别并完成安装流程。

例如：

请帮我安装这个 Skill：https://github.com/op7418/guizang-ppt-skill
安装完成后，告诉我它的用途、依赖要求，以及应该如何调用。

不同工作区里，安装方式可能不完全一样。有些会直接支持安装，有些则会先分析仓库结构，再提示你确认放置位置或依赖要求。

第二步：调用使用

安装完成后，可以直接让 Codex 调用这个 Skill 去完成一项真实任务。

如果这个 Skill 已经提前安装过，你通常也可以通过斜杠命令、技能选择器，或者在任务里明确点名的方式来调用它。

例如：

请使用刚刚安装的 PPT Skill，根据“AI 编程工具入门”这个主题生成一份适合分享的演示稿。先告诉我还缺哪些关键信息。

如果你没有给足上下文，Codex 往往会先回到这个 Skill 的操作手册里，看看它需要什么输入，然后再向你追问必要信息。

当你补齐背景、主题、受众或风格要求后，它会按该 Skill 的流程去读取 README、模板和相关文档，再生成结果。

如果这个 Skill 的默认产物是 HTML 演示稿，你通常可以直接在 Codex 内置浏览器里打开预览。

你要重点检查什么

• Codex 安装的是不是你指定的那个 Skill，而不是名称相似的别的仓库。
• 安装后有没有说明依赖要求、输出格式和调用方式。
• 生成结果是否符合这个 Skill 原仓库描述的能力边界。
• 如果结果不理想，是 Skill 本身限制，还是你提供的输入信息不够。

风险提醒

• 社区 Skill 不是官方能力，质量和维护状态差异会很大，使用前最好先看仓库 README。
• 不要默认“给出 GitHub 链接就一定能一步安装成功”，有些 Skill 还会依赖额外脚本、模板或本地环境。
• 第一次验证时，优先选一个小任务，确认 Skill 能正常运行后，再拿去做正式产物。

你的代码跑在云服务器上，本地一行代码都没有——Codex 照样能帮你找到 Bug、修好它、跑通测试。这篇文章手把手带你走一遍完整流程。

最后核对

官方资料最后核对日期：2026-06-19。本文依据 OpenAI Codex changelog 整理，仅提供中文摘要和阅读索引；功能开放范围、账号计划、地区限制、模型可用性与版本号，请以官方原文为准。

本页用于快速了解 Codex 近期变化，涵盖桌面 App、移动端、CLI、模型、插件、权限与远程控制等内容。为保持阅读清晰，本文自 2025 年起整理，并不逐项搬运官方 GitHub PR 清单。

最后核对日期：2026-05-27。

OpenAI 官方

• Codex 产品页：Codex 的产品定位、使用界面和团队能力概览。
• Codex in ChatGPT Help Center：计划可用性、入口和常见问题。
• OpenAI Codex CLI Getting Started：CLI 入门、安装和基础能力。
• Codex 文档入口：Codex 桌面 App、CLI、Cloud、配置、安全、Skills、MCP 等官方文档入口。
• Codex cloud docs：云端任务、GitHub 连接和仓库工作流入口。
• Introducing Codex：Codex 发布背景和云端软件工程代理介绍。
• Introducing the Codex app：Codex 桌面 App 相关介绍。
• Work with Codex from anywhere：ChatGPT 手机 App 中的 Codex 入口、跨设备连接和可用性说明。
• Unrolling the Codex agent loop：Codex agent loop 背后的工作方式介绍。

官方文档重点页面

• Codex App docs（桌面端）：桌面 App 功能入口，包含本地项目、Review、Automations、Worktrees、Local Environments、In-app Browser、Computer Use 等主题。
• Codex CLI features：CLI 交互模式、非交互模式、功能概览。
• AGENTS.md：项目规则文件的官方说明。
• Codex security：沙盒、审批和安全边界。
• Codex config basic：基础配置。
• Codex config advanced：高级配置。
• Codex config reference：完整配置参考。
• Codex skills：Skills 官方说明。
• Codex Cloud docs：云端任务、环境、仓库连接和任务执行入口。

GitHub 官方仓库

• openai/codex：Codex CLI 开源仓库。
• AGENTS.md 相关文档：项目规则文件相关说明。
• CLI getting started：CLI 首次使用流程。
• Authentication：认证和登录相关说明。
• Exec：非交互模式相关说明。
• Slash Commands：CLI 会话命令说明。
• CLI 安装与构建：系统要求、源码构建和日志说明。
• CLI 配置：配置文档索引。
• Sandbox 文档：沙盒与审批官方入口。
• Exec Policy：命令执行策略相关说明。
• Skills：CLI 仓库中的 Skills 文档。

如何使用这些资料

• 入门安装优先看 Help Center 和 GitHub README。
• 了解产品边界优先看 OpenAI Codex 产品页。
• 做团队接入时优先看 Help Center、平台文档、App 文档和企业相关说明。
• 写教程时不要整段翻译原文，应转化成中文场景和可复现步骤。
• 涉及价格、计划、模型、可用地区、功能开关、账号权限时，必须打开原文重新确认。