如果你已經把 Cursor、Claude Code、ChatGPT 用得很順，下一個讓你「再升一級」的問題不是換更強的模型，而是怎麼讓工作不要「死」在對話縫隙之間。
OpenAI Codex 團隊的開發者體驗工程師 Jason Liu (jxnl)，同時也是 Python AI 套件 Instructor 的作者，近期在長文〈Codex-maxxing〉中分享了他過去半年的工作方式：把 Codex 從「協助寫程式的助理」，逐步改造成能持續運作、跨工具、跨時間段「替自己處理事情」的特助。
他坦言：「我在意的不是 agent 能幫我寫程式，而是我離開之後，工作能不能繼續推進。」
如果你已經會寫 prompt，這篇真正要談的是下一步：不要只把 AI 當成一次性回答機，而是把 prompt、記憶、工具權限與排程串成一條可持續運作的工作流。
第一招：把重要工作主題「釘選」成長期對話串
第一步，是不要把每個任務都切成孤立的新對話。Jason 會為每個重要工作流維持一條釘選的對話串，例如：
- 「個人幕僚長」（原文 Chief of Staff，負責統整訊息、排序待辦與草擬回覆）
- 「Agents SDK」（產品開發）
- 「OpenAI CLI」（內部工具）
- 「Twitter monitor」（市場情報）
- 「Codex for OSS」（社群專案）
這些不是普通聊天記錄，而是長期工作的專案線。他形容它們是「megathreads」，已經壓縮 (compact) 了好幾個月。
重點是，每條對話串都保留了該工作流的偏好、過去決策與未完事項，每次回來不必重新交代。
編按：Codex 設有快捷鍵：用
Command-1到Command-9直接跳到對應的釘選對話串。
另外要注意的是，長對話串的 token 成本通常高於短對話串（每次回來都不在cache內）。因此，Jason的取捨是：對在意的工作流，連續性值得這筆錢。
第二招：把記憶丟出對話串，存進「可審視的檔案」
只有長對話串還不夠。Jason 點出一個關鍵問題：如果記憶只留在聊天紀錄裡，就很難檢查、整理，也可能在壓縮時失真。對話串能累積脈絡，但它不是可靠的知識庫；你不知道哪一輪壓縮會捨棄哪段，也很難回頭審視「agent 到底記住了什麼」。
他的解法是把記憶從對話串裡搬出來，改放到一個資料夾裡，讓 AI 每次工作前先讀過。
Jason 用的工具是 Obsidian，是一個把純文字檔當筆記的免費軟體，所有筆記都是一般的 .md 檔，可以用任何編輯器打開。任何資料夾結構都可以，他自己長這樣：
專案資料夾/
├── TODO.md # 待辦清單
├── people/ # 跟我合作的人
├── projects/ # 進行中的專案
├── agent/ # 給AI看的指示
└── notes/ # 隨手筆記
想自己從零開始建一套嗎？
《數位時代》先前在〈用Claude Code管理100篇研究筆記！OpenAI共同創辦人公開LLM知識庫系統，貼一段指令就能建起來〉裡示範了起手式：裝好 Obsidian、把資料夾指給 Claude Code，再貼一段指令，AI 就會自動把整個知識庫的骨架幫你建好。建立完成後再回來看 Jason 的進階用法，會更有感。
最關鍵的一步，是在資料夾頂層放一個叫 AGENTS.md 的純文字檔。它的作用不是補充資料，而是定義 agent 在這個工作區裡的行為規則：要讀哪些檔案、怎麼更新記憶、哪些事可以做、哪些事必須先問。AI 每次進到這個資料夾工作前，都會先讀過這份檔案。
Jason 在 AGENTS.md 裡寫的指示大意是：「當你對某個人有更多了解、某個專案有進度、某項未完成事項可以收掉時，把對應的頁面更新一下。」翻成日常版本就是：
- 「當你對某個人（同事、客戶、朋友）有新的了解，更新
people/裡那個人的檔案」- 「當某個專案有新進度，更新
projects/對應的頁面」- 「當某項待辦完成了，把
TODO.md對應那行劃掉」
AI 看到這份守則後，每次工作完就知道學到的東西要記到哪個資料夾、哪個檔案。下次再來，它先讀過守則、再翻一下相關檔案，就能接上前一次的脈絡，不需要你重新交代。
換言之，這個方法把「對話記憶」變成「可審視、可編輯、可重用的工作日誌」。Jason 強調：「我要它把學到的東西都寫下來。」
這個原則跨領域都能套：
- 業務：
clients/放每個客戶的偏好與往來紀錄，pipeline.md放這個月在追的案子，工作守則寫「每次跟客戶通話完，更新對方檔案裡的『最新關注點』」。下次 AI 幫你擬報價或排會議前，先讀過這幾份檔案。- 行銷：
campaigns/放每檔活動的目標與成效，tone.md放品牌口吻範例與禁用詞，工作守則寫「下次寫文案前先讀過tone.md，產出後把素材歸檔到對應 campaign」。- 客服：
faq.md放常見問題標準答覆，escalation.md放升級處理流程，工作守則寫「遇到 FAQ 之外的問題，把問題與最後處理方式記到unresolved.md」。下次再遇到類似問題，AI 就有得參考。
共通做法是把工作流程拆成幾個資料夾，把規矩寫進一個 AGENTS.md，剩下讓 AI 自己邊做邊整理。
一開始不用設計完美架構；先有一份待辦、一個專案資料夾、一份工作守則，就能開始。資料夾結構其實不重要，重要的是「規矩寫清楚，檔案AI跟你都知道放在哪」。
第三招：用 Automations 讓對話串自動跑
這一招是 Jason 文章中最具操作性的部分。
Jason 在文中把這類做法稱為 Heartbeats；對照 OpenAI 官方文件，公開功能名稱是 Automations。它的價值不是「定時提醒」，而是讓同一條對話串帶著既有脈絡定期回來執行：檢查、整理、草擬、等待事件發生後接續處理。
原文提到三個實例：
個人幕僚長（每 30 分鐘執行一次）
每 30 分鐘檢查一次 Slack 和 Gmail，
找出需要我注意、但我還沒回覆的訊息。
幫我判斷哪些最重要。
如果有人問我問題，請盡可能深入查資料，
先幫我草擬回覆，但不要送出。
「等我回到 Slack，回覆通常已經存在 drafts 裡。最花時間的搜集脈絡那一段，agent 已經做完。」
Amazon 客服退款（等待事件發生後接手）
第二個例子更生活化。Jason 說，自己有一次包裹被偷，Amazon 客服頁面顯示大約要等 25 分鐘才會有真人客服加入。這種情境麻煩的地方不是「怎麼跟客服說話」，而是你得一直盯著畫面，等客服出現後立刻接續處理。
於是他建立一個 @computer 對話串，讓 agent 直接操作電腦畫面，並下這樣的指令：
每 5 分鐘檢查一次客服人員是否已加入這個對話。
如果客服上線了，請盡力幫我完成退款。
一旦客服回覆，改成每 1 分鐘檢查一次，
這樣你可以更快接續回應。
他的重點不是炫耀 AI 會退貨，而是說明 Automations 可以處理這種「先等待、事件發生後再加快反應」的任務。
最後他洗完澡回來，退款已經辦好了。這類自動化若涉及發送訊息、付款、刪除或帳務操作，最好事先設定「先草擬、先詢問，不要直接送出」的規則。
動畫專案的回饋循環
他在 Slack 貼了一支影片，請 Codex 每 15 分鐘檢查留言，有新意見就重新算圖、回 Slack 並 tag 留言者。中間 Slack MCP（讓 AI 連接外部工具的一種介面）不支援上傳檔案，agent 就改用 @computer 點 Add file 按鈕硬上。
「真正的價值不是『agent 會每 15 分鐘檢查一次』，而是這個迴圈跨了三個工具：Slack 收回饋、Remotion 渲染、@computer 上傳。」
第四招：寫得起的目標 = 明確 + 可驗證
接著是 Goals。它處理的是比單次 prompt 更大的任務：你不是只叫 AI「做一件事」，而是給它一個可以反覆推進的大目標。Jason 對 Codex 的這個功能有一句話評論：「有野心，但要有驗證標準。」
他舉的最近案例：把 Python 的終端顯示套件 Rich 完整移植到 Rust。為什麼這個目標 Codex 能跑：
- 野心夠大：整個函式庫的移植
- 驗證標準明確：必須通過 Rich 原本的全部單元測試
「弱目標是『執行這個 Markdown 計畫』。強目標是給 agent 一個它可以反覆推進的成功條件。」沒有驗證機制的執行，是在許願，不是在工作。
這個原則不只工程師用得到。把它翻譯到不同職能身上，差別只在「驗證標準長什麼樣」：
| 角色 | 弱目標（許願） | 強目標（可驗證） |
|---|---|---|
| 業務 | 「幫我整理一份潛在客戶名單」 | 「從 CRM 抓出過去 90 天未聯絡、年營收 1,000 萬以上的客戶，產一份依採購意願排序的清單，附三句話聯絡理由」 |
| 行銷 | 「幫我想幾個社群貼文標題」 | 「給我 10 個標題，每個都符合：≤20 字、含一個具體數字、不用『極致』『顛覆』等空洞詞、第一句必須是問句或反差陳述」 |
| 編輯 | 「幫我潤這篇稿」 | 「砍掉所有破折號開頭的補充句、把 5 個以上的條列改成散文、文末加一段 3 行內的觀點作結」 |
總之，重點是把模糊形容詞（好、漂亮、完整）換成可數的、可比對的、可勾選的條件。
Jason 強調的「驗證標準」，本質就是一種「規格表」，因為agent只能透過客觀標準來自我驗證。
第五招：把產出物搬進「側邊欄」一起看
最後是側邊欄 (side panel)。它把 Codex 從「文字回覆框」往「工作台」推進：文件、網頁、小工具可以直接打開，一邊看、一邊標註、一邊改。
Jason 認為這是 Codex 最被低估的功能。在側邊欄裡，agent 可以同時：
- 渲染 Markdown、試算表、CSV、PDF、簡報並讓你即時標註
- 操作 in-app 瀏覽器（用 JavaScript 透過
$browser控制）- 並列開 Storybook、Remotion Studio、Slidev（簡報工具）、Streamlit 等 UI 工具
他特別推一個小技巧：請模型做一個單檔 index.html，把它丟進側邊欄，「不需要 server、不需要 build、立刻能互動」。比 Markdown 更接近一個可操作的小應用。
為什麼這招好用？因為大多數工作的最後一哩，不是「拿到一份文字答案」，而是「在這份東西上面再改一輪」。靜態的 Markdown 答案只能讀，互動的 HTML 可以點、可以填、可以即時看結果。
以下舉三個非工程師也能直接複製的場景：
- 業務報價試算頁：請 agent 做一個單檔 HTML，左邊輸入客戶規模、合約期、付款方式，右邊即時算出報價單與毛利。改條件就改參數，不用回頭跟 agent 重述前提。
- 行銷貼文 A/B 對照器：請 agent 把同一篇貼文的 3 個版本並排顯示，下面加一個「字數／emoji 數量／hashtag 數」即時統計，順手就能挑出最適合的一版。
- 編輯校對 checklist：把這篇文章的待查事項（人名拼寫、數字交叉、連結是否失效）做成一個有勾選框的 HTML，跑完一輪心裡有底。
共通點是：side panel 讓 agent 的產出不再只是「最終答案」，而是「下一輪迭代的起點」。
你不必真的會寫前端，只要能把需求說成規格：「我要一個有 X、Y、Z 欄位、按鈕按下去做 W 的單檔 HTML」，剩下交給 agent。
結語：自己的AI助理自己養
Jason 在文章中總結了一句話：「工作不該因為我換了地點、換了裝置、結束了當前對話就停下。」
先把工作主題拆成釘選對話串；再把記憶丟出對話串、存進可審視的檔案；接著用 Automations 讓它定期推進；最後給每條對話串一個明確的成功條件。
把 agent 養成一個會自己往前走的特助，比單次寫程式的提示工程，更接近 AI 真正改變工作方式的那一段。
資料來源：Codex-maxxing — Jason Liu、Jason Liu 個人介紹、OpenAI Codex、OpenAI Academy：Codex Automations、OpenAI Help：Using Codex with your ChatGPT plan、OpenAI Help：Codex remote access from ChatGPT mobile
本文初稿為AI編撰，整理．編輯/ 李先泰
