如何把 Codex 用到極致

大多數開發者第一次用程式 agent 都是為了寫程式：檢查一個倉庫、生成一份 diff、跑測試、開一個 pull request。

這至今仍是 Codex 的重心。但電腦上的很多工作本來就以程式為中介：執行 shell 指令、瀏覽網頁、呼叫 API、匯出文件、回應事件、觸發自動化。當這些介面逐一向 Codex 開放，它給人的感覺就不再是狹義上的程式助手，而更像一套用來完成電腦上各種工作的系統。

Codex 應用把這個轉變落到了實處。一個執行緒（thread）能保留上下文、使用工具、呈現產物（artifacts），並跨多輪 prompt 持續下去，而不是每次互動結束後就重置。

想從 Codex 身上得到更多，就要把這些能力組合起來用：

• 持久執行緒（durable threads），保留上下文
• 語音、操控（steering）、排隊（queuing），讓使用者始終留在回路裡
• 瀏覽器、computer-use、MCP server 和 connector，讓 Codex 在倉庫之外也能動作
• 執行緒自動化（thread automations）和目標（Goals），在使用者離開時繼續推進工作
• 側邊欄（side panel），使用者在那裡審閱程式、文件、投影片和其他產物

持久執行緒

持久執行緒：長期執行的 Codex 執行緒，能跨多次會話保留工作上下文。

置頂執行緒（pinned threads）是把持久執行緒放在手邊的一種方式。它適合反覆出現的工作流程，比如：

• 一個參謀長（Chief of Staff）執行緒（相當於 Thread 的大腦）
• 一個發佈執行緒
• 一個文件審閱執行緒
• 一個專門做外部監控的執行緒

這些是持久的工作區，不是簡短的聊天。Codex 可以隨時間反覆回到這些執行緒裡，保留此前的決定、偏好和工作上下文——否則這些東西就得從頭重建。

置頂執行緒的快捷鍵讓這件事變得實用。Command-1 到 Command-9 能直接跳進已儲存的執行緒。

這個確實很有用，因為用 AI 開發久了，我會發現很多時候同一個任務會散落在不同的 Thread 中，這個操作步驟相當於是把 Thread 變成了「角色」。

語音輸入

語音輸入的價值在於，它能在一個想法被壓縮成打磨過的文字之前，捕捉到它粗糙的版本。

Codex 內建了語音輸入。對於那些說出來很自然、打字卻很彆扭的模糊起點，它尤其好用：

我記得有個叫 Ben 的人在 Slack 裡提過這件事。 具體細節我不記得了。 你去查一下。

對一個能搜尋、能收集上下文、能回來彙報的 agent 來說，這通常就夠了。

在任務還沒完全成形時，花兩三分鐘把想法一股腦倒出來，它也很合適。

轉錄文本同理。一份原始的會議轉錄，或者口述的計畫筆記，往往比一段簡短的摘要提供更好的素材，因為它保留了不確定、強調，以及沒說完的思路。

操控與排隊

當語音和對一個進行中任務的明確控制配合起來，它會變得更有用。

操控（Steering）：在目前步驟結束之前，用新的方向打斷一個正在執行的 Codex 任務。

當 agent 走錯了方向、需要在它做完之前糾正時，操控就有用。比如在審閱一個網站時，使用者可以一邊在側邊欄標註介面，一邊打斷它的工作：

• 把這個改小一點
• 這兩個元素之間的間距感覺不對
• 這句文案是錯的

排隊（Queuing）：加入一些讓 Codex 在目前步驟完成之後再做的工作。

排隊不一樣。它不打斷進行中的任務，而是把下一個任務排進佇列。使用者可能會說：

等這件事做完，把預覽連結在 Slack 裡發給審閱的人。

操控改變 Codex 此刻正在做的事，排隊改變接下來該發生的事。兩者都讓使用者在工作展開的過程中始終貼近它。

Steering 也非常有用，我目前經常用到 Steering 的地方是使用 goal 的時候定期讓他出執行計畫，判斷與預期是否相符，是否有漂移等。

工具與觸達範圍

一旦一個執行緒具備了連續性，下一個問題就是：它能作用於什麼。Codex 可以一層層地向外延伸：

• $browser，對應側邊欄裡的應用內瀏覽器，Codex 在那裡可以檢查和標註網頁介面
• @chrome，對應已登入的瀏覽器狀態，以及基於 Chrome 的工作流程
• @computer，對應那些只存在於桌面圖形介面（GUI）中的工作

$browser 適合在側邊欄裡做瀏覽器審閱。@chrome 適合那些依賴使用者 Chrome 上下文、需要登入狀態的瀏覽器工作。@computer 適合那些只能透過桌面 GUI 完成的任務。

MCP server 和 connector 把同樣的思路延伸到工作流程的其餘部分。

Slack、Gmail 和 Calendar 之所以重要，是因為很多重要的任務一開始是以訊息、收件匣條目或排程問題的形式出現的，之後才變成程式。

Skills 讓重複的工作流程可以複用。一個工作流程一旦被證明有用，就把它打包成一個 skill，這樣 Codex 下次能再跑一遍，而不用從零重新學習這套流程。

隨處都能工作

Codex 行動版改變了「使用者必須坐在工位前」這件事。一個任務可以在 Mac 上啟動——檔案、權限和本地配置都已經在那裡——然後在使用者用手機查看時繼續推進。

這在一些細小的時刻很重要。一個人可以在 Codex 跑一個較長的任務時離開工位，在外面回答一個問題、批准下一個步驟，或者在回到座位之前給執行緒換個方向。本地環境留在原處，而使用者不必。

Automation

自動化按計畫執行 Codex 的工作。如果一個重複性任務應該每次從一個工作區全新開始——比如一份日報，或者一次定期的倉庫檢查——就用排程自動化（scheduled automation）。如果這個計畫應該回到一個帶著執行上下文的活躍對話裡，就用執行緒自動化（thread automation）。

執行緒自動化：心跳式的、週期性的喚醒，按計畫回到同一個 Codex 執行緒。

置頂執行緒很有用，但它們仍然在等使用者回來。執行緒自動化可以每隔幾分鐘或幾小時檢查一次某件事，持續下去直到滿足某個條件，並隨時間調整節奏。

一個參謀長執行緒可能每 30 分鐘跑一次：

每 30 分鐘，檢查 Slack 和 Gmail 裡那些需要我關注、還沒回覆的訊息。 幫我把最重要的事排出優先級。 如果有人問我問題，盡可能深入地研究答案，並替我起草一份回覆，但不要發出去。

當使用者回來時，收集上下文這個最昂貴的部分往往已經做完了。發出什麼，仍然由人來決定。

執行緒自動化也適合回饋循環。一個執行緒自動化可以盯著 pull request 的評論、Google Docs 的評論或 Slack 的回覆，在使用者離開時讓周邊的工作繼續往前。

設想一個動畫製作的工作流程：審閱的人在 Slack 裡分享了一段影片。一個執行緒自動化可以按計畫檢查這個會話，在評論到來時算出一個更新的版本，並在同一個會話裡 @ 那位審閱者回覆。如果某個整合無法完成最後的上傳，桌面自動化可以透過 GUI 把這一步做完。

這個循環橫跨三處：用 Slack 收回饋、用程式庫做算圖、用桌面自動化完成最後的上傳。

automation 對我的日常來說也很重要，不過這就相當於是個定時任務，這個大家應該都熟知了。

/goal

當一個任務有一條真實的終點線、agent 能持續朝它推進時，目標（Goals）最為強大。一個弱的目標是這樣的：

目標：運行時間更長的 Codex 任務，帶有一條終點線，agent 能長期朝它持續工作。

把這個 Markdown 檔案裡的計畫實現出來。

一個更強的目標有一條可度量的成功標準。

舉個例子，一個工程師可能要把一個內部工具從 Python 遷移到 Rust：建好新目錄，定義好目標，並把終點線寫明確——新實作在單元測試通過之前都不算完成。

一個目標把持續的執行和一個驗證器（verifier）結合在一起。使用者定義結果、停止條件，以及那個能說明 Codex 是否在靠近終點的信號。

有用的驗證器包括：

• 一個測試套件
• 一個 benchmark
• 一次 bug 重現
• 一個驗證矩陣
• 一個必須一直保持通過的端到端工作流程

有野心很重要，但沒有驗證，它就只是一個願望。

jason 這篇對於 /goal 的作用跟我和大家的預期幾乎一致，AI 可以幫你連續做完所有的工作，但你要得保證他不漂移。

側邊欄

側邊欄把工作成果留在產生它的那個對話旁邊。使用者不必匯出一個產物再切換上下文，而是可以就地審閱它。產出可能是程式，但也可能是一份投影片、一個 PDF、一個瀏覽器頁面、一張表格，或者過程中產生的其他產物。

它尤其擅長四件事：

1. 檢查產物
2. 標註哪裡需要改
3. 操作網頁介面
4. 審閱改動

側邊欄讓使用者可以就地審閱 Markdown、試算表、資料表、文件和投影片。他們可以檢查、標註、修改這些產物，而不打斷整個回路。

那份投影片或 PDF 可以一直開在產生它的執行緒旁邊，隨時可以直接審閱和修補。

應用內瀏覽器讓 Codex 可以檢查一個渲染好的頁面、控制它，並直接在被審閱的介面上回應標註。對一個頁面或產物的評論留在工作回路內部，而不是變成一次單獨的交接。

網頁同時成為輸出和控制介面。Codex 可以建構一個產物，在側邊欄裡打開它，檢查它、除錯它，並就地不斷打磨同一個物件。

下面這些載體尤其合適：

• index.html，用於輕量的靜態產物
• Storybook，用於 UI 審閱
• Remotion Studio，用於程式化的動畫
• 基於瀏覽器的投影片，用於簡報
• 資料應用（data apps），用於分析類工作流程

單單一個 index.html 檔案，不需要伺服器，就能成為一個持久的、可互動的產物。執行緒自動化還可以隨時間刷新這些靜態產物，這樣當使用者回來時，執行緒裡已經有新的東西在等著。

共享記憶

當長期執行的執行緒能共享一份位於任何單一對話之外的記憶時，它們會變得更有用。

共享記憶：儲存在單一執行緒之外的持久上下文，讓未來的工作可以從一個明確、可審閱的東西接著做下去。

一個經得起時間的做法，是把持久執行緒錨定在一個 Obsidian vault 裡。實際操作上，這意味著一個由純文字檔案組成的資料夾，它始終便於檢查、編輯、移動，也便於長期保存。團隊可以把這個資料夾放進雲端儲存、Git、Dropbox、Google Drive，或者其他適合自己工作流程的同步層。

一個 vault 大致可能長這樣：

 体验AI代码助手 代码解读复制代码vault/
├── TODO.md
├── people/
├── projects/
├── agent/
└── notes/

在頂層，AGENTS.md 可以定義：當 Codex 對人、專案、決定和未了結的事情了解得更多時，它應該如何更新這個工作區。

不要照搬某一個確切的 vault 結構。要教會 agent：持久上下文應該住在哪裡、應該保留哪些上下文，以及什麼時候不要製造無謂的變動。

一份實用的 AGENTS.md 可能會寫：

• 把 ~/vault 當作持久的工作記憶。
• 寧可要規範的筆記，也不要筆記到處蔓延。
• 明確地把 TODO、人、專案、每日小結和草稿筆記各自歸位。
• 保留決定、阻塞項、負責人、日期和有用的連結。
• 如果沒有發生有意義的變化，就不要去攪動這個 vault。

程式倉庫裝的是程式。vault 裝的是滾動的上下文：涉及的人、變了什麼、卡在哪裡、需要跟進什麼，以及那些否則會在一次次會話之間消失的東西。

重要的上下文不該只活在一份對話記錄裡。把它寫在某個下一個執行緒能接著讀下去的地方。

Codex 自己也有第一方的記憶功能，在 Settings > Personalization > Memories 裡。它們為偏好、重複出現的工作流程和已知的坑提供了一個本地的回憶層。它們是對顯式寫下來的上下文的補充，而不是替代。Chronicle 朝同一個方向使力——它幫助 Codex 從最近的螢幕上下文中建構記憶。

從程式向外

Codex 仍然從程式出發。但程式周圍的更多工作，現在可以透過同一套系統觸達：MCP server、瀏覽器介面、桌面控制、執行緒自動化，以及可審閱的產物。

這改變了控制模型。操控打斷進行中的工作。排隊把下一個任務排好隊。執行緒自動化在使用者走開時讓一個執行緒保持活躍。目標則加上一條具體的終點線，讓 Codex 能持續朝它工作。

現在，Codex 能把一個工作流程從指令、到執行、再到產物審閱完整地承載下來——哪怕這項工作已經離開了程式倉庫。

我的想法

這篇介紹的很多功能我覺得非常實用。

老模型是一個 prompt 換一個 diff，agent 是你呼叫的一個函式。新模型是一個持久執行緒，你像帶一個同事那樣帶它。steering 是當面打斷，queuing 是交代下一件事，automation 是它自己按點幹活，goal 是給它一份驗收標準。文章列的那一長串，本質是一套管理下屬的原語。

而且一個非常具有可品味性的在於 /goal 那一節，goal 沒有驗證，你的藍圖只是個願望。這句不只對 Codex 成立。

Agent 落地的真問題不在能力，能力早就夠了，缺的是一個能回答它有沒有做對的東西。Python 遷 Rust 那個例子好就好在終點線可執行——單測通過，而不是感覺差不多。我自己的基本和文章的一致：給不出驗證的任務，agent 的產出基本不能直接用。

但最承重的一節是共享記憶，它卻被排在很靠後的位置。前面那一串能力，底色都是讓一個執行緒能長期接著幹；可只要上下文還只活在對話記錄裡，所謂長期就是假的——執行緒一長照樣丟。

真正讓執行緒持久的是那個 vault：一個純文字資料夾，加一個 AGENTS.md 教 agent 怎麼維護它。注意 AGENTS.md 裡那條沒有實質變化就別攪動 vault。

最後一點：vault 這個模式不是 OpenAI 獨有的。Claude Code 有 CLAUDE.md，各家 agent 各自摸索，最後都收斂到同一件事——agent 的記憶就是倉庫裡的純文字檔案，能看，能改，有 version control 。agent 要變成能長期託付的東西，靠的不是模型多強，是它有沒有一塊外部記憶。

功能 OpenAI 會一直加，但那塊持久的、純文字的、你自己也在維護的記憶，得你自己搭了來維護。

原文：Jason Liu（@jxnlco）《Getting the most out of Codex》，2026-05-20 發佈於 X（長文形式）。推文連結：x.com/jxnlco/stat…

原文出處：https://juejin.cn/post/7644783891102548010