自己的AI助理自己養！OpenAI工程師曝5大Codex進階用法，打造「專屬AI貼身特助」|數位時代 BusinessNext

如果你已經把 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。