第一部分

从下载安装到项目实战，一篇文章带你真正理解 Codex 的工作方式。

前言：不要再把 Codex 当成另一个 ChatGPT

如果你过去一年一直关注 AI 编程，应该已经见证了一个非常明显的变化。

最开始，我们习惯的是 GitHub Copilot——它负责补全代码；后来是 ChatGPT——你复制一段代码进去，让它帮你解释、改 Bug；再后来，Cursor、Claude Code、Codex 等工具陆续出现，AI 开始真正进入项目，读取代码、修改文件、运行命令，甚至完成一个完整的开发任务。

很多人第一次打开 Codex，都喜欢输入一句：

帮我做一个博客网站。

然后发现结果并没有想象中那么好。

原因其实很简单。

你把 Codex 当成了聊天机器人，而它更像是一位新加入团队的软件工程师。

你不会对一位工程师说“帮我做个平台”，而是会说：

• 看一下这个仓库。

• 理解一下项目结构。

• 修复首页按钮无法点击的问题。

• 新增一个登录页面。

• 跑一下测试，看看有没有报错。

• 修改完成后告诉我改了哪些文件。

这正是 Agent 与 Chat 最大的区别。

ChatGPT 擅长回答问题，而 Codex 擅长完成任务。

理解这一点，后面的所有内容都会容易很多。

---

开始之前：先决定你用什么方式连接 Codex

很多教程一上来就教你安装 CLI。

其实真正应该先解决的问题只有一个：

你准备用什么方式使用 Codex？

目前主要有两种方式。

第一种，是直接使用 ChatGPT 账号登录。

如果只是偶尔写点代码，体验一下 Codex，这种方式最简单。

安装完成以后，只需要执行：

codex login

选择 Sign in with ChatGPT，浏览器会自动打开登录页面，授权完成即可开始使用。整个过程几分钟就能完成。但是注意最好需要有一个国外的手机号码做认证，不然去一些接受短信平台如herosms一毛钱收条验证码也可以。

这种方式最大的优点就是简单，没有额外配置，也不需要管理 API Key。

如果你属于下面这些情况：

• 第一次接触 Codex

• 想快速体验 Agent

• 资金充裕

那么直接使用 ChatGPT 登录就足够了。

---

为什么很多人后来都会切换到 API？

但如果你真正开始每天使用 Codex，你会发现另一种方式越来越常见——API Key。

原因并不复杂。

Agent 类工具和普通聊天最大的区别，就是它会频繁读取项目、运行命令、修改文件，还会不断进行推理。

如果每天都在开发项目，固定订阅未必就是成本最低的方案。

很多开发者反而会选择：

按调用量计费。

对于中小项目来说，很多时候比长期订阅更加灵活。

另外还有几个现实原因：

• 自动化脚本需要 API；

• CI/CD 需要 API；

• 团队统一管理 Key 更方便；

• 一个 Key 可以根据需要切换不同模型。

因此，不少开发者都会通过兼容 OpenAI API 的 MaaS（Model as a Service）平台来接入 Codex。

对于国内用户来说，这也是目前比较常见的一种方式。

---

一个比较省心的接入方案

本文后面的演示，我使用的是魔芋 AI提供的兼容 OpenAI API 接口。

主要原因并不是因为它是唯一选择，而是：

• 配置流程比较简单；

• 可以直接生成兼容 OpenAI 的 API Key；

• 日常开发过程中整体比较稳定；

• 后续如果需要切换其他模型，也比较方便统一管理。

如果你已经在使用其他兼容 OpenAI API 的 MaaS 平台，同样可以按照本文继续操作，流程基本一致。

整个配置也非常简单。

获取 API 密钥

1. 点击前往 （手机号或邮箱一键注册）魔芋AI大模型网关I全球大模型一站式调用及服务平台魔芋AI大模型聚合平台（大模型网关平台）专注于提供高效能、低成本的多品类 AI 模型服务，助力开发者和企业聚焦产品创新。https://www.moyu.info/register?aff=qBX9

 2、注册成功后进入【令牌管理】
        

        3、模型广场上复制要使用的模型ID
        要配置moder ID时候要去模型广场复制名称。

我们可以前往模型广场查看全球主流模型。如果注册后前往模型广场没有看到想用的全球模型，可以联系客服，添加客服申请模型广场开白。有技术问题也可以联系客服进行解答。

分组不同可以设置在令牌管理那选择

获取 API Key 后，只需要在登录界面通过 API 密钥登录：

按照提示输入 Key 即可完成登录。

后面的所有使用方式，无论是 ChatGPT 登录还是 API 登录，基本没有区别。

---

安装 Codex CLI

相比桌面版 App，我其实更推荐大家尽早熟悉 CLI。

原因很简单。

CLI 更接近真实开发流程。

以后无论是 VS Code、Cursor、自动化脚本，还是 CI/CD，都离不开终端。

安装过程其实只有三步。

第一步：安装 Node.js

Codex CLI 基于 Node.js，因此首先确认电脑已经安装 Node。

打开终端：

node -v
npm -v

如果能够看到版本号，就说明环境已经准备完成。

---

第二步：安装 Codex

执行：

npm install -g @openai/codex

安装完成以后，可以检查版本：

codex --version

如果能够正常输出版本号，就说明安装成功。

---

第三步：不要在错误的位置启动 Codex

这是很多新人最容易忽略的一件事。

很多人安装完成以后，直接就在桌面打开终端：

codex

这是非常不推荐的。

因为 Codex 会把当前目录当成整个工作区。

也就是说：

你在哪里启动它，它就认为哪里是你的项目。

因此官方一直建议：

不要直接在下面这些地方启动：

• 桌面

• 下载目录

• 系统目录

• 根目录

正确的做法应该是：

先创建一个项目目录。

例如：

AI-Projects
    hello-codex

然后：

cd hello-codex

codex

这样 Codex 就会把整个 hello-codex 当作自己的工作空间，而不会扫描其他无关目录。

这是一个非常小的细节，却能避免很多莫名其妙的问题。

---

第一次启动 Codex，它到底在做什么？

很多人第一次运行 Codex，都会有一个误解：

为什么它什么都没回答？

事实上，它已经开始工作了。

只不过，它做的第一件事不是回答问题，而是理解项目。

举个例子。

假设你的目录是：

hello-codex
│
├── package.json
├── README.md
├── src
├── public
└── package-lock.json

当你输入：

codex

Codex 通常会先阅读：

• package.json

• README

• 当前目录结构

• Git 状态

• 项目依赖

甚至还会判断：

• 这是 React？

• Next.js？

• Vue？

• Python？

• Go？

然后才开始理解你的任务。

也就是说，它并不是一句一句聊天。

它是在做一位工程师真正会做的事情：

先了解项目，再开始干活。

理解这一点以后，你会发现很多 Prompt 都应该重新写。

例如，不要直接说：

帮我优化一下。

而应该告诉它：

阅读当前项目，理解整体结构，不要修改任何文件。总结项目架构、核心模块以及启动方式。

或者：

请先分析为什么 npm run build 会失败，不要修改代码，只输出你的排查计划。

你会发现，Codex 的表现会稳定得多。

---

Agent 的核心思维：不要让 AI 猜

很多人觉得 Codex 不稳定，其实问题往往不在模型，而在任务描述。

举一个很常见的例子。

很多新人会这样写：

做一个官网。

对于人来说，这句话已经很模糊。

对于 AI 来说，更是不知道从哪里开始。

更好的方式应该像写需求文档一样。

例如：

目标：

制作一个 AI 产品官网。

要求：

首页

产品介绍

价格页

联系我们

限制：

不要修改已有 API

不要新增数据库

使用 TailwindCSS

完成以后告诉我修改了哪些文件。

你会发现。

Codex 的质量，会立刻提高一个等级。

因为 Agent 最怕的不是复杂。

而是模糊。

任务越清晰，它完成得越稳定。

---

小结

如果说过去我们学习 ChatGPT，重点是学 Prompt。

那么学习 Codex，真正要学的是任务管理。

从这一刻开始，不妨把它当成团队里的第一位 AI 工程师，而不是一个更聪明的聊天机器人。

在下一部分，我们将正式进入 Codex 的核心工作流，包括 Project、Thread、Sandbox、权限控制、计划模式、Diff 审查 等关键概念，并结合实际开发案例，带你建立一套真正适合日常开发的 Agent 工作方式。
 

第二部分

上一部分，我们完成了 Codex 的安装，并理解了一个最重要的观念：Codex 不是聊天机器人，而是一位 AI 工程师。

接下来，我们正式进入 Codex 最重要的一部分——工作流（Workflow）。

很多人觉得 Codex 不稳定，其实不是模型的问题，而是没有理解它的工作方式。

---

如果只记住一句话，请记住这一句

很多新手第一次打开 Codex，喜欢一直在同一个对话里不断追加需求。

例如：

帮我做一个首页。

……

再帮我加登录。

……

再帮我修一下按钮。

……

顺便写一下 README。

……

再优化一下移动端。

十几轮下来，你会发现 Codex 越来越"笨"。

它不是变笨了，而是上下文已经开始混乱。

这也是很多人觉得 Agent 不稳定的真正原因。

真正的软件开发不是这样工作的。

一个项目，会拆成很多 Issue。

一个 Issue，对应一个 PR。

一个 PR，只完成一件事情。

Codex 也是一样。

所以，在真正开始开发之前，你首先要理解两个概念。

Project。

以及 Thread。

---

Project：它其实就是你的项目

Project 很好理解。

你可以把它直接理解成：

一个 Git 仓库。

或者：

一个代码目录。

例如：

AI-Website

├── src
├── public
├── package.json
└── README.md

这就是一个 Project。

Codex 所有的工作都会围绕这个目录展开。

很多人会问：

为什么 Codex 不像 ChatGPT 一样直接聊天？

因为它首先需要知道：

这个项目有哪些文件？

使用什么框架？

有哪些依赖？

Git 当前是什么状态？

哪些文件已经修改？

哪些不能碰？

也就是说。

Project 是 Codex 的工作现场。

---

Thread：真正决定效率的地方

如果说 Project 是办公室。

那么 Thread 就是今天的工作任务。

例如：

你的项目叫：

AI Dashboard

今天可能有这些任务。

Thread 1

新增登录页面

Thread 2

修复首页无法加载

Thread 3

优化移动端

Thread 4

更新 README

Thread 5

检查 Build 是否成功

每一个 Thread 都应该只负责一个目标。

很多人看到这里觉得：

这不是废话吗？

其实不是。

这是 Agent 最重要的使用习惯。

---

我的经验：把 Thread 当成 Git Branch

我现在基本把 Thread 和 Git Branch 一一对应。

例如：

feature/login

对应一个 Thread。

里面只讨论登录。

---

bug/navbar

对应一个 Thread。

里面只修导航栏。

---

refactor/payment

对应一个 Thread。

里面只讨论支付模块。

这样有几个好处。

第一。

上下文非常干净。

第二。

以后回来继续做的时候。

Codex 能马上进入状态。

第三。

Review 非常容易。

第四。

不会出现：

"我昨天明明是在修 Bug，为什么今天突然开始改 CSS？"

所以。

以后不要把所有事情塞进一个 Thread。

这是使用 Agent 最大的习惯改变。

---

一个 Thread，只做一件事

举个真实例子。

不要这样：

帮我：

增加登录

修按钮

改 Header

优化手机端

增加支付

写 README

检查有没有 Bug

这是典型的大杂烩。

正确应该拆成：

Thread A

新增登录页面

完成。

归档。

---

Thread B

检查首页按钮为什么不能点击

完成。

归档。

---

Thread C

重新设计 Header

完成。

归档。

这样 Codex 的准确率会高很多。

---

为什么复杂任务一定要开启 Plan

很多新人最喜欢做的一件事情。

就是：

打开 Codex。

直接输入：

重构整个项目。

然后等待。

这是我最不建议的做法。

对于复杂任务。

我几乎都会先开启 Plan Mode。

因为真正优秀的工程师。

不会一上来就开始写代码。

他一定会先思考。

---

例如我现在要修一个 Build Bug。

我一般这样写：

请不要修改代码。

先阅读整个项目。

然后给我一个排查计划。

确认以后再开始修改。

或者直接：

/plan

Codex 会先告诉你：

准备检查：

package.json

tsconfig

vite.config

Build 日志

预计：

先复现问题

定位原因

修改

再次验证

这时候。

你再决定要不要继续。

很多时候。

你甚至会发现：

它第一步就理解错了。

如果直接开始修改。

后面就全偏了。

所以。

复杂任务一定先计划。

这是我每天都会用到的功能。

---

不要让 Codex 自由发挥

这是第二个经验。

很多人觉得：

AI 越自由越聪明。

实际上完全相反。

例如。

不要写：

帮我优化一下项目。

这种 Prompt 基本等于没说。

更好的方式应该是：

目标：

修复首页性能。

限制：

不要修改 API。

不要新增依赖。

不要修改 UI。

验收：

Lighthouse Performance

提升到 90 分以上。

你会发现。

Codex 改动一下子就变少了。

而且成功率明显提高。

---

学会限制修改范围

Codex 最大的优点。

也是最大的风险。

它真的会改代码。

所以。

一定要告诉它：

哪些文件可以改。

哪些不能改。

例如：

请只修改：

Home.tsx

Navbar.tsx

不要修改：

package.json

API

数据库

其他文件

或者。

只允许最小修改。

不要重构。

不要调整项目结构。

这是我最常用的一句话。

因为 AI 很容易：

顺手。

把整个项目一起改了。

---

Sandbox：为什么 Codex 老是在等你批准？

很多新人第一次都会遇到。

Codex 工作到一半。

突然停住。

然后出现：

Waiting for approval。

很多人第一反应。

是不是卡住了？

其实没有。

它是在等你批准。

---

Sandbox 可以理解成：

Codex 的工作围栏。

它可以：

看哪些文件？

改哪些文件？

能不能联网？

能不能运行命令？

能不能访问项目外目录？

这些都由 Sandbox 控制。

---

例如。

它可以：

修改：

index.html

App.tsx

style.css

但是。

如果它突然想：

访问桌面

读取下载目录

安装依赖

联网

删除文件

就会停下来。

等待你批准。

---

新人千万不要直接 Full Access

很多教程为了省事。

直接让大家：

danger-full-access

我并不推荐。

尤其第一次使用。

建议保持：

workspace-write

+

on-request

什么意思？

可以修改当前项目。

但是：

危险操作必须先问我。

这是目前最安全。

也是最符合日常开发的方式。

---

看不懂命令，就不要点 Allow

例如。

Codex 准备运行：

git reset --hard

或者：

rm -rf

不要因为赶时间。

直接 Allow。

你完全可以问：

解释一下：

为什么需要执行这条命令？

风险是什么？

有没有更安全的方法？

Agent 最大的优势。

不是替代人。

而是：

随时可以解释自己的行为。

---

Diff，比 AI 的总结更重要

很多人都有一个坏习惯。

Codex 修改完成以后。

直接看它最后一句：

已完成。

然后就 Commit。

千万不要。

真正重要的是：

/diff

因为总结可以骗人。

代码不会。

Diff 会告诉你：

新增了哪些内容。

删除了哪些内容。

改了哪些文件。

我自己的流程永远都是：

Codex 完成

↓

/diff

↓

Review

↓

git diff

↓

确认

↓

Commit

从来不会跳过。

---

Prompt 模板

这是推荐给大家的模板。

目标：

完成什么。

背景：

目前项目是什么。

修改范围：

允许修改哪些文件。

限制：

不要修改哪些内容。

不要新增依赖。

不要重构。

验收标准：

完成以后：

告诉我：

修改了哪些文件。

为什么这样改。

还有哪些风险。

你会发现。这比一句："帮我优化一下。" 稳定太多。

---

小结

很多人认为，Agent 编程的核心是模型能力。

但我越来越觉得，真正拉开差距的并不是 GPT-5、Claude 还是其他模型，而是工作流。

当你开始把 Project 当成仓库，把 Thread 当成 Issue，把 Plan 当成设计评审，把 Diff 当成 Code Review，你就会发现，Codex 不再只是一个聊天窗口，而是真正融入了软件开发流程。

下一部分，我们将进入真正的实战环节：从一个空项目开始，带着 Codex 一步步完成一个完整功能，并分享我每天都在使用的命令、AGENTS.md 配置以及与 Cursor、Claude Code 协作的工作流，帮助你把 Codex 真正用进日常开发，而不仅仅是“体验一下 AI 写代码”。

第三部分

到这里，你已经知道如何安装 Codex，也理解了 Project、Thread、Sandbox 等核心概念。

最后一部分，我们不再讲概念，而是回到开发现场：Codex 到底应该怎么用，才能真正成为你的 AI 工程师？

---

一个真实的开发案例

假设现在接到一个很普通的需求：

给公司的 AI 产品做一个 Landing Page。

很多人第一句话会直接告诉 Codex：

做一个官网。

如果你这样做，大概率会得到一个"能看"，但不太能用的页面。

真正高效的做法，其实更接近项目管理。

---

第一步：建立规则，而不是开始写代码

我拿到一个新项目以后，第一件事情几乎不是聊天。

而是执行：

/init

它会帮助你生成一个 AGENTS.md。

很多新人会忽略这个文件。

实际上，它可能是整个 Codex 最重要的能力之一。

为什么？

因为 ChatGPT 的 Prompt，每一次都要重新写。

而 AGENTS.md，更像是给整个项目制定了一份长期规则。

例如：

项目技术栈：

Next.js 15
TypeScript
TailwindCSS

开发规范：

保持组件化

优先修改已有组件

不要新增依赖

不要修改接口

提交代码保持 ESLint 无报错

所有回答使用中文

以后每一个 Thread。

Codex 都会优先参考这些规则。

也就是说。

很多 Prompt，不需要再重复写。

这也是大型项目效率远高于普通聊天的重要原因。

---

第二步：先理解项目，而不是立即开发

很多新人打开项目以后第一句话就是：

帮我增加登录。

我一般不会这样做。

而是先告诉它：

阅读整个项目。

不要修改任何文件。

请告诉我：

项目目录结构

技术栈

主要页面

公共组件

状态管理方式

API 调用方式

最后总结目前存在的问题。

为什么？

因为真正的工程师。

进入一个新项目。

第一天不会马上开始改代码。

他会先读 README。

再读目录。

再读架构。

Codex 也一样。

它理解得越完整。

后面的成功率越高。

---

第三步：复杂需求，永远拆任务

这是我认为 Agent 编程最大的思维变化。

例如：

不要这样：

开发一个 SaaS 后台。

而应该拆成：

第一天：

完成登录页面。

第二天：

完成 Dashboard。

第三天：

增加用户管理。

第四天：

增加权限管理。

第五天：

增加数据统计。

每一个功能。都是一个 Thread。

每一个 Thread。都是一次独立开发。

这样上下文始终保持干净，Review 也容易，Bug 也更少。

---

学会让 Codex 自己验证结果

很多人有一个误区。

认为 AI 改完代码以后。

自己再运行项目。

其实。

Codex 本身就可以完成验证。

例如：

修改完成以后：

运行 npm run build

如果失败。

继续修复。

直到能够正常构建。

最后告诉我修改了哪些文件。

或者：

修改完成以后：

运行 npm test

确保所有测试通过。

Codex 会按照流程：

修改

↓

Build

↓

失败

↓

继续修

↓

再次 Build

↓

成功

整个过程其实已经非常接近真实的软件开发。

这也是 Agent 与聊天机器人最大的区别。

---

如果它连续失败怎么办？

这个问题几乎每天都会遇到。

很多新人最大的错误就是：让它一直试。一直改。一直 Build。

最后整个项目都乱了。

其实。

连续失败三次左右，最好让它停下来。

例如：

暂停修改。

总结一下：

目前尝试了哪些方案？

为什么失败？

还有哪些可能原因？

下一步建议是什么？

注意。

这里不要继续改。

而是：

先分析。

很多时候。

它自己就会发现：

真正的问题根本不在刚才修改的地方。

这比让它继续"蒙"要高效得多。

---

Git 工作流

很多人问：

Codex 会不会把代码改坏？

答案当然是：

会。

所以一定要配合 Git，这套流程推荐给大家。

git status

↓

Codex

↓

/diff

↓

git diff

↓

Review

↓

git add .

↓

git commit

其中。

我最常看的其实不是 Git。

而是：

/diff

因为它可以第一时间告诉我：

哪些文件改了。

哪些代码删了。

哪些内容新增了。

如果发现：

它改了 package.json。

改了数据库。

改了 API。

而这些根本不是这次任务需要的。

我会立即要求：

请撤销这些修改，只保留首页相关内容。

不要觉得这是在折腾 AI。

真正的软件开发。

Code Review 本来就是必须的。

---

Codex 最值得记住的几个命令

Codex 有很多 CLI 命令，但真正每天都会用到的，其实并不多。

命令	用途	使用频率
/plan	大任务先规划	⭐⭐⭐⭐⭐
/diff	查看改动	⭐⭐⭐⭐⭐
/review	代码 Review	⭐⭐⭐⭐⭐
/status	查看上下文和模型	⭐⭐⭐⭐
/compact	压缩长对话	⭐⭐⭐⭐
/permissions	修改权限	⭐⭐⭐
/model	切换模型	⭐⭐⭐
/quit	结束任务	⭐⭐⭐

如果你刚开始学习。

真的没有必要去记几十个命令。

把这几个用熟。

已经足够应付绝大多数项目。

---

长对话以后，一定记得 Compact

很多人不知道。

Codex 也有上下文长度限制。

当一个 Thread 做了几个小时以后。

里面已经积累了：

日志/Build/Bug/Diff/测试

上下文会越来越长。

这时候，用：

/compact

它会把整个历史。

压缩成一份摘要。

然后继续工作。

这不仅节省 Token。

也能减少 AI 因为上下文过长导致的理解偏移。

---

Codex、Cursor、Claude Code 怎么配合？

不要把它们当竞争关系，而是流水线。

比如：

产品需求

↓

ChatGPT

整理需求

补充细节

↓

Codex

完成开发

修 Bug

生成代码

↓

Cursor

局部修改

快速编辑

↓

Git Review

↓

提交 PR

如果涉及到长文档，让 ChatGPT 整理。

如果涉及复杂工程，交给 Codex。

如果只是改一个变量，Cursor 更快。

每个工具都有自己的位置。

真正提高效率的，不是换模型，而是把工具放到最合适的位置。

---

五个最容易踩的坑

最后，再强调一下踩过的坑。

第一，不要让 Codex 猜。

需求越模糊。

结果越差。

---

第二，不要一次做十件事情。

一个 Thread。

一个目标。

---

第三，不要随便给 Full Access。

默认保持审批。

安全第一。

---

第四，不要跳过 Diff。

AI 的总结可以错。

代码不会。

---

第五，不要相信第一次结果。

优秀的软件，本来就是不断迭代出来的。

Agent 也是如此。

---

写在最后：真正改变开发方式的，不是 AI，而是工作流

过去几年，很多人都在讨论：

AI 会不会取代程序员？

这个问题本身可能问错了。真正发生变化的，并不是程序员消失了。而是开发流程正在改变。

过去，更多是在"写代码"。今天，开始更多地"管理任务"。

过去，关注的是每一行代码。今天，关注的是目标、计划、Review、验证和交付。

Codex 的意义，也并不只是帮你节省几分钟写代码的时间。

它更像是团队里多了一位不会疲倦的工程师。

你需要告诉它目标。

给它边界。

检查它的成果。

而不是把所有事情都交给它。

当你真正理解这一点以后，你会发现，学习 Codex，其实学的不是一个新工具，而是一种新的开发方式和内容生产方式。

未来的软件开发，很可能都会围绕 Agent 展开。而今天花时间建立正确的工作流、理解 Project、Thread、Plan、Diff、Review 等概念，就是在为未来的开发方式打基础。

与其说 Codex 是一个会写代码的 AI，不如说，它是一位需要你管理、协作和审查的 AI 工程师。 当你学会与它合作，而不是把它当成聊天机器人时，它才能真正成为开发过程中最有价值的生产力工具。