上礼拜，有个刚入行的朋友拉我坐到他电脑前。
他说他装好了 Codex，卡了半小时，不知道第一步该干嘛。
我扫了一眼他的屏幕。左边是项目和任务，中间一个输入框，右上角三个按钮写着 Local、Worktree、Cloud，下面还躺着个 Plan 的开关。
他问我，这真的只是个写代码的工具吗，怎么看着像个操作系统。
我笑了笑。这个问题我太熟了。每一个第一次打开 Codex 的人，几乎都是在同一屏被劝退的。
Codex App 的主界面。底下那个输入框不只是聊天，它其实是一个任务控制台。
今天想跟你把这件事掰开讲清楚。不是教你背命令，是从第一次打开它开始，把界面上每一个让你发懵的地方，逐个说成人话。
先纠正一个最根本的误会。
Codex 不是一个聊天机器人。
它是一个能亲自下手的 Agent。
普通的聊天工具，你问它一句，它给你一段文字，就结束了。
Codex 不一样。它除了回答，还能读你的文件、改代码和文档、运行命令、看 Git 改动、打开网页、操作应用，还能把已经接好的外部工具调起来。
所以它处理一件事，基本跑的是这么四步。
Prompt → Plan → Execute → Verify
你提任务，它想怎么做，它实际读写文件和跑命令，最后它检查结果。四步里，最容易被人忽略的是最后一步。
「完成了」三个字，不等于「做对了」。
Codex 说一句「完成了」，只能说明它停下了当前这一次执行。它证明不了文件一定正确，证明不了页面一定能用，也证明不了测试一定通过。
这句话请先记下。等会儿讲 Diff 和验收的时候，你会反复用上它。
它一共五个入口。CLI、Codex App、Cloud、IDE 扩展、Chrome 扩展。区别我整理成了一张表。
五个入口的差别。先挑一个用趁手，别的按场景再补。
新手没必要五个都学。你已经打开桌面 App，就先把 App 用明白。习惯终端的，再补 CLI。剩下那几个，都是为具体场景服务的，不是越多越专业。
回到开头那一屏。Codex App 的主体，就三块。
左边管项目和任务，中间管对话和执行，右边看改动。
项目对应一个工作目录。你加一个网站仓库、一个文章目录、一个工具工程，本质上是在跟它说，这一批文件属于同一件长期工作。
任务是一个项目下面的一次独立对话。一个任务最好只盯一个结果，比如检查这篇文章的结构、修登录页的报错、整理昨天的提交记录。
项目可以长期存在，任务得有结束点。
左侧的项目和任务。项目是目录，任务是它下面的一次对话。
右边那块 Diff 面板，是我觉得最被低估的部分。
很多人的用法是，让它跑完，扫一眼有没有红红绿绿，就关了。
其实它还能干更多。看所有没提交的修改，在具体某一行旁边留评论，按文件或改动块去暂存、撤销，直接在 App 里 commit、push、开 Pull Request。
哪一行有问题，就在哪一行点一下留言，比你在输入框里打字描述「上面那个函数」要准得多。
接下一个最容易出事故的地方。
工作区。
工作区就是 Codex 当前干的活所在的目录。选错目录，是你「找不到文件」「改到别处」「读了太多无关材料」的根本原因。
选目录就一个标准。完成这件事所需的文件，能不能塞进一个最小的目录。
能，就只开这个目录。别为了省一次切换，把整个桌面、个人主目录、一堆不相干的项目，一股脑全交给它。
任务在哪里跑，也有三种。
Local 直接改你选的目录，适合绝大多数日常活，改文档、修 Bug、跑测试。它的问题是你们可能同时改同一个文件。
Worktree 给任务一份隔离副本。它在副本里改，你正在用的目录纹丝不动。适合同时开好几个任务改同一个仓库，或者你想让它试一个改动，又不想马上碰当前分支。
Cloud 把任务丢到云端。适合边界清楚、可以异步等的活，代码审查、修明确的 Issue、批量重构。需要频繁讨论、依赖本机文件的活，还是 Local 顺。
接着是权限，这块不能含糊。
三档权限。对小白来说 Workspace-write 就够。
只想看不想改，就用 Read-only。Full access 不该为了少点几次确认就打开。
看到审批弹窗，先看四件事。它要执行什么命令，在哪个目录执行，要不要联网，这一步对当前目标是不是真有必要。
凡是装依赖、上传文件、删数据、改账号设置、对外发布、碰凭据，都值得停下来多看一眼。
再讲 Plan。
Plan 是个好东西，但不是回回都要。复杂任务里，它能让你提前发现范围太大、顺序不对、准备装不必要的依赖。简单任务里，它可能只是一道多余的形式。
改个标题、查一个报错的位置、跑一条确定的命令，没必要先列五步计划。
接任务先想清楚两件事。真正的问题是什么，最短可靠的路径是什么。
能直接做完，就不搭流程。能复用现成的东西，就不从零做。能改局部，就不推翻重来。能一条命令解决，就不写脚本。
下面这三个词，是新手最常混在一起的。
Skill、Plugin、MCP。
一句话说清。Skill 教 Codex 怎么干一类事，Plugin 把一整套能力打包好塞给你，MCP 让 Codex 连上外部工具和数据。
Skill 是操作手册，Plugin 是能力包，MCP 是外部接口。
装插件之前先问一句，当前的任务是不是反复需要这个系统的数据或动作。只用一次的网站，不一定值得装插件商店。能用原生功能完成的事，不必为了「生态」再套一层。
插件商店。能用原生功能完成的事，不必为了「生态」再套一层。
还有两个容易被过度神化的功能。Automation 定时任务，和 /goal 长期目标。
Plan、Automation、/goal，管的是三件不同的事。
Automation 是闹钟，/goal 是长期任务的状态。普通几分钟的任务不需要 /goal。需要你频繁判断、方向还不明朗的探索，也别硬把它设成「不做完不停」。
一个能用的 /goal，得有可验证的结束条件。「把所有测试迁移完，并让现有测试全部通过」，就比「持续优化这个项目」合适得多。
再说 CLI。它不是必选项，但它把 Codex 的能力暴露得最直接。
CLI 的常用命令。先记五个，其余用到再查。
命令不用背。先记住 /plan、/review、/diff、/permissions、/status 这五个，够你扛一阵子。
回到最开始那个问题。刚开始用，到底该按什么顺序学。
从 0 到 1 的四段。缺哪一层再补哪一层，别一次装满。
第一阶段就练四件事。选对工作区，新建一个任务，在 Read-only 和 Workspace-write 之间切换，学会看 Diff。
能独立判断「它改了什么、有没有越界」，基础这一关就算过了。
第二阶段加 Plan、终端和 /review。第三阶段才到 Worktree 和多任务并行。第四阶段按真实需求装扩展，重复工作固化成 Skill，要连外部系统才接 MCP，要定时跨天运行才开 Automation。
用 Codex 熟不熟练，从来不取决于你装了多少插件，也不取决于你每次写多长的一段 Prompt。
真正的分水岭，是你能不能给它对的材料和边界，能不能在它跑偏时及时纠偏，能不能用 Diff、终端、测试、页面去判断结果，而不是只盯着那一句「已经完成」。
工具的尽头，是把人从「写代码的人」，变成「下判断的人」。
你负责说清要什么、划好边界、最后验收。剩下的，交给它。
最后留一张速查表。想不起来该用哪个的时候，回来翻这一页。
速查表。你现在要做的事，对应优先用哪个。
祝你早点在 Codex 里做出点真正顺手的东西。
有问题欢迎在评论区交流！👇
👋 关注亿麦AI，每周分享一个AI落地真实案例，帮你少走弯路。
首发于「亿麦AI应用开发」