如何把 Codex 用到極致

來源：市場資訊

（來源：石臻說AI）

石臻說AI

編輯：石臻

導讀： 很多人第一次用 Codex，還是把它當成「更會寫代碼的 ChatGPT」：看倉庫、改 diff、跑測試、提 PR。

真正有意思的變化，是 Codex 的邊界正在往外推：當瀏覽器、郵件、日程、MCP、桌面 GUI、自動化都接進來之后，Codex 就不再只是 coding agent，而是在變成一個「電腦工作系統」。

先別急著把 Codex 理解成 IDE 插件

很多開發者最早接觸 coding agent，通常是從代碼任務開始的。

比如讓它讀一個 repo，理解架構，改一段實現，跑一遍測試，再幫你準備 PR。這當然還是 Codex 的主場。但如果只停在這里，就會低估它真正的變化。

因為電腦上的很多工作，本來就已經被代碼、命令、網頁、API 和文件系統包了一層。只要這些表面能被 Codex 操作，它就自然會從「寫代碼」擴展到「把電腦上的工作往前推」。

這就是這篇長文的核心判斷：Codex 的重心仍然是代碼，但它的工作邊界已經不是代碼。

說白了，以前我們問的是「它能不能把這個函數寫對」。現在更值得問的是：「它能不能在一個真實工作流里，把上下文、工具、產物和人的判斷串起來」。

長線程比單次回答更重要

這篇文章反復強調一個詞：durable threads，長線程。

它不是簡單的聊天記錄保存，而是讓一個工作流有自己的長期上下文。比如你可以有一個專門處理發布的線程，一個做文檔審查的線程，一個負責外部監控的線程，甚至一個類似 Chief of Staff 的線程。

這些線程的價值，不在于「記得你上次說過什么」這么淺。更重要的是，它能保留一整套工作習慣：哪些來源可信、哪些步驟要先跑、哪些人需要被提醒、哪些檢查不能漏。

這也是我覺得很多人會低估的一點：AI agent 的生產力，不只來自模型變聰明，也來自上下文不再每次清零。

一個短聊天里的 AI 很像臨時工。你每次都要重新交代背景、規則、口味和禁忌。長線程更像一個持續工作的項目房間，里面的材料、半成品、決策記錄都還在。

語音、轉向、排隊：人還在回路里

這里有幾個看起來小，但實際很關鍵的控制方式：voice、steering、queuing。

語音輸入的意義不是「懶得打字」。它更適合捕捉還沒整理好的想法。很多真實任務一開始都不是一個漂亮 prompt，而是一段含糊的描述：

我記得 Slack 里好像有人提過這個，名字可能叫 Ben，但細節我忘了。你去找一下。

對傳統工具來說，這句話信息太臟。但對能搜索、整理、追問、匯報的 agent 來說，這反而是很自然的入口。

Steering 是另一種控制：任務跑到一半時，用戶可以打斷它，立刻糾偏。Queuing 則是不打斷當前任務，只把下一步排到隊列里。比如「做完后把預覽鏈接發給審核人」，這就是排隊。

這套控制模型背后的重點是：人沒有被踢出回路。

很多 agent 產品容易把「自動化」講成「你不用管了」。但真實工作不是這樣。越是復雜任務，越需要用戶在關鍵節點做判斷。好的 agent 不是替你拍板，而是把決策點提前暴露出來，讓你用最少的介入改變方向。

工具接入之后，Codex 開始離開 repo

長線程解決的是「上下文能不能留下來」。工具解決的是「它到底能碰到什么」。

Codex 的觸達范圍大概可以分成幾層：

層級適合做什么browser在側邊欄里查看網頁、標注、調試頁面Chrome處理依賴登錄態的真實網頁流程computer use操作只能通過桌面 GUI 完成的任務MCP / connectors接入 Slack、Gmail、Calendar 等工作入口Skills把重復工作流封裝成可復用能力

這個方向很關鍵。因為很多重要工作并不是從代碼倉庫開始的。

它可能從一條 Slack 消息開始，從一封客戶郵件開始，從日歷里的會議開始，從一個 Google Docs 評論開始。過去這些入口彼此割裂，最后還是人來做搬運工。現在 Codex 有機會把它們接到同一個工作線程里。

這里也有一個現實提醒：工具越多，風險越大。

能讀 Slack、能看 Gmail、能操作瀏覽器，意味著權限邊界、確認機制、日志記錄都會變得更重要。真正成熟的 agent 工作流，不是「盡可能自動執行」，而是「把可自動化的部分自動化，把需要人負責的部分清楚地停下來」。

自動化和 Goals：從陪聊變成追結果

文章里還有兩個概念值得單獨拿出來：Automations 和 Goals。

Automations 是讓 Codex 按計劃啟動工作。比如每天生成報告，定期檢查 repo，或者讓一個活躍線程每隔一段時間醒來，看看 Slack、Gmail、PR 評論有沒有新東西需要處理。

Goals 則更像長跑任務：你給它一個明確終點和驗證器，讓它持續往那個結果推進。

弱目標是：

按這個 Markdown 里的計劃實現一下。

強目標是：

把這個內部工具從 Python 遷到 Rust。目錄要建好，功能要對齊，單元測試全部通過才算完成。

差別就在驗證器。

沒有驗證器的目標，只是愿望。測試、benchmark、復現腳本、端到端流程，這些東西把「繼續努力」變成了「有沒有更接近完成」。

這也是未來 agent 工作流最實用的一條分界線：不是任務越大越適合交給 agent，而是越能被驗證的任務，越適合讓 agent 長時間推進。

側邊欄和移動端：產物就在對話旁邊

Codex app 的 side panel 也在這套敘事里占了很大位置。

它解決的是另一個老問題：AI 產出一個東西之后，人到底在哪里審。

如果輸出是代碼，可以看 diff。如果輸出是網頁，就應該直接打開頁面。如果輸出是文檔、表格、PDF、deck，就應該在同一個工作上下文旁邊審閱、標注、修改，而不是導出以后切到另一個地方重新溝通。

OpenAI 最近把 Codex 接進 ChatGPT 移動端，也是同一個邏輯：長任務不應該把人綁死在電腦前。

你可以在 Mac 上啟動一個任務，讓本地文件、權限、依賴都留在那臺機器上；人離開桌面后，手機繼續看進度、回答問題、批準下一步、改變方向。

這不是簡單的「遠程控制電腦」。更像是讓工作線程跟著人走，而執行環境還留在最合適的地方。

真正的變化：上下文、工具、驗證器

這篇長文最值得記住的，不是某一個功能，而是一個框架。

Codex 正在從三個方向變重：

1. 1

   上下文：長線程、共享記憶、項目文件，讓工作不用每次重來。

2. 2

   工具：瀏覽器、Chrome、MCP、連接器、桌面 GUI，讓它能碰到真實工作表面。

3. 3

   驗證器：測試、檢查矩陣、端到端流程，讓長任務知道什么叫完成。

如果說早期 coding agent 的問題是「能不能寫對代碼」，下一階段的問題會變成：「能不能在真實工作流里，帶著上下文和驗證器，把事情推到完成」。

我覺得這才是 Codex 這波變化的重點。

它不是要把程序員變成甩手掌柜。相反，它把人的角色往上抬了一層：少做搬運、檢索、重復執行，多做目標定義、判斷和驗收。

總結一下：Codex 仍然從代碼出發，但它的產品形態已經在往「工作系統」移動。長線程解決上下文，工具連接真實工作表面，Goals 和驗證器讓任務有終點。真正能用起來的 agent，不是全自動替你決定，而是在正確的節點讓你介入。

• Codex App Features：https://developers.openai.com/codex/app/features/
• Codex Automations：https://developers.openai.com/codex/app/automations
• Work with Codex from anywhere：https://openai.com/index/work-with-codex-from-anywhere/