Codex-maxxing: treating Codex like an operating loop (將 Codex 視作營運迴圈)

原始來源與檔名：2026-06-16T093908+0800-Codex-maxxing treating Codex like an operating loop.md

NAPKIN | 餐巾紙

餐巾紙公式

Agent = 持續迴圈 (Operating Loop) + 外部記憶 (Disk Memory) + 視覺驗證 (Visual Review)

摒棄一次性對話，將 AI 轉化為具有狀態、可驗證且持續運作的非同步工作引擎。

一句話

不要只把編程 Agent 當作高級自動補全，而應該將其打造成具備外部記憶、能自我驗證且持續迭代的工作迴圈 (Operating Loop)。

餐巾紙草圖

[ One-shot Prompting ]         [ Operating Loop ]
User -> Prompt -> Code         User -> Task
(End)                          |
                               v
                         +-------------+ <---- Memory (Disk/Notes)
                         |   Agent     |
                         +-------------+ ----> Visual/Browser Review
                               |
                               v
                         [ Verification ] (Tests, Lint, Build)
                               |
                               +-> Done / Await Approval

ROUND 1: SKELETON | 骨架掃描

“這篇文章在說什麼”

核心問題: 如何最大化 AI 編程助手 (如 Codex) 的價值，而不是僅停留在「代碼生成」的表面？
核心答案: 將 Codex 視為一個持續的「工作迴圈 (Operating Loop)」，透過系統提示詞賦予其持久記憶、視覺驗證與自動化跟進的能力。
論證結構: 案例與指令型 (提供具體的 System Prompt 並解釋其設計理念)。

章節骨架

工作模式的轉變: 從一次性對話走向持續的工作迴圈。
自定義指令實踐: 將迴圈思維寫入 System Prompt。
持久化與驗證: 強調硬碟記憶與多維度結果驗證。
實戰應用與背書: 透過開源專案與專家觀點佐證迴圈的強大。

ROUND 2: DISSECTION | 血肉解剖

“憑什麼這麼說”

隱形假設與邊界條件

隱形假設:
- AI 模型具有足夠的上下文理解能力，能閱讀與修改本地硬碟檔案，並利用瀏覽器等工具進行自我驗證。
- 使用者熟悉如何切割任務，並能夠管理多個同時運作的 Agent 迴圈。
邊界條件:
- 當任務屬於極短篇、一次性的代碼諮詢時，建立複雜的迴圈可能過於冗餘。
- 若系統不具備提供本地文件讀寫或瀏覽器查閱權限 (沙箱過於嚴格)，此工作流將難以實現。

ROUND 3: SOUL | 靈魂提取

“還能怎麼用”

知識連結: 這與軟體工程中的 CI/CD 流水線 (持續整合/持續交付) 以及控制理論中的「閉環反饋系統 (Closed-loop feedback system)」概念高度吻合。
深層洞見: 未來的 AI 不是「問答機」，而是「非同步工作者」。我們的工作將從「編寫代碼」轉移到「設計與管理迴圈」。
行動呼籲: 立即將文章中提供的 Prompt 貼入你所使用的 AI Agent (如 Cursor, Codex 等) 的自定義指令中，並開始建立你的第一個持久化工作迴圈。

Codex-maxxing: treating Codex like an operating loop (Architectural Deep Dive)

前言/背景

多數開發者在使用 AI 編程代理 (Coding Agents) 時，仍將其視為「高級的自動補全」或「一次性的問答機器 (One-shot chat box)」，這大幅低估了 AI 的潛力。本文旨在探討一種名為 “Codex-maxxing” 的模式，即將 Codex (或其他相似的 AI 代理) 轉變為一個持久的、具備驗證能力的營運迴圈 (Durable Operating Loop)，從根本上改變人機協作的工作流。

章節詳細總結

從一次性問答到持續營運迴圈

作者指出，若只要求 AI 生成代碼便停止，會浪費大量的上下文價值。更好的模式是將代理視為持續執行的工作流：

持久的對話串 (Persistent threads)：針對長期的工作流保持對話狀態。
基於磁碟的記憶 (Disk-backed notes)：將記憶寫入實體檔案，便於審查與比對 (Diff)。
視覺化審查 (Browser surfaces)：利用瀏覽器介面進行真實的視覺檢查，而非僅依賴文字反饋。
輕量化互動 (Small HTML apps)：當需要互動時，產出小型的 HTML 應用而非死板的 Markdown。
後續自動化與驗證 (Automations & Verification)：設立清晰的驗證閘門 (Verification gates)，在標記完成前自動進行測試與檢查。

一個高價值的 Codex 執行緒應該能夠：檢查本地應用程式、打開靜態產物、檢視渲染出的簡報、監控 PR (Pull Request)、更新專案筆記，並最終帶著「可審查的結果」返回。

核心自定義指令 (System Prompt) 深度解析

作者提供了一段配置於 Settings > Personalization > Custom instructions 的指令，其架構設計極具參考價值：

1. 持續性工作 (Ongoing Work)

要求代理優先使用持久對話串。
狀態外掛 (State Externalization)：明確指示將上下文寫入具體文件 (如 TODOs, AGENTS.md, 決策記錄等)。這解決了 LLM 記憶力有限與對話窗格過長的缺點。
強調磁碟檔案才是單一真相來源 (Source of Truth)，代理應主動更新這些檔案，而非只在對話歷史中提供資訊。

2. 產物設計 (Artifacts)

優先產出可檢查的結果 (Inspectable outputs)。
對於輕量互動，預設生成單一且自包含的 index.html (包含 CSS/JS)，除非絕對必要，否則避免引入複雜的後端架構。
根據任務特性靈活使用多種載體 (Markdown, CSV, PDF, Storybook, Streamlit 等)，並在創建視覺產物後，主動使用應用內瀏覽器打開與驗證。

3. 瀏覽器與電腦操作 (Browser/Computer Work)

範圍界定 (Scoping)：對代理的工具權限做精細控制。
- 一般靜態或本地服務使用預設 Browser。
- 需要登入狀態或 Cookie 時才使用 Chrome。
- 僅在無法透過 Shell、檔案或瀏覽器解決時，才動用 Computer Use (GUI 級別控制)。
要求代理必須以「檢查渲染結果 -> 修復最小問題 -> 重新檢查」的閉環方式進行。

4. 迴圈與驗證 (Recurring Loops & Verification)

自動化心跳 (Heartbeat)：當需要輪詢或監控時，代理應建議帶有明確停止條件的自動化流程。
安全邊界：代理可草擬回覆與行動，但未經明確批准，不得採取公開或帳戶級別的操作。
嚴格的驗證閘門：
- 禁止僅因為「修改了檔案」就宣告成功。
- 必須執行最小單位的驗證：如測試 (Tests)、代碼格式化 (Lint)、類型檢查 (Typecheck)、建置 (Build)、冒煙測試 (Smoke test) 或截圖。
- 向開發者報告「改變了什麼」、「如何驗證的」以及「殘留風險」。

開源與實戰應用背書

作者提到他利用這套 “Looping” 工作流來維護包含 OpenClaw、Veritas Kanban 等開源專案，並為客戶開發解決方案。在任何特定時間點，他都有超過十幾個迴圈在 Codex 中並行運作。此外，OpenAI 的 Jason Liu 亦曾強調：「你不再應該只是提示 (Prompting) 你的編程代理，你應該設計迴圈 (Loops) 來提示你的代理。」

總結與結論

系統架構思維轉移：開發者應從「微觀代碼生成者」升級為「宏觀系統編排者 (System Orchestrator)」，設計並管理具備自主驗證與狀態更新能力的 AI 迴圈。
記憶體外掛化 (Disk-as-Memory)：LLM 的對話上下文不可靠，必須將系統決策、待辦清單和專案狀態實體化為本地檔案 (如 AGENTS.md)，這有助於版本控制與跨執行緒共享記憶。
測試與驗證左移 (Shift-Left Verification)：AI 代理不該只對代碼修改負責，還必須對代碼的正確性與視覺渲染負責。將 CI 流水線的思維 (Lint, Build, Test) 融入代理的 Prompt 中，能大幅降低錯誤率。
操作權限的最小化原則 (Least Privilege)：在 Prompt 中嚴格區分不同工具 (Browser vs Chrome vs Computer Use) 的使用場景，並設置安全卡控 (需人工批准才能進行公開操作)，是防範 AI 幻覺引發災難的關鍵架構決策。