第一个任务

前面几页装好了 Codex、接好了模型。这一页带你完整走一遍真实的工作流程：准备一个小项目，让 Codex 先读懂它，再修一个 bug、补测试，你来审改动、提交代码。整个过程大约二十分钟，用到的东西以后每天都会用。

示例用 Python 标准库写，不需要装任何依赖。电脑上没有 Python 的话，把示例换成你熟悉的语言也一样，重点是流程。

第一步：准备项目和 Git

新建一个文件夹并初始化 Git：

bash

mkdir ~/codex-first-task && cd ~/codex-first-task
git init

为什么一定要用 Git

Codex 会直接修改文件。有了 Git，你随时能用 git diff 看它改了什么，用 git restore 撤销不满意的改动。Codex 的 /diff、/review 也依赖 Git。在没有版本管理的目录里让智能体改代码，是新手最常见的翻车原因。

创建两个文件。stats.py 是一个小工具函数，里面藏着一个 bug：

python

# stats.py
def average(numbers):
    """返回一组数字的平均值。"""
    return sum(numbers) / len(numbers)


def describe(numbers):
    """返回最小值、最大值和平均值组成的字典。"""
    return {
        "min": min(numbers),
        "max": max(numbers),
        "avg": average(numbers),
    }

test_stats.py 是现有的测试：

python

# test_stats.py
import unittest
from stats import average, describe


class TestStats(unittest.TestCase):
    def test_average(self):
        self.assertEqual(average([1, 2, 3]), 2)

    def test_describe(self):
        self.assertEqual(describe([4, 8]), {"min": 4, "max": 8, "avg": 6})


if __name__ == "__main__":
    unittest.main()

先自己跑一遍测试，再做第一次提交，作为干净的起点：

bash

python3 -m unittest -v
git add . && git commit -m "初始版本"

第二步：启动 Codex

在项目目录里运行：

bash

codex

第一次在这个目录启动，会先看到信任提示，大意是「信任这个文件夹吗？Codex 可以在这里读取、编辑和运行文件」。选 Trust and continue。信任决定会被记住，下次不再询问；项目里的 .codex/config.toml、钩子等项目级配置也只在信任后才生效。

只信任你自己的项目

从网上克隆的陌生仓库里可能带有项目级配置和钩子。不熟悉的仓库可以选择受限方式打开，先看看里面有什么。

进入后你会看到这些界面元素：

区域	作用
顶部 / 消息区	显示对话、Codex 的思考摘要、它运行的命令和输出、修改的文件
输入框	底部，输入你的请求，`Enter` 发送
状态行	输入框下方，显示模型、上下文剩余、当前目录等
提示行	按 `?` 可以查看所有快捷键

第三步：先问，别急着让它改

第一句话不要直接下命令，先让它读懂项目。这样既能确认它理解对了，你也能顺便检查模型是否接通：

text

这个项目是做什么的？有哪些函数和测试？你觉得哪里有潜在问题？先不要修改任何文件。

Codex 会去列目录、读文件，然后给你总结。一个合格的回答应该指出：average 传入空列表时会因为除以零报 ZeroDivisionError，describe 传入空列表时 min() 也会报错。

你会在消息区看到它运行的每一个命令（比如列目录、查看文件内容）。这些只读操作在默认权限下不需要你批准。

用 @ 引用文件

在输入框里输入 @，再敲几个字母，会弹出文件搜索，选中后文件路径会插入到消息里。明确告诉它看哪个文件，比让它自己找更快更准。

第四步：让它修改

现在给出一个具体、可验证的任务：

text

修复空列表的问题：
1. average([]) 返回 None，不要抛异常
2. describe([]) 返回 {"min": None, "max": None, "avg": None}
3. 在 test_stats.py 里为这两种情况各补一个测试
4. 改完运行 python3 -m unittest -v，确认全部通过
不要修改其他行为。

这个提示有几个好习惯：说清期望结果、列出验收方式（跑哪个命令）、划定边界（不改其他行为）。

看它的计划和过程

Codex 通常会先简短说明打算怎么做，然后开始改文件、跑测试。每次改文件，消息区都会显示改动摘要（哪些行增删）。如果测试失败，它会读报错继续修，直到通过或者需要你决定。

在它干活的过程中：

发现方向不对，按 Esc 打断，然后告诉它正确的做法；
想补充要求，直接输入，按 Tab 排队，当前步骤结束后它会看到；
按 Ctrl+T 可以查看完整的执行记录。

审批

使用默认权限（Default）时，Codex 可以直接修改工作目录里的文件、运行本地命令，所以这个任务你可能一次审批都不会遇到。当它要做超出范围的事情时——联网安装依赖、写工作目录外的文件、修改 .git 目录（比如提交代码）——会弹出审批框：

选项	含义
Yes, proceed	这次允许
Yes, and don't ask again ...	本次会话（或以该前缀开头的命令）以后不再询问
No, and tell Codex what to do differently	拒绝，并告诉它换个做法

看清楚命令再批准，尤其是 rm、git push、curl ... | sh、安装软件这类命令。想体验每一步都审批，可以输入 /permissions 切到 Read Only 再重做一遍。权限的完整说明见沙箱与审批。

第五步：看 diff

它说改完了，不要直接相信，自己看改动：

text

/diff

/diff 会显示当前的 Git 改动，包括新建但还没被 Git 跟踪的文件。逐行看一遍：

改动是否只涉及 stats.py 和 test_stats.py？
average 的修改是否只处理了空列表，没有改变正常输入的结果？
新测试是否真的覆盖了两种空列表情况？

在另一个终端窗口里运行 git diff 效果一样。不满意的地方直接告诉它，比如「describe 里不要重复判断空列表，复用 average 的逻辑」。

第六步：自己跑测试

它说测试通过了，你也跑一次。不用退出 Codex，在输入框里以 ! 开头可以直接执行 shell 命令：

text

!python3 -m unittest -v

应该看到 4 个测试全部通过。养成习惯：验证结果以你亲眼看到的输出为准。

第七步：让它审查一遍

text

/review

会弹出几个审查范围：对比某个基础分支、审查未提交的改动、审查某个提交，或者输入自定义的审查要求。这里选 Review uncommitted changes。Codex 会以审查者的视角重新读一遍改动，按严重程度列出问题。这一步能抓住不少「写的时候没注意」的问题，比如漏掉的边界情况、命名不一致。审查用的模型由配置里的 review_model 决定。

第八步：提交

确认没问题后提交。建议自己在终端里执行，你最清楚这次改了什么：

bash

git add stats.py test_stats.py
git commit -m "处理空列表输入并补充测试"

也可以让 Codex 帮你写提交信息并提交，但因为 .git 目录默认在沙箱里是只读的，它执行 git commit 时会请求审批。

到这里你已经完成了一个标准循环：提问 → 下任务 → 观察 → 审 diff → 验证 → 审查 → 提交。之后无论任务大小，都是这个节奏，只是每一步的内容更多。

交互界面速查

操作	方法
发送消息	`Enter`
输入框内换行	`Ctrl+J`（多数终端里 `Shift+Enter` 也可以）
引用文件	输入 `@` 后搜索
打开命令菜单	输入 `/`
执行 shell 命令	以 `!` 开头，如 `!git status`
粘贴图片	复制截图后 `Ctrl+V`，或启动时 `codex -i 截图.png`
打断 Codex	`Esc`
编辑上一条消息	输入框为空时按 `Esc`，再按一次进入编辑
运行中追加消息	输入后按 `Tab` 排队
翻历史输入	`↑` / `↓`；`Ctrl+R` 搜索历史
查看完整记录	`Ctrl+T`
用外部编辑器写长消息	`Ctrl+G`
调整推理强度	`Alt+,` 降低，`Alt+.` 提高
退出	`/quit`，或连按两次 `Ctrl+C`

快捷键可以用 /keymap 修改，完整的斜杠命令见斜杠命令。

下次接着做：恢复会话

关掉终端后，会话记录还在。回到项目目录：

bash

codex resume            # 弹出会话列表，选一个继续
codex resume --last     # 直接继续最近一次
codex resume --all      # 列出所有目录的会话，不只是当前目录

会话内输入 /resume 效果相同。恢复后 Codex 能看到之前的对话，但文件以磁盘上的当前内容为准；如果你中间手动改过代码，告诉它一声。

新手常犯的错误

错误	后果	正确做法
不用 Git 就开始	改坏了回不去	先 `git init` 并提交一次
在家目录或根目录启动	工作区过大，可能误改无关文件	在具体项目目录里启动
第一句就是「帮我做个完整网站」	结果难以检查，返工多	拆成小步骤，每步可验证
不给验收标准	它「觉得」完成了	说明跑哪个命令、期望什么输出
不看 diff 就提交	混入意外改动	每次提交前 `/diff` 或 `git diff`
为了省事直接选 Full Access	命令不受限，误操作代价大	用默认权限，需要时单次批准
一个会话塞十个话题	上下文被无关内容挤满，表现变差	换话题就 `/new`
把 API Key 贴进对话	Key 进入会话记录	Key 只放在配置文件或环境变量里

小结

先 git init 并提交，再在项目目录里启动 codex，只信任自己的项目。
先提问让它读懂项目，再给出带验收标准和边界的具体任务。
用 /diff 审改动、!命令 自己验证、/review 再查一遍，最后自己提交。
Esc 打断、Tab 排队、@ 引用文件、Ctrl+V 粘贴图片；codex resume 继续上次的会话。

下一步：提示词最佳实践，或者用 C 路线做一个完整的小项目。

第一个任务 ​

第一步：准备项目和 Git ​

第二步：启动 Codex ​

第三步：先问，别急着让它改 ​

第四步：让它修改 ​

看它的计划和过程 ​

审批 ​

第五步：看 diff ​

第六步：自己跑测试 ​

第七步：让它审查一遍 ​

第八步：提交 ​

交互界面速查 ​

下次接着做：恢复会话 ​

新手常犯的错误 ​

小结 ​

第一个任务

第一步：准备项目和 Git

第二步：启动 Codex

第三步：先问，别急着让它改

第四步：让它修改

看它的计划和过程

审批

第五步：看 diff

第六步：自己跑测试

第七步：让它审查一遍

第八步：提交

交互界面速查

下次接着做：恢复会话

新手常犯的错误

小结