我跑通第一个 Codex 任务的全过程，以及踩的那些坑

装完 Codex 那天晚上，我挺兴奋的。打开终端，cd 进公司的正式项目，输入了一句现在想想都觉得鲁莽的话：

帮我重构一下用户模块。

然后我就看着它一口气改了十几个文件——登录、权限、接口、测试、前端页面全动了。改完之后它告诉我"已完成"，我看着满屏的 diff，完全不知道哪些是必要的改动，哪些是它的"自由发挥"。

那次体验给我最大的教训就是：第一天用 Codex，目标不应该是"让它证明自己很强"，而是让自己理解它怎么读文件、怎么改文件、怎么展示 diff、怎么被你纠正。

所以我后来重新来了一次，用一个只有几行代码的玩具项目。这篇文章就是那次完整过程的复盘。

从一个只有一行逻辑的文件开始

我先建了一个干净的目录：

mkdir hello-codex
cd hello-codex

然后创建了一个 main.py，内容就这几行：

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

为什么选这么简单的？因为只有这样，后面 Codex 改了什么我才能一眼看懂。你看不懂的 diff，就不是你能审查的 diff。

紧接着做了一件到现在都觉得最重要的事——打一个 Git 检查点：

git init
git add -A
git commit -m "init: hello codex demo"

后来我才知道，没有这一步的话，Codex 改坏文件时你连回退的地方都没有。Git 检查点就是你和混乱之间最后那道防线。

我做的第一件事：让它只读，不让它动手

启动 Codex 之后，我的第一条消息是：

请解释 main.py 这个文件在做什么，用新手能听懂的话说。不要修改任何文件。

这一步看起来多余，但其实验证了三件事：Codex 能正常启动、它能读到当前目录的文件、它理解的内容和我理解的是否一致。

如果它连一个 add 函数都解释错了，你就该警惕了——可能是当前目录不对，也可能是项目结构比它预想的复杂得多。总之，先确认它站在正确的起点上，再让它跑。

让它改一个很小的东西

确认它能正常读项目之后，我才给了第一个修改任务：

请给 main.py 里的 add 函数加上类型注解，并在传入非数字时抛出 TypeError。

要求：
1. 只修改 main.py。
2. 不要新增第三方依赖。
3. 改完后告诉我你改了哪几行。

这个任务满足三个条件：范围小（只改一个文件）、结果清楚（函数签名和错误处理会变化）、容易审查（你能看懂 diff）。

它改出来的结果大概是这样的：

def add(a: float, b: float) -> float:
    if not isinstance(a, (int, float)) or not isinstance(b, (int, float)):
        raise TypeError("a and b must be numbers")
    return a + b

别只看它说什么，要看它改了什么

这是我觉得很多人会忽略的一步。Codex 改完之后会告诉你"完成了"，有时候还会给你一个修改摘要。但摘要不能替代 git diff。

我跑了一下：

git diff

然后问自己三个问题：它是不是只改了 main.py？它新增的逻辑我能不能看懂？有没有出现我没要求的改动？

三个问题都没问题，那这次就算成功了。

说实话，我第一次看到 diff 的时候有个小惊喜：它确实只动了 main.py，没有"顺手"给你加个 __init__.py 或者改个 .gitignore。这说明任务范围写清楚，它是会遵守的。

不满意？在同一个会话里纠正就好

后来我试了一个场景：假设我不满意它的错误提示是英文的，我直接在同一个会话里说：

刚才的错误提示用中文，并且不要改变函数名。请重新调整。

它会基于当前上下文继续改。不需要退出，不需要重开会话，不需要从头来。这一点比我预期的方便很多。很多工具需要你重来，但 Codex 更像是"在对话里持续协作"。

让它补个测试，然后跑验证

代码改完之后，我让它补了一个最小测试：

请为 add 函数创建一个最小测试文件 test_main.py。

要求：
1. 使用 Python 标准库 unittest。
2. 覆盖正常相加和非数字报错两个场景。
3. 不要引入第三方测试框架。

然后跑：

python -m unittest

测试通过了。但如果没通过，我也不会慌。把报错直接交给 Codex：

刚才运行 python -m unittest 失败，错误如下：<粘贴报错>。请先解释原因，再做最小修复。

这就是 Codex 真正好用的地方——你可以让它在"修改 -> 验证 -> 修正"的循环里持续推进，而不是一次交付就结束了。

改坏了怎么办？

有 Git 检查点就不慌。放弃所有未提交改动：

git restore .

如果还新增了文件想一起删掉：

git clean -fd

但这两个命令要谨慎。执行前先看 git status，确认你确实要丢弃那些改动。新手可以让 Codex 先解释：

请解释 git restore . 和 git clean -fd 会删除什么。不要执行命令。

理解了再动手，这个习惯会让你少很多"啊我的代码呢"的时刻。

确认没问题，保存这次成果

最后提交：

git add -A
git commit -m "feat: add type checks for add"

到这里，我跑通了 Codex 最核心的工作闭环：

提出小需求 -> Codex 修改 -> 你审 diff -> 运行验证 -> Git 保存

回过头来看，什么让我意外？

有几个点是我之前没想到的。

第一，任务越小，Codex 表现越好。这不是它能力不行，而是小任务意味着更少的歧义。你让一个人"优化用户模块"和"给 add 函数加类型注解"，哪个更容易做对，不言而喻。

第二，git diff 比 Codex 的总结更可信。Codex 会给你一段友好的文字说明"我做了什么"，但文字是可以美化甚至遗漏的。diff 是硬事实，一行一行地摆在那里。

第三，在同一个会话里纠正它，比重新开一个会话高效得多。因为上下文还在，它知道之前改了什么、你为什么不满意。

我后来把这个节奏用到了真实项目里：先让它只读解释一个模块，然后改一个小函数，再补一个测试。三次练下来，我对它的协作方式就有了直觉。

不需要一口气做十件事。你要练的是"可控地使用 Codex"，而不是测试它能不能一次完成大项目。 这个心态转变，可能是跑通第一个任务最大的收获。