Codex App Windows 版入门教程:手把手教你从不会用到真正用顺

3 月 4 日，OpenAI 把 Codex App 正式带到了 Windows。

很多人装完第一反应，是打开一个线程，然后开始问它：帮我写个页面，帮我改个 Bug，帮我重构一下。

这么用不能说错，但实话说，这只是把 Codex 用成了一个会写代码的聊天框。

我这几天重新梳理了一遍它在 Windows 上的正确打开方式，发现真正拉开差距的，不是你会不会问，而是你会不会把项目边界、工作模式、代码检查面板（Review）、AGENTS、技能包（Skills）这些东西配起来。

上一篇我已经写过安装踩坑了，这篇不重复聊报错。就聊一件事：Codex App Windows 版，怎么用，才是真的高效。

先把一个误区掰正：Codex 不是“另一个 ChatGPT”

如果你把 Codex 当成普通对话产品，你很快就会觉得它“也就那样”。

因为它的强项，本来就不是陪你聊天，而是围绕项目、线程、Git 和终端，持续把活干下去。官方现在把它的能力写得很明确了：多项目、多线程、独立工作副本（Worktree）、内置终端、代码检查面板（Review）、自动化任务（Automations）、技能包（Skills），这是一整套工作台，不是单轮问答工具。

换句话说，ChatGPT 更像“我问你答”，Codex 更像“我把任务交给你，你在这个项目里继续做事”。

这个定位一旦想明白，后面的很多操作就都顺了。

第一件事，不是发 prompt，而是把项目切对

Codex App 里最重要的对象不是聊天窗口，而是项目空间（Project）。

一个项目空间（Project），本质上就是一个工作目录。你选错了目录，后面所有上下文、权限边界、代码检查面板（Review）、独立工作副本（Worktree）都会跟着歪。

如果你用的是单仓多项目（monorepo），千万别一股脑把整个仓库都丢进去，尤其是前后端、脚本、文档混在一起的那种。官方文档专门提了一句：如果一个仓库里有多个 app 或 package，最好拆成多个项目，这样沙箱边界更清晰，Codex 看到的文件也更聚焦。

这个细节非常值钱。因为很多人觉得 Codex “容易乱改”，其实不是它乱，是你给它的工作区太大了。

我自己的建议很简单：

• 单项目仓库：直接按仓库根目录建项目空间（Project）
• 单仓多项目（monorepo）：按实际要开发的 app 或 package 单独建项目空间（Project）
• 只做内容或脚本：按最小工作目录建 Project，不要把无关目录塞进去

Windows 用户先做一个选择：原生 PowerShell 还是 WSL

这一段其实不用想复杂。你只需要先决定：让 Codex 跟着 Windows 干活，还是跟着 Linux 干活。

如果你的项目本来就在 Windows 上跑得挺稳，比如 Node、Python、小工具脚本这些，直接用 PowerShell 就行，不一定非得上 WSL。

但如果你的项目明显偏 Linux 生态，比如 bash、make、Docker、Linux 路径、shell 脚本用得很多，那就从一开始直接走 WSL。关键不是哪个“更高级”，关键是别混用。今天在 PowerShell 跑，明天在 WSL 跑，这种最容易把自己搞乱。

还有一点要特别注意，如果你在设置里面选择了特定的环境，在线程里面使用的时候就会自动在这个环境运行，比如你选择了

windows native

如果你此时换成

Linux的设置，那么你之前的工作的线程是不能继续使用的，因为会出现报错的情况；

只有线程当前使用的环境和你设置的环境保持一致才能正常使用。

你就按这个标准判断：

• 项目本来就能在 Windows 原生稳定跑：直接 PowerShell
• 项目长期依赖 Linux 工具链：直接 WSL
• 你电脑用户名有中文，之前又踩过权限坑：尽量把 CODEX_HOME 和项目路径放到纯英文路径

上一篇我写的那些权限问题，本质上也都说明了一件事：Windows 不是不能用，而是你要尽量减少环境分裂。

本地环境配置（Local Environment）是进阶项，不用一上来就碰

这个功能对代码项目确实有用，但我不建议普通用户一开始就把它当重点。

它本质上是干两件事：第一，给 Worktree 配 setup script。第二，给常用命令配 action 按钮。

它适合什么场景？适合你让 Codex 进入一个新副本目录之后，自动知道先装依赖、先 build、先跑检查，不用每次重新猜“这个项目怎么启动”。

比如一个前端项目，最简单可以写成这样：

npm installnpm run build

然后再配几个顶部 action：

npm run devnpm testnpm run lint

这样你每次都不用重新敲命令，Codex 也不用猜你平时怎么启动项目。

但如果你现在只是写文章、问问题、改一点代码，不怎么让它本地跑完整流程，这块完全可以先放一边，后面再学。

Prompt 别写成愿望清单，要写成“任务单”

Codex 官方的 Prompting Guide 里有个核心建议，我很认同：先从简单 prompt 开始，但把上下文、约束和验收条件补清楚。

这句话翻成人话就是，别写那种“帮我优化一下这里”。

你得像给同事派活一样，把范围、限制、验证方式说清楚。Codex 很能干，但它也真的很听话。你说得越模糊，它越容易一路干到沟里去。

我现在最常用的是这种写法：

在 `src/features/login` 范围内修复登录页表单提交后按钮不恢复的问题。要求：1. 不要改 API 结构2. 不要新增依赖3. 先阅读相关组件、hook 和提交逻辑，再动手4. 修改后运行 `npm test` 和 `npm run lint`5. 最终告诉我根因、改了哪些文件、还有什么风险

如果我不想它一上来就开改，我会再加一句：

先不要改代码。先定位根因，给我一个最小修改方案，我确认后再动手。

这类 prompt 有个共同点：不是许愿，而是在下任务。

官方 Workflows 文档也建议，把验证步骤写进 prompt 里，比如跑哪些测试、怎么证明修好了。这个习惯一养成，你会发现 Codex 的稳定性直接上一个台阶。

斜杠命令（Slash Commands）很有用，尤其是这几个

很多人装完 Codex App，压根没碰过斜杠命令（slash commands）。

先提醒一句：这里写的是官方文档里的英文命令名。你如果用的是中文界面，实际看到的名称是中文，或者需要从命令菜单里点选，不一定完全按英文输。这里最好以你自己客户端里弹出来的命令列表为准。

其实这几个命令在日常里很顺手，尤其是线程变多之后：

• /status（状态）：看线程 ID、上下文使用情况、额度信息
• /review（代码审查）：直接进 code review 模式，看未提交改动或对比 base branch
• /plan-mode（计划模式）：先让 Codex 进入规划模式，适合复杂任务先拆步骤
• /mcp：看 MCP 连接状态

如果你是那种一上来就丢大任务的人，/plan-mode 很值得用一下。不是因为它会变聪明，而是因为它会先把步骤摊出来，避免直接冲进去乱改。

还有一个很多人没注意到的细节：技能包（Skills）也可以直接用 $技能名 触发。这个后面我会讲。

当前工作区（Local）和独立工作副本（Worktree），其实就是“原件”和“副本”

这一块最容易把人绕晕，所以我直接用大白话说。

你可以把 Local 理解成原件，把 Worktree 理解成副本。

Local 就是你现在手头这份真实项目目录。Codex 如果在 Local 里工作，改的就是你眼前这份文件。Worktree 则是 Git 帮你额外开出来的一份项目副本，Codex 在里面改，不会直接碰你现在这份原件。

所以这两个的区别其实很简单：Local 是直接改原件，Worktree 是先开副本，再改副本。

如果还是抽象，你就把它想成写文档：Local 是直接改正式稿，Worktree 是先另存为一个试改版，再去试改版里改。

真正要分清的，不是术语，而是这三个按钮

如果你在界面里看到这些操作，可以这样理解：

• 本地 Local：继续在原项目里干
• 派生到新工作树：保留当前线程，再新开一个线程，让新线程去项目副本里干
• 移至工作树：不额外开新线程，直接把当前这个线程搬到项目副本里去干

这三个看着像功能名，其实本质上只是在回答一个问题：这次任务到底是在原件上做，还是在副本上做。

派生到工作树后

得到这样的界面，会在你看到的线程里面出来一个“已从xxx派生”，此时你继续输入的对话就在派生的线程里面记录，而原来的线程是不记录的，两个是独立的线程，点击“已从xxx派生”后回到原来的线程，派生的线程在设置里面。

设置里面默认是自动删除的

所以如果你只是问问题、改文章、做一点小修改，继续待在 Local 就够了。只有当你怕改乱原项目，或者想让 Codex 放开手试方案时，Worktree 才开始有价值。

你真正要会的，其实只是“怎么找到 Worktree”

按照你现在看到的界面，最实用的结论不是“怎么来回切”，而是：Worktree 其实有单独的管理页。

如果你点了“派生到新工作树”，最明显的变化通常是当前任务会显示“已从 xx 派生”。这个提示只是来源说明，不是切换按钮。

真正要找之前派生过的 Worktree，应该去：

• 设置
• 工作树
• 在这里看每个 Worktree 对应的目录和关联的对话

这就解释了为什么你回到原线程后，会觉得“那个 Worktree 找不到了”。不是它一定没了，而是它不在主线程列表里直观地挂着，而是被放到了工作树管理页里。

也就是说，Worktree 线程 和 Local 线程 不是同一个聊天记录本。你在副本里新增的对话，不会自动长到原线程里，这个是正常设计，不是记录丢了。

Worktree 这套设计，现阶段更像“隔离副本”，不是“丝滑切换”

这个地方我得说实话。按现有界面看，Worktree 更像一个给进阶用户准备的“隔离副本模式”，而不是一个对新手非常顺手的“随时来回切换模式”。

你在设置里能看到两个很关键的信号：

• 有单独的工作树管理页
• 默认开启了自动删除旧 Worktree

这说明产品设计思路本身就是：Worktree 是后台管理的副本资源，不是长期摆在前台给你反复切的主工作流。

所以如果你是第一次上手，我更建议你这么理解：

• Local：默认模式，绝大多数时候先用这个
• 移至工作树：把当前任务搬到副本里做，适合你怕改乱原项目的时候
• 派生到新工作树：额外开一个副本任务，适合并行试方案
• Worktree 用完之后，去“设置 -> 工作树”里统一看和管理

至于 handoff，如果你在当前界面里没有看到明确按钮或入口，那就不要把它当成必须掌握的操作。对普通用户来说，先搞明白 Local 和 Worktree 的区别，已经够用了。

你现在这个阶段，到底该怎么用

按你现在的使用方式，我的建议很简单：

• 写文章、问问题、小修改：一直用 Local
• 先别急着频繁派生 Worktree
• 真正开始让 Codex 改很多代码，而且你怕它把当前项目搞乱时，再用 Worktree
• 如果你只是想“当前线程直接切去副本里继续干”，用“移至工作树”
• 如果你想“保留当前线程，再开一个分身去副本里干”，用“派生到新工作树”
• 如果你派生完之后找不到之前的 Worktree，去“设置 -> 工作树”里找，不要只在主线程列表里翻

这样最不绕，也最符合大多数刚上手用户的习惯。

审查模式（Review）更像“问题清单”，而 diff 在普通对话里就能看

这一点我也得按你现在实际看到的界面来说，不然很容易把人带偏。

很多人第一次用 Codex，会把 diff 和 Review 混在一起。其实这两个东西不是一回事。

普通对话里，只要 Codex 真改了文件，你就能直接看到修改差异，也就是常见的红删绿加视图。这个就是 diff，用来回答一个最直接的问题：它到底改了什么。

而如果你在 Codex App 里点“审查未提交的更改”或者“基于基础分支进行审查”，当前更常见的结果不是弹出一个像 GitHub Desktop 那样的 diff 面板，而是进入审查模式，然后给你一条条问题结论。

也就是说，你现在在界面里更容易看到的是：

• 它帮你审查出了什么问题
• 每条问题对应哪个文件、哪几行
• 严重程度大概是什么

所以更准确的区分应该是：

• diff：看它改了什么
• Review：看它改得有没有问题

如果你第一次用 Review，发现自己点来点去都只是得到一条结果，不知道 diff 在哪，这不是你不会用，而是当前这个界面本来就更偏‘问题卡片模式’。

按现在截图里的界面，普通用户最实用的用法其实只有两个：

• 审查未提交的更改：适合看你当前工作区里还没提交的内容有没有明显问题
• 基于基础分支进行审查：适合拿当前改动和基础分支做一次更正式的审查

这两个入口的区别，你可以先这样理解：

• 前者像“帮我看看我手头这些还没提交的改动有没有问题”
• 后者像“站在要合并代码的角度，帮我看看相对基础分支有没有问题”

如果你只是日常自己改代码，先用“审查未提交的更改”就够了。不要一上来就在这两个入口之间来回切，因为当前界面给你的呈现结果确实很像。

另外还有一个很实际的点：如果你真正想一行一行看代码差异，很多时候普通对话里的 diff 已经够用了，或者直接去 VS Code、GitHub Desktop 这类工具里看会更直接。Review 更适合拿来发现问题，不太适合当成“手动比对 diff 的主界面”。

所以这段最准确的说法不是“Review 比追问一句更重要”，而是：普通对话适合看改动，Review 适合查问题。

想长期稳定，AGENTS.md 还是值得写

这东西我还是建议代码项目配一份，但表达要收一收。它不是“必须神物”，更像是你给 Codex 的项目工作规矩。

官方文档已经写明白了：Codex 会在开始工作前先读 AGENTS.md。 而且它支持全局、仓库根目录、子目录逐层覆盖。

你可以把它理解成“这个项目该怎么合作”的说明书。比如：

## Working agreements- 使用 pnpm，不要改成 npm- 改完前端代码后运行 `pnpm lint`- 不要修改 `dist/` 和生成文件- 只做和当前任务直接相关的改动- 如果需要新增依赖，先说明原因

这样做最直接的好处是：你不用每次开新线程都重新教一遍“这个项目怎么干活”。

如果你是写作目录、内容目录、资料目录，也不是不能写，只是可以更简单。比如规定新文章放 drafts/、不要随便改 published/、术语优先用大白话，这些都可以写进去。

同样的活做了三次，就该做成技能包（Skill）

技能包（Skills）这个东西，对新手最容易误会成“高级插件”。其实不是。

你可以把 Skill 理解成：给 Codex 准备好的专项工作说明书。 某一类任务你已经做顺了，比如固定风格改稿、固定格式审查、固定套路排查，那就别每次重新解释，直接做成 Skill。

而 SKILL.md 就是这个技能包里的核心说明文件，写清楚：这个技能是干嘛的、什么时候用、按什么步骤做、最后输出什么。

所以一句话就够了：

• Prompt 解决一次任务
• Skill 解决一类任务

只是不用一上来就做很多，先把最常用的一类任务做成 Skill 就够了。

自动化任务（Automations）可以先知道，但不用急着上

Automations 的方向没有问题，就是把“总要做的事”定时跑起来。

比如这些场景就很适合：

• 每天早上扫一遍最近代码变更，生成简报
• 每周看一次依赖更新和潜在风险
• 定时整理某个目录里的错误日志

但对普通用户来说，这块不用上来就碰。因为它背后会牵涉 Worktree、权限、触发规则这些东西，前面几块你还没跑顺，自动化只会把复杂度再往上抬一层。

所以更稳的建议是：先手动跑通，再考虑自动化。

换句话说，Automations 先知道它是干嘛的就行，不一定要把它放进你第一周的主工作流。

我自己现在更认可的高效工作流，是这 6 步

我更建议你按这个顺序理解：

第一步：先把项目空间（Project）建对单项目仓库就按仓库根目录建。单仓多项目（monorepo）就按你当前真正要动的那个 app 或 package 来建，不要一上来把整个大仓库全塞进去。

第二步：默认先用 Local刚上手的时候，大多数任务都先在 Local 里做。问问题、改文章、小改代码，都没必要上来就碰 Worktree。

第三步：Prompt 写成任务单把范围、限制、验收条件写清楚。你不是在许愿，而是在派活。

第四步：代码项目再考虑 AGENTS.md如果你会反复在同一个项目里干活，那就把工作规矩写下来，别每次重新解释。

第五步：需要隔离风险时，再上 WorktreeWorktree 更像后台副本，不是人人都要天天切的主功能。真怕改乱原项目，或者你想让 Codex 放开手试方案，再用它。

第六步：普通对话先看 diff，审查模式再查问题普通对话里的红删绿加，适合看“它改了什么”；审查模式适合看“它改得有没有问题”。这两个别混着用。

这 6 步跑顺之后，你对 Codex 的体感会稳定很多。不是每个功能你都要马上用到，而是先把最常用、最不容易踩坑的那部分用顺。

最后说几个最容易把 Codex 用拧巴的习惯

第一，把它当普通聊天机器人。一直追问，不看文件、不看 diff、不看项目边界，这样很容易越聊越乱。

第二，一上来就追求全功能。Worktree、Automations、Skills 这些都没错，但不是第一天就必须全会。

第三，不写约束，只给一句“帮我优化一下”。你说得越模糊，它越容易朝错误方向一路干下去。

第四，明明只是想看改了什么，却跑去审查模式里找 diff。普通对话里的 diff 和审查模式不是一回事，别混着找。

第五，把所有问题都归因到工具不行。很多时候不是 Codex 不行，而是项目边界没切对、提示没写清楚、或者你把进阶功能当成了入门功能。

最后收一下

如果你也是第一次认真用 Codex App Windows 版，我现在最真实的建议不是“把所有功能都学会”，而是：先把最顺手的那部分用起来。

先会三件事就够了：

• 项目目录别选错
• Prompt 别写太虚
• 改完先看 diff

剩下像 Worktree、Skills、Automations 这些，知道它们是干嘛的，等真遇到场景了再上，不晚。

这类产品现在还在快速迭代，很多功能官方概念讲得很完整，但真到界面体验上，还是得自己踩一遍才知道哪里顺、哪里绕。把这些坑记下来，比堆一堆概念更有用。

这篇先写到这。你如果也在用 Codex App，踩到什么坑，评论区告诉我，我继续补。

以上觉得有用的话，关注下、点个赞或收藏、转发给你需要的朋友，如果想第一时间收到推送，也可以给我个星标⭐ 谢谢你看我的文章，下次见。