第一部分从下载安装到项目实战一篇文章带你真正理解 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 类工具和普通聊天最大的区别就是它会频繁读取项目、运行命令、修改文件还会不断进行推理。如果每天都在开发项目固定订阅未必就是成本最低的方案。很多开发者反而会选择按调用量计费。对于中小项目来说很多时候比长期订阅更加灵活。另外还有几个现实原因自动化脚本需要 APICI/CD 需要 API团队统一管理 Key 更方便一个 Key 可以根据需要切换不同模型。因此不少开发者都会通过兼容 OpenAI API 的 MaaSModel as a Service平台来接入 Codex。对于国内用户来说这也是目前比较常见的一种方式。本文后面的演示我使用的是魔芋 AI提供的兼容 OpenAI API 接口。魔芋AI安装 Codex CLI相比桌面版 App我其实更推荐大家尽早熟悉 CLI。原因很简单。CLI 更接近真实开发流程。以后无论是 VS Code、Cursor、自动化脚本还是 CI/CD都离不开终端。安装过程其实只有三步。第一步安装 Node.jsCodex 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当你输入codexCodex 通常会先阅读package.jsonREADME当前目录结构Git 状态项目依赖甚至还会判断这是 ReactNext.jsVuePythonGo然后才开始理解你的任务。也就是说它并不是一句一句聊天。它是在做一位工程师真正会做的事情先了解项目再开始干活。理解这一点以后你会发现很多 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更新 READMEThread 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。我一般这样写请不要修改代码。 先阅读整个项目。 然后给我一个排查计划。 确认以后再开始修改。或者直接/planCodex 会先告诉你准备检查 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 工程师。当你学会与它合作而不是把它当成聊天机器人时它才能真正成为开发过程中最有价值的生产力工具。
