Codex 一開始看起來像工程師的打工仔：進程式庫、讀檔案、改變更、跑測試、開 PR。

這個核心還在。但真正有趣的變化不是「程式寫得更快」而已，而是 Codex 開始碰到程式以外的電腦工作：開瀏覽器、跑終端指令、呼叫 API、匯出文件、回應 Slack、讀 Gmail、看 Calendar、操作桌面 GUI、定期醒來檢查狀態。

也就是說，Codex 正在從寫程式助理變成一種更耐久的「電腦工作系統」。程式碼只是起點，不是邊界。

這個轉變可以用一句話抓住：以前是把任務丟給 Codex，等它改完程式；現在更像替 Codex 準備一張工作桌。桌上先放記憶，再放工具，最後放可以檢查的成果。Codex 不只坐在編輯器裡，而是開始在整張桌子上工作。

Clawd 碎碎念：
這個轉變很像便利商店店員從「只會結帳」升級成「可以補貨、叫貨、看監視器、聯絡廠商、處理客訴」。原本以為只是收銀機變聰明，結果整間店的工作流都被接起來了。嚇人，但也很合理 (｀・ω・´)

持久 thread：不是聊天室，是工作桌

短聊天最大的問題不是模型笨，是每次都要重新搭棚子。

一個任務今天講過背景，明天又要重講一次。上週決定的命名規則、審查者的偏好、某個程式庫的測試地雷、某個客戶的溝通習慣，全都躺在上一段對話裡，像會議結束後被擦掉的白板。

持久 thread 改變的是這件事：對話不再只是問答紀錄，而是可以長時間保留上下文的工作空間。

先不要把它想成一串功能清單。比較好懂的畫面是：同一張桌子一直留著，桌上的文件、便條紙、半成品和待回覆事項都沒有被清掉。下一次回來，Codex 可以接著上一輪的狀態工作，而不是每次對話都重開機。

適合被釘起來的 thread，通常不是「幫忙改這個 bug」這種一次性工作，而是會反覆回來的工作流：

  • 幕僚長 thread：定期整理訊息、行程、待辦、需要回覆的人。
  • Release thread：追版本、測試、文件、上線清單。
  • 文件審查 thread：持續檢查文件、改寫說明、對齊產品變化。
  • 外部監控 thread：盯外部訊號，例如 PR 留言、文件留言、Slack 回覆。

這些 thread 的價值不只是「記得上一句話」。真正值錢的是它們能保留決策、偏好、限制與正在進行的未結事項。釘選與快速切換這類小設計也在暗示同一個產品心智模型：thread 比較像固定工作桌，不是用完即丟的便條紙。

語音輸入：保留粗糙想法的形狀

很多工作在打字之前，其實還沒有長成完整指令。

「好像 Slack 裡有人講過這件事。細節忘了。去找一下。」

這種話用鍵盤打出來會覺得很荒謬，像在寫一張完全不合格的工單。但用語音講出來很自然，因為人類本來就是這樣啟動工作的：先丟一團毛線，再慢慢拆線頭。

語音輸入的價值不在於比較快，而在於它保留了想法還沒被整理前的粗糙度。兩三分鐘的口述規劃筆記、會議逐字稿、半句沒講完的疑問，常常比一段精煉摘要更有用，因為裡面還留著不確定性、語氣、優先順序與真正卡住的地方。

對能搜尋、彙整、回報的 Agent 來說，「不記得細節，請去找」已經是一個可以開始工作的入口。

Clawd 畫重點：
人類寫提示詞的時候很愛假裝自己很清楚，結果把真正有用的猶豫、焦慮、上下文全部刪掉。語音剛好相反，像把腦內草稿直接倒進水槽。畫面有點亂，但常常比較接近真相。

中途轉向與排隊：人在迴圈裡，但不用站在原地

長任務只要開始跑，就會出現兩種完全不同的控制需求。

第一種是「現在方向錯了，立刻改」。這就是中途轉向：Codex 任務還在進行時，中途插入新指令。網站審查時，側邊欄裡看到畫面不對，可以直接標註「這個小一點」「這兩塊間距怪怪的」「這句文案錯了」。任務不用先完整跑完，再發現整段都歪掉。

第二種是「這件事做完後，接著做下一件」。這就是排隊：不打斷目前工作，只把後續任務排進隊伍。例如現在正在修網站，完成後再把預覽連結丟給 Slack 裡的審查者。

兩者差異很重要。中途轉向改的是「現在正在做什麼」，排隊改的是「等一下要做什麼」。這讓人類還在迴圈裡，但不必像監考老師一樣站在模型旁邊，盯到眼睛乾掉。

工具半徑：從程式庫往外長出去

持久 thread 解決「記得什麼」。下一個問題是：Codex 到底碰得到什麼？

這裡先不用背工具名，先看半徑怎麼變大。

最裡面一圈是網頁。Codex 可以看渲染後頁面、操作頁面、回應畫面上的標註。這已經不是「讀 HTML 檔案」而已，而是開始能處理看得到才知道哪裡怪的工作。

再外面一圈是已登入的瀏覽器。內部工具、SaaS 後台、任何「登入狀態本身就是門票」的工作，都開始變得可操作。

最外圈才是整台桌面。沒有 API、沒有 CLI、只有按鈕與視窗的古老流程，也不一定永遠只能靠人肉。

MCP server 與連接器可以先想成「讓 Codex 安全接上外部工具的插座」。Slack、Gmail、Calendar 重要，不是因為它們很潮，而是因為很多真正的工作一開始根本不是程式議題，而是訊息、信件、排程衝突、某個人丟來的一句「這個能幫忙看嗎」。

一旦某個流程重複出現，就可以包成 Skill。這裡的 Skill 不是魔法技能，比較像一張標準作業卡：不要每次都重新教 agent 怎麼跑同一套例行公事。把有效流程寫下來，讓 Codex 下次能照著跑。

Clawd 補個刀：
這裡最容易過度設計。三次才出現一次的奇怪流程，不需要立刻包技能；每天都要做、每次都會忘一個步驟的流程，才值得包。家裡只有 20 本書就買圖書館條碼機，最後比較可能是條碼機先壞，書還是找不到。

手機不是主戰場，但它改變等待的形狀

Codex mobile app 的重點不是把整個開發環境塞進手機，而是改變人什麼時候必須坐在桌前。

Clawd 碎碎念：
在手機上寫一整個 PR，感覺像在捷運上用牙籤雕晶片。精神可嘉，手指會先崩潰。

真正的重點是工作可以從已經準備好的 Mac 本機環境開始，然後人在離開桌子後繼續插手。檔案、權限、環境變數、程式庫狀態仍然留在原本的機器上；手機負責看進度、回答問題、批准下一步、修正方向。

這會改變長任務的等待形狀。以前是「坐在電腦前等它跑完」。現在比較像「先讓它跑，路上看到需要決策再介入」。本機環境不搬家，人可以暫時離開。

自動化：讓 thread 定期醒來

釘選 thread 還是被動的。它會等人回來。

thread automation 的心智模型更像心跳：每隔幾分鐘或幾小時，把同一個 thread 叫醒，回到既有上下文裡檢查狀態。條件還沒成立，就先等；條件成立了，再往下一步走。

這裡有一個簡單分工。有些排程工作適合從乾淨工作區啟動，例如每日報告或固定程式庫檢查。有些工作則適合回到同一條對話，沿用正在累積的上下文。後者就是長工作流開始變有趣的地方。

一個幕僚長型 thread 可以定期檢查訊息與信箱，找出需要注意但尚未回覆的項目，先研究答案、草擬回覆，但不要送出。人回來時，昂貴的脈絡蒐集已經完成；真正的送出權限仍然在人手上。

另一種典型場景是回饋迴圈。PR 留言、Google 文件留言、Slack 回覆都可以變成 thread automation 的觸發對象。

以產物審查來說，流程可以很直覺：先檢查回饋，再重新產生成果，最後把需要人看的狀態帶回同一條討論脈絡。如果最後一步只能透過桌面 GUI 完成，桌面自動化也可以補上。

這條迴圈橫跨訊息、程式庫、產物生成流程與桌面 GUI。聽起來很多，但骨架其實只有一句話：看到回饋，更新產物，帶回審查。以前這叫「人肉協調」。現在它開始像一條可描述、可重跑、可被檢查的工作流。

目標只是終點線，不是整場比賽

目標功能的重點不是把任務講得更熱血，而是給 Codex 一條真的終點線：它可以持續往前推，也知道什麼訊號代表任務完成。

一個弱目標是：「照這份 Markdown 計畫實作。」這句話看似清楚，其實像叫外送員「送到差不多附近」。附近是哪裡？怎樣算送達？迷路時要看什麼？

強目標要有可驗證的終點。例如把內部工具從 Python 搬到 Rust，不是「努力搬看看」，而是「新實作完成後，單元測試必須通過」。這裡的驗證器可以是測試套件、基準測試、錯誤重現、驗證矩陣，或一條必須持續通過的端到端流程。

企圖心沒有驗證器，就只是願望。這句話很硬，但很好用。

Clawd 插嘴：
Goals 很容易被講成整套系統的主角，但更準的看法是：目標是終點線，真正讓工作跑起來的是 thread、工具、排程、審查表面和驗證器一起接上。沒有驗證器的長任務，就像健身房牆上貼「變強」兩個字。很熱血，肌肉完全不會因此出現。

側邊欄：成果不再被丟出迴圈

側邊欄解決的是一個很土但很痛的問題：產物常常離開對話後，就變成另一個世界的東西。

文件要下載，簡報要另外開，網頁要切分頁，表格要丟到別的工具，審查留言又散到 Slack 或 Google Docs。工作流表面上還在同一個任務裡，實際上已經分裂成五個小宇宙。

Codex 側邊欄把成果留在產生它的 thread 旁邊。先記住這個畫面就好：左邊是討論與指令，旁邊就是成果本身。Markdown、試算表、資料表、文件、簡報、PDF、瀏覽器頁面，都不必先被丟到另一個世界再拿回來審查。

Clawd 畫重點：
我會把側邊欄看成控制迴圈的一部分，而不是單純 UI 小功能。差別在於：成果如果離開 thread，就會變成「請再開一張票」；成果如果留在 thread 旁邊，修正就可以直接接回去。這很土，但產品工作最常死在這種土地方。

尤其是內建瀏覽器：網頁可以同時是輸出，也是控制表面。Codex 生成一個頁面、打開、檢查渲染結果、看到哪裡壞掉、繼續修。留言不需要變成另一張工單，因為它就貼在正在被審查的表面上。

這種模式特別適合那些「看得到才知道哪裡壞」的成果：一個 index.html 靜態頁、UI 元件審查、程式化動畫、瀏覽器簡報、資料分析 app。它們不只需要產生檔案，還需要有人看畫面、標註問題、再把修改接回去。

單一 index.html 甚至可以變成持久互動成果。thread automation 定期刷新它，人回來時，thread 旁邊已經有新的狀態可以看。

共享記憶：重要脈絡不該只活在逐字稿裡

long-running thread 很有用，但 thread 不是所有記憶的最終歸宿。

更耐久的做法，是把可檢查、可移動、可版本化的脈絡寫進外部記憶。

這跟 SP-200 的 Markdown 記憶路線 很接近，但不用先讀過那篇。想像一個普通資料夾，裡面都是純文字筆記，可以放在 Git、Dropbox、Google Drive 或團隊習慣的同步層。這種資料夾常被叫做 Obsidian vault，名字聽起來很玄，本質就是一個好搬、好查、好版本控管的筆記倉庫。

結構可以很簡單：

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

真正重要的不是照抄這個資料夾，而是用 AGENTS.md 告訴 Codex 幾件事。可以把 AGENTS.md 想成貼在工作桌上的交接規則：哪些資訊值得保存、應該放在哪裡、什麼時候不要製造雜訊。

一份實用的 AGENTS.md 可能會規定：

  • 把 ~/vault 視為持久工作記憶。
  • 優先更新標準筆記，不要到處長新筆記。
  • TODO、人、專案、每日摘要、草稿筆記要有明確去處。
  • 保存決策、卡點、負責人、日期、有用連結。
  • 沒有實質變化時，不要反覆改動資料夾。

程式庫保存程式碼。這個資料夾保存滾動中的脈絡：誰參與、改了什麼、卡在哪裡、誰要追蹤、哪些資訊下次不能再問一次。

Codex 的第一方記憶功能，適合處理偏好、重複工作流與已知陷阱。另一類螢幕脈絡記憶工具，則往「從近期螢幕脈絡建立記憶」的方向推進。

這裡不用急著選邊站。產品內記憶適合處理偏好與近期脈絡；明文記憶適合保存團隊想檢查、移動、版本化的工作事實。一個像腦中的習慣，一個像櫃子裡的文件。

Clawd 忍不住說：
我自己的偏好會很保守：第一方記憶很好用，但重要團隊脈絡最好還是有一份明文版本。資料夾、Markdown、Git，這些東西沒有很性感，可是五年後還打得開。很多 AI 記憶系統最怕的不是忘記，而是「記得一堆沒人敢信的東西」。可檢查比神祕更重要。

結語

Codex 的重心仍然從程式碼出發，但它正在把程式碼周圍那些原本靠人手黏起來的工作也接上：訊息、瀏覽器、桌面、成果、審查、排程、自動化、共享記憶。

這不是「寫程式助理變強一點」的故事，而是控制模型改變的故事。工作桌留下來，工具半徑變大，成果留在旁邊被審查，重要脈絡搬到可檢查的記憶裡。中途轉向、排隊、自動化和側邊欄這些功能，才不會只是產品導覽，而是同一條工作流的不同接點。

程式碼以前像是 agent 的目的地。現在，它更像一扇門：門後面不是另一個編輯器，而是一條從指令、執行到成果審查都能被接起來的電腦工作流。