交流群即將上線
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 · 核准與沙盒。 把邊界搞清楚，後面才敢讓它幹更大的活。