交流群即将上线
03 · 跑通你的第一个任务
先挑对任务
第一个任务的标准只有一条：改完你能在一分钟内看出对错。
不是「重构这个模块」，不是「把测试覆盖率提上去」。这类任务它会干很久、 改一大片，然后你面对几百行 diff 不知道从哪看起，最后只能凭感觉点接受—— 这一次你什么也没学到。
好的第一个任务长这样：
- 「给
src/utils/date.ts里的formatRange补一个跨年区间的单元测试，只改测试文件。」 - 「
README里的安装步骤和package.json的 scripts 对不上，帮我核对并改README。」 - 「把
api/user.go里那三处重复的错误处理提成一个函数，行为不要变，跑一遍go test ./...。」
共同点：范围小、边界写死了（「只改测试文件」）、有明确的验收动作。
开跑
bash
cd ~/your-project
git status # 确认工作区是干净的
codex进去之后直接用中文说你要什么。第一句尽量把三件事说清楚：
- 改什么：具体到文件或函数。
- 别碰什么：明确划出红线。
- 怎么算完成：跑哪个命令、看到什么结果。
text
给 src/utils/date.ts 里的 formatRange 补单元测试，覆盖跨年的区间（比如 2025-12-28 到 2026-01-03）。
只改 src/utils/date.test.ts，不要动实现文件。
写完跑 npm test -- date.test，测试通过再告诉我。它跑的时候在干什么
你会看到它交替做几件事：读文件、提出改动、请求跑命令、看输出、继续。 这里有两个地方值得停下来看清楚：
一、请求审批的时候。 默认的 Auto 模式下，它在工作空间里读写、跑命令不用问你； 但要写工作空间之外的文件、或者要联网，就会停下来请求审批。 看到审批提示别习惯性回车——先看清楚它想干什么。
二、给出 diff 的时候。 这是你真正要审的东西。别看它的自然语言总结，看 diff 本身。
跑完之后自己再确认一遍：
bash
git diff # 它到底改了什么
npm test # 它说通过了，你自己跑一遍「它说测试通过了」不等于测试通过了
自己跑一遍。这是整套流程里最便宜的一次验证。
几个当场就有用的命令
在交互式会话里：
| 命令 | 干什么 |
|---|---|
/status | 看当前会话的状态，包括工作空间包含哪些目录 |
/permissions | 切换权限，比如临时改成 read-only 只讨论不动手 |
/model | 换模型或调推理强度 |
/review | 对当前改动做一次代码审查（见案例 01） |
想继续之前的会话：
bash
codex resume第一次就翻车的几种情况
它改了一堆你没让它改的文件。 提示词里的边界没说死。下次把「只改 X」写进去， 或者干脆先切到 read-only（codex --sandbox read-only）让它先给方案，你同意了再放开。
它反复跑同一个失败的命令。 通常是环境问题——依赖没装、端口占用、 或者它跑的命令需要联网而沙盒默认禁网。直接告诉它环境情况，比让它自己猜快得多。
它说改完了但结果不对。 把失败的输出原样贴回去。它看不到你终端里的东西， 除非那条命令是它自己跑的。
改动散得到处都是，想全部撤掉。
bash
git checkout -- . # 撤掉未暂存的修改
git clean -fd # 删掉它新建的文件（先 git clean -nd 看一眼）这也是为什么 02 篇里让你先 git init。
下一步
跑通了就去 04 · 审批与沙盒。 把边界搞清楚，后面才敢让它干更大的活。