Codex advanced annotation mode：前端 UI 修改從「靠嘴描述」變成「指哪改哪」

Codex / UI Feedback / Frontend Workflow

這則 Threads 說到 Codex 除了 Appshots、goal mode，也加入 advanced annotation mode。它補上的不是模型能力，而是溝通介面：把「這個按鈕太小、那塊留白太擠」從模糊文字描述，變成在瀏覽器中直接選元素、調整、預覽、批次標註，再交給 Codex 處理。

核對資訊：搜尋到 9to5Mac / OpenAI release notes 摘要：Codex for Mac 更新包含 Appshots、Goal mode、in-app browser improvements；release notes 提到 advanced annotation mode、faster asset extraction、read-only JavaScript context、tab grouping usability、less Chrome extension tab clutter 等 browser use improvements。本文以 Threads 可見內容與公開摘要整理，不假裝已完整讀取 OpenAI 內部說明。

它解決什麼痛點

UI 問題通常是空間感、比例、對齊、節奏、視覺層級，很難用文字精準描述。設計師 / PM / 工程師來回說「再小一點、往左一點、感覺不對」會消耗大量上下文。

advanced annotation mode 的價值

使用者可在內建瀏覽器裡直接標註或調整元素，讓 Codex 知道「哪個元素」與「想改成什麼」。這比單純截圖或口頭描述更可執行。

跟 Appshots / goal mode 的關係

Appshots 給 Codex 視覺上下文；goal mode 讓任務有目標導向；advanced annotation mode 則讓 UI feedback 精準落到頁面元素與批次 comments。三者合起來像一套前端修版工作流。

對產品團隊的影響

未來「設計回饋 → 工程修改」會更像 Figma comment + browser live edit + coding agent 的混合體。PM 不必把所有感覺翻成 CSS 語言，工程師也少猜需求。

舊流程	新流程
截圖 → 圈圖 → 文字描述 → agent 猜元素 → 改錯再回報	內建瀏覽器直接選元素 → 標註 / 預覽 → 批次交給 Codex → 修改與驗證
問題在「語意對焦」：到底是哪個 div？哪個 state？	問題在「可執行回饋」：標註直接綁定畫面位置與元素。
適合大方向需求	適合 spacing、font size、color、layout、CTA hierarchy 等細節修版。

使用這類功能時的好習慣：

每個 annotation 都寫「目的」，不只寫「改小」。例如：降低次要 CTA 視覺權重。
同一輪批次處理同一類問題：spacing、typography、contrast、responsive，不要混雜。
標註後仍要跑 viewport / responsive 檢查，避免桌面版修好、手機版壞掉。
把最終改動回寫成 design rule，否則下次還會重犯。
敏感頁面仍要注意 browser context 與 agent 可見資料。

來源：
Threads: https://www.threads.com/@prompt_case/post/DYo2u2Ajc2p