禮拜六晚上十一點多，我在兩個客戶專案的 Codex 裡各設了一個 goal。一個是幫一位工程顧問公司老闆做的請款＋報價系統，另一個是一位營建業二代的發包系統。
兩個我用了不同的寫法，事後看起來是個意外的對照組。
發包系統那邊我很懶，只打了一句：
let's set up the goal based on current development plan
Codex 自己把它擴成一段完整的目標，還附了一條完成條件——migration 要過、整合測試要過、沒有未解的 Critical/High 缺陷、桌機手機深淺色都要驗過、金額和匯出要能對到帳本、客戶那邊兩位同事要在 staging 走完一輪簽核到付款。這條完成條件是它寫的，不是我。 我看了一下，覺得比我自己會寫的還嚴，就讓它去了。
請款系統那邊我認真一點，寫了一頁。這一頁裡沒有任何「怎麼做」——沒說先做資料庫還是先做畫面、沒說用哪個套件、沒說要開幾張票。有的是四種東西：
做完長什麼樣（五條，第一條是 "The chairman can create and issue a quotation on mobile"）。什麼不能做（不能自己 merge、不能擴範圍、Neon 和正式環境等我回來再說、mock 過的東西不算驗證過）。先做哪個（先讓老闆手機上開得出報價單，其他的後面接）。還有最後一句，我現在覺得是整頁最重要的一句：
I'd keep October 1 as the delivery target and use the acceptance criteria—not the date—as the definition of done.
然後我就去睡了。
禮拜一早上看到的東西
請款系統在設目標之前，最忙的一天是 9 月 1 號：9 個 commit、7 個 PR。設了之後的 24 小時：74 個 commit、17 條 branch，Codex 的工作 session 從之前兩個月加起來 34 次，變成一晚 64 次。發包系統那邊沒那麼誇張，但同一個晚上 10 點到 11 點半連續 merge 了 5 個 PR，測試從 43 個變 62 個。
這些數字不能直接拿去說「產出翻了八倍」。commit 多不代表做完的事多；那 17 條 branch 現在全部堆在我這裡等 review，瓶頸從機器搬到人身上了。這件事後面講。
真正讓我停下來看的，是它怎麼做的。
它第一件事不是寫程式，是把那一頁目標拆成 19 張 GitHub issue，外加一張總表把它們串起來。拆法跟我前一天跟AI討論共寫的開發計畫幾乎一樣——不是因為它抄我的（它有讀），是給了明確的驗收條件之後，拆法其實沒有太多選擇。
然後每一輪開工前，它會在 journal 寫一行：「前次 goal turn 判定為 progress」。它在給自己打分。有進展就繼續，沒進展就換方向。這不是我教的，是 goal 這個機制本身的東西。
我最在意的那個時刻
做到帳號系統的時候，它碰到一個要改既有行為的決定：登入帳號要不要改成 email 全公司唯一。這會影響現有使用者。
它沒有猜。它做了一個實驗——用合成資料證明舊系統確實允許兩家公司用同一個帳號名——把證據寫進 journal，標記「待 John 明確核准」，然後繞過去做不依賴這個決定的其他票。廠商匯入、報價模板、附件上傳，一路做下去。
另一個例子更短。前一天我拍板說「急件例外」這個功能不做。它的 journal 裡有一句：「急件 override 依已拍板決定不實作。」就這樣，沒有多問，也沒有偷偷做。
帶人的時候我通常只講一句：手上能做的先做，真的不能做的再來問，但問之前自己先想過，不要什麼都無腦問。這句話有的人一個月就懂，有的人一直學不會。這裡是那一頁裡的一句 "Surface unresolved conflicts before implementing affected behavior"。
目標到底要寫什麼
回頭看兩個專案的對照，我的心得是：目標不是一句話，是「做完長什麼樣」加上「什麼不能碰」。 你可以像我在發包系統那樣只打一句，讓它自己擴——但你要去讀它擴出來的完成條件，因為那就是它接下來幾十個小時判斷「有沒有進展」的尺。它寫的尺比我嚴，是運氣好；下次不一定。
「先讓老闆手機上開得出報價單」這一句也很關鍵。沒有它，它可能會先把資料庫整理得漂漂亮亮，一個月後什麼都能看，就是老闆還沒摸到。
然後呢，代價是？
老實說我還不知道這樣跑一個月會怎樣。
Review 變成我的工作。17 條 branch、疊在一起的 draft PR，它一條都沒有自己 merge（這是規則，它守了），所以全部在我這裡。以前是我等它，現在是它等我。
它開的票比我計畫的多。我寫了 19 個任務，它做著做著多開了幾張——說明頁、規則設定指令之類。目前看都合理，但目標給得越寬，它自己補的東西越多，這是要盯的地方。
還有 token。這種跑法吃的量是任務模式的好幾倍，雖然大部分是 cache 命中，帳單我還在看。
所以我不會說「以後都這樣用」。我會說：如果你手上有一個驗收條件寫得出來的專案，而你這幾天沒空盯，試一次。禮拜六晚上設，禮拜一早上看。
看完你會跟我一樣，先花一個早上 review。
常見問題
Codex 的 goal 跟一般交辦任務有什麼不同？
交辦任務，AI 做完就停，下一步等你。交辦目標，它做完一件事會自己問「離目標近了嗎、下一件最該做什麼」，每一輪開工前給自己打分——判斷的責任從你身上移到它身上。
目標應該怎麼寫？
目標不是一句話，是「做完長什麼樣」加上「什麼不能碰」：列出完成條件、明講不能做的事（不能自己 merge、不能擴範圍）、指定第一個要能看到的成果，並用驗收條件而不是日期當 definition of done。只打一句讓它自己擴也可以，但要去讀它擴出來的完成條件。
這樣跑的代價是什麼？
review 變成人的工作——它不會自己 merge，所有 branch 都堆在你這裡；它會多開你沒計畫的票，目標給得越寬補得越多；token 用量是任務模式的好幾倍。適合驗收條件寫得出來、而你這幾天沒空盯的專案。