# Codex 指哪改哪：不要再靠嘴描述 UI 問題 做介面任務時，最卡的常常不是 AI 不會改，而是你很難用文字講清楚哪裡怪。Codex 的瀏覽器標註可以把位置講清楚，再搭配 /plan 和 /goal 讓任務往前推。 > 同一題有更完整的整理：《Codex 桌面版怎麼用：把文件、畫面與排程接進同一個工作入口》（https://be-ai-curator.com/blog/codex-desktop-tips-context-entry） 上一篇我寫 Codex 桌面版時，重點放在「它怎麼接住工作現場」。 這篇想接著講一個更具體的小功能：做介面任務時，不要只靠文字描述問題。 因為 UI 工作裡最常卡住的，不一定是 AI 不會改。 很多時候，是你很難用一句話講清楚： - 哪個按鈕太小 - 哪塊間距太擠 - 哪個區塊手機版會跑版 - 哪個地方看起來就是不對，但你一時說不出來 如果只用文字講，很容易變成來回猜謎。 你說「右上那個有點怪」。 AI 可能真的去改右上，但改的不是你看到的那個問題。 ![介面任務可以直接在 Codex 瀏覽器中標註畫面問題](https://be-ai-curator.com/images/blog/codex-goal-mode-practical-tips-annotation-mode.png) ### 先把位置講清楚 Codex 的 in-app browser 可以預覽網頁，也可以用 Annotation mode 在頁面上選元素、框區域、留下 comment。 白話說，你可以直接在畫面上告訴它： - 這個按鈕太小 - 這幾個選項太擠 - 手機版這裡會跑版 這件事看起來很小，但對 UI 任務很重要。 因為 AI 不再只收到一段模糊描述。 它收到的是「畫面位置」加上「你希望它注意什麼」。 ### 標註完，不代表放飛 但標註畫面不等於叫 AI 自由發揮。 我會再補三件事。 第一，終點是什麼： > 請把這個設定頁調到手機版不擠。 第二，邊界是什麼： > 可以改前端樣式和元件排列，但不要改資訊架構，也不要新增沒有討論過的功能。 第三，什麼時候要停下來： > 如果某個修改會影響品牌風格，或需要我判斷取捨，就停下來問我。 這三個條件加上畫面標註，才比較像一個可以交出去的任務。 ### `/plan` 和 `/goal` 接在哪裡 如果一開始還講不清楚，可以先用 `/plan`。 讓 Codex 先整理： - 這次要改哪些畫面 - 哪些是標註到的位置 - 哪些地方不能動 - 改完要拿什麼證據回來 等你認同這個整理，再用 `/goal` 讓它往前推。 官方文件把 `/goal` 描述成一個 persistent goal。簡單說，就是 Codex 會朝著這個目標工作，直到完成、暫停，或需要更多 input。 ![先用 plan 把終點、邊界、停下條件整理清楚，再交給 goal 執行](https://be-ai-curator.com/images/blog/codex-goal-mode-practical-tips-plan-goal-flow.png) ### 一個比較完整的寫法 你可以這樣寫： > 請把這個設定頁調到手機版不擠，優先處理我在瀏覽器裡標註的地方。可以改前端樣式和元件排列，但不要改資訊架構，不要新增沒有討論過的功能。如果某個修改會影響品牌風格，或需要我判斷取捨，就停下來問我。完成後請回報改了哪些位置，並附上驗證方式。 這段話真正有用的地方不是它比較長。 而是它同時交代了四件事： - 目標 - 畫面位置 - 修改邊界 - 停下條件 ![Codex Goal 模式不是待辦清單，而是持續推進的工作狀態](https://be-ai-curator.com/images/blog/codex-goal-mode-practical-tips-goal-state.png) ### 人還是要保留判斷 我不會把這個功能理解成「AI 可以完全自動幫你做設計」。 比較好的理解是： 人負責指出問題、定義邊界、保留判斷。 AI 負責把可執行的部分往前推。 這樣少掉的不是人的品味。 少掉的是「你到底在指哪裡」和「下一步要做什麼」的來回摩擦。 ### 官方來源 [developers.openai.com](https://developers.openai.com/codex/app/commands) [developers.openai.com](https://developers.openai.com/codex/app/browser) --- 來源：AI 主理人 https://be-ai-curator.com/blog/codex-goal-mode-practical-tips · 更新於 2026-05-28