跑第一個真實任務:讓 Codex 在你的 repo 修一個 bug

學新工具最容易卡在「讀完文件才敢動」。這一課不這樣。我們挑一個你本來就要處理、又夠小的東西，直接讓 Codex 在你的 repo 跑一次完整迴圈。

第一步：挑對第一個任務

好的第一個任務：範圍小、有明確驗收、做錯容易回退。

適合的：修一個有重現步驟的 bug、補一段缺的測試、照現有 pattern 加一個小端點、換掉一個過時的 API 用法。

先不要挑：橫跨半個系統的大重構、你自己都還沒想清楚的設計、會碰 migration／部署的東西。第一次，要的是走完一圈。

第二步：先把工作區弄乾淨

在乾淨的 git 工作區開始：先 commit 或 stash 手邊改動，最好開一個新分支。

理由很簡單：Codex 會直接改你的檔，你要能用 git diff 清楚看到它改了什麼、用 git checkout 一秒回退。乾淨的起點，讓「審查」和「反悔」都變便宜。

第三步：把任務講清楚

別只丟「修一下登入的 bug」。講成它能照著做的樣子：

「使用者在 token 過期後按重新整理會白畫面。重現：登入 → 等 token 過期 → 點重新整理。我猜在 auth/session.ts 的 refresh 流程。幫我定位、修掉，並補一個涵蓋『過期後重新整理』的測試。改完跑 npm test 確認綠的。」

它包含了：現象、重現步驟、你的猜測(給它起點)、預期結果、怎麼驗。 講清楚不清楚，結果差很多——下一階段「把任務講成規格」會深講。

第四步：看著它跑，別走開

交出去後，Codex 會開始動：讀相關檔、提出改動、跑指令。第一次，留下來看——你會看到它怎麼定位、改了哪些檔、跑了什麼。

它要跑指令或改檔時，可能會停下來請你核准。第一次就一個個看過再放行，別急著全開自動。如果它要做你沒預期的事(改到不相關的檔、跑破壞性指令)，喊停。怎麼設定哪些自動、哪些要放行，是「approval 與權限」那一課的主題。

第五步：審 diff，別直接收

它說「好了、測試綠了」，先別 merge。這是整條路線的核心習慣：

• git diff 從頭讀一遍——每一行都該是你看得懂、同意的。
• 自己再跑一次測試，別只信它說「綠了」。
• 想一下它沒改到的：漏掉的邊界、順手改壞的地方。

AI 寫的 code 可能看起來合理卻有 bug，或用一個不存在的 API 講得很篤定。讀 diff 不是不信任它，是你本來對任何 PR 都會做的 code review。

不滿意？告訴它哪裡不對讓它改;或 git checkout 回退、把任務講得更清楚再來。反悔很便宜——這就是第二步弄乾淨工作區的回報。

你剛剛完成了什麼

你讓 Codex 在真實 repo 跑完了一圈：乾淨起點 → 講清楚 → 看它讀改跑 → 審 diff → 收或重來。這就是用 coding agent 工作的完整節奏。

下一課，我們用 Codex 最特別的一招：把手機配對起來，讓你離開電腦也能看它做事、遠端核准下一步。

林子睿（編輯：廖玄同），《跑第一個真實任務:讓 Codex 在你的 repo 修一個 bug》，矽基前沿 [Si]gnals，2026-06-19。https://signals.tw/articles/codex-first-task/