首页 / Codex 教程 / 第一个任务

Codex 教程

第一个任务

本教程共 32 篇 · 第 5 篇 · 更新于 2026-07-26 · 约 8 分钟阅读

CodexCodex 教程第一个任务diffGit检查点审批沙箱

5. 第一个任务

本节目标:完整跑通从启动 codex、发送消息、查看 diff、到 Git 回滚的闭环,拿到第一次成功体验。

别拿正式项目练手

第一次用 Codex,千万别拿你的正式仓库开刀。先建个三行代码的玩具项目。

正式项目文件多、依赖杂,Codex 一上来读半天,它改了什么你根本看不过来。而你恰恰是在「看不过来」的时候最容易瞎点同意。玩具项目就两三行,它动了哪个字你一眼能逮住。

打开终端,建个玩具目录:

mkdir hello-codex
cd hello-codex

塞一个最简单的 Python 文件进去:

echo 'def add(a, b):
    return a + b' > main.py

Windows 用户直接用记事本新建一个 main.py,把下面两行贴进去:

def add(a, b):
    return a + b
Tip

玩具项目就是你的「空巷子」—改砸了删掉重建,三十秒的事,心一点不慌。

启动 Codex

在项目目录里启动 Codex:

codex
Warning

一定要在项目目录里启动 codex,别在桌面或主目录裸启。Codex 把你当前所在的目录当工作区—你在哪启动,它就读哪儿、在哪儿动手。

第一次启动会引导你登录(按上一章走完登录)。登录后看到欢迎界面和输入框。

先让它解释代码

第一个任务建议先让它解释代码,而不是改代码。两个理由:一是确认 Codex 真读到了你的文件,不是在凭空瞎编;二是解释类任务零风险,它只读只说,不动你一个字。

在输入框里敲(用大白话,不用记格式):

解释 main.py 这个文件在做什么,用新手能听懂的话说

回车。Codex 会自己去读 main.py—你不用手动把文件喂给它。然后它给你一段大白话,大意是:这里定义了一个 add 函数,收两个参数,返回相加的结果。

这一步跑通意味着两件事:Codex 装对了、登录态正常,而且它确实在读你机器上的真实文件。

Note

把对 Codex 的指令分三类记:解释型(零风险,不动文件)、修改型(会动文件,要审 diff)、生成型(会建或改文件,要审 diff)。

让它改代码,然后审 diff

接着上面的会话,直接敲:

给 main.py 里的 add 函数加上类型注解,并补充基本的错误处理

默认档下,Codex 在工作区里改文件是直接动手的,不会每改一个文件都停下来弹窗等你点同意。它改完会把这次改了什么以 diff(差异对比)的形式摆给你看。

你的 main.py 大概会从:

def add(a, b):
    return a + b

变成类似这样:

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

怎么看懂一个 diff

diff 就是「改之前」和「改之后」的逐行对照,看懂它只需记一条:

  • - 开头 / 红色的,是要删掉的旧行
  • + 开头 / 绿色的,是要加上的新行
  • 没标记的,是没动的上下文

扫一遍 diff,问自己三个问题就够了:

  1. 它改的是不是我让它改的那块?
  2. 加进来的逻辑,我看得懂、认可吗?
  3. 有没有删掉我其实想留的东西?

三个都「是」,这版改动留着;有一个「不对」,就补一句话让它改或 Git 退回。

Warning

审 diff 是新手和老手最大的分水岭。跳过这一步直接提交,迟早翻车—它可能「自作主张」顺手改了你没要求的逻辑。

什么时候它会停下来问你

默认 Auto 档下,在工作区里改文件不弹审批。只有它要干一件出圈的事时才停下来问:

Codex 想干的事默认 Auto 档下你看到的提示
在工作区里读 / 改文件直接做,不打扰你一般没有弹窗
在工作区内跑命令直接跑一般没有弹窗
需要联网或出圈的命令停下来先问同意 / 拒绝
改工作区之外的文件停下来先问同意 / 拒绝

真碰到这个提示时,看懂了就同意,不对劲就拒绝并补一句说清哪不行。

拒绝不是终点

看完 diff 不满意,不是「这次白干了」。Codex 在同一个线程里干活,上下文都还在,你直接补一句让它改就行。

比如它引了一个你项目里没装的第三方库,你没批准,直接补一句:

别引第三方库,用 Python 标准库 functools.lru_cache 实现就行

它立马撤回原方案,换成标准库重写了一版。全程没退出会话、没重头解释需求。

Git 检查点回滚

万一你没细看就点了同意,改动已经落盘了—别慌,只要你提前做了一件事:打 Git 检查点。

让 Codex 动手之前,在项目目录里跑(只在第一次需要 git init):

git init
git add -A && git commit -m "codex 动手前的存档点"

万一改炸了,想整个退回到动手前那一刻:

git restore .
Warning

git restore . 会丢弃工作区里所有未提交的改动,退回到你上一次 commit 的样子。只在你确实想全部放弃时用。要是有一部分改对了想留,就别一刀切,回会话里用大白话让它改回去。

完整流程走一遍

把上面的步骤串成一条完整的流程:

  1. 建玩具项目并打 Git 存档
mkdir hello-codex && cd hello-codex
echo 'def add(a, b):
    return a + b' > main.py
git init && git add -A && git commit -m "初始版本"
  1. 在项目目录里启动 Codex
codex
  1. 让它解释代码(零风险试水):
解释 main.py 这个文件在做什么,用新手能听懂的话说
  1. 让它改代码,然后审 diff
给 main.py 里的 add 函数加上类型注解,并补充基本的错误处理
  1. 回终端确认改动落地

退出 Codex(Ctrl + C/exit),回到终端看文件:

cat main.py

想确认 Codex 到底改了哪几行,用 Git 给你一个上帝视角:

git diff
Tip

两边对得上,说明你看到的 diff 就是它实际改的,踏实了。

小结

第一个任务的核心就一个闭环:

提需求 -> Codex 在沙箱里改 -> 你审 diff -> 留下或退回

关键动作回顾:

步骤动作关键点
建项目mkdir + 建文件 + git commit先用玩具练手,动手前先存档
提需求用大白话,越具体越好大活先让它出方案,别埋头改
解释「解释 xxx 文件」零风险,先确认它读到了文件
改代码「给函数加类型注解」默认档直接改、同步摊出 diff
审 diff扫三问:改对没、认不认、删错没新手和老手的分水岭
反悔「改回去」/ git restore .Git 是最硬的后悔药

这套动作就是你之后所有 Codex 使用的最小内核。后面再花哨的功能,本质都是在这个循环上做加法。而那个最该刻进肌肉记忆的动作,永远是审 diff。

下一章咱们讲配置文件 config.toml,把那些每次都要手动调的开关写成永久默认。