06 · 跑通第一个任务
📚 系列导航：上一篇 05 · 接入 DeepSeek 等国产模型 把「换大脑」那条野路子讲透了。配置篇到此为止——这一篇正式上手干活，让 Codex 实打实改一次你的代码，跑通从提需求到看 diff 验收的完整闭环。下一篇 07 · 桌面 App 全景 再把桌面端那张脸看个遍。
兄弟们，先交代一件我刚上手 Codex 时干的蠢事。
那是我装好 Codex CLI 的头一个晚上，兴冲冲想试试它到底能不能改代码。我直接 cd 进了公司一个跑了两年、几百个文件的主仓库，劈头一句「把用户模块重构一下，太乱了」。Codex 读文件读了十几秒，刷屏刷得我眼花，然后甩出一大坨改动——横跨七八个文件。我当时心一横「应该没问题吧」，眼睛都没细看就点了同意。
结果呢？它确实「重构」了，但顺手改了两个我压根没让它碰的接口签名，本地测试当场红一片。我花了快一个小时才把它的改动一行行捋清楚、挑出哪些要、哪些得退回去。那一晚我最大的教训不是「Codex 不行」，而是「我跳过了那个最该停下来看的动作——审 diff」。
说句实话，这篇我最想塞给你的，就是这个动作。今天咱们不碰大项目，建个三行代码的玩具，五分钟走一遍「提需求 → Codex 在沙箱里改 → 看 diff 验收 → 留下或退回」的完整一圈，让你第一次拿到「Codex 帮我改对了代码、而且全程我看得明明白白」的成功体验。桌面 App 和 CLI 两条路我都给你走一遍。
看完这一篇，你会拿到：
- 一套从开终端 / 开 App 到跑通第一个任务的完整动作流程，照着做就行
- 把「审 diff」这个核心动作刻进肌肉记忆——这是新手和老手最大的分水岭
- 桌面 App 与 CLI 两种走法的逐步操作 + 预期输出，能自己验证成没成
- 几个让你第一次就不踩坑的关键提醒（拒绝后怎么补话、改错了怎么退回去）
⚠️ 下文凡涉及具体命令、参数、默认行为，都以 Codex 官方文档 为准；模型名、界面文案这类会随版本变的东西，看到时以你本地实际显示为准。
01 别拿正式项目练手，先建个玩具
先说结论，这是我用一小时换来的：第一次用 Codex，千万别拿你的正式仓库开刀，建个三行代码的玩具项目。
为什么？开头我那场翻车讲得够清楚了——正式项目文件多、依赖杂，Codex 一上来读半天，它改了什么你根本看不过来，而你恰恰是在「看不过来」的时候最容易瞎点同意。玩具项目就两三行，它动了哪个字你一眼能逮住，这才是用来练手的。
类比：学骑自行车先找条没人的小路。 没人一上来就骑去早高峰的主干道——先找条空巷子，摔了也不疼，把平衡和刹车的手感找到。玩具项目就是你那条空巷子：改砸了？删掉重建，三十秒的事，心一点不慌。
哪些人尤其得听这条劝：
- 完全没碰过命令行的——光是 Codex 读文件那几秒滚屏，就够你手心冒汗了，别再叠加「改的是真项目」的压力。
- 刚从别的工具切过来的——比如你用惯了 Claude Code，以为 Codex 一个套路，结果它的沙箱、审批节奏跟你预期的不一样（这正是上一篇 05 和 02 核心概念 反复提醒的），先在玩具上摸清脾气。
- 急着出活的——越急越要先跑通一次最小流程，把链路验通了再上真活，比中途翻车省时间。
打开终端（Mac 上是「终端 / Terminal」，Windows 上推荐 PowerShell），敲这两行建个玩具目录：
bash
mkdir hello-codex
cd hello-codex这两行的意思是：新建一个叫 hello-codex 的文件夹，再进到里面。mkdir = make directory（建文件夹），cd = change directory（进文件夹）。
接着塞一个最简单的 Python 文件进去。Mac / Linux 直接用：
bash
echo 'def add(a, b):
return a + b' > main.pyWindows PowerShell 里用 echo 写多行有点别扭，你直接用记事本新建一个 main.py ，把下面两行贴进去存好就行：
python
def add(a, b):
return a + b💡 一句话总结：第一次用 Codex，先建个三行代码的玩具当「空巷子」——它改了啥你一眼看得清，改砸了删掉重建，全程心不慌。
02 把需求提清楚：Codex 干活的「想→做→看」循环
项目建好了，先别急着启动，花一分钟想清楚一件事：你到底要让它干嘛，这话怎么说。
为什么先聊这个？因为 Codex 不是许愿池——你扔进去什么质量的需求，它就回你什么质量的活。02 核心概念 讲过它是个代理（Agent），干活靠一个循环：调用模型，执行模型指示的动作（读文件、改文件、调工具），直到任务完成或被你取消。翻成大白话还是那三个动作——想 → 做 → 看。
类比：把活儿交给一个靠谱的装修工长。 你说「这屋子收拾收拾」，他只能凭感觉来，多半不合你意；你说「主卧刷成米白、阳台加个洗手池、下周五前完工」，他就知道照着干、还能自己验收对没对。需求越具体、越带「怎么算完成」，工长（Codex）越不容易跑偏。 这正是官方在《Prompting》里给的两条核心建议：
- 让它能自我验证：需求里带上复现步骤、验收方式、要跑的 lint / 测试，Codex 产出的质量明显更高。
- 大活拆小步：复杂任务拆成一个个小而专注的步骤，它好测、你好审；实在不知道怎么拆，直接让 Codex 先给你出个方案（plan）。
举几个你真会遇到的场景，体会下「模糊」和「具体」的差别：
| ❌ 模糊的需求 | ✅ 具体的需求 |
|---|---|
| 「优化一下这个函数」 | 「给 add 加类型注解，传入非数字时抛 TypeError」 |
| 「这测试为啥挂了」 | 「跑 pytest，定位失败原因，修好后再跑一遍确认全绿」 |
| 「把项目重构下」 | 「先别动手，列个重构方案给我，我确认了再分步改」 |
最后那行是我现在最常用的开场——遇到稍微大点的活，第一句永远是「先给方案，别动手」。这是我从开头那场翻车里学乖的：让它先把计划摆出来，我审一遍方向，再放它动手，比它闷头改完我再收拾残局强太多。
💡 一句话总结：Codex 在「想→做→看」里干活，你给的需求越具体、越带验收标准，它越不跑偏；大活先让它出方案，别一上来就让它埋头改。
03 第一个任务先「读」不「改」：确认它真读到了你的文件
第一个真正的任务，我建议你先让它解释代码，而不是改代码。
为什么先解释？两个实在的理由：一是确认 Codex 真读到了你的文件，而不是在凭空瞎编（新手最大的疑虑就是「它到底看没看我代码」）；二是解释类任务零风险——它只读、只说，不动你一个字，最适合第一次试水。
类比：新搭档入职第一天，你先让他「读读代码、跟我讲讲这块干嘛的」。 你不会上来就甩核心模块让他重构——先听他复述一遍，你立马就知道他读懂没、靠不靠谱。让 Codex 解释代码，就是这个「入职第一天」的试探动作。
不管你用 CLI 还是 App，在输入框里敲这句（用大白话，不用记什么格式）：
text
解释 main.py 这个文件在做什么，用新手能听懂的话说回车。Codex 会自己去读 main.py ——你不用手动把文件「喂」给它，它在代理循环里自己就把相关文件读了。然后它给你一段大白话，大意是：这里定义了一个 add 函数，收两个参数 a 和 b ，返回它俩相加的结果。
这一步跑通，意味着两件事成立了：Codex 装对了、登录态正常，而且它确实在读你机器上的真实文件。地基稳了，下一步才敢放它动手。
把对 Codex 的指令分三类记，你以后心里就有谱：
| 指令类型 | 干什么 | 例子 | 风险 |
|---|---|---|---|
| 解释型 | 让它读懂、讲给你听 | 「解释这段代码」 | 零风险，不动文件 |
| 修改型 | 让它改现有代码 | 「给这个函数加类型注解」 | 会动文件，要审 diff |
| 生成型 | 让它写新东西 | 「补一个测试用例」 | 会建 / 改文件，要审 diff |
我自己每进一个陌生项目，雷打不动第一句都是「先帮我理一遍这个项目的结构」。一来确认 Codex 读得到、读得对；二来它理出来的结构图，常常比我自己翻半天还清楚——这是解释型任务白送的福利。
💡 一句话总结：第一个任务先用「解释型」试水——确认它真读到了你的文件、地基稳了，再放它动手改；修改型和生成型，后面都得过「审 diff」那一关。
04 核心动作：改完审 diff（全篇最该记住的一节）
到高潮了：让 Codex 真正改一次代码。这一节是整篇的命门，开头我那一小时就栽在没做好它。
接着上面的会话，直接敲：
text
给 main.py 里的 add 函数加上类型注解，并补充基本的错误处理这里得先把一个新手最容易误会的点说清楚——默认档下，改工作区里的文件这件事，Codex 是直接动手的，不会每改一个文件都停下来弹窗等你点同意。 为啥？02 讲过，默认的 Auto 档（workspace-write 沙箱 + on-request 审批）里，在工作区圈内读文件、改文件、跑命令都算「圈内动作」，沙箱本来就是为这个放开的，所以照做不打扰你；只有「出圈」的动作——比如改工作区之外的文件、要联网——才会停下来先问你。换句话说，它的默认节奏是：
- 找到该改的文件（这里是
main.py），直接在沙箱里把改动落下去 - 把这次改了什么，以 diff（差异对比）的形式摆给你看——终端里直接打印，你也能随时
git diff复查 - 你来事后把关：扫一眼 diff，对就留着；不对就让它改回去、或者用 Git 退回（下两节细讲）
那「审 diff」还重要吗？太重要了——它只是从「改前批准」挪到了「改后复查」。 Codex 把改动落盘 + 同步把 diff 摊在你面前，你这一眼扫下去就是质量关；真发现改错了，工作区里的改动你还没 commit，一条命令就能退回去。所以默认档不是「不让你把关」，而是「先改给你看、你靠 diff 和 Git 兜底」。
类比：同事先把改动提交到一个临时分支，再喊你过来看。 他没等你点头就动了手，但东西全在分支上、没合进主干——你扫一遍他改的地方，满意就合，不满意一句「这块退回去」就抹掉。Codex 默认就是这种「先改、改完摊给你看、你拿 diff 和 Git 决定去留」的同事，而那份摊给你看的东西就是 diff。
⚠️ 想要「改之前先停下来问我 / 先只出方案不动手」的体验？那不是默认档，得你主动调严：在会话里
/permissions切到read-only（只读只分析、要动手先问），或者干脆第一句就说「先别动手，列个方案给我」。默认的 Auto 档是放它直接改、你事后把关。
怎么看懂一个 diff
diff 就是「改之前」和「改之后」的逐行对照，看懂它只需记一条：
-开头 / 红色的，是要删掉的旧行+开头 / 绿色的，是要加上的新行- 没标记的，是没动的上下文，给你定位用的
你这次的 main.py 大概会从：
python
def add(a, b):
return a + b变成类似这样（具体写法 Codex 每次可能略有不同，意思对就行）：
python
def add(a: float, b: float) -> float:
if not isinstance(a, (int, float)) or not isinstance(b, (int, float)):
raise TypeError("a 和 b 必须是数字")
return a + b加了类型注解（a: float），也加了基本的错误处理（传进来不是数字就报错）。你扫一遍 diff，问自己三个问题就够了：
- 它改的是不是我让它改的那块？（别像我那样，让它改 A，它顺手动了 B）
- 加进来的逻辑，我看得懂、认可吗？
- 有没有删掉我其实想留的东西？
三个都「是」，这版改动留着；有一个「不对」，就补一句话让它改、或者 Git 退回（下两节讲怎么补、怎么退）。这一遍扫描，就是「审 diff」——前后不到十秒，却是新手和老手最大的分水岭。
什么时候它才会停下来问你
默认 Auto 档下，在工作区里改文件不弹审批，所以这次加类型注解你多半看不到「同意 / 拒绝」的弹窗——改完直接落盘、diff 打在终端里。那「同意 / 拒绝」的提示在什么时候才冒出来？答案是它要干一件出圈的事的时候——典型就这几类：
| Codex 想干的事 | 默认 Auto 档下 | 你会看到的提示 |
|---|---|---|
| 在工作区里读 / 改文件 | 直接做，不打扰你 | 一般没有弹窗，改完给 diff |
| 在工作区内跑命令（如测试） | 直接跑，不打扰你 | 一般没有弹窗 |
| 需要联网或出圈的命令（如装包） | 停下来先问 | 「同意 / 拒绝」让你点 |
| 改工作区之外的文件、要联网 | 停下来先问 | 「同意 / 拒绝」让你点 |
真碰到这个「同意 / 拒绝」提示时，照着选就行：看懂了、放心 → 同意；不对劲 → 拒绝并补一句说清哪不行（下一节讲）。不同入口文案略有出入，有的还给你一个「同意且本次不再问」的提速选项。
给新手的一条铁律：刚上手别图省事把档位调到最松（比如 never 或完全访问）。 这话我用一小时的代价换来的——一旦放到最松，它连出圈动作都不问了，在你没细看的情况下一口气改五六个文件，等你反应过来，已经分不清哪个改动是你要的、哪个是它自作主张加的了。教训就一条：越是不熟，越要保留那道「出圈先问 + 事后审 diff」的关卡。
⚠️ 沙箱模式和审批策略都是可调的（02 讲过
read-only/workspace-write和on-request/never，15 权限详解 还会细讲）。往严了调（如read-only），它连改文件都要先问你；往松了调（如never/ 完全访问），连出圈动作都不拦——放开权限前，先确认你真的信得过当前这摊活。
💡 一句话总结：默认档下 Codex 在工作区里直接改、改完把 diff 摊给你看，只有出圈的动作才停下来问你；审 diff 就扫三件事——改对地方没、逻辑认不认、删错东西没；第一次别把档位调到最松，留住那道把关。
这张图把这一节的逻辑摊平了看：提需求 → Codex 分析 → 在沙箱里改文件，工作区圈内的动作（绿色那条主线）直接落盘、不每次问你；只有「出圈动作」（改圈外文件、联网）才拐去右边那条红线停下来问。改完落到「审 diff」这个岔口——满意就往下 git commit 留住，有问题就补句话让它改、或 git restore 退回，绕回去重改一版。
05 拒绝不是终点：补一句话，让它重来
新手常有个误会：以为「拒绝」就是把这事黄了、得从头再来。不是。拒绝其实是一次「换个方向再来」的机会。
Codex 在一个**线程（Thread）**里干活——官方定义：一个线程就是一次会话，你的提问加上后续的模型输出和工具调用，一个线程里可以有好多轮对话。所以无论是当场拒绝了它的某个出圈请求，还是看完 diff 觉得改得不对，这次会话的上下文都还在，你直接补一句，它就顺着改。
类比：点菜上来不合口，你不用换家餐厅，跟服务员说一声「这个太咸了，重新做一份淡点的」就行。 整桌菜的语境、你之前的要求，厨房都还记着，改的只是你不满意那一点。看完 diff 不满意、补句话让它重来，就是这个「退回去重做」的动作，成本极低。
举个我上周真碰到的：让 Codex 给一个函数加缓存，它 diff 里顺手引入了一个我项目里没装的第三方库。我没批准，直接补了一句：
text
别引第三方库，用 Python 标准库 functools.lru_cache 实现就行它立马撤回原方案，换成标准库重写了一版 diff，这回干净利落，我才点的同意。全程没退出会话、没重头解释需求——这就是「拒绝 + 补话」的顺滑之处。
所以记住这个心态转变：
| ❌ 新手以为 | ✅ 实际上 |
|---|---|
| 拒绝 = 这次白干了 | 拒绝 = 让它换个方向再来一版 |
| 不满意只能自己上手改 | 用大白话说清哪不对，它重写 |
| 每次不行都得重启会话 | 同一线程里多轮迭代，上下文还在 |
💡 一句话总结：看完 diff 不满意（或当场拒了某个请求）不是终点，而是「退回去重做」——在同一个线程里补一句话说清哪不对，Codex 顺着改，不用退出、不用从头解释。
06 改错落地了怎么办：Git 是你最硬的后悔药
万一你像开头的我一样，没细看就点了同意，改动已经落盘了——慌不慌？不慌，只要你提前做了一件事：打 Git 检查点。
这是 Codex 官方在快速上手里给的一条建议，大意是：「Codex 会改你的代码库，建议在每个任务前后各创建一个 Git 检查点，这样需要时能轻松回退。」注意——它讲的后悔药就是 Git，不是什么工具内置的撤销。
类比：打硬仗前先存盘。 你在 Boss 战前手动存个档，打输了不用从头通关，读档回到存档点就行。git commit 就是你在让 Codex 动手前，亲手存的那个档——它改炸了，你一行命令就能读档回去。
具体怎么做？让 Codex 动手之前，在项目目录里跑（只在第一次需要 git init）：
bash
git init
git add -A && git commit -m "codex 动手前的存档点"万一改炸了、想整个退回到动手前那一刻：
bash
git restore .⚠️
git restore .会丢弃工作区里所有未提交的改动，退回到你上一次 commit 的样子。只在你确实想全部放弃 Codex 这轮改动时用；要是有一部分改对了想留，就别一刀切，改用下一段的细办法。
如果只是某几处不满意，最省事的还是回到会话里用大白话让它改回去——它记得这个线程里干过什么：
text
刚才那次改动我不满意，帮我退回到改之前的样子把两条后悔药摆一起，你按场景挑：
| 后悔药 | 怎么用 | 适合场景 | 局限 |
|---|---|---|---|
| 会话里说「改回去」 | 直接打字告诉 Codex | 刚改完、就一两处不满意 | 依赖它理解你的意思，非永久 |
| Git 回退 | 动手前 commit，炸了 git restore . | 想干净利落退回某个确定状态 | 得提前存档，restore 是一刀切 |
我的铁律：让 Codex 碰任何稍微重要点的代码前，先 git commit 存一档。 这习惯救过我不止一次——有回它把一个配置文件改得面目全非，我连看的耐心都没有，直接 git restore 退回去重新提需求，三秒钟的事。Git 才是你最硬的那块底牌。
💡 一句话总结：Codex 改炸了别慌——动手前
git commit存档，炸了git restore .一键读档；小修小补回会话里说「改回去」，但真正的进度，永远交给 Git 兜底。
07 动手（一）：CLI 五分钟跑通全流程
光看不练假把式。这一节把前面串成一条能照着敲、有预期输出的完整流程，走的是 CLI。打开终端，跟着走。
第一步：建玩具项目并打 Git 存档（Mac / Linux）
bash
mkdir hello-codex && cd hello-codex
echo 'def add(a, b):
return a + b' > main.py
git init && git add -A && git commit -m "初始版本"Windows 用户：前两行 mkdir / cd 照敲，main.py 用记事本新建贴入那两行 Python，git 三连命令一样跑。
预期：hello-codex 里有个 main.py（那两行 add 函数），且已经有一次 Git 提交。可以 ls（Windows 用 dir）确认文件在。
第二步：在项目目录里启动 Codex
bash
codex预期：出现 Codex 的交互界面，底部是输入框和光标。如果提示你登录，说明前面登录没完成，回 03 安装与登录 把登录走一遍。
⚠️ 一定要在项目目录里启动
codex，别在桌面或家目录裸启。 Codex 把你当前所在的目录当工作区——你在哪启动，它就读哪儿、在哪儿动手。这是新手最常踩的第一个坑。
第三步：让它解释代码（零风险试水）
text
解释 main.py 这个文件在做什么，用新手能听懂的话说预期：Codex 读取 main.py ，用大白话告诉你这是个「把两个数相加」的函数。看到它准确说出 add 函数的作用 = 它真读到了你的文件，成功。
第四步：让它改代码，然后审 diff
text
给 main.py 里的 add 函数加上类型注解，并补充基本的错误处理预期：默认档下 Codex 直接把 main.py 改掉，并把这次改动以 diff（红 - 旧行、绿 + 新行）打印在终端里。按第 04 节那三问扫一遍 diff。要是它中途要跑命令或干出圈的事，会冒出「同意 / 拒绝」让你点——看懂了再同意。
第五步：回终端确认改动落地
退出 Codex（退出按 Ctrl + C 或输入 /exit，以界面提示为准），回到终端看文件：
bash
cat main.py（Windows PowerShell 用 type main.py ）
预期：main.py 里出现了类型注解（像 a: float ）和错误处理（raise TypeError(...) ）。和你刚才批准的 diff 对得上 = 全流程跑通，恭喜！
想再确认一遍 Codex 到底改了哪几行，Git 给你一个上帝视角：
bash
git diff预期：终端打印出和你刚才在 Codex 里看到的那份 diff 基本一致的内容。两边对得上，说明「你看到的」就是「它改的」，踏实了。
💡 一句话总结：CLI 全流程五步——建项目存档 →
codex启动 → 解释代码试水 → 改代码并审 diff → 回终端用cat/git diff验收；记得在项目目录里启动，记得改前先 Git 存档。
08 动手（二）：桌面 App 走一遍同样的活
不爱碰终端的，桌面 App 把同样的流程做成了点点点。注意：桌面 App 目前只有 macOS 和 Windows，Linux 暂时没有（Linux 用户走上面 CLI 那条路）。
App 的整体节奏和 CLI 一模一样，就是把「敲命令」换成了「点界面」，核心那个「看 diff 验收」一步不少。按官方快速上手的步骤走：
- 打开 Codex App，登录——用 ChatGPT 账号或 OpenAI API key （03 讲过两者区别）。
- 选项目文件夹——挑一个你想让 Codex 干活的目录。第一次练手就选刚才那个
hello-codex（或随便建个玩具目录）。之前用过 App / CLI / IDE 扩展的话，这里会列出历史项目。 - 确认选的是 Local——官方强调：发第一条消息前，确保选的是 Local（具体位置以你界面实际显示为准），让 Codex 在你本机干活，而不是云端。这一步新手最容易忽略。
- 发第一条消息——在输入框里打需求，跟 CLI 里一字不差地来：
text
解释 main.py 这个文件在做什么，用新手能听懂的话说确认它读懂了，再发改代码那句：
text
给 main.py 里的 add 函数加上类型注解，并补充基本的错误处理预期：默认 Local 档下，App 同样会直接把改动落到你的项目里，然后在审查面板（review pane）里把这次改了什么一行行高亮给你看——官方说这个面板反映的是你 Git 仓库里尚未提交的改动，也就是改完之后的复盘视图。这正是 App 比 CLI 舒服的地方——图形化的 diff 看得更清楚，旁边还有暂存、提交、回退的按钮。看完满意，直接在面板里提交；不满意，让它改回去或退掉。
官方在快速上手的 CLI / IDE 那两条里都建议你改前后各打一个 Git 检查点，方便随时回退；App 这边内置了 Git 功能，看完 diff 你可以在界面里直接暂存、提交。
CLI 和 App 到底选哪个？给你一张对照表，按自己的习惯挑：
| 维度 | CLI（命令行） | 桌面 App |
|---|---|---|
| 平台 | ✅ Mac / Windows / Linux 全有 | ❌ 仅 Mac / Windows |
| 上手门槛 | 要敲命令，怕终端的人发怵 | ✅ 点点就行，对小白友好 |
| 看 diff | 终端里文本 diff，够用 | ✅ 图形面板，更直观 |
| 多任务并行 | 开多个终端窗口 | ✅ 多项目并排切换，体验更顺 |
| 核心流程 | 提需求 → 它改 → 审 diff 验收 | 完全一样，只是换成点界面 |
我自己的用法：写代码、跑命令我常驻 CLI（顺手、跨平台）；但遇到改动多、diff 长的活，我会切到 App 里审 diff，那个图形面板一行行看，比在终端里翻文本舒服不少。一次登录后两端一般都能用（具体以官方鉴权说明为准），挑你顺手的。
💡 一句话总结：桌面 App 把同样的活做成点点点（仅 Mac / Windows），发消息前记得选 Local；它的图形审查面板看长改动更舒服，但「Codex 改完、你审 diff 验收」这个核心动作，和 CLI 一模一样。
09 全流程一张图
把这一篇的完整闭环，用一张图收个尾——不管你走 CLI 还是 App，跑的都是这一圈：
这张图最该盯住的是中间那个审 diff 岔口：Codex 在沙箱里把改动落下去、同步摊出 diff，你看懂了就留着、看着不对就让它改回去或 Git 退回——这个「人来把关」的环节，就是你和 Codex 协作的安全阀。开头我那一小时，丢的就是这一步。
💡 一句话总结：整个第一个任务，核心就一个闭环——提需求 → Codex 在沙箱里改 → 你审 diff → 留下或退回；把「审 diff」这一步焊死在流程里，你就再不会重蹈我那场翻车。
10 小结
这一篇你干了一件实事：完整跑通了 Codex 的第一个任务——从建项目、启动，到解释代码、改代码、审 diff 验收，CLI 和 App 两条路都走了一遍。
把核心动作串起来回顾：
| 步骤 | 动作 | 关键点 |
|---|---|---|
| 建项目 | mkdir + 建文件 + git commit | 先用玩具练手，动手前先存档 |
| 提需求 | 用大白话，越具体越好 | 大活先让它出方案，别埋头改 |
| 解释 | 「解释 xxx 文件」 | 零风险，先确认它读到了文件 |
| 改代码 | 「给函数加类型注解……」 | 默认档直接改、同步摊出 diff，你事后把关 |
| 审 diff | 扫三问：改对没·认不认·删错没 | 新手和老手的分水岭，别跳过 |
| 反悔 | 「改回去」/ git restore . | Git 是最硬的后悔药 |
你现在应该能：在 CLI 或 App 里启动 Codex、用自然语言让它读懂并修改一段代码、看懂它给的 diff 并决定留下还是退回、知道改错了怎么退回去。
这套动作——提需求 → 看 diff → 留下 / 退回 / 反悔——就是你之后所有 Codex 使用的最小内核。后面再花哨的功能（MCP、子代理、技能、自动化……），本质都是在这个循环上做加法。而那个最该刻进肌肉记忆的动作，永远是「审 diff」——别像开头的我，用一小时去换这个教训。
💡 一句话总结：第一个任务的最小内核就一句——提需求 → Codex 改 → 你审 diff → 留下或退回；默认档是放它直接改、你靠 diff 和 Git 事后兜底，要「改前先问」就主动切到更严的档。
下一篇 07 · 桌面 App 全景——这篇你已经在 App 里浅尝了一次，但桌面端能干的远不止改代码：多项目并行、worktree 隔离、内置浏览器、自动化任务……下一篇带你把桌面 App 这张脸看个全。先想个问题：你刚在 App 里审 diff 时，有没有觉得那个图形面板比终端舒服？如果是，下一篇你大概率会爱上它。