Codex 官方文章解讀：如何把 Codex 用到極致

多數開發者第一次使用 Codex，通常是從程式碼任務開始：閱讀倉庫、修改 diff、執行測試、打開 pull request。

這仍然是 Codex 的核心場景。但電腦上的很多工作本來就被程式碼和工具包圍：執行 shell 命令、瀏覽網頁、呼叫 API、匯出文件、回應訊息、觸發自動化。隨著這些能力逐漸接入 Codex，它就不再只是狹義的程式碼助手，而更像一個幫你完成電腦工作的系統。

Codex app 讓這種變化變得更具體。一個 thread 可以保留上下文、呼叫工具、展示產物，並在多輪提示之間持續推進，而不是每次對話都重新開始。

想更充分地使用 Codex，關鍵是把這些能力組合起來：

持久執行緒，用來保存長期上下文
語音輸入、steering 和 queuing，讓使用者仍然掌控過程
browser、computer use、MCP servers 和 connectors，讓 Codex 走出倉庫
thread automations 和 Goals，讓任務在使用者離開後繼續推進
側邊欄，用來審閱程式碼、文件、投影片、網頁和其他產物
共享記憶，把重要上下文寫到執行緒之外

持久執行緒

Durable threads 指的是能在多次會話之間保留工作上下文的長執行緒。

Pinned threads 是一種很實用的入口。它適合放那些會反覆回來的工作流程，例如：

Chief of Staff 執行緒
發布執行緒
文件審閱執行緒
外部監控執行緒

這些不是臨時聊天，而是持續存在的工作空間。Codex 可以在後續繼續回到同一個執行緒，沿用之前的決策、偏好和背景資訊，避免每次都從零重建上下文。

快捷鍵也讓它更順手。Command-1 到 Command-9 可以直接跳轉到已保存的執行緒。

語音輸入

語音輸入的價值在於，它能捕捉還沒有被整理成正式文字的想法。

Codex 內建語音輸入。它特別適合那些說起來很自然、打字時卻很彆扭的模糊起點：

1
2
3


我记得 Slack 里好像有个叫 Ben 的人提过这个。
具体细节我不记得了。
帮我去找一下。

對於一個能搜尋、整理上下文並彙報結果的 agent 來說，這通常已經足夠開始。

語音也適合兩三分鐘的想法傾倒。會議轉錄、口述規劃筆記、未整理的原始記錄，往往比一句摘要更有用，因為它們保留了不確定性、重點和沒說完的思路。

Steering 和 queuing

語音和顯式控制結合起來時，會更有用。

Steering 指的是在 Codex 任務執行過程中插入新的方向，讓它在當前步驟結束前改道。

例如在審閱網頁時，使用者可以一邊在側邊欄標註，一邊打斷當前任務：

1
2
3


这里再小一点。
这两个元素之间的间距不对。
这句文案写错了。

Queuing 則不同。它不打斷當前任務，而是把下一步工作排到佇列裡：

1

这项工作完成后，把预览链接发给 Slack 里的 reviewer。

Steering 改變 Codex 現在正在做什麼。Queuing 改變它接下來應該做什麼。兩者都讓使用者在任務展開時仍然靠近現場。

工具和可觸達範圍

執行緒有了連續性之後，下一個問題就是：它能操作什麼？

Codex 可以一層層向外擴展：

$browser：適合側邊欄裡的網頁檢查、標註和 review
@chrome：適合依賴使用者 Chrome 登入狀態的瀏覽器工作流程
@computer：適合只能透過桌面 GUI 完成的任務

MCP servers 和 connectors 把同樣的思路擴展到更多工作流程中。Slack、Gmail、Calendar 很重要，因為很多任務最初不是以程式碼形式出現，而是以訊息、郵件和日程問題出現。

Skills 則適合固化重複工作。當某個流程已經被證明有用，就可以把它打包成 skill，讓 Codex 下次不必重新學習這套步驟。

從任何地方繼續工作

Codex mobile app 改變了使用者必須坐在電腦前的時間。

一個任務可以在 Mac 上開始，因為檔案、權限和本機環境都在那裡；隨後使用者離開桌面，只用手機繼續確認、補充或改方向。

這在很多小場景裡很有價值：Codex 跑長任務時，使用者可以離開座位；如果它需要確認，可以在外面回覆；如果方向錯了，也能及時 redirect。真正留在原地的是本機環境，而不是使用者本人。

自動化

Automations 可以按計劃執行 Codex 工作。

如果一個週期任務應該從某個 workspace 重新開始，例如日報或常規結庫檢查，可以用 scheduled automation。如果調度應該回到一個已有對話，並沿用它的上下文，就更適合 thread automation。

Thread automations 更像心跳式喚醒：按固定節奏回到同一個 Codex thread。

Pinned threads 需要使用者主動回來，而 thread automation 可以每幾分鐘或每幾小時檢查一次，持續執行到滿足條件為止，並隨時間調整節奏。

例如，一個 Chief of Staff 執行緒可以每 30 分鐘執行一次：

1
2
3


每 30 分钟检查 Slack 和 Gmail，找出需要我注意但还没有回复的消息。
帮我判断哪些最重要。
如果有人问我问题，尽可能深入研究答案，并替我起草回复，但不要发送。

使用者回來時，最耗時的上下文收集往往已經完成。真正要不要發送，仍然由人決定。

Thread automations 也適合反饋循環。它可以定期查看 pull request 評論、Google Docs 評論或 Slack 回覆，在使用者離開時繼續推進周邊工作。

比如一個動畫工作流程，reviewer 在 Slack 裡發來影片反饋，thread automation 定時檢查執行緒；如果有新評論，就重新渲染版本，並在同一個 Slack thread 裡回覆 reviewer。如果某個整合無法完成最終上傳，桌面自動化還可以透過 GUI 補上最後一步。

這個循環會跨過 Slack、程式碼庫和桌面應用，但對使用者來說仍然留在同一個工作流程裡。

Goals

Goals 最適合那些有明確終點、並且 agent 可以持續推進的任務。

一個較弱的 goal 可能是：

1

实现这个 Markdown 文件里的计划。

更強的 goal 會有可衡量的完成標準。

例如，把一個內部工具從 Python 遷移到 Rust 時，可以先建好新目錄，再把目標說清楚：新實作只有在單元測試通過後才算完成。

Goal 本質上是持續執行加驗證器。使用者需要定義結果、停止條件，以及判斷 Codex 是否更接近目標的訊號。

常見的驗證器包括：

測試套件
benchmark
bug reproduction
validation matrix
必須持續通過的端到端工作流程

任務可以有野心，但沒有驗證條件時，它更像願望，而不是 goal。

側邊欄

側邊欄把工作產物放在生成它的對話旁邊。使用者不必匯出檔案、切換上下文，再回頭描述問題。產物可能是程式碼，也可能是 deck、PDF、網頁、表格，或者工作過程中生成的其他 artifact。

它特別適合四類工作：

檢查 artifact
標註需要修改的地方
操作網頁介面
審閱變更

Markdown、表格、資料表、文件和投影片都可以直接在側邊欄裡看。使用者可以檢查、標註、修改，而不用把這個過程變成另一輪交接。

如果是 deck 或 PDF，它可以一直停在產生它的 thread 旁邊，隨時接受 review 和修復。

瀏覽器也是類似的工作面。Codex 可以打開渲染後的頁面，檢查它，回應使用者在頁面上的標註，並繼續修復同一個對象。網頁既是輸出結果，也是控制表面。

這些表面尤其適合放在側邊欄裡：

index.html 這種輕量靜態 artifact
Storybook
Remotion Studio
瀏覽器投影片
資料分析應用

一個單獨的 index.html 檔案就可以成為長期存在的互動 artifact，不一定需要伺服器。Thread automations 也可以定期刷新靜態 artifact，讓使用者回來時看到新的結果。

共享記憶

長執行緒很有用，但重要上下文不應該只存在於對話記錄裡。

Shared memory 指的是把持久上下文存放在執行緒之外，讓未來的工作可以從明確、可審閱的地方繼續。

一種穩定做法是把持久執行緒錨定在 Obsidian vault 裡。實際形態可以很簡單：一組普通檔案，方便檢查、編輯、移動和長期保存。團隊可以把它放在 cloud storage、Git、Dropbox、Google Drive 或其他同步層裡。

一個 vault 可能長這樣：

1
2
3
4
5
6


vault/
├── TODO.md
├── people/
├── projects/
├── agent/
└── notes/

頂層的 AGENTS.md 可以說明 Codex 應該如何維護這個工作空間：什麼資訊要寫下來，寫到哪裡，什麼時候不要製造噪音。

一個實用的 AGENTS.md 可以這樣寫：

1
2
3
4
5


- Treat ~/vault as durable work memory.
- Prefer canonical notes over note sprawl.
- Route TODOs, people, projects, daily summaries, and scratch notes explicitly.
- Preserve decisions, blockers, owners, dates, and useful links.
- If nothing meaningful changed, do not churn the vault.

不要照抄某個 vault 結構。更重要的是教會 agent：長期上下文應該放在哪裡，哪些資訊值得保留，什麼時候不應該反覆改動檔案。

倉庫存放程式碼。Vault 存放滾動上下文：相關人員、發生了什麼、哪裡卡住、誰負責、下一步是什麼，以及那些如果不寫下來就會在會話之間消失的細節。

Codex 也有第一方記憶能力，可以在 Settings > Personalization > Memories 中配置。它適合記錄偏好、重複工作流程和常見卡點，但它更適合作為顯式 written context 的補充，而不是替代品。Chronicle 也在同一個方向上推進：從最近的螢幕上下文中幫助 Codex 建立記憶。

從程式碼向外擴展

Codex 仍然從程式碼開始。但程式碼周圍的更多工作，現在也能被同一個系統觸達：MCP servers、瀏覽器介面、桌面控制、thread automations 和可審閱 artifact。

這改變了使用 Codex 的控制方式。Steering 用來打斷正在進行的工作。Queuing 用來排下一步。Thread automations 讓執行緒在使用者離開後繼續活動。Goals 給長期任務加上明確終點和驗證訊號。

當這些能力連起來時，Codex 就能把一個工作流程從指令推進到執行，再推進到 artifact review。即使任務已經離開程式碼倉庫，它仍然可以留在同一個系統裡完成。

原文連結：Getting the most out of Codex