Codex 客户端使用教程：把 AI 编程助手真正装进你的电脑

为什么 Codex 客户端值得单独写一篇教程？

以前我们用 AI 写代码，大多是这样的流程：

1. 把报错复制到聊天窗口；
2. 把代码片段贴给 AI；
3. AI 给出修改建议；
4. 我们再手动复制回编辑器；
5. 跑一下，报错，再继续问。

这个流程能用，但始终有一种割裂感：AI 在聊天窗口里，项目在编辑器里，命令在终端里，Git diff 又在另一个地方。

Codex 客户端解决的正是这个问题。

它不是单纯的“代码问答工具”，而是一个面向真实开发流程的 AI 工作台。你可以把一个项目交给它，让它阅读代码、制定计划、修改文件、运行命令、检查结果、展示差异，最后再由你决定是否接受、提交或继续修改。

这也是它真正好用的地方：AI 不再只是告诉你怎么做，而是可以进入项目，和你一起把事情做完。

一、Codex 客户端是什么？

Codex 客户端可以理解成一个专门为 AI 编程任务设计的桌面应用。

它把过去分散在聊天窗口、终端、Git 工具、浏览器和编辑器里的工作，整合到了一个更清晰的界面里。你可以在里面：

• 添加和管理多个项目；
• 为同一个项目开启多个独立任务线程；
• 让 Codex 在本地项目中直接工作；
• 使用 Git worktree 隔离不同任务的改动；
• 查看代码 diff；
• 对具体代码行留下反馈；
• 让 Codex 修复 PR review 评论；
• 运行终端命令；
• 预览网页应用；
• 创建定时自动化任务；
• 通过 Skills、MCP 和插件扩展能力。

如果说 IDE 解决的是“人怎么写代码”，那么 Codex 客户端解决的是“AI 怎么参与开发流程”。

二、下载安装 Codex 客户端

Codex 客户端目前主要面向 macOS 和 Windows 用户。

macOS

macOS 用户下载时需要注意自己的芯片类型：

• Apple Silicon：M1、M2、M3、M4 等；
• Intel：老款 Intel Mac。

下载对应版本后，像普通 macOS App 一样安装并打开即可。

Windows

Windows 用户可以从 Microsoft Store 安装 Codex 客户端。

如果你习惯命令行，也可以使用 Windows 包管理器安装：

wingetinstallCodex -smsstore

Windows 版本支持原生运行，也可以根据需要配置 WSL2。普通用户直接用默认 Windows 原生模式就够了；如果你的项目主要放在 Linux 环境或依赖 Linux 工具链，再考虑 WSL2。

登录方式

第一次打开 Codex 客户端时，它会要求登录。你可以选择：

• 使用 ChatGPT 账号登录；
• 或使用 OpenAI API key。

对大多数个人用户来说，直接用 ChatGPT 账号登录最简单。API key 更适合已经有 API 计费和开发环境管理需求的人。

三、第一次打开客户端：先添加项目

打开 Codex 后，第一步不是让它马上写代码，而是添加项目。

你可以选择一个本地项目文件夹，比如：

~/Projects/my-app

D:/Projects/my-app

添加后，Codex 会把这个目录作为一个项目来管理。之后你可以在左侧项目列表里切换不同项目。

如果你之前使用过 Codex CLI、IDE 扩展或客户端，过去打开过的项目也可能会出现在列表里。

第一次任务建议这样问

添加项目后，先不要直接说“帮我实现某个功能”。更稳的做法是先让它读项目：

请先阅读这个项目，不要修改任何文件。请告诉我：

1. 项目主要目录结构是什么；

2. 启动和构建命令是什么；

3. 核心模块分别负责什么；

4. 如果我要继续开发，最需要注意哪些约定和风险。

这一步特别重要。

它能帮助你判断 Codex 是否理解了项目结构，也能让后续任务更准确。对于陌生项目来说，这一步几乎可以替代你前半小时甚至一小时的摸索。

四、理解 Codex 客户端的三个工作模式

在 Codex 客户端里，每个任务线程都可以选择运行模式。最常见的是三种：

1. Local：最直接的本地模式

Local 模式就是让 Codex 直接在你当前选择的项目目录里工作。

适合这些任务：

• 解释项目结构；
• 修改一个小 bug；
• 改一个按钮样式；
• 补一个单元测试；
• 查一个报错原因；
• 更新一小段文档。

Local 模式的优点是简单直接；缺点是它会直接影响你当前工作区，所以使用前最好确认 Git 状态是干净的。

推荐习惯：

git status

如果当前有重要改动，建议先提交、stash，或者改用 Worktree 模式。

2. Worktree：最适合认真开发的模式

Worktree 是 Codex 客户端非常值得重点使用的功能。

它会基于你的 Git 仓库创建一个独立工作区，让 Codex 在那个隔离环境里完成任务。这样你可以继续在原来的项目目录工作，而 Codex 在另一个 worktree 里并行处理它的任务。

这特别适合：

• 同时让 Codex 做多个任务；
• 不想污染当前工作区；
• 想先让 Codex 尝试一个方案；
• 功能改动比较大，需要慢慢 review；
• 想让 Codex 在后台跑测试、修复、重构。

你可以把 Local 理解成“当前桌面”，把 Worktree 理解成“给 Codex 单独开了一张工作台”。

我个人更推荐：只要是正式改代码，优先用 Worktree。

3. Cloud：把任务交给远程环境

Cloud 模式适合把任务放到远程环境里跑，比如：

• 处理比较耗时的任务；
• 让 Codex 在云端环境里完成修改；
• 需要与 GitHub 仓库、PR 流程结合；
• 团队希望统一运行环境。

如果你只是个人本地开发，前期可以先用 Local 和 Worktree。等你熟悉后，再把 Cloud 纳入工作流。

五、一个推荐的完整使用流程

下面是一套我觉得非常稳的 Codex 客户端工作流。

第一步：打开项目

打开 Codex 客户端，在左侧选择你的项目。

如果还没有项目，点击添加项目，选择本地代码目录。

第二步：选择 Worktree 模式

如果只是问问题，可以用 Local。

如果要改代码，建议选择 Worktree。

这样 Codex 的改动不会直接污染你当前项目目录，你可以更放心地让它尝试。

第三步：先让它出计划

不要一上来就让它动手。可以这样写：

我想给登录页增加“记住我”功能。请先不要修改代码，先阅读相关文件并给出计划：

1. 你准备查看哪些文件；

2. 你认为需要改哪些文件；

3. 可能的风险点是什么；

4. 准备用什么方式验证。

等 Codex 给出计划后，你再判断是否合理。

如果计划太大，可以追一句：

请收窄范围，只做最小必要改动，不要重构无关代码。

第四步：让它开始实现

确认计划后，再说：

按这个计划实现。请尽量保持最小改动，完成后运行相关测试或 typecheck，并总结修改了哪些文件。

这时 Codex 会开始查看文件、修改代码、运行命令。你可以在任务侧边栏看到它的计划、操作过程、来源和阶段性总结。

第五步：看 Review 面板

任务完成后，不要直接提交。

先打开 Review 面板，看它到底改了什么。

Review 面板通常会显示：

• 哪些文件被修改；
• 每个文件具体改了哪些行；
• 哪些改动已暂存；
• 哪些改动还未暂存；
• 是否可以按文件或按代码块 revert。

如果你发现某处不对，可以直接在 diff 的具体行上写评论，比如：

这里不要改成 localStorage，我们项目里统一用 storageService。

然后回到线程里告诉 Codex：

请处理我在 Review 面板里留下的 inline comments，保持改动范围尽量小。

这种“对着 diff 精确反馈”的体验，是 Codex 客户端比普通聊天式 AI 更好用的地方之一。

第六步：运行验证

你可以让 Codex 自己运行验证命令：

请运行项目的 typecheck 和相关测试。如果失败，先解释失败原因，再尝试修复。

也可以自己在内置终端或外部终端里运行。

常见命令包括：

npm test

npm run typecheck

npm run lint

pnpm test

pnpm typecheck

pnpm lint

具体命令取决于你的项目。

第七步：提交或继续调整

确认没问题后，你可以在 Codex 客户端里 stage、commit、push，甚至创建 PR。

如果你更习惯自己的 Git 工具，也可以回到 IDE、GitHub Desktop 或命令行里完成提交。

六、Prompt 怎么写，Codex 才更稳定？

Codex 客户端很强，但你给的任务越清楚，它就越稳定。

一个好用的 Prompt 可以包含四部分：

目标：

给登录页增加“记住我”功能。

上下文：

项目是 React + TypeScript。登录相关文件可能在 src/pages/Login.tsx、src/api/auth.ts、src/store/user.ts。

限制：

不要新增依赖。

不要重构无关代码。

保持现有 UI 风格。

如果发现已有封装，优先复用。

完成标准：

1. 页面出现“记住我”复选框；

2. 勾选时登录状态持久化；

3. 不勾选时仅当前会话有效；

4. 运行 typecheck；

5. 总结修改文件和验证结果。

这个模板适合大多数开发任务。

你也可以把它简化成一句：

请先读相关文件并给出计划，确认后再实现。实现时保持最小改动，完成后运行验证并总结 diff。

这句话几乎可以成为你使用 Codex 的默认开场白。

七、Review 面板：Codex 客户端最值得用的地方

如果只把 Codex 当成“会写代码的聊天框”，那就太浪费了。

客户端真正厉害的地方之一是 Review 面板。

它让你可以像做代码审查一样检查 Codex 的工作：

• 按文件查看改动；
• 按代码块接受或回退；
• 在具体行上留下评论；
• 让 Codex 根据评论继续修改；
• 查看 PR 相关上下文；
• 处理 reviewer 的反馈。

这意味着你和 Codex 的协作方式可以从：

你改一下这个地方。

升级成：

我在 diff 里标了三处问题，请只处理这些 inline comments，不要扩大改动范围。

这种反馈方式更像真实团队协作，也更容易得到稳定结果。

八、内置浏览器：做前端时特别好用

如果你做的是 Web 项目，Codex 客户端里的内置浏览器非常实用。

你可以先让 Codex 启动本地开发服务器，比如：

请启动本地开发服务器，并打开首页预览。

然后在内置浏览器里查看页面效果。

如果发现问题，你可以直接对页面区域留下评论，例如：

这个按钮在移动端超出了卡片边界，请修复布局，不要改变卡片结构。

然后让 Codex 根据浏览器评论修复：

请处理我在页面上留下的评论，只修复移动端布局问题。

这种方式特别适合：

• 修 UI 细节；
• 调响应式布局；
• 处理溢出、错位、间距问题；
• 对比设计稿；
• 验证某个页面是否真的修好了。

需要注意的是，内置浏览器更适合本地页面、公开页面、无需登录的页面。涉及复杂登录态、浏览器插件或个人账号状态时，还是用你平时的浏览器更稳。

九、Automations：让 Codex 定期帮你做事

Codex 客户端还有一个很有想象力的功能：Automations。

你可以把它理解成“定时运行的 Codex 任务”。

比如你可以让 Codex 每天或每周做这些事：

• 检查项目最近的错误日志；
• 总结过去一周代码变化；
• 扫描依赖升级风险；
• 定期生成技术周报；
• 检查某个测试是否还在失败；
• 发现问题后把结果放到 inbox 里。

如果项目是 Git 仓库，自动化任务还可以跑在独立 worktree 里，避免影响你当前正在写的代码。

这类能力会让 Codex 从“我问一次，它做一次”的助手，变成“它可以周期性帮我盯着事情”的工作流工具。

十、权限和安全：一定要让 Codex 在边界内工作

Codex 客户端能修改文件、运行命令、使用工具，所以安全边界非常重要。

使用时建议记住三条原则：

1. 不确定时，选择更窄的权限

当 Codex 请求执行某个命令时，如果你不确定它是否安全，不要随便批准长期权限。

优先选择一次性批准，或者让它解释命令目的：

请解释你要运行这个命令的原因，以及它会修改哪些文件或环境。

2. 让 Codex 留在项目目录里

不要轻易让 Codex 在整个电脑里到处访问。

大多数开发任务只需要当前项目目录。需要跨仓库时，更建议分别添加项目，而不是让它突破项目边界。

3. 正式改代码优先用 Worktree

Worktree 是最好的安全垫之一。

它让 Codex 的尝试和你的主工作区隔离开。即使改错了，你也可以直接丢掉那个 worktree 或回退改动。

十一、把项目规则写清楚：让 Codex 越用越顺手

Codex 很聪明，但它并不会天然知道你的团队习惯。

所以建议在项目里准备一份给 AI 看的项目说明，比如：

# 项目协作规则

## 技术栈

– React + TypeScript + Vite

– 包管理器使用 pnpm

– 样式使用 Tailwind CSS

## 开发约定

– 不要使用 npm install

– 不要修改 generated/ 目录

– 新增逻辑优先补测试

– 不要随意重构无关代码

## 验证命令

– pnpm typecheck

– pnpm lint

– pnpm test

## 交付要求

– 总结修改文件

– 说明验证结果

– 如果没有运行测试，必须说明原因

你可以把这类规则写进项目文档，也可以让 Codex 帮你整理。

推荐第一次打开项目时这样问：

请阅读项目并帮我生成一份适合 Codex 使用的项目协作规则，包含技术栈、常用命令、目录约定、禁止事项和完成标准。先输出草稿，不要写文件。

确认没问题后，再让它写入项目。

十二、非程序员也可以怎么用 Codex 客户端？

虽然 Codex 是面向开发场景的工具，但它不只属于程序员。

很多现代工作本质上都可以拆成：读取文件、理解结构、修改内容、运行工具、生成结果。Codex 客户端擅长的正是这些事。

1. 做个人网站

你可以直接准备一个空项目，然后对 Codex 说：

帮我做一个个人主页，包含自我介绍、项目展示、联系方式。风格简洁现代，适配手机端。完成后启动本地预览。

它可以帮你生成页面、样式、组件，并在本地跑起来。

2. 整理博客和 Markdown 文档

如果你有一堆 Markdown 文件，可以让 Codex：

• 统一标题层级；
• 自动生成目录；
• 修正格式；
• 补充 front matter；
• 检查错别字；
• 批量修改文件名；
• 按博客发布规范整理文章。

3. 分析数据

把 CSV 或 JSON 放进项目，让 Codex 写脚本处理：

• 清洗数据；
• 统计指标；
• 生成图表；
• 输出分析报告；
• 找异常值；
• 做一个简单数据看板。

4. 做自动化小工具

很多重复劳动都可以交给 Codex 起步：

• 批量重命名文件；
• 整理下载目录；
• 把 Excel/CSV 转成指定格式；
• 生成周报；
• 把接口返回转成文档；
• 做一个本地脚本或小网页。

5. 帮团队沟通技术变化

让 Codex 根据代码改动生成不同版本的说明：

• 给产品看的功能摘要；
• 给测试看的验证清单；
• 给运营看的上线影响；
• 给开发看的技术风险；
• 给老板看的项目进展。

这类用法会让非技术同学也能更低门槛地理解和参与技术流程。

Codex 客户端真正改变的是“AI 在哪里工作”

过去，AI 在聊天框里工作。

现在，Codex 客户端让 AI 进入了项目、Git、终端、浏览器和自动化流程里。

它不只是更方便地生成代码，而是让 AI 更自然地参与完整开发过程：

• 先理解项目；
• 再制定计划；
• 然后修改代码；
• 接着运行验证；
• 最后通过 Review 面板与你一起打磨结果。

对开发者来说，它像一个可以并行处理任务的 AI 工程师。

对团队来说，它像一个能处理重复工程任务的自动化成员。

对普通用户来说，它可能是把想法变成网站、脚本、数据报告和小工具的最快入口。

如果你还没认真试过 Codex 客户端，我建议不要从很大的需求开始。

就从一个真实的小任务开始：让它读一个项目、修一个小 bug、补一个测试、整理一篇文档，或者做一个简单网页。

你很快会发现：

Codex 好用的地方，不是它替你思考，而是它终于可以进入你的工作现场，和你一起把事情推进。