Codex 把前端頁面改完，test 過了、build 也綠了，還是得把 localhost 打開看一次。CSS overflow、loading state、modal 疊錯層，或某個按鈕在手機寬度下被擠出畫面，這些問題不會出現在 terminal 裡等你。
如果只是 code 裡的問題，讓它繼續讀檔、跑 test 就好；但 bug 活在畫面上，就該讓它真的去看畫面。Browser 可以把 local 或 public page 打開，把那條 flow 跑一次，看到哪裡不對再回 code 修。[1][2][5] 畫面已經重現，卻還是看不出原因，就往 console、network、DOM 或 runtime 再挖一層。[4][5]
再往外一點，如果問題在 native app、simulator、system setting 這些 browser 根本碰不到的地方，才需要 Computer Use。[1][3][6] Memory 則完全是另一條線，它比較像是在幫後面的 task 少重講幾次背景。[2][7]
所以這篇其實只要抓住一件事：你要 Codex 看到的，到底是哪一層 state。
先看 bug 活在哪裡
如果只是查資料、改欄位、建立一筆有明確 schema 的東西，而且本來就有 API、MCP 或其他 structured integration 可以用，那直接走那一層最省事。你拿到的是明確欄位和 action，之後要 review 也比較知道它到底做了什麼。OpenAI 對 Computer Use 的文件也是同一個方向：有 dedicated plugin 或 MCP 能處理 repeatable data access 時，優先用 structured interface。[6]
但像「390px 寬度時 modal 有沒有蓋住 CTA」這種問題，API 回再多資料也沒辦法幫你看畫面。這時直接開 Browser 就好。頁面真的有問題，但你懷疑是某個 request 失敗、runtime error、DOM state 或 CSS 最後套錯，再切 Developer mode 去查。[4][5]
Desktop app 也是一樣。如果你只要讀一個值，而 app 已經有 plugin / MCP，沒必要叫 Agent 模擬人類點半天；可是如果你要確認的是「按下 Save 之後 spinner 到底有沒有消失」，那畫面本身就是答案的一部分，這種才適合 Computer Use。[6]
Figure 1｜先選能看見 state 的介面，再談工具強弱。
這幾個工具不要排成「API / MCP → Browser → Computer Use」的升級表。要驗 UI，本來就可以直接進 Browser；只是改一個有 schema 的欄位，也完全沒必要繞去點畫面。工具選得越貼近你要驗的那個 state，後面越好收。
前端 bug，就讓它把同一條 flow 再跑一次
例如登入失敗後，手機版的 error banner 把 Submit button 往下擠，小一點的 viewport 甚至要 scroll 才按得到。
這時一直叫 Codex 看 component 跟 CSS，其實很容易卡在「看起來應該修好了」。它可以猜是哪個 style 在作怪，但最後還是得開 localhost，把登入失敗的狀態真的做出來，看 button 現在到底在哪。In-app Browser 可以自己開 local development server 或 public page，點、輸入、看 screenshot，也能直接在頁面上的 element 或區域留下 feedback；改完之後，再回同一條 flow 驗一次。[1][2][5]
大概會變成這樣：
change code
→ run or check the local server
→ open the affected route
→ reproduce the target UI state
→ inspect the rendered result
→ change the smallest relevant code path
→ reload and run the same UI flow againtest passes 跟 build passes 還是要看，只是它們沒有替你回答「使用者現在看到的畫面對不對」。測試綠了，只代表那支 test 覆蓋到的行為沒壞；build 成功，也只是這份 code 能正常產出。bug 如果只存在畫面上，最後那一下還是要回畫面看。
如果頁面已經重現，盯著畫面卻還是抓不到原因，那就別再猜 CSS 了，直接開 Developer mode。它可以透過受控的 Chrome DevTools Protocol 看 network traffic、console output、runtime error、DOM、applied styles，也能做 performance profiling。[4][5] Full CDP access 會碰到比較敏感的 browser internals，所以需要用到這一層時還會再要求 approval。[5]
只是查 framework 文件的話，Web search 就夠了。Browser 的價值在於你剛改過的那個頁面，它真的能幫你跑一次、看一次。
Browser 到不了的地方，再把 Computer Use 打開
macOS app、Windows app、simulator，或某些藏在 native menu 裡的 setting，本來就不在 in-app Browser 的世界裡。這些情況如果又沒有 structured integration 可以直接拿到 state，Computer Use 才派得上用場，它能看畫面、點擊、輸入，把 GUI-only flow 也納進驗證。[1][3][6]
但「能點」跟「應該用點的」還是兩回事。App 已經有 plugin / MCP，而且只是查資料或更新欄位，就讓它走那條乾淨的 path；碰到「Save 按下去之後 spinner 一直掛著」這種非看畫面不可的問題，再讓 Computer Use 接手。[6]
Windows 上的 Computer Use 會直接在 foreground 操作 desktop app，Agent 跑的時候 pointer 會動、文字也會真的打進去。[3] 所以你如果還想同時用同一個 desktop session，兩邊就是會打架。這跟模型能力沒什麼關係，單純是同一套 GUI 沒辦法同時給兩邊控制。
Prompt 也最好跟著收窄。比如只跑某一條 onboarding flow，碰到第一個失敗就停；修完之後，再把完全同一條 flow 重跑一次。這樣它到底驗了什麼還看得懂，真的跑錯 window 時也知道從哪裡開始追。反過來丟一句「把我電腦裡相關的 app 都看一遍，自己處理」，最後多半只會得到一段很難 audit 的操作紀錄。
Browser 看到的 page content 也要當成 untrusted context。讓 Agent 進某個 site，不代表頁面上的文字突然變成可信指令，更不代表後面的 action 全都自動批准。[5] Computer Use 又比 Browser 多碰到 app 和 system state，所以 app、window、flow、停止條件寫得越清楚越好。
Sandbox / Approval 還是照原本的 execution boundary 走：Sandbox 管 file、shell、network 這些能力能走到哪裡，Approval 決定什麼時候要停下來問人。[8] Computer Use 還會多一層 OS permission，例如 Screen Recording、Accessibility 和 app access；它們只是在決定 Codex 能不能碰某個 app，不會順便把 shell、file write 或 network 的限制一起解掉。[6]
Memory 可以幫你省背景，但規則跟證據別塞進去
同一個 repo 做久了，最常被重複講的往往是那些小東西：用哪個 package manager、平常怎麼跑 workflow、有哪些 repo convention、輸出習慣是什麼。這類背景如果已經穩定，而且後面的 task 還會一直用到，就很適合交給 Memory。[2][4][7]
如果只是同一件事做到一半，晚點回來接著做，那 Thread 就夠了。Memory 比較像是你已經開了另一個 task，還希望 Codex 不用重新把那些固定背景摸一次。[2][7]
但每次都必須遵守的 repo / team rule，還是放 AGENTS.md 或 checked-in documentation。OpenAI 的 Memories 文件也是這樣建議：Memory 留給 recall，required guidance 放在能長期維護的文件裡。[7] 至於某次 deployment 為什麼失敗、哪個 command 到底跑出了什麼、某個 diff 有沒有真的發生，這些都直接回 log、file、issue、diff 或 command output 看，不要讓 Memory 幫你「回想」。
Figure 2｜Memory 可以幫忙 recall，但不能取代 rules 或 evidence。
如果昨天 production deployment 失敗，Memory 跳出一句「好像是 migration」，那只能當提醒，不能當結論，deployment log 還是得開。相反地，如果它只是讓下一個 task 一開始就知道這個 repo 平常用 pnpm，少問一次、少查一次，那它就已經很有用了。
Codex 現在可以自己看更多 state，也可以自己碰更多介面，但驗證反而不用搞得更抽象。頁面有問題，就回頁面；runtime 有問題，就看 runtime；desktop flow 壞了，就把那條 flow 重跑一次。Memory 幫你省背景；規則和證據照樣放回能直接檢查的地方。
參考資料
- OpenAI, Codex，幾乎無所不能, 2026-04-16. https://openai.com/zh-Hant/index/codex-for-almost-everything/
- OpenAI, ChatGPT & Codex changelog, 2026-04-16 entry. https://developers.openai.com/codex/changelog
- OpenAI, ChatGPT & Codex changelog, 2026-05-29 entry, Computer Use on Windows. https://developers.openai.com/codex/changelog
- OpenAI, ChatGPT & Codex changelog, 2026-06-11 and 2026-06-16 entries, Browser Developer mode and Memories. https://developers.openai.com/codex/changelog
- OpenAI, Browser, living documentation. https://learn.chatgpt.com/docs/browser
- OpenAI, Computer Use, living documentation. https://learn.chatgpt.com/docs/computer-use
- OpenAI, Memories, living documentation. https://learn.chatgpt.com/docs/customization/memories
- OpenAI, Running Codex safely at OpenAI, 2026-05-08. https://openai.com/index/running-codex-safely/