# 策展 · X (Twitter) 🔥🔥

> 📖 本站完整內容索引（documentation index）：[llms.txt](/llms.txt)

> 作者：jason (@jxnlco) · 平台：X (Twitter) · 日期：2026-05-22

> 原始來源：https://x.com/jxnlco/status/2057153744630890620

## 中文摘要

# 如何最大化 Codex 的使用效益

大多數開發者初次使用程式開發 Agent 時，通常是為了處理程式碼：檢查程式庫、建立 diff、執行測試，並發起一個 pull request。

這依然是 Codex 的核心重心。但電腦上的許多工作其實早已透過程式碼來運作：執行 shell 指令、瀏覽網頁、呼叫 API、匯出文件、回應事件以及觸發自動化流程。隨著這些介面陸續開放給 Codex，它給人的感覺已不再僅限於狹義的程式開發助手，而是一個能協助完成電腦工作的系統。

Codex 應用程式讓這種轉變變得具體。一個對話串（thread）可以保留上下文、使用工具、呈現 artifact，並在多次提示（prompt）之間延續，而不是在每次互動後就重置。

要最大化 Codex 的效益，關鍵在於整合運用以下功能：

- 可持久化的對話串，用以保存上下文
- 語音輸入、引導（steering）與排程（queuing），讓使用者能持續參與流程
- 瀏覽器、電腦操作（computer-use）、MCP 伺服器與連接器，讓 Codex 的能力超越程式庫的範疇
- 對話串自動化與目標（Goals），即便使用者不在電腦前，工作也能持續進行
- 側邊欄，讓使用者能檢視程式碼、文件、簡報與其他 artifact

## 可持久化的對話串（Durable threads）

> 可持久化的對話串：長期運行的 Codex 對話串，能在多次工作階段間保存工作上下文。

釘選對話串是讓這些持久化對話串隨手可得的一種方式。它們對於重複性的工作流程非常實用，例如：

- 幕僚長（Chief of Staff）對話串
- 發布（release）對話串
- 文件審閱對話串
- 專門用於外部監控的對話串

這些是持續性的 workspace，而非短暫的聊天。Codex 可以隨時間多次回顧這些對話串，保存先前的決策、偏好設定以及工作上下文，省去從零開始重建的麻煩。

釘選對話串的捷徑讓這一切變得更有效率。使用 Command-1 到 Command-9 即可直接跳轉到已儲存的對話串。

## 語音輸入

語音輸入之所以有價值，是因為它能在想法被壓縮成精煉的文字之前，捕捉到最原始的構思。

Codex 內建語音輸入功能。對於那些「說起來很自然，但打字卻很彆扭」的模糊起點，它的效果特別好：

我覺得某個叫 Ben 的人在 Slack 上提過這件事。
我不記得細節了。
請去查一下。

對於一個能夠搜尋、收集上下文並回報的 Agent 來說，這樣通常就足夠了。

這也適用於在任務尚未完全成形前，進行兩到三分鐘的想法傾倒（thought dump）。

逐字稿的運作方式也相同。一份原始的會議逐字稿或口述的規劃筆記，通常比簡短的摘要更能提供優質的素材，因為它保留了不確定性、語氣強調以及尚未完成的思考脈絡。

## 引導與排程

當語音輸入結合對主動任務的明確控制時，會變得更加實用。

> 引導（Steering）：在當前步驟完成前，透過新的指令中斷正在進行的 Codex 任務。

當 Agent 走錯方向，且需要在完成前進行修正時，引導功能就派上用場了。例如，在進行網站審閱時，使用者可以在側邊欄標註介面時中斷工作：

- 把這個縮小一點
- 這兩個元素之間的間距感覺不對
- 這段文案寫錯了

> 排程（Queuing）：在當前步驟完成後，新增 Codex 要執行的工作。

排程則不同。它不會中斷正在進行的任務，而是將下一個任務加入執行序列。使用者可能會說：

工作完成後，把預覽連結傳給 Slack 上的審閱者。

引導會改變 Codex 當下正在做的事；排程則改變接下來該發生的事。兩者都能讓使用者在工作進行時，保持對進度的掌握。

## 工具與觸及範圍

一旦對話串具備了連續性，下一個問題就是它能操作什麼。Codex 可以分層向外擴展：

- `$browser`：用於側邊欄的應用程式內瀏覽器，Codex 可在此檢查並標註網頁介面
- `@chrome`：用於已登入的瀏覽器狀態與基於 Chrome 的工作流程
- `@computer`：用於僅能透過桌面 GUI 執行的工作

`$browser` 適合側邊欄的瀏覽器審閱；`@chrome` 適合依賴使用者 Chrome 上下文的已登入瀏覽器工作；`@computer` 則適合僅能透過桌面 GUI 執行的任務。

MCP 伺服器與連接器將相同的概念延伸到工作流程的其他部分。Slack、Gmail 和行事曆之所以重要，是因為許多重要的任務在變成程式碼之前，都是以訊息、收件匣項目或排程問題的形式出現。

Skills 讓重複性的工作流程變得可重用。一旦某個工作流程被證明有效，就將其封裝為 skill，這樣 Codex 就能再次執行它，而無需從頭學習該流程。

## 隨時隨地工作

Codex 行動裝置應用程式改變了使用者必須坐在辦公桌前的限制。任務可以在 Mac 上開始（因為檔案、權限與本機設定都在那裡），然後在使用者透過手機查看進度時繼續進行。

這在瑣碎時刻顯得格外重要。使用者可以在 Codex 執行較長任務時離開座位，從外部回答問題、批准下一步，或在回到座位前重新導向對話串。本機環境保持不變，但使用者不必被綁在電腦前。

## 自動化

自動化功能會按排程執行 Codex 的工作。當重複性工作需要從 workspace 重新開始時（例如每日報告或定期檢查程式庫），請使用排程自動化；當排程需要回到帶有執行上下文的活躍對話時，請使用對話串自動化。

> 對話串自動化：心跳式（heartbeat-style）的定期喚醒呼叫，按排程回到同一個 Codex 對話串。

釘選對話串雖然實用，但它們仍需等待使用者回歸。對話串自動化可以每隔幾分鐘或幾小時檢查一次進度，持續執行直到滿足特定條件，並隨時間調整頻率。

一個幕僚長對話串可以每 30 分鐘執行一次：

每 30 分鐘檢查一次 Slack 和 Gmail，找出需要我注意且尚未回覆的訊息。
協助我優先處理最重要的事項。
如果有人問我問題，請盡可能深入研究答案並為我草擬回覆，但先不要發送。

當使用者回來時，收集上下文這類耗時的部分通常已經完成了。最後決定發送什麼的，依然是人類。

對話串自動化也適用於回饋迴圈。對話串自動化可以監控 pull request 留言、Google Docs 留言或 Slack 回覆，並在使用者不在時讓周邊工作持續推進。

考慮一個動畫工作流程，審閱者在 Slack 分享了一段影片。對話串自動化可以按排程檢查對話串，當有留言時渲染出更新版本，並在同一個對話串中回覆並標記審閱者。如果某個整合功能無法完成最終上傳，桌面自動化可以透過 GUI 完成該步驟。

這個迴圈橫跨了用於回饋的 Slack、用於渲染的程式庫，以及用於最終上傳的桌面自動化。

## 目標（Goals）

當任務有一個 Agent 可以持續推進的明確終點時，目標（Goals）的功能最強大。一個薄弱的目標是：

> 目標：長期運行的 Codex 任務，設有 Agent 可以持續努力邁向的終點。

執行這個 Markdown 檔案中的計畫。

一個強大的目標則具備可衡量的成功標準。

例如，工程師可以透過設定新目錄、定義目標並明確指出終點，將內部工具從 Python 遷移到 Rust：新的實作必須通過單元測試才算完成。

目標結合了持續執行與驗證機制。使用者定義結果、停止條件，以及顯示 Codex 是否正接近目標的訊號。

實用的驗證機制包括：

- 測試套件
- 基準測試（benchmark）
- Bug 重現
- 驗證矩陣
- 必須持續通過的端到端工作流程

野心固然重要，但沒有驗證，那只是空想。

## 側邊欄

側邊欄將工作內容保留在產生它的對話旁邊。使用者無需匯出 artifact 再切換上下文，而是可以直接在原地進行審閱。輸出結果可能是程式碼，也可能是簡報、PDF、網頁、表格或其他過程中產生的 artifact。

它特別適合處理以下四種工作：

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

側邊欄讓使用者能在原地審閱 Markdown、試算表、資料表、文件與簡報。他們可以檢查、標註並修改 artifact，而不會中斷工作流程。

![](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/1779412504885-iaHIx6vBrXsAAV42qjpg.jpg)

簡報或 PDF 可以保持開啟在產生它的對話串旁邊，隨時準備進行直接審閱與修正。

![](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/1779412504889-iaHIx6njlXIAAWuXhjpg.jpg)

應用程式內建的瀏覽器讓 Codex 可以檢查渲染後的頁面、進行控制，並直接在審閱中的介面上回應標註。對頁面或 artifact 的評論會留在工作迴圈內，而不是變成一個獨立的交接過程。

網頁同時成為了輸出結果與控制介面。Codex 可以建立一個 artifact，在側邊欄開啟它、檢查它、除錯它，並在原地持續優化同一個物件。

![](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/1779412504874-iaHIx62e0WgAA9wE4jpg.jpg)

這些介面特別適用於：

- `index.html`：用於輕量級的靜態 artifact
- Storybook：用於 UI 審閱
- Remotion Studio：用於程式化動畫
- 基於瀏覽器的簡報：用於展示
- 資料應用程式：用於分析工作流程

單一的 `index.html` 檔案可以成為無需伺服器的持久化互動式 artifact。對話串自動化也可以隨時間更新靜態 artifact，讓使用者回來時，對話串中總有新的東西在等待。

## 記憶（Shared memory）

當長期運行的對話串能共享對話之外的記憶時，它們會變得更有用。

> 記憶：儲存在單一對話串之外的持久化上下文，讓未來的工作能從明確且可審閱的基礎上恢復。

一種持久化的模式是將對話串錨定在 Obsidian 庫（vault）中。實際上，這意味著一個由純文字檔案組成的資料夾，易於檢查、編輯、移動並長期保存。團隊可以將該資料夾儲存在雲端儲存空間、Git、Dropbox、Google Drive 或任何適合其工作流程的同步層中。

一個庫的結構可能如下：

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

在頂層，`AGENTS.md` 可以定義 Codex 在了解更多關於人員、專案、決策與未完成事項時，應如何更新該 workspace。

不要照搬某個特定的庫結構。要教會 Agent 持久化上下文應該存放在哪裡、該保留什麼上下文，以及何時不該進行無謂的變動。

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

- 將 `~/vault` 視為持久化工作記憶。
- 優先使用規範化的筆記，而非雜亂的筆記堆疊。
- 明確歸類 TODO、人員、專案、每日摘要與隨手筆記。
- 保存決策、阻礙事項、負責人、日期與實用的連結。
- 若沒有實質變動，請勿更動庫的內容。

程式庫存放程式碼，而庫（vault）存放滾動式的上下文：相關人員、變更內容、阻礙事項、需要後續追蹤的事項，以及那些在工作階段之間容易遺失的資訊。

重要的上下文不應只存在於對話逐字稿中。請將其寫在下一個對話串可以接續的地方。

Codex 在「設定 > 個人化 > 記憶」（Settings > Personalization > Memories）中也有原生的記憶功能。它們為偏好設定、重複性工作流程與已知陷阱提供了本機回憶層。它們是用來補充而非取代明確的書面上下文。Chronicle 透過協助 Codex 從近期的螢幕上下文建立記憶，也朝著相同的方向發展。

## 從程式碼向外延伸

Codex 依然從程式碼出發。但現在，圍繞程式碼的更多工作都可以透過同一個系統觸及：MCP 伺服器、瀏覽器介面、桌面控制、對話串自動化以及可審閱的 artifact。

這改變了控制模型。引導功能中斷了正在進行的工作；排程功能安排了下一個任務；對話串自動化讓對話串在使用者離開時保持活躍；目標功能則增加了 Codex 可以持續努力邁向的明確終點。

現在，Codex 能夠將工作流程從指令、執行一路帶到 artifact 審閱，即使工作已經超出了程式庫的範圍。

## 標籤

Codex, Agent, 自動化, 功能更新, Codex