核心概念

Jason Liu 是 OpenAI Codex 團隊的 Developer Experience Engineer。2026 年 5-6 月，他透過個人部落格與 OpenAI 官方白皮書發表「Codex-maxxing」方法論，核心命題只有一句話：工作不應在每次提示之間消亡（work shouldn't die between prompts）。

傳統 AI 助手的使用模式是「問 → 得到答案 → 下一個問題」，每次對話都是全新的空白石板。而 Codex-maxxing 提倡把 Codex 當成一個持久工作空間——工作在這裡發生、脈絡在這裡積累、任務在這裡繼續，而不是每次對話後重設。

這個方法論由十個相互支撐的實踐維度構成：

1. 耐久線程（Durable Threads）

Liu 為每個重要工作流保留一條「釘選線程」，例如他的首席參謀、Agent SDK 開發、OpenAI CLI 等。這些線程經過數月壓縮累積，儲存歷史決策、個人偏好與未完成任務。重訪成熟線程的成本確實比空白線程高，但 Liu 的判斷是：對真正重要的工作流，連續性的價值遠超成本。

2. 語音輸入（Voice Input）

語音輸入的優勢不在速度，而在於讓 AI 接收未經剪輯的思考。Liu 使用 macOS 內建語音輸入與 Wispr Flow，在規劃時說出模糊但自然的指示，讓 Codex 從原始思維中提取意圖，而非接收精心構造的書面提示。

3. 操舵（Steering）

允許在 Codex 執行工具呼叫之間注入新指令，不需等待整個任務完成。Liu 在審查輸出時可持續口述修改——縮小圖示、修正文字、調整間距、開 PR、等預覽部署完成、傳送連結——這些指令逐步注入，不需事先全部指定。

4. 記憶系統（Memory System）

Liu 在 Obsidian 中維護一個 vault 作為 Codex 的長期記憶：

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

Vault 同時是 GitHub 倉庫，帶來兩個好處：Codex 可在雲端直接讀寫，以及 git diff 成為記憶審查介面（每次記憶更新都是可讀的 commit）。AGENTS.md 指引告知 Codex 何時應更新哪些頁面：學到新資訊時、做了決策時、有懸而未決的問題時。記憶分三層：顯式磁盤 vault（真實來源）、Codex 內建記憶（快速回憶層）、Chronicle（結構化記憶研究預覽）。

5. 電腦與瀏覽器使用

Liu 區分三種工具：$browser（本地網頁檢查與標注）、@chrome（需要已登入狀態與多分頁的任務）、@computer（純 GUI 操作）。連接器（$slack、$gmail、$calendar）擴展工具範圍；技能（Skills）讓重複工作流可重用。

6. 遠端控制（Remote Control）

長時間任務不需要使用者守在電腦旁。Codex 繼續在桌機執行，使用者可從手機查看進度、回答問題、改變方向，保持長期任務的動量而不因切換裝置重啟脈絡。

7. 心跳（Heartbeats）

線程可設定定期自動執行。幾個實際案例：

  • 首席參謀：每 30 分鐘掃描 Slack 與 Gmail，優先排序訊息，起草但不自動發送回覆
  • 反饋監控：監控 Google Docs 或 PR 評論，在反饋到達時保持工作進行
  • 退款跟進：用 @computer 每 5 分鐘檢查客服是否上線，上線後改為每 1 分鐘

8. 可驗證目標（Goals）

長時間任務必須有可驗證的終點線，而非模糊願景。Liu 的範例：將 Rich 函式庫移植至 Rust 時，以原函式庫的完整單元測試套件作為成功指標——通過測試 = 任務完成，不需要人工判斷「差不多了嗎？」

9. 側面板（The Side Panel）

提供三種核心功能：（1）檢查工件——Markdown、試算表、CSV、PDF 在此渲染可直接評論；（2）操作網路介面——內建瀏覽器讓 $browser 可控，直接標注網頁；（3）審查變更——在批准之前查看差異。

10. 網路介面工作流（Web Surfaces）

Liu 偏好的輸出格式不是靜態文件，而是可互動的輕量應用：index.html（靜態工件首選）、Storybook（UI 元件審查）、Remotion Studio（程式化動畫）、Slidev（技術簡報）、Streamlit（資料應用）。核心洞察：一旦輸出成為小應用而非文件，人與 AI 的工作關係就改變了——HTML 比 Markdown 更具互動性，比靜態截圖更耐久。

關鍵要點

  • 從問答模式轉向工作空間模式：Codex 不是回答機器，是工作發生的地方；脈絡應在任務之間存活
  • 記憶需要顯式架構：靠 AI 自動記憶不可靠，需用 vault + AGENTS.md 建立顯式知識管理層
  • 心跳讓 AI 主動而非被動：不是使用者記得去問 Codex，而是 Codex 定期觸發並報告狀態
  • 可驗證目標比模糊願景更適合 AI：單元測試、格式正確性、特定數值——可量化的終點讓 AI 知道何時停止
  • 語音輸入改變資訊品質：未剪輯的口語思考比精心書寫的提示更富語境，AI 提取意圖更準確

實務應用

啟用耐久線程的場景：個人 wiki 維護、程式庫遷移、週期性報告生成——任何有持續迭代需求的工作流。一次性問答則不需要。

首席參謀（Chief of Staff）設定模板：建立一條線程並設定心跳，每 30 分鐘讀取 Slack/Gmail 摘要 → 分類為「需立即回覆」「可延後」「僅供知悉」→ 為前兩類起草回覆並等待確認。讓忙碌期間的溝通管理半自動化。

記憶 vault 啟動指南：在 GitHub 新建私有倉庫，建立 AGENTS.md 說明更新規則，Obsidian 指向同一路徑。Codex 透過 GitHub 在雲端讀寫，不需本地存取。

與常規 Codex 用法的差異：多數人「完成任務 → 關閉對話 → 下次重新描述情境」。Codex-maxxing 要求投資在脈絡架構上——初期設定較複雜，但複雜長期任務的執行效率大幅提升。

延伸觀點

Jason Liu 的 Codex-maxxing 方法論在業界研究中有更廣泛的理論支撐，以下整合三個獨立來源的交叉驗證觀點：

四層記憶架構是業界共識

多個來源獨立提出相同的記憶分層模型：工作記憶（當前上下文窗口）→ 情節記憶（最近跨 session 歷史）→ 語義記憶（結構化事實與偏好）→ 檔案記憶（向量數據庫長期存儲）。Liu 的 vault 架構對應了這個四層模型——Obsidian vault 承擔語義與檔案記憶的角色，而 Codex 線程上下文是工作記憶與情節記憶的即時層。

這個分層設計解釋了為什麼「讓 AI 自己記住」通常失敗：模型只有工作記憶，沒有外部持久層，重啟後一切重置。

長時間任務失敗的數據背書

研究指出，超過 4 小時的 AI Agent 任務若無狀態持久化，因超時或中斷失敗的風險高達 90%。此外，LLM 在長上下文中的表現顯著下降——準確度最高可降低 30-50%。這從統計角度解釋了 Heartbeats + Checkpointing 的必要性：不是錦上添花的工程設計，而是生產環境的生存條件。

狀態外部化是架構鐵律

多個技術來源一致強調：Agent 進程應是無狀態的，狀態必須外部化。Agent 進程可以是臨時的（重啟、橫向擴展都不影響工作流），但狀態必須存於外部數據庫——Postgres、Redis、向量索引——才能在任何時間點恢復。Liu 的 GitHub vault 正是這種設計的輕量實現：Codex 本身是無狀態進程，真正的記憶在 GitHub 上，任何 session 都可存取。

工具調用的幂等性設計

生產環境中被反覆強調但常被忽略的原則：工具呼叫必須可安全重試（idempotent）。長時間任務中途失敗時，若工具有副作用（寫入、發送、刪除），重試可能造成重複執行。這正是 Liu 在可驗證目標（Goals）部分強調「用測試套件而非模糊標準」的更深層理由——可驗證的終點能讓系統在重試時判斷任務是否已完成，而不是盲目重做。

NVIDIA × Codex：萬人工程師的 GPT-5.5 實戰手冊 Codex 安全生產部署：沙盒、審批工作流與可觀測性 Simplex × Codex：AI 原生軟體開發的五個轉型原則 Codex 行動整合：跨裝置管理 AI 編程任務

反向連結

以下頁面引用了本頁：