开篇语

最近Codex非常火，特别是在技术圈，相信很多小伙伴都已经体验过了。但是要想把这个工具从入门真正落地到生产环境，只会简单的命令和对话是远远不够的。所以这期视频，不说废话，直接带大家从头到尾把Codex的实战流程彻底走一遍。本期视频依然面向程序员小伙伴或者准备加入Vibe Coding 的新人。

这个视频分为以下4个大部分：
1. 认识 Codex 与环境准备

  1. 基础交互与真实开发流程

  2. 上下文、多模态与会话管理

  3. 从个人工具到团队工作流

可以看到屏幕上密密麻麻的知识点和时间戳，，这期视频的含金量绝对拉满。只要你花点时间看完这期视频，我保证你能彻底吃透Codex，把它变成你手里最顶级的生产力工具。我也知道市面上还有Claude Code ，OpenCode这些同类的工具，看完这期视频你也能一通百通，迅速掌握其他工具。

一：认识 Codex 与环境准备**

1. Codex 是什么？

到底什么是Codex。

先来一句话定义: Codex 是OpenAI旗下的软件工程智能体。

最近爆火的理由是它不仅仅满足于写代码这件事，已经开始向通用智能体发展。就开发而言，它不是单纯帮你补全代码的工具，而是能进入你的项目，理解代码结构，修改文件，运行命令，检查测试结果，并根据项目规则持续推荐任务的Coding Agent。

最近它还加入了Use Computer 功能，让它更接近一个“会使用电脑和开发工具的AI程序员”，而不是一个只能回答问题的聊天窗口。

2.Codex的生态：CLI、桌面客户端、IDE扩展、Codex 手机端

Codex目前的生态非常全面，它不只是一个工具，而是一组开发入口。它是围绕软件开发任务设计的AI工程生态，
这个生态覆盖了不同的开发场景：

  • 命令行里的Codex CLI
  • 编辑器里的IDE 扩展
  • 桌面端的 Codex App
  • 手机操控的 Codex 手机端

你可以把它理解成不同AI工程师，出现在不同工作平台上。甚至普通人可以用桌面端的Codex 完成写作、制作PPT、画图和视频剪辑工作。

3. 安装Codex 桌面客户端 和 CLI

当我们知道Codex 到底是什么后，就可以进入到实操环节。先来看如何按照Codex，很多小伙伴第一步就被卡主了，但你不要害怕，这也是你最难的一步，只要迈过去了，就会一路坦途。
现在很多教程，叫大家使用中转站，这种严重不推荐。中转站鱼龙混杂，找个能一直使用，不惨假的太难了。最近还流行用Codex 使用DeepSeek代码，以及其他各种国产模型，这种形式作为补充使用可以，但是不使用ChatGPT，完全发挥不出来它本身的优势来，也不推荐。 所以还是要自己想尽一切办法注册自己的OpenAI帐号，然后使用。

注册帐号

为了避免违规，注册帐号的部分，我写了一份文字版安装教程，有需要的直接和我说吧，保证帮你使用上。

当然这套流畅是我目前走下来，最简单最省钱的流畅了。

（1）安装前的准备

  • 能科学上网：也就是可以正常的打开，也就是能打开（https://www.openai.com）, 具体的方法是不让在视频里讲的，所以如果你不会，直接告诉我。
  • 准备两个Apple帐号（国区、土耳其）：一般的小伙伴都会有一个国区帐号，接下来需要注册一个土耳其区帐号，马上我就会讲注册办法。
  • 人民币80元钱左右，购买礼品卡（后面会讲具体的方法）。
  • 准备好Apple手机或者平板。

如果你上面这三样，其中有没办法准备好的。只能考虑使用国内大模型使用Codex、中转站或者找人帮忙安装了。下面我也会教大家使用国内模型的方法。

（2）注册Apple帐号-超详细步骤

如果你准备好了这三样，我们就可以开始了。
- 首先进入苹果的官网(https://www.apple.com.cn) , 进入之后，点击购物车按钮，然后点击登录。

  • 创建你的Apple账户：如果你有了国区的苹果帐号，你有苹果手机或者平板，就一定会有一个国区的苹果帐号，如果没有，那你先注册一个国区帐号。这里只演示创建一个土耳其区的帐号。地区我们需要选择土耳其，邮箱建议使用Gmail的，然后电话直接使用+86，这是中国大陆的电话。注意要和国区的电话不同，你可以用朋友或者爸妈的。点击完成后，会进入到邮箱验证环节，这部完成后，就注册好了。

  • 对苹果设备进行加速。现在到手机端操作了，手机端操作需要使用“网易UU加速器”，登录后，加速“App Stroe”进行加速。，这个加速是免费的。

  • 重新登录 App Stroe。注意我们需要大退，然后再用刚才注册的土耳其区帐号登录。

  • 配置网络环境（科学上网）。然后重新打开APP Stroe 会变成全英文。如果不是英文，说明你的网络环境没有配置好。

  • 安装ChatGPT：到App Stroe中搜索ChatGPT，选择安装。这时候会跳出付款页面，如果这时候让我们付款，我们只需要选择None。

  • 充值礼品卡，获得500里拉：某鱼搜索“土耳其礼品卡”，或者使用（https://www.seagm.com）直接找到土耳其礼品卡就可以了。

  • 付款页面：用豆包生成土耳其地区的邮寄方式，就可以得到对应的城市、电话和详细地址。我们这时候也有了500里拉，就可以充值成功了。

  • 系在Codex桌面端，打开ChatGPT，左下角就可以选择下载Codex了，到此为止，全部安装完成。

（3）接收验证码

有时候因为网络不稳定，或者帐号太新，会要求我们验证手机号，而且大陆手机号没办法验证，但我们依然有办法解决这个问题（我的博客里是有文字版教程的，但是视频中不方便说，遇到问题去查看文字教程吧。）这时候我们就需要使用接码平台。

我这里使用的是https://hero-sms.com ，然后是用日本或者泰国的方式电话号接码就可以了。这个也是需要提前充值的。

安装Codex Desktop （桌面版）

当你有了帐号后，直接到https://openai.com/zh-Hans-CN/codex/ 去下载Codex 桌面客户端，就可以了。下载之后选择安装，安装过程非常简单，你是windows就选Windows版本下载，Mac的选Mac 下载。如果你还不能打开这个网址，去看文字版安装教程。

下载之后，用我们注册好的OpenAI帐号登录就可以了，如果你看了文字教程，这时候你应该已经是Plus会员了。也就是说你可以使用了。

![[Pasted image 20260608151511.png]]

Codex CLI的验证和安装

如果你是用Codex写代码，我建议你还要验证一下CodexCLI是否安装好了。因为在开发程序这件事上，最推荐的入口不是先打开桌面端程序，而是先安装 Codex CLI。因为 CLI 是最贴近真实开发现场的方式：你在哪个项目目录启动它，它就能围绕这个项目读取代码、执行命令、修改文件、运行测试，并和你持续对话。

Codex Desktop 和 Codex CLI 是同一个本地 Codex 生态的两个入口，也就是说大多数情况下，你安装好了Desktop也就安装了CLI。桌面端会使用本地 Codex 能力；但如果你想在任何终端里直接输入 codex，最好仍然单独验证 CLI 命令是否可用。

验证Codex CLI是否可用，打开PowerShell，然后输入：

codex --version
codex-cli 0.137.0

如果出现版本号，说明安装成功，如果提示找不到命令，需要手动安装CLI。
安装前需要确认自己已经安装了node 和npm ，然后是用下面的命令进行安装。

npm install -g @openai/codex

你已经安装了桌面端，并登录过了，这里就不需要你再登录了。

4. 新建项目和打开第一个项目

平时和Codex 交流、或者作图并用不到项目，但是如果你想用它写代码，就需要创建一个项目。这里先讲如何创建一个新项目。
![[Pasted image 20260608155954.png]]
在客户端点击“新对话”，然后在对话框下面有一个“进入项目工作”的下拉框，选择“添加新项目”，会出现两种方式:

  • 第一种“新建空白项目" : 选择后让你给项目起个简短的名字，起好后，项目就建立完成了。但这时候项目默认创建到了Codex的工作空间，所以不推荐使用这种方式。
  • 第二种"使用现有文件夹"： 点击后，会让你选择已存在项目的文件夹，如果你还没有项目，就自己到磁盘中任意位置，创建一个项目文件夹就可以。

你还可以使用Codex CLI的方式打开或者创建，我这里打开命令行，我使用的是开源的Warp，你使用PowerShell也是没有问题的。命令都是一样的，我这里以E盘的Test文件为例。

直接输入：

cd e:/Test
codex
// 如果还没有创建文件夹
e:
mkdir Test
cd Test 
codex

5. 让它读懂项目结构- 老项目专用

如果你已经有了个老项目，我们进入项目的第一件事，不是上来就让它写代码，而是先让它证明自己读懂了项目。

这一步我推荐安装一个插件CodeGraph，它可以把项目解析成符号和调用关系，说白了它是Codex全面了解一个代码项目的插件。有了它就不用从零翻代码，而是直接看代码图谱，也就是会让智能体从“能回答”，变得更快，更少工具调用、更结构化的回答和编码。而且它生成的是本地图谱，不再消耗多余Tokens。

安装方法

进入命令行，然后输入命令：

npm i -g @colbymchenry/codegraph

或者你直接跟Codex说

帮我安装 "@colbymchenry/codegraph" 这个插件。

这样Codegraph这个插件就安装好了。

然后在进入项目后，需要初始化一下codegraph，直接在命令行输入。

cd your-project
codegraph init -i

之后Codex就有了整个项目的知识图谱，再使用就是隐式的使用，然后再问项目相关的问题，他就会自动先去看它自己生成的关系和图谱。如果图谱中没有相关的东西，她就再深入了解，然后生成。不仅会为你节省Tokens，还会让Agent使用越来越快。

下面我就拿我自己的博客项目为例，让Codex给我列出项目结构，并存放到项目根目录下的FilesTree.md下。

我们来到Codex桌面客户端来操作，我这里已经建好了项目。然后打开命令行工具，比如PowerShell，进入到项目目录的位置。

先用命令行初始化CodeGrraph，然后打开来到Codex，直接打字。

了解项目，以树状形式，列出项目结构，并把结构放入到FilesTree.md 文件下。

这时候Codex就开始思考和查看项目了，我们稍等一会，它就会给我们新建一个md文件，并在里边把项目结构列出了。

二、基础交互与真实开发流畅

第一大部分完成了，现在你的Codex和项目已经准备好了，接下来进入Codex的核心工作流畅。带着你一步步实现一个程序。通过一个实战，掌握Codex开发程序的整个流畅。我们就开发一个最简单的ToDoList(任务清单列表)的项目，这也是大多数学程序时作的第一个项目。

1. VSCode中新建项目-实战带动学习

因为是编程，所以这里转战到了VSCode中，你直接搜索VSCode就可以下载并安装它，因为时间关系，安装的步骤我就不展示了。然后我们打开VSCode，可以安装一个“中文的插件”，再到插件市场搜索“Codex” ，找到正确的插件，然后进行按照。

安装后，我们可以到系统中新建文件夹。比如我这里是E:/code/codex-test，这个路径你随意，没必要和我一样。我是用命令行创建的项目。然后把项目目录拖到VSCode中，这样项目就创建完成了。

2. Codex的工作方式：读代码、制定计划、改文件、运行命令、验证结果

接下来正式进入Codex的核心工作方式。
很多新手第一次用 Codex，会直接输入一句：

帮我制作一个ToDoList 应用

这当然可以，但如果你想让 Codex 更稳定、更可控，我更推荐你理解它背后的工作流程。

第一步，读代码。
第二步，制定计划。
第三步，修改文件。
第四步，运行命令。
第五步，验证结果。

这五步，其实就很像一个真实程序员接到任务后的工作方式。

比如你给一个人类工程师一个需求：登录页面点击按钮没有反应。一个靠谱的工程师不会上来就乱改。他会先看项目结构，找到登录页在哪里，看看按钮绑定了什么事件，请求发到了哪个接口，再判断问题可能出在哪里。

Codex 也是一样。

第二步：制定计划

因为我们是一个全新的项目，所以第一步读代码，就可以先省略掉了。从第二步开始"制定计划"。
比如我们这样对Codex说：

现在我要制作一个ToDoList的应用，Vue.js 来制作，让我直接能在浏览器里运行。请给我一个计划，不要直接开发。

这里的重点是“先给计划”。因为 Codex 的能力很强，但越是能自动执行，我们越要让它在关键节点停一下。计划不是形式主义，它能让你判断 Codex 有没有找对方向。
如果计划里出现明显不对的地方，比如它要开发的样式不对，你就可以立刻纠正它。这样比等它改完一堆文件再回滚，要舒服得多。

**第三步，修改文件

当你确认计划没问题，就可以说：

按这个计划修改代码, 开发时要保持代码简洁，不要做无关开发。

开发中有一条非常关键，就是保持代码简洁，不要有过多的冗余代码。修改代码也是一样，能改一处解决，就不要顺手改十处；能修 bug，就不要顺手重写架构。

第四步，运行命令。

这也是 Codex 和普通聊天工具最大的区别之一。普通聊天工具通常只能告诉你“你应该运行 npm test”。但 Codex 可以直接在你的项目里运行命令，比如：

npm test
npm run build
npm run lint

当然，具体命令取决于你的项目。前面为什么要先让 Codex 总结启动命令和测试命令？就是为了让它后面知道该怎么验证。

这时候我们就可以在浏览器里查看这个DodoList项目了，也就是最后一步，验证结果了。上面这个流程就是最简单的开发或者修改需求的一个完整流畅。

这五步开发流程，也是我建议大家学习 Codex 时最先养成的习惯。不要急着追高级功能，先把这个基础循环用熟。因为只要这个循环稳定了，Codex 就不再只是一个会聊天的 AI，而是一个能参与真实开发任务的 AI 工程同事。

3.让 Codex 执行终端命令：测试、构建、查日志、跑脚本

上面的程序我们可以看到结果了，接下来我们看Codex很重要的一个能力：执行终端命令

Codex大家觉的好用的一个最主要原因，就是他可以运行终端命令，也就是从一个只会写代码的智能体，变成了可以调试环境，找Bug，测试、构建项目，到最后运行项目的全流程智能体。

(1)查看有哪些命令

比如我们可以对Codex说：

请查看这个项目有哪些可用脚本，并告诉我测试、构建、启动分别应该运行什么命令。

它就会去读package.json 或者项目里的说明文档，然后告诉你应该运行哪些命令。
比如前端项目里，常见命令可能是：

npm test
npm run build
npm run lint
npm run dev

后端项目可能是：

这里要理解一点：让 Codex 跑命令，不是为了炫技，而是为了验证。

（2）开发循环：运行、观察、分析、再修复

写代码只是第一步，真正可靠的开发流程，一定要有验证。比如 Codex 修完一个 bug 之后，你可以继续说：

请运行项目已有的测试命令，确认这次修改没有破坏现有功能。

如果测试失败，也不用马上慌。你可以让 Codex 继续读取失败信息：

测试失败了，请根据终端输出分析原因。先告诉我问题在哪里，不要急着修改。

这就是 Codex 和普通代码助手最大的区别之一：它不是只生成代码，而是可以参与“运行、观察、分析、再修复”的循环。

（3）查看日志 辅助开发

除了测试和构建，Codex 也可以帮我们查日志。
比如和Codex说：

请查看最近的错误日志，找出导致启动失败的关键报错。

或者说：

请运行启动命令，如果失败，请根据日志定位原因。

所以我们通过直接和Codex用自然语言说话，就可以查看错误日志，从而定位到错误位置，找到错误位置后，你就可以直接和Codex说：

修改这个错误，完成后续开发。

（4）执行命令的风险 注意事项

执行终端命令很强大，但是越强大的东西，越需要防范注意。这里有一个重要习惯：涉及删除文件、安装依赖、修改数据库、发布上线这类高风险命令时，不要让 Codex 直接执行。你可以要求它先解释：

这个命令会做什么？有没有风险？确认后我再让你执行。

所以这一节的核心不是“Codex 能跑命令”，而是：让 Codex 用命令验证自己的判断。

你可以记住一个简单流程：

  1. 先让它找命令
  2. 再让它运行命令
  3. 然后让它解释结果
  4. 最后根据结果继续修复

当你掌握这个流程之后，Codex 就不只是一个写代码的工具，而是一个能和你一起完成测试、构建、查日志、跑脚本的开发助手。

4. 权限模式讲解：请求批准、替我审批、完全访问权限

接下来我们讲 Codex 里非常重要的一部分：权限模式。

因为 Codex 不只是聊天，它可以读文件、改代码、运行命令。既然它能真正操作项目，那我们就必须知道：什么时候让它自己做，什么时候必须让它先问我们。

在对话窗口的下面可以看到，它有三种权限模式：

  • 请求批准：编辑外部文件和使用互联网时始终询问
  • 替我审批：仅对检测到风险操作请求批准
  • 完全访问权限：可不受限制地访问互联网和您电脑上的任何文件

（1）请求批准

这个模式最适合新手，也适合你不太熟悉的项目。它的特点是：Codex 可以帮你分析问题、提出计划，但遇到修改文件、执行命令、访问敏感位置时，会先停下来问你。

比如它可能会说：我准备修改这两个文件，是否允许？

这个模式的好处是安全。你可以看到 Codex 想做什么，再决定要不要放行。

所以如果你刚开始使用 Codex，我建议先用这个模式。尤其是公司项目、生产项目、重要仓库，不要一上来就给太高权限。

（2）替我审批

这个模式更适合日常开发。它的意思是：在当前项目范围内，Codex 可以更主动地帮你读代码、改文件、运行测试，不用每一步都问你。

比如你让它修一个 bug，它可以自己修改项目里的代码，然后运行测试命令验证。

但这并不代表它完全没有限制。通常情况下，如果它要访问项目外的文件、使用网络、做更高风险操作，还是会受到限制或者需要额外确认。

所以“替我审批”适合你信任当前项目，也希望 Codex 工作更流畅的时候使用。

你可以这样理解：

请求批准：每个关键动作都让我看一眼。
替我审批：项目内的常规开发动作，让 Codex 自己推进。

(3)完全访问权限

这个模式权限最大。Codex 可以更自由地操作你的机器，包括跨目录访问、运行更多命令，甚至在配置允许时使用网络。

它的效率最高，但风险也最高。

所以我不建议新手一开始就使用完全访问权限。除非你非常确定当前任务安全，项目可信，而且你知道 Codex 可能会做什么。

比如你在一个临时测试目录里，让 Codex 批量整理文件、安装依赖、跑完整构建，这种情况下可以考虑完全访问权限。

但如果是重要项目、公司代码、带有密钥或生产配置的目录，就不要随便开这个模式。

做个简单的比喻：

请求批准：Codex 每一步都先敲门。
替我审批：Codex 可以在项目房间里自由工作。
完全访问权限：Codex 拿到了整台电脑的通行证。

我个人建议的使用顺序是：


陌生项目：请求批准。
日常开发：替我审批。
临时环境或高度信任任务：完全访问权限。

最后记住一句话：

权限越高，效率越高；但权限越高，你越要确认任务和项目是可信的。

Codex 很强，但越强的工具，越需要边界感。真正稳定的使用方式，不是永远给最大权限，而是根据任务风险选择合适的权限。

5. 查看 diff、验证测试、让 Codex 总结改动

当 Codex 修改完代码之后，我们不要马上就说“完成了”。真实开发里，写完代码只是第一步。接下来还有三件事非常重要：

  • 查看 diff
  • 跑测试
  • 让Codex 总结改动。

(1)查看diff

diff 就是这次到底改了哪些内容。Codex 修改代码后，你可以让它自己先总结，也可以用 git 查看：

git diff

如果你在Codex里，可以直接和它说：

请查看这次改动的 diff，告诉我主要修改了哪些地方，有没有无关改动。

比如我在TodoList下面增加了一个全选的功能，它却顺手重构了整个项目，或者修改了一堆无关样式，这就要小心。

所以看 diff 的重点不是逐行挑刺，而是看三个问题：

  • 改动范围是否合理？
  • 是否只解决当前问题？
  • 有没有无关重构或风险操作？

（2）跑测试

如果项目里有测试命令，就让 Codex 跑测试：

text 请运行项目已有的测试命令，验证这次修改是否通过。

如果项目没有测试，也可以让它运行构建或 lint：

如果没有测试，请运行构建或 lint，至少确认项目没有明显错误。

测试失败也没关系。关键是让 Codex 根据失败信息继续分析：

测试失败了，请根据输出分析原因。先告诉我问题在哪里，不要急着继续修改。

这里你会发现，Codex 的优势不是一次写对所有代码，而是它可以参与“修改、运行、观察结果、继续修复”的循环。

(3) 让 Codex 总结改动

当 diff 看过了，测试也跑过了，最后要让 Codex 给你一个清晰的交付说明。

可以这样和它说：

请总结这次修改：改了哪些文件、每个文件为什么要改、运行了什么验证命令、结果是什么。

一个好的总结应该包含四部分：
- 修改文件
- 修改原因
- 验证命令
- 验证结果
这一步很适合放进你的开发习惯里 ，也就是写入AGENTS.md 文件里，后面我会专门讲解这部分知识。
所以 Codex 的完整闭环，不是“它说修好了”就结束，而是：


看 diff，确认改动范围；
跑测试，确认功能没有坏；
看总结，确认这次任务有证据。

记住，AI 写代码并不等于任务完成。只有经过 diff 和测试验证的代码，才更接近可以交付的代码。一个可靠的 Codex 工作流，最后一定要有改动总结和验证结果。

三、Codex的 上下文、多模态与会话管理

前面我们已经看到，Codex 可以读代码、改文件、跑命令、验证结果。但真正用好 Codex，还要学会管理上下文。

上下文就是 Codex 当前知道的信息：项目结构、你的要求、测试输出、修改记录、截图内容，以及项目规则。上下文越清楚，Codex 的判断越稳定。

这一部分我们会讲多模态输入、会话恢复、上下文清理，以及 AGENTS.md 项目记忆。掌握这些后，Codex 就不只是一次性回答问题，而是能围绕真实项目持续协作。

1. 图片输入：截图报错、UI 截图、设计稿截图如何交给 Codex

Codex 是拥有多模态能力的，也就是说他可以生成图片和看到图片。在真实开发里，很多问题不是一句文字能说清楚的。比如页面错位、按钮溢出、控制台报错、设计稿和实现不一致，这些问题最适合直接截图给 Codex 看。

（1）截图报错

比如你运行项目时，浏览器或者终端出现了一段报错。你可以把截图发给 Codex，然后说：

这是当前报错截图，请帮我识别关键错误信息，并结合项目代码分析可能原因。先不要修改文件。

(2) UI 截图

比如移动端页面按钮被挤出屏幕，或者文字重叠。你可以说：

这是页面截图，移动端布局出现溢出。请结合当前项目样式，定位可能相关的组件和 CSS 文件。

如果你希望它修复，可以继续说：

请按最小改动修复这个 UI 问题，并说明你改了哪些样式。

（3） 设计稿截图

如果你有 Figma 或其他设计稿截图，可以交给 Codex，让它对比当前页面实现：

这是设计稿截图，请对比当前页面实现，指出主要差异。先给我修改建议，不要直接改代码。

这里也建议先让 Codex 做差异分析，再决定是否修改。

使用图片时，我建议大家养成一个习惯：图片加文字说明一起发。

不要只丢一张截图。你最好告诉 Codex：

这张图是什么？
哪里不对？
你希望它做什么？
是否允许修改文件？

比如一个完整提示词可以这样写：

这是移动端页面截图，问题是底部按钮被遮挡。请结合项目代码定位原因，先给我修复计划，不要修改文件。

这样 Codex 不只是识别图片，而是把图片变成项目上下文的一部分。

所以图片输入的核心价值，不是让 Codex 看热闹，而是让它看见你看见的问题。

当文字描述不清楚时，截图就是最好的上下文。

2.图片生成/编辑：让 Codex 生成图标、占位图、教程封面素材

刚才讲的都是对图片的识别，Codex 还可以帮我们生成和编辑图片。这个能力在开发和内容创作里都很实用。比如你在做一个新项目，暂时还没有正式设计素材，就可以让 Codex 先生成图标、占位图、插画，甚至教程封面和UI设计图。

比如我现在要给ToDoList 应用生成一个图标，就可以和Codex说：


请生成一个简洁的应用图标，主题是 任务列表和操作，适合放在项目首页。

这里要注意，图片生成和代码生成一样，提示词越清楚，结果越稳定。

你最好说明四类信息：

1. 用途是什么；
2. 画面里有什么；
3. 风格是什么；
4. 尺寸或比例是什么。

这里提供我一张生成视频头图的提示词，里边内容很多，目的是让小伙伴明白。生成图片到底要如何精细的用提示词控制图片。

生成一张竖版短视频封面图，比例 3:4，风格参考爆款知识类视频封面，画面要有强烈冲击力和漫画感。

画面上方放置醒目的中文标题： “Claude Ultracode 超码 上线 保姆级实战教程 操控100个Agent并行开发” 文字占据画面上二分之一部分，字体粗壮夸张，类似手写海报字和科技标题字结合。 “Claude Ultracode 超码 上线 ”使用白色粗体笔刷字 ，“保姆级实战教程"使用蓝色粗体笔刷字， “操控100个Agent并行开发”使用橙黄色火焰字体，带火焰燃烧、火星飞溅、爆炸光效。

画面下方中间是一个夸张日漫风格的程序员人物（参考我给你的图片），头发稀疏，戴圆形眼镜，很高兴，表情很酷，不要张嘴，要冷冷的微笑，双手抱在胸前和给的预览图一样，穿着深蓝色的衣服。人物动作夸张，表情抓人，漫画线条明显。 
画面下方左边是知识卡片，卡片内容有6个: 
- 开启超码功能 
- 概念讲解
- 实战项目 
- 控制好Tokens 
- 复用工作流 
- 对超码的理解
这些知识卡片使用冰冻形式的漫画字体。 注意这些卡片都再人物的后边，但不要挡住太多知识卡片


背景是深黑色和深蓝色，远处有不清晰的密密麻麻的AI机器人在编写代码，带速度线、笔刷划痕、蓝色光效、红橙火焰飞溅。整体高饱和、高对比、锐利清晰，像 B 站/抖音爆款科技知识视频头图，商业海报质感。



不要真实照片风格，不要低清晰度，不要水印，不要多余文字，不要英文乱码，不要人物畸形，不要多余手指。面、游戏宣传海报，高对比度，高饱和度，强光影，动态构成

如果你已经有一张图片，也可以让 Codex 做编辑。比如上面这张生成的图片，我想要一个横版的，就可以和它说:

把这张图片生成横版的，要两张，要求4:3的比例和16:9的

这时候就生成了两张横版的图片。
对开发者来说，图片生成最适合三个场景：


第一，项目早期没有素材，用它做占位图。
第二，做教程、文章、视频时，用它生成封面和插图。
第三，做产品原型时，用它快速探索视觉方向。

用AI生成图片，现在已经是新兴职业了。写提示词也有很多技巧，需要你花很多精力去学习和实践。不过我们生成简单的开发用图，还是不需要那么多技巧的。

3. Resume：恢复历史会话，接着上次任务继续做

喝口水，休息一会。接下来我们讲一个非常实用的功能：Resume，恢复历史会话，特别对喜欢使用终端命令行的程序员小伙伴特别有用。

我们用 Codex 做真实项目时，一个任务不一定一次就做完。比如你今天让 Codex 分析了项目结构、制定了修复计划、改了一半代码，但临时有事关掉了窗口。明天再继续，如果从头解释一遍，就很浪费时间。

这时候就可以用 Resume。 我们这里来到了VSCode中的命令终端进行操作。

在终端里，你可以输入：

codex resume

它会列出之前的会话，你选择一个，就可以接着上次的上下文继续工作。

如果你想直接恢复最近一次会话，可以用：

codex resume --last

Resume 的价值在于，它保留了前面的对话、计划、判断和任务进度。你不用重新告诉 Codex：这个项目是什么、刚才改了哪些文件、下一步要做什么。

比如恢复之后，你可以直接说：

继续上次的任务。请先回顾当前进度，然后告诉我下一步准备做什么。

这句话我很推荐。因为恢复会话后，不要马上让 Codex继续改代码，最好先让它总结一下上下文。

Resume 很适合这些场景:

长任务做到一半；
调试问题需要分多次处理；
代码审查还没结束；
昨天的计划今天继续执行；
复杂项目不想重复解释背景。

不过也要注意，如果项目文件在这期间发生了变化，恢复后最好让 Codex 重新检查一下当前状态。

恢复上次任务后，请先检查当前 git diff 和项目状态，再继续。

所以 Resume 的核心不是“打开旧聊天记录”，而是让 Codex 接着一个工程任务继续工作。

用好这个功能，你就可以把 Codex 当成一个长期协作的开发伙伴，而不是每次都从零开始的聊天窗口。

4. Clear 与上下文压缩：什么时候清空，什么时候保留上下文

接下来我们讲上下文管理里另一个重要问题：什么时候清空上下文，什么时候保留上下文。

Codex 在一个会话里会记住很多信息，比如你前面的需求、它读过的文件、运行过的命令、测试输出、修改计划。这些信息就是上下文。

上下文的好处是：Codex 可以接着前面的任务继续做，不用每次从零开始。

（1）保留/清空 上下文

但上下文太多，也可能带来问题。比如前面讨论过很多无关方案，或者任务方向已经变了，Codex 还在参考旧信息，这时候它的判断可能会变得不稳定。而且上下文越多Tokens的消耗也是越多的。

所以我们要学会两个动作：

  • 保留上下文
  • 清空上下文

什么时候应该保留？

如果你还在做同一个任务，比如继续修同一个功能开发，比如说登录功能、继续分析同一个项目，那就应该保留上下文。

这时候，你经常会和Codex说：

继续刚才的任务，沿用前面的分析和计划。

什么时候应该清空？

如果你已经换了一个完全不同的任务，或者前面的对话很混乱，或者 Codex 一直被旧方案影响，改了三次Bug依旧存在，这时候就可以清空上下文。

在 CLI 里，可以使用：

/clear

如果是客户端里，直接开始一个新的对话就可以了。

（2）压缩/总结上下文

除了手动清空，还有一种情况叫上下文压缩。简单理解，就是当会话太长时，Codex 会把前面的内容压缩成摘要，尽量保留重要信息，减少无关细节。（在客户端中，当对话过长时，会自动压缩上下文）

但压缩毕竟是摘要，不可能百分百保留所有细节。所以在长任务里，我们最好主动让 Codex整理阶段性总结。

比如和Codex说：

请总结目前任务目标、已完成内容、关键决策、剩余问题，方便后面继续。

这样即使后面上下文变长，重要信息也更容易被保留下来。

你可以记住一个简单原则：

  • 同一个任务，保留上下文。
  • 换了任务，清空上下文。
  • 长任务，中途做总结。

这就是 Codex 上下文管理最实用的三句话。

用好 Clear 和上下文压缩，Codex 就不会被旧信息拖累，也更容易在长任务里保持稳定。

5. AGENTS.md：Codex 的项目记忆文件，保存项目规则、测试命令、代码规范

接下来我们讲一个非常重要的文件：AGENTS.md。

（1）什么是AGENTS.md文件

如果说普通提示词是一次性的提醒，那么 AGENTS.md 就是 Codex 的项目说明书。

我们在使用 Codex 时，经常会反复提醒它：

修改代码前先说计划。
改完之后要跑测试。
不要改生产配置。
遵守项目现有代码风格。

如果每次都手动说一遍，就很麻烦。这个时候，就可以把这些长期规则写进 AGENTS.md。

Codex 在进入项目时，会读取这个文件，并把它当成项目级指导。也就是说，只要规则写在这里，Codex 后续处理任务时就会参考它。

AGENTS.md  适合保存三类内容。

（2）第一类，是项目命令。

比如：

## Commands

- 启动项目：npm run dev
- 运行测试：npm test
- 构建项目：npm run build
- 代码检查：npm run lint

这样 Codex 就不用每次都重新猜测试命令是什么。

（3）第二类，是代码规范。

比如：

## Code Style

- 优先使用 TypeScript。
- 保持现有组件结构。
- 不要做无关重构。
- 修改样式时优先复用已有 class。

这能让 Codex 的改动更贴近项目习惯。

（4）是工作规则。

比如：

## Workflow

- 修改文件前先说明计划。
- 修改完成后必须总结改动。
- 如果测试失败，先分析原因，不要盲目继续改。
- 涉及删除文件、安装依赖、修改配置时，先询问用户。

这些规则其实就是你希望 Codex 像团队成员一样遵守的工作方式。

所以我建议每个长期项目都准备一个 AGENTS.md。它不需要一开始写得很复杂，先写最关键的几条就够了。当你经验越来越丰富的时候，这个文件的内容也会越多，但过多的内容和约束，反而会让Codex变的混乱。

比如最小版本可以这样写：


# AGENTS.md

## Project Rules

- 修改前先说明计划。
- 保持最小改动，不做无关重构。
- 修改后运行测试或构建命令。
- 总结修改文件、原因和验证结果。

以后当你发现 Codex 经常犯同一种错误，比如忘记跑测试、改动范围太大、忽略某个目录规则，就可以把这条经验补进 AGENTS.md。

这就是一个很重要的思路：不要每次都靠临时提醒，要把重复规则沉淀下来。

所以 AGENTS.md 的核心价值，不是多一个文档，而是让 Codex 更像了解这个项目的长期协作者。

它保存的不是代码，而是项目里的工作习惯。我在文字稿里放了我真实项目的一份AGENTS.md,你们可以参考一下。

四 .扩展 Codex：从工具到团队工作流

第四部分我们进入 Codex 的扩展能力。前面讲的是如何使用 Codex 完成单个开发任务，这一部分讲的是如何把 Codex 接入更大的工作流。

通过 MCP，Codex 可以连接 Figma、GitHub、文档、浏览器等外部工具；通过 Skills，可以把重复流程封装成可复用能力；通过 Subagents，可以让多个 agent 并行探索、测试和审查；通过 Hooks，可以在关键节点加入校验、日志和安全检查；最后再用 Plugins 把这些能力打包分发。

学到这里，Codex 就不只是个人工具，而是可以逐步变成团队级 AI 开发系统。

1.MCP 是什么：把 Figma、GitHub、文档、浏览器等外部工具接进 Codex

第一个要讲的扩展能力，就是MCP。我们先讲理论，然后再来两个实战，把MCP的内容全部掌握牢固。

（1）什么是MCP

MCP 的全称是 Model Context Protocol，可以简单理解成：让 Codex 连接外部工具和外部上下文的标准接口。

前面我们讲的 Codex，主要是在本地项目里工作。它可以读代码、改文件、运行命令。但真实开发中，很多信息不只在代码仓库里。

比如下面的情况：

  • 设计稿在 Figma 里；
  • 需求在Docs文档里；
  • 任务在 GitHub Issue 里；
  • 页面效果需要浏览器验证；

如果没有 MCP，你可能需要手动复制这些信息给 Codex。
有了 MCP，Codex 就可以通过对应的 MCP Server 读取或操作这些外部工具。
你可以把 MCP 想象成 Codex 的“外接工具接口”。

( 2 ) MCP的核心价值

MCP 的核心价值是：

把 Codex 从本地代码助手，扩展成能理解外部工作环境的开发智能体。

不过这里也要注意：MCP 不是越多越好。每接一个外部工具，就等于给 Codex 多了一种能力，也多了一层权限和风险。

所以新手使用 MCP，我建议先从低风险、只读类工具开始，比如文档查询、设计稿读取、浏览器截图。等熟悉之后，再接入 GitHub 操作、任务管理、线上日志这类更强的工具。

我们可以这样理解：

AGENTS.md 让 Codex 理解项目规则；
MCP 让 Codex 连接项目之外的世界。

当 Codex 能同时看到代码、设计稿、需求文档和运行页面时，它的判断就会更接近真实开发现场。

这就是 MCP 的意义。

它不是一个单独功能点，而是 Codex 进入团队工作流的入口。

2. 以 Docs MCP 为例：让 Codex 读取外部上下文再写代码

接下来我们用一个实战例子，演示 MCP 的价值：Docs MCP。 我这里有一份Docs格式的开发需求文档，文档里主要是开发一个时钟应用的例子。

（1） 检查是否安装了Docs MCP

进入终端，我这里依然是用的Warp，你可以使用任何的命令行终端。进入一个项目，我这里还是使用ToDoList这个项目，我通过cd 命令快速进入了项目。

cd e:/code/TodoList
codex
/mcp

如果已经安装，你会看到类似这些 MCP server：

MCP Tools

  • codegraph
    • Auth: Unsupported
    • Tools: codegraph_callees, codegraph_callers, codegraph_context,
    codegraph_explore, codegraph_files, codegraph_impact,
    codegraph_node, codegraph_search, codegraph_status

  • codex_apps
    • Auth: Bearer token
    • Tools: (none)

  • node_repl
    • Auth: Unsupported
    • Tools: js, js_add_node_module_dir, js_reset

  • openaiDeveloperDocs
    • Auth: Unsupported
    • Tools: fetch_openai_doc, get_openapi_spec, list_api_endpoints,
    list_openai_docs, search_openai_docs

这里有一个OpenaiDeveloperDocs 这个就是 Docs 的MCP服务了，如果你没有，就需要再安装。

（2） 安装 Docs MCP

如果你没有安装 类似的MCP服务，推荐安装 OpenAI 官方 Docs MCP：

我是用Codex CLI进行安装，因为这种方法最简单。

codex mcp add openaiDeveloperDocs --url https://developers.openai.com/mcp

注意：安装完成后，重新打开 Codex，或者重新开一个会话, 重新查询mcp服务

codex
/mcp

这时候就会有这个MCP服务了

（3）使用Docs MCP服务

使用的时候可以回答桌面端，或者直接CLI也没有问题。
比如这时候可以和Codex说：

请使用 Docs MCP 来查看这个需求文档，然后给我一个开发计划，先不要直接编写代码。

这句话有两个关键点：

  • 第一个关键点是：让 Codex 明确使用 Docs MCP。

  • 第二个关键点是：先给建议，不要马上改代码。

如果你确认开发计划没有问题，在继续说。

计划没有问题，现在可以开始开发了。

这样就形成了一个更可靠的开发流程。MCP 的价值不是“多了一个工具按钮”，而是让 Codex 拿到项目之外的上下文。

这在使用新框架、新 SDK、新 API 时非常有用。

如果没有 Docs MCP，我们可能要自己打开浏览器、搜索文档、复制内容、再粘贴给 Codex。

有了 Docs MCP，Codex 可以直接完成“查文档、读项目、给建议、改代码、跑验证”这一整套流程。

这就是 MCP 在真实开发里的意义：它让 Codex 不再只依赖聊天上下文，而是能主动读取外部知识，再回到项目中完成任务。

3.Skills：把重复流程做成可复用能力，例如日报、代码审查、发布流程

接下来我们讲 Codex 的另一个扩展能力：Skills。 事先说，这个只是简单的介绍，让你知道什么是Skills，会使用，会简单的制作。但并不深入，因为Skill值得拿出一个完整的视频来讲。我会尽快出Skills的相关视频，帮小伙伴们补足短板。

言归正传！前面我们讲过 AGENTS.md，它适合保存项目规则，比如测试命令、代码规范、工作习惯。

而 Skills 更适合保存一套可重复执行的流程。

比如你经常让 Codex 做这些事：
- 每天生成项目日报
- 审查当前代码改动
- 整理发布说明
- 检查安全风险

如果每次都手写一大段提示词，就很麻烦。这个时候，就可以把这套流程做成一个 Skill。

一个 Skill 通常是一个文件夹，里面有一个 SKILL.md。这个文件会告诉 Codex：什么时候使用这个 Skill，以及使用时应该按什么步骤做。

接下来我们做一个最简单的实操案例：创建一个“代码审查 Skill”。

它的作用是：当我让 Codex 审查代码时，它不要随便泛泛而谈，而是按照固定顺序检查 bug、测试缺口、风险和可维护性。

我们可以先让 Codex 帮我们创建 Skill。提示词可以这样写：

请帮我创建一个名为 code-review 的 Skill。
用途是：当我要求审查当前代码改动时，Codex 按固定流程检查潜在 bug、测试缺口、安全风险和可维护性问题。
请生成 SKILL.md 内容，用中文，先不要写入文件，先展示给我确认。

Codex 可能会生成类似这样的内容：

---
name: code-review
description: 当用户要求审查当前代码改动、review diff、检查 PR/工作区变更、找潜在 bug、测试缺口、安全风险或可维护性问题时使用。按固定代码审查流程读取变更、理解上下文、优先报告高风险问题，并给出可验证的改进建议；适用于本地 git diff、暂存区、未提交改动、PR patch 或用户粘贴的代码变更。
---

# Code Review

## 目标

以代码审查者身份检查当前改动，优先发现会导致线上问题、数据错误、安全风险、测试遗漏或长期维护成本上升的缺陷。不要把审查变成泛泛夸奖或风格润色；先找风险，再给建议。

## 固定流程

1. 明确审查范围
   - 如果用户没有指定范围，默认审查当前工作区相对 `HEAD` 的改动。
   - 优先查看 `git status --short`、`git diff --stat`、`git diff`。
   - 如果存在暂存区改动，也查看 `git diff --cached`。
   - 如果用户提供 PR、commit、patch 或文件路径，只审查用户指定范围。

2. 理解改动意图
   - 从 diff、文件名、测试、提交信息或用户描述推断本次改动要解决的问题。
   - 必要时阅读相关调用方、被调用方、配置、测试和数据模型。
   - 若项目提供 CodeGraph，结构性问题优先使用 `codegraph_context`、`codegraph_callers`、`codegraph_callees`、`codegraph_impact` 等工具理解影响面。

3. 按风险顺序检查
   - 潜在 bug：边界条件、空值、异常路径、并发/异步、状态同步、生命周期、类型假设、时区/日期、分页、缓存、权限分支、回滚路径。
   - 测试缺口：新增行为没有测试、只测 happy path、缺少回归测试、缺少错误路径/边界值/权限测试、测试断言过弱。
   - 安全风险：认证绕过、授权缺失、敏感信息泄漏、注入风险、路径遍历、SSRF/XSS/CSRF、不安全反序列化、日志泄密、依赖或配置误用。
   - 可维护性问题：重复复杂逻辑、职责混乱、隐式约定、命名误导、错误处理不一致、难以扩展的分支、破坏已有架构边界。
   - 兼容性和迁移风险：schema 变化、配置默认值变化、API 合约变化、老数据/老客户端兼容、部署顺序问题。

4. 验证判断
   - 能运行轻量测试或静态检查时，运行与改动最相关的命令。
   - 不要为了审查大范围重构或修改文件，除非用户明确要求修复。
   - 如果不能运行测试，说明原因，并把结论标记为基于静态审查。
   - 对每条问题尽量给出可复现路径、失败条件或具体触发场景。

5. 输出审查结果
   - 先列发现的问题，按严重程度排序。
   - 每条问题包含：严重级别、文件/行号、问题描述、影响、建议修复方向。
   - 如果没有发现明确问题，直接说明“未发现阻塞性问题”，再列出残余风险或建议补充的测试。
   - 不要把“改得不错”放在最前面；总结放在问题之后。

## 严重级别

- P0：会导致数据损坏、安全事故、服务大面积不可用，或必须立即阻止合并。
- P1：高概率线上 bug、权限/安全缺陷、关键流程失败、明显缺失的回归测试。
- P2：中等风险问题、边界条件缺陷、维护成本显著增加、测试覆盖不足但不一定阻塞。
- P3：低风险建议、可读性、局部重构、命名或一致性改进。

## 输出格式

使用以下结构：

```markdown
## Findings

- [P1] 标题
  文件：`path/to/file.ext:123`
  问题：说明具体缺陷，不要泛泛而谈。
  影响：说明什么场景会失败或造成风险。
  建议：给出最小可行修复方向。

## Tests / Verification

说明已运行的命令和结果；如果未运行，说明原因。

## Summary

用 1-3 句话概括整体风险和下一步。

你看，这个 Skill 的价值，不是写了多少文字，而是把“代码审查应该怎么做”固定下来。

以后你就不用每次都说：

请帮我审查代码，重点看 bug、风险、测试，不要只看风格。

你只需要说：

请使用 code-review Skill 审查当前改动。

或者如果 Codex 能根据描述自动匹配，它也可能在你说“帮我 review 当前 diff”时自动启用这个 Skill。

这里要强调一个点：Skill 不一定非要很复杂。新手刚开始可以先做“纯文字流程型 Skill”，不需要脚本、不需要 MCP、不需要插件。

比如：

  • 日报 Skill：固定输出今日完成、遇到问题、明日计划。
  • 发布 Skill：固定检查版本号、变更记录、测试结果。
  • 代码审查 Skill：固定检查 bug、风险和测试缺口。

等流程稳定之后，再考虑给 Skill 加脚本、模板、参考文档，甚至打包成 Plugin。

所以 Skills 的核心价值是：把你反复说的话，变成 Codex 可以反复调用的能力。

当你发现自己第三次输入同一套提示词时，就可以考虑把它做成 Skill 了。

4.Subagents：什么时候让多个 agent 并行探索、测试、审查

(1) 什么是Subagents

接下来我们讲 Subagents，也就是子代理。

你可以把它理解成：让 Codex 临时派出多个小助手，分别去处理不同方向的任务，最后再把结果汇总回来。

平时我们用 Codex，大多数时候一个 agent 就够了。比如修一个小 bug、解释一个文件、改一个按钮样式，这些任务没必要开多个 agent。

(2) Subagents的适用场景

但如果任务比较大，或者需要从多个角度同时分析，Subagents 就很有用。

比如下面这些场景：

  • 审查一个比较大的代码改动；
  • 排查一个复杂 bug；
  • 分析一个陌生项目；
  • 同时检查安全、测试和性能问题；
  • 对一个方案做多角度评估。

这类任务如果都塞给一个 agent，它可能会读很多文件，输出很多中间信息，上下文会变得很乱。

Subagents 的好处就是：把不同方向拆出去。

比如一个 agent 专门看安全风险，一个 agent 专门看测试缺口，一个 agent 专门看可维护性。它们各自探索，最后主 agent 只接收总结。

这样主会话会更干净，结果也更有层次。

（3）实战-用Subagents审查代码

接下来我们做一个实操案例：用多个 Subagents 审查当前代码改动。

你可以这样对 Codex 说：

请使用 subagents 并行审查当前 git diff。
派出 3 个 agent：
1. 安全审查 agent：检查权限、输入校验、敏感信息和潜在安全风险。
2. 测试审查 agent：检查这次改动是否缺少测试，现有测试是否覆盖关键路径。
3. 可维护性审查 agent：检查代码结构、重复逻辑、命名和长期维护风险。

请等待三个 agent 都完成后，再汇总结果。
最终输出按严重程度排序，并给出文件位置和修改建议。
暂时不要修改文件。

这个提示词里有几个关键点。

  • 第一，要明确说“并行审查”。

  • 第二，要告诉 Codex 派几个 agent，每个 agent 负责什么。

  • 第三，要要求它等待所有 agent 完成后再汇总。

  • 第四，要说明最终输出格式。

  • 第五，先不要修改文件，只做审查。

这样 Codex 就不会把所有事情混在一起，而是按角色拆分任务。

Subagents 特别适合读多、查多、分析多的任务。比如代码审查、日志分析、文档总结、项目理解。

但我不建议一上来就让多个 agent 同时改代码。因为多个 agent 同时写文件，很容易互相冲突，最后还要花时间合并。

所以新手记住一个原则：

  • 并行探索可以大胆用；
  • 并行写代码要谨慎用。

如果你只是修一个小问题，用一个 Codex 就够了。
如果你要从多个角度理解一个复杂问题，Subagents 就很适合。

Subagents 的核心价值，不是让 Codex 看起来更高级，而是让复杂任务拆成多个清晰方向，最后再收敛成一个高质量结论。

5. Hooks：在 Codex 生命周期中插入自定义校验、日志、安全检查

接下来我们讲 Hooks。

（1）Hooks是什么

Hooks 是 Codex 里更偏高级的一种扩展能力。它的作用是：在 Codex 工作过程中的某些关键节点，自动执行我们自己的脚本。

听起来有点抽象，我们换个说法。

Codex 在工作时，会经历很多动作：

  • 用户提交提示词
  • Codex 准备运行命令
  • Codex 执行完命令
  • Codex 准备结束任务
  • 上下文准备压缩

Hooks 就是让我们在这些节点插入自己的检查逻辑。

比如下面这些操作：

  • 运行命令前，检查有没有危险命令；
  • 任务结束后，自动记录日志；
  • 用户提交提示词时，检查有没有误贴 API Key；
  • Codex 修改完成后 ，自动提醒运行测试；
  • 上下文压缩前，自动生成摘要。

所以 Hooks 的核心价值是：把规则从“口头提醒”变成“自动执行”。

前面我们讲过 AGENTS.md 和 Skills。它们更多是告诉 Codex 应该怎么做。
而 Hooks 更进一步，它可以在关键节点真正触发脚本，做检查、记录或者拦截。

(2) 实战- 终端命令检查器

接下来我们举一个简单实操案例：防止 Codex 执行危险命令。

比如我们希望 Codex 在运行终端命令前，检查命令里有没有这些高风险内容：

  • 删除目录
  • 强制清理 git
  • 删除 .env 文件
  • 把密钥打印出来

我们可以做一个 PreToolUse Hook。意思是：在 Codex 使用工具之前，先执行我们的检查脚本。

作一个Hooks一般有两部分代码组成: hooks.json 和 python 文件。

hooks.json的位置在：

.codex/
  hooks/
  hooks.json

概念上，配置大概像这样：

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Bash",
        "hooks": [
          {
            "type": "command",
            "commandWindows": "python .codex\\hooks\\check_command.py",
            "command": "python3 .codex/hooks/check_command.py",
            "timeout": 10,
            "statusMessage": "Checking command safety"
          }
        ]
      }
    ]
  }
}

解释一下这段代码的重要部分：

PreToolUse：在 Codex 使用工具前触发
matcher: Bash：只检查终端命令
commandWindows：Windows 下运行的 Hook 命令
timeout: 10：最多运行 10 秒

check_command.py 的放置目录：

.codex/
  hooks/
    check_command.py
  hooks.json

然后 check_command.py 里就可以写规则，这就是我写的Python代码，你可以到文字版教程，找到这个代码。(当然这要求你会Python代码，所以说对于没有代码基础的人，制作Hooks还是有一定难度的，你也可以让Codex生成Python代码)

#!/usr/bin/env python3
import json
import os
import re
import sys
from datetime import datetime
from pathlib import Path


DANGEROUS_PATTERNS = [
    {
        "name": "强制删除目录",
        "pattern": r"\b(rm\s+-rf|Remove-Item\b.*\b-Recurse\b.*\b-Force\b|rd\s+/s\s+/q|rmdir\s+/s\s+/q)\b",
        "level": "high",
        "reason": "可能递归删除大量文件，风险很高。",
    },
    {
        "name": "强制重置 Git",
        "pattern": r"\bgit\s+reset\s+--hard\b",
        "level": "high",
        "reason": "会丢弃未提交修改，可能导致工作内容丢失。",
    },
    {
        "name": "清理未跟踪文件",
        "pattern": r"\bgit\s+clean\b.*\s(-fd|-df|-fx|-xf)\b",
        "level": "high",
        "reason": "可能删除未跟踪文件，包括临时文件或新建代码。",
    },
    {
        "name": "删除环境变量文件",
        "pattern": r"(\bdel\b|\berase\b|\bRemove-Item\b|\brm\b).*(\.env|\.env\.local|\.env\.production)",
        "level": "high",
        "reason": "可能删除包含本地配置或密钥的环境文件。",
    },
    {
        "name": "打印敏感环境变量",
        "pattern": r"(printenv|Get-ChildItem\s+Env:|echo\s+\$env:|echo\s+\$).*(TOKEN|SECRET|PASSWORD|API_KEY|OPENAI_API_KEY|CODEX_API_KEY)",
        "level": "medium",
        "reason": "可能把密钥或令牌输出到日志中。",
    },
    {
        "name": "修改远程仓库历史",
        "pattern": r"\bgit\s+push\b.*(--force|--force-with-lease)",
        "level": "high",
        "reason": "可能改写远程分支历史，影响团队协作。",
    },
    {
        "name": "执行下载脚本",
        "pattern": r"(curl|wget|Invoke-WebRequest|iwr).*(\|\s*(sh|bash|powershell|pwsh)|Invoke-Expression|iex)",
        "level": "high",
        "reason": "从网络下载内容并直接执行，存在供应链和安全风险。",
    },
]


def read_stdin_text():
    try:
        if sys.stdin is None or sys.stdin.closed:
            return ""
        return sys.stdin.read()
    except Exception:
        return ""


def try_parse_json(text):
    if not text.strip():
        return None
    try:
        return json.loads(text)
    except Exception:
        return None


def extract_command(payload, raw_text):
    """
    尽量兼容不同 Codex 版本或不同 Hook 输入格式。
    优先从 JSON 里找 command 字段，找不到再检查环境变量和原始文本。
    """
    candidates = []

    if isinstance(payload, dict):
        candidates.extend(
            [
                payload.get("command"),
                payload.get("cmd"),
                payload.get("input"),
                payload.get("tool_input"),
                payload.get("arguments"),
            ]
        )

        tool_input = payload.get("toolInput") or payload.get("tool_input")
        if isinstance(tool_input, dict):
            candidates.extend(
                [
                    tool_input.get("command"),
                    tool_input.get("cmd"),
                    tool_input.get("input"),
                ]
            )

        params = payload.get("params") or payload.get("parameters")
        if isinstance(params, dict):
            candidates.extend(
                [
                    params.get("command"),
                    params.get("cmd"),
                    params.get("input"),
                ]
            )

    for key in [
        "CODEX_TOOL_COMMAND",
        "CODEX_COMMAND",
        "COMMAND",
        "TOOL_COMMAND",
    ]:
        value = os.environ.get(key)
        if value:
            candidates.append(value)

    if raw_text.strip():
        candidates.append(raw_text.strip())

    for item in candidates:
        if isinstance(item, str) and item.strip():
            return item.strip()

        if isinstance(item, dict):
            for key in ["command", "cmd", "input"]:
                value = item.get(key)
                if isinstance(value, str) and value.strip():
                    return value.strip()

    return ""


def find_matches(command):
    matches = []
    for rule in DANGEROUS_PATTERNS:
        if re.search(rule["pattern"], command, re.IGNORECASE | re.DOTALL):
            matches.append(rule)
    return matches


def write_audit_log(command, matches):
    log_dir = Path(".codex") / "hooks" / "logs"
    log_dir.mkdir(parents=True, exist_ok=True)

    log_file = log_dir / "command_safety.log"
    record = {
        "time": datetime.now().isoformat(timespec="seconds"),
        "command": command,
        "blocked": bool(matches),
        "matches": [m["name"] for m in matches],
    }

    with log_file.open("a", encoding="utf-8") as f:
        f.write(json.dumps(record, ensure_ascii=False) + "\n")


def main():
    raw_text = read_stdin_text()
    payload = try_parse_json(raw_text)
    command = extract_command(payload, raw_text)

    if not command:
        print("[Hook] 未检测到可解析的命令内容，允许继续。")
        return 0

    matches = find_matches(command)
    write_audit_log(command, matches)

    if not matches:
        print("[Hook] 命令安全检查通过。")
        return 0

    print("\n[Hook] 已拦截高风险终端命令。")
    print(f"\n命令内容：\n{command}\n")
    print("命中的风险规则：")

    for item in matches:
        print(f"- {item['name']} [{item['level']}]: {item['reason']}")

    print("\n建议：")
    print("- 如果只是想查看文件，请改用只读命令。")
    print("- 如果确实需要执行，请先向用户解释风险和影响范围。")
    print("- 不要自动执行删除、强制重置、密钥输出、远程强推等高风险命令。")

    return 1


if __name__ == "__main__":
    sys.exit(main())

代码编写完成，保存后，重启 Codex 桌面端，或者重新打开一个 Codex 线程。

如果 Codex 提示有新的 Hook 需要信任，就按界面提示查看并信任。官方文档里也提到，非托管的 command hook 通常需要用户 review/trust 后才会运行。

Hooks对于新手来说还是有些难度的，我不建议新手一开始就折腾 Hooks。刚开始先掌握 CLI、AGENTS.md、MCP 和 Skills。等你发现某些规则必须自动执行，而不是靠每次提醒 Codex，才考虑 Hooks。 当然如果你经验不足，让Codex编写Hooks是一个非常不错的选择。

6.Plugins：把 Skills、MCP、Hooks 打包成可安装的 Codex 扩展

最后我们讲 Plugins，也就是 Codex 插件。

（1）什么是Plugins

前面我们分别讲了 Skills、MCP 和 Hooks。

  • Skills 用来封装重复流程。
  • MCP 用来连接外部工具。
  • Hooks 用来在 Codex 工作过程中插入校验、日志和安全检查。

那 Plugins 是什么呢？

你可以把 Plugin 理解成一个“打包盒”。它可以把 Skills、MCP 配置、Hooks、说明文档、图标和其他资源打包在一起，变成一个可以安装、分享、复用的 Codex 扩展。

如果说 Skill 是一个单独能力，那么 Plugin 就是一组能力的集合。

举个例子，假设我们团队经常做代码审查。我们可能需要三样东西：
- 一个 code-review Skill，规定审查流程；
- 一个 GitHub MCP，用来读取 PR 和 issue；
- 一个 Hook，在审查结束后自动记录日志。

如果这些都分散配置，每个人都要手动复制文件、改配置、装 MCP，很容易出错。

这时候就可以把它们打包成一个 Plugin，叫： team-code-review

安装这个 Plugin 后，团队成员就能获得同一套代码审查能力。

所以 Plugins 的价值，不是让 Codex 多一个花哨功能，而是让一套工作流可以被安装、分发和标准化。

(2)实战-代码审查插件

接下来我们做一个实战案例：设计一个“代码审查插件”。

为了演示方便，让大家能最快速度学会插件的创建和使用。插件不封装过多的内容，这个插件只包含一个 Skill： code-review。

它的作用是：当用户要求审查代码时，Codex 按固定流程检查 bug、测试缺口、安全风险和可维护性。

我们新建一个项目，就叫做team-code-review.
插件目录可以长这样：

team-code-review/
  .codex-plugin/
    plugin.json
  skills/
    code-review/
      SKILL.md

plugin.json 是插件的说明文件。它告诉 Codex：这个插件叫什么，版本是多少，里面有哪些 Skills。

代码如下:

{
  "name": "team-code-review",
  "version": "1.0.0",
  "description": "Team code review workflow for Codex.",
  "skills": "./skills/"
}

然后 skills/code-review/SKILL.md 使用我们上面讲的那个skill就可以了。

这样，一个最小插件就完成了。

视频结束语

到这里，我们就完成了 Codex 入门的完整路线：从安装和登录，到读代码、改文件、跑命令、验证结果，再到上下文管理、AGENTS.md、MCP、Skills、Subagents、Hooks 和 Plugins。

我们接下来还会出AI相关的完整视频，比如如何写好一个Skill，希望你关注我，继续在AI的海洋里冲浪吧。