下午三點，某個工程師回到一條放了好幾天的 Codex 對話。

桌上還有上次做到一半的網站、跑過的測試、審查者嫌字太擠的留言、Slack 裡等回覆的人、還有一份「上線前不要再忘」的清單。工程師沒有從零開始解釋背景，只補一句：「照昨天那個方向繼續，但先修側邊欄裡那個間距。」

這就是這波 Codex 變化最有意思的地方。重點不是「模型又更會寫程式」而已，而是 Codex 開始把電腦工作搬到同一張桌上：記憶留在 thread 裡，工具接到桌邊，成果放在旁邊可以直接看，必要時再用自動化把同一條工作流叫醒。

以前的 Codex 比較像坐在編輯器裡的寫程式助理。現在的方向更像一張會留下現場的工作桌。程式碼還在桌上，但旁邊開始多了瀏覽器、終端機、文件、行事曆、信箱、桌面 GUI、審查表面和共享記憶。

Mogu OS：
這裡最容易誤會成「Codex 加了一堆功能」。功能當然有加，但真正的戲在控制權：人不用把工作拆成十張小紙條丟給十個工具，Codex 也不用每次醒來都失憶。桌子還在，東西還在，下一輪可以接著做。這聽起來很普通，偏偏產品工作最常死在普通的地方 (⁠◕⁠‿⁠◕⁠)

持久 thread：桌子不用每天清空

短聊天最大的浪費，不是模型笨，而是每次都要重新擺桌。

昨天才講過命名規則，今天又要講一次。上週才決定哪個測試最會炸，下一輪又從頭踩。審查者喜歡什麼語氣、某個專案不能碰哪個檔案、哪封信還沒回，全部被鎖在舊對話裡。人類看得到歷史紀錄，但工作本身沒有真的接住它。

持久 thread 的價值，是讓對話變成長時間存在的工作空間。它不只是聊天逐字稿，而是桌面本身：文件、半成品、待處理事項和判斷依據都留在那裡。下一次回來，Codex 不必先問「所以背景是什麼」。

最適合釘起來的，不是一次性的「幫忙修這個 bug」，而是會反覆回來的工作流：

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

釘選和快速切換看起來只是介面細節，其實在講同一件事：thread 不是用完就丟的便條紙，而是可以回來工作的固定桌位。

Mogu 碎碎念：
「記得上一句話」不值錢，聊天機器人本來就該做到。值錢的是記得一整串工作脈絡：誰拍板、哪裡卡住、下次不要再問哪個蠢問題。這種記憶不浪漫，但它會直接省掉一堆「等等，之前不是說好…」的尷尬時刻。

語音：把還沒成形的工作先放上桌

很多工作剛開始時，不像指令，比較像一團還沒整理好的念頭。

「Slack 好像有人提過這件事，細節忘了，先去找。」這句話如果硬打成工單，會顯得很廢；用嘴巴講出來，反而很自然。因為人類啟動工作常常就是這樣：先把模糊的狀況丟上桌，再慢慢找邊界。

語音輸入的重點不是快幾秒，而是它保留了粗糙想法的形狀。兩分鐘的口述規劃、會議逐字稿、半句沒講完的疑問，常常比一段整理得很漂亮的提示詞更有料。裡面有猶豫、有優先順序、有真正卡住的點。

對能搜尋、整理、回報的 Agent 來說，「細節忘了，去找」已經不是爛需求，而是一個可開始工作的入口。語音把尚未成形的工作先放上桌，Codex 再去補足它缺的脈絡。

中途轉向、排隊、手機：人可以離桌，但不能消失

長任務跑起來以後，最麻煩的不是等，而是控制。

有時候方向當下就錯了。網站審查跑到一半，側邊欄裡看到畫面太擠、按鈕文案不對、某個區塊順序怪怪的，這時候需要的是中途轉向：把新指令插進正在進行的任務，別等整段跑完才發現做歪。

有時候現在的方向沒錯，只是後面還有下一步。修完網站後，把預覽連結丟給 Slack 裡的審查者；產出文件後，再整理成 PDF；測試綠了，再準備發佈清單。這是排隊：不打斷當前工作，只把下一件事放在桌邊。

中途轉向管「現在正在做什麼」，排隊管「做完以後接什麼」。兩者加起來，人才真的在迴圈裡，而不是站在模型旁邊盯到眼睛乾。

手機也在這裡變得合理。Codex 手機 app 的重點不是把整個開發環境塞進掌心，而是讓人離開桌前後，仍然能看進度、回答問題、批准下一步、修正方向。檔案、權限、環境變數和程式庫狀態留在 Mac 上；手機負責把人拉回決策點。

Mogu 畫重點：
手機版最怕被期待成「在手機上寫完整 PR」。那不是生產力，那是手指耐力測驗。比較健康的定位是：本機環境繼續跑，人去買咖啡也能批准、打斷、排下一步。手機不是工作桌，是桌上的呼叫鈴。

工具半徑：桌上開始有插座

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

第一圈是網頁。Codex 不只讀 HTML，而是看渲染後的畫面、操作頁面、回應畫面上的標註。很多 UI 問題只有看到成品才知道哪裡怪；這種工作不能只靠讀檔案。

第二圈是已登入的瀏覽器。內部工具、SaaS 後台、需要登入狀態才能進去的流程，開始有機會被接進同一張桌。

第三圈是桌面。沒有 API、沒有 CLI、只有視窗和按鈕的老流程，以前只能靠人肉。桌面操作把這類流程也拉進可描述、可檢查的範圍。

MCP server 和連接器可以先理解成桌邊的安全插座。Slack、Gmail、Calendar 不是因為名字潮才重要，而是因為很多工作一開始根本不是程式議題。它們是訊息、信件、排程衝突，或某個人丟來一句「這個能幫忙看嗎」。

當某個流程重複出現，就可以包成 Skill。Skill 不是魔法，而是一張貼在桌邊的標準作業卡：同樣的例行公事，不要每次都重新教 agent。

Mogu 歪樓一下：
Skill 的界線要克制。每天做、每次都漏步驟的流程，值得包；三週才出現一次、而且每次長得不一樣的怪任務，先別急著包。把工作桌整理好是美德，把桌子貼滿「也許哪天會用到」的規則，最後會變成另一種髒亂。

自動化與目標：讓 thread 自己醒來，也知道何時停

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

thread automation 更像替同一張桌子設定鬧鐘。每隔幾分鐘或幾小時，把同一條 thread 叫醒，回到既有上下文裡檢查狀態。條件還沒成立，就先等；條件成立了，再往下一步走。

有些排程工作適合從乾淨工作區開始，例如每日報告或固定程式庫檢查。有些工作則適合回到同一條對話，因為上下文本身就是工作的一部分。幕僚長型 thread 可以定期掃訊息和信箱，找出需要注意但尚未回覆的項目，先研究答案、草擬回覆，但不要送出。人回來時，最花時間的脈絡蒐集已經完成，真正的送出權限還在人手上。

回饋迴圈也是同一個邏輯：檢查 PR 留言、Google 文件留言或 Slack 回覆；重新產生成果；把需要審查的狀態帶回原本的 thread。如果最後一步只能透過桌面 GUI 完成，桌面自動化就補上那一段。

但自動醒來還不夠。長任務還需要知道什麼叫「完成」。目標功能的重點，不是把任務講得很熱血，而是給 Codex 一條真的終點線。

弱目標像「照這份 Markdown 計畫實作」。看起來清楚，其實沒有停車格。強目標會帶驗證器：把內部工具從 Python 搬到 Rust，不是「努力搬看看」，而是「新實作完成後，單元測試必須通過」。驗證器可以是測試套件、基準測試、錯誤重現、驗證矩陣，或一條必須持續通過的端到端流程。

沒有驗證器的目標，只是放在桌上的口號。Codex 可以很努力，但努力不等於抵達。

Mogu OS：
Goals 很容易被講成主角，但更準的看法是：目標只是桌上的終點線。真正讓事情動起來的是 thread、工具、排程、側邊欄和驗證器一起接好。沒有驗證器的長任務，就像任務標題寫「變強」兩個字。很燃，完全不知道該練哪塊肌肉。

側邊欄：成果要放在伸手碰得到的地方

成果一離開 thread，工作就開始裂開。

文件下載到別處，簡報另外開，網頁切到新分頁，表格丟進另一個工具，審查留言散在 Slack 或 Google Docs。名義上還是同一件事，實際上已經變成五個小宇宙。

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

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

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

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

Mogu 歪樓一下：
我會把側邊欄看成控制迴圈的一部分，不是漂亮 UI。成果如果離開 thread，下一步常常變成「再開一張票」。成果如果留在 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 的第一方記憶適合處理偏好、重複工作流與已知陷阱。另一類螢幕脈絡記憶工具，則往「從近期螢幕脈絡建立記憶」的方向前進。兩邊不用急著選陣營：產品內記憶像習慣，明文記憶像文件櫃。重要團隊脈絡通常需要後者。

Mogu 認真說：
我對 AI 記憶的偏好很保守：第一方記憶很好用，但重要團隊脈絡最好還是有明文版本。Markdown、資料夾、Git，這些東西一點都不炫，可是五年後還打得開。很多 AI 記憶系統最可怕的不是忘記，而是記得一堆沒人敢信的東西。

把舊文接回這張桌

這篇其實是把 gu-log 前面幾條線拉到同一張桌上。

SP-197 講的是 Goals 和驗證器：長任務不能只靠熱血，要知道何時算完成。SP-200 講的是 Markdown 記憶：重要脈絡要能被檢查、移動、版本化。SP-183 講的是替 agent 設計表面：成果不能只是給人看的，也要讓 agent 能操作。SP-196 則把個人 AI 放到更大的作業系統想像裡。

SP-210 的新角度，是把這些東西排成一條工作流：thread 留住現場，工具接到桌邊，成果留在側邊欄，外部記憶保存脈絡，驗證器決定什麼叫完成。

結語

Codex 的起點仍然是程式碼，但邊界已經不只在程式碼。

真正的變化是電腦工作的控制模型。以前人把任務切成很多段：去 Slack 找一句話、到程式庫改檔案、開瀏覽器看畫面、丟 Google Docs 等回饋、整理下一步、再回到終端機。每一段都要靠人把脈絡搬來搬去。

現在那張桌子開始留下來。thread 記得現場，工具半徑變大，手機把人拉回決策點，自動化讓工作自己醒來，側邊欄讓成果別逃出迴圈，明文記憶把重要脈絡收進文件櫃。

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