前兩天，OpenAI 內部的一位工程師 Jason Liu 發了一篇長文，Getting the most out of Codex（如何把 Codex 榨乾）。
算是官方下場，手把手教你怎麼把 Codex 的能力壓榨到極限。
01
關於作者
Jason Liu（@jxnlco），目前是OpenAI Codex 團隊的開發者體驗工程師。
他出生在中國北方，靠近蒙古草原的邊境地帶，自稱是「北方華裔蒙古人」。從小在加拿大長大，在安大略省的一所公立藝術學校讀了四年高中，學數字動畫和設計。本科考進了滑鐵盧大學讀計算數學和統計，最早學的其實是數學物理，後來才轉向電腦。
他職業生涯的主要軌跡是：Meta 做內容稽核演算法，然後去了 Stitch Fix（美國一家時尚電商）做了五年機器學習，一路做到 Staff Engineer。在 Stitch Fix 的時候，他搞了一套多模態嵌入系統（ResNet-50、CLIP+GPT-3），還開發了個叫 Flight 的內部框架，每天處理 3.5 億次請求，內部採用率 80%。
離開 Stitch Fix 之後，他創辦了 567 Studios 做獨立諮詢，客戶包括 Zapier、HubSpot、Weights & Biases、Pydantic 這些公司。同時還在 Maven 上開課教 RAG 和 AI Agent，學員來自 OpenAI、Anthropic、Google、微軟等 50 多家公司。
不過他最廣為人知的身份，可能還是開放原始碼專案Instructor的作者。
這個庫有 1.3 萬 GitHub 星標，月下載量超過 600 萬，能用 Pydantic 從 LLM 輸出中提取結構化資料。OpenAI 官方後來推出的 Structured Outputs 功能，明確表示受到了 Instructor 的啟發。
他此前曾發過一條推，調侃在 OpenAI 的經歷：
“我申請 OpenAI 的時候，以為自己會做 evals。簽合同的時候，以為會做 agents。入職的時候，以為會做 Codex。工作一個月後，以為會做知識工作。結果現在……我在做動態圖形。
總之，這位在開發者工具和 AI 應用領域浸泡了快十年的人，現在專門負責 Codex 的開發者體驗。他基於內部視角對外寫的這篇指南，值得我們一讀。
02
持久線程
文章開頭提出了一個核心概念：Durable Threads（持久線程）。
Codex 的線程不是一次性的短對話，它是一個持久化的工作空間，關掉再打開，之前的決策、偏好和工作上下文都還在，不需要從頭來過。
Jason 建議使用者把不同類型的工作分配到不同的固定線程中：
•首席幕僚線程，處理日常雜務、收發郵件、安排優先順序
•發佈管理線程，追蹤版本發佈進度
•文件審查線程，持續稽核和更新文件
•外部監控線程，跟蹤外部資訊變化
用Command-1到Command-9快速鍵可以直接跳到對應線程，把它們當作常駐工作台來用。
這和 Claude Code 的 memory 系統有異曲同工之處，只是 Codex 選擇了一條更「顯式」的路：你自己決定那些上下文需要保留，而不是讓模型自動記憶。
03
語音輸入
語音輸入我一直就在使用，叫：我做了一個 AI 時代的效率神器，已開源。語音輸入這個功能乍一看可能平平無奇，但用過之後你就再也回不去了。
Jason 分享的用法是：在想法還沒成形的時候，先用語音把粗糙的念頭倒出來。
比如這樣說一句：
“我記得有個叫 Ben 的人在 Slack 裡提了這個事，具體細節我忘了，你去找找。
語音的好處在於，它保留了思考中的不確定性和強調重點。兩三分鐘的語音傾倒，比花五分鐘寫一段精確的 prompt 效率要高許多。
而且原始的語音轉錄稿（包括猶豫、強調、沒說完的半句話）比整理過的摘要資訊量更大。開會的時候直接把會議錄音喂給 Codex，比自己寫會議紀要效率要高得多。
04
即時干預
這部分 Jason 提出了兩個控制機制，解決的是同一個問題：人不需要等 Agent 做完才能參與。
Steering（即時干預），在 Agent 執行過程中隨時打斷糾正。比如看著它做網頁，直接說「這個間距不對」「這段文案不對」。不用等它做完再推翻重來。
Queuing（任務排隊），不打斷當前任務，直接追加後續指令：「做完之後，把預覽連結發給 Slack 裡的審閱者。」
一個是糾偏，一個是追加。兩者配合的效果是：你可以一邊看著 Agent 幹活，一邊即時調整方向，同時把後續任務排好隊。整個過程不需要停下來重新寫 prompt。
05
從程式設計到萬能
接下來是 Codex 能力邊界的擴展，這部分是整篇文章最關鍵的資訊。
Jason 把 Codex 的操作範圍分成了幾個層次：
•內建瀏覽器，在側邊欄中檢查和標註網頁
•Chrome 級工作流，使用你已登錄的瀏覽器狀態，處理需要身份驗證的操作
•桌面 GUI，操作那些只有圖形介面的應用
•MCP 伺服器和連接器，把能力延伸到更廣泛的工作流中
也就是說……Codex 已經不只是個寫程式碼的工具了。
它可以幫你看 Slack、查 Gmail、操作 Google Docs，甚至在你的電腦桌面上點來點去。Jason 在文中的原話是：
“從指令到執行到產物審查，即便工作已經超出了程式碼倉庫的範圍。
06
技能和雲端
Skills（技能）的概念和 Claude Code 的 Skills 有些類似：把驗證過的工作流封裝成可復用的模組，下次直接呼叫，不需要重新教一遍。
另一個值得關注的是Cloud Context（雲端上下文）。Codex 的任務可以從電腦上啟動，然後在手機上繼續跟進。你可以離開工位，讓 Codex 在後台跑更長的任務，隨時從手機上審批下一步、或者重新調整方向。
也就是說，Codex 不只是一個繫結在本地終端上的工具，它的工作狀態是跟著帳號走的。
07
兩種自動化
Codex 區分了兩種自動化模式：
定時自動化（Scheduled Automations），按時間表運行，每次從頭開始。比如每天早上生成一份日報，或者定時檢查某個倉庫的狀態。
線程自動化（Thread Automations），在同一個線程中定時喚醒，帶著之前的上下文繼續工作。
Jason 舉了個例子：
“每 30 分鐘檢查一次 Slack 和 Gmail，找到需要我關注的未回覆消息。幫我排出優先順序。如果有人問了我一個問題，儘可能深入地研究答案，幫我起草回覆，但不要傳送。
這就是個全天候線上的私人助理。
你離開電腦，它在後台幫你收集資訊、整理回覆、跟蹤 PR 評論。等你回來，昂貴的上下文收集工作已經做完了，你只需要審閱和確認。
線程自動化還有一個用法，是用來做反饋循環。比如讓它持續關注 PR 評論、Google Docs 裡的批註、或者 Slack 頻道的回覆，在你離開的期間保持工作推進。
這個設計的核心洞察是：Agent 最有價值的能力，不在於它能替你做什麼，而在於它能替你等什麼。
08
目標驅動
/goal是 Codex 上個月推出的新功能，我之前寫過一篇文章專門介紹，Codex 推出 /goal 功能，不達目標，不罷休
簡單來說，Goal 就是給 Agent 設定一個明確的終點線，讓它自己跑到終點。
Jason 在文中區分了「弱目標」和「強目標」：
弱目標：「按照這個 Markdown 檔案裡的計畫實現。」
強目標：把一個 Python 項目遷移到 Rust，用單元測試作為成功標準。
目標驅動
好的目標需要配套驗證機制：
•測試套件
•基準測試
•Bug 復現步驟
•端到端工作流
Jason 的總結是：
“野心當然重要，但沒有驗證機制，它終歸只是個願望。
09
側邊欄
側邊欄（Side Panel）承擔了四個功能：檢查產物、標註修改、操作網頁、審查程式碼變更。
它支援的格式包括 Markdown、電子表格、資料表、文件、幻燈片、程式碼、PDF 等等。
Jason 特別推薦了幾種適合在側邊欄中使用的產物格式：
•index.html，輕量級靜態產物，不需要伺服器
•Storybook，UI 元件審查
•Remotion Studio，程序化動畫
•瀏覽器幻燈片，簡報
•資料應用，分析工作流
一個單獨的index.html檔案就能建立出不需要伺服器的互動式產物。配合線程自動化，還能定時刷新這些靜態產物，讓你每次回到線程時都能看到最新內容。
而且你可以直接在側邊欄的渲染介面上做標註，標註會留在工作循環中，不會變成單獨的「交接文件」。
10
共享記憶
這部分和 Claude Code 的 memory 系統有些類似。
Jason 的建議是：重要的上下文不應該只存在對話記錄裡，要寫到一個 Agent 下次能找到的地方。
他推薦的方案是用一個 Obsidian 知識庫來儲存持久資訊：
●●●vault/
├── TODO.md
├── people/
├── projects/
├── agent/
└── notes/
└
然後在AGENTS.md裡告訴 Codex 怎麼使用這個知識庫：
“把 ~/vault 當作持久工作記憶。優先更新已有筆記，而不是到處建立新檔案。按照 TODO、人物、項目、每日摘要和草稿分類。保留決策、阻塞項、負責人、日期和有用連結。如果沒有有意義的變化，就不要動知識庫。
知識庫可以放在雲端儲存、Git、Dropbox、Google Drive 等任何同步工具上。程式碼歸程式碼倉庫，滾動的工作上下文歸知識庫。
除了外部知識庫，Codex 還有一套內建記憶系統（Settings > Personalization > Memories），用於記錄偏好、常用工作流和已知的坑。配合螢幕上下文捕獲，Codex 可以從你最近的操作中自動建立記憶。
11
全部串起來
把上面這些功能組合在一起，Jason 描繪的是這樣一個工作模型：
即時干預打斷正在走歪的方向，任務排隊在不打斷的前提下追加工作，線程自動化在你不在的時候保持進度，目標設定明確的終點線。
從「給它一段 prompt 讓它寫程式碼」，到「管理一個持續運行、跨倉庫、跨應用、自動化的工作系統」……
Codex 能做的和想要做的，顯然已經超出了程式設計工具的範疇。
12
另一種 open
回看 Codex 剛發佈的時候……，如果你也有用過就會知道，那會兒真的是極其難用。不論是模型在程式設計上的能力，還是 Harness（編排層）的設計和實現，相比 Claude Code 差距都不小。
但 OpenAI 正視到了這個差距，並一直在快速追趕。
過去的兩個月，Codex 的更新節奏更是密到讓人目不暇接，除了先是全線對標 Claude Code 到部分超過 Claude Code（尤其像多模態生成這樣的 claude 完全忽視的領域），甚至還搞了個Codex 外掛直接做進了 Claude Code 裡，直殺入對手腹地……
甚至便是說 Codex 已經超過了 Claude Code，也並不算誇張。只是 Claude Code 在生態和使用者心智上還是有先發優勢的，社區更成熟，開發者的肌肉記憶更深。
我自己就……有時明明想用 cx（codex 的 alias），結果還是習慣性地輸入了 cc（Claude Code 的 alias）……
而且在使用上，OpenAI 對國內使用者相對更為友好。同時它也比較開放，對於社區（比如龍和馬）一直敞開大門，還時常一言不合就幹出重設用量這種事。
雖然模型不 open，但這個 open 也不錯……
而現在，官方親自下場，教你怎麼把 Codex 的每一個 token 都壓榨完全來了。
那就充好錢、好好學，暴力壓榨起來吧！ (AGI Hunt)