6 個讓 Codex 不再瞎忙的工作流 Skill

我作為一個用了 Codex 接近兩年的用戶。

在工作的過程中，整理了一些值得分享的 Skill。我認為它們很有價值，也很值得公開分享。

這些 Skill 怎麼來？

它們不是一開始就被設計出來的，而是我不斷觀察自己的行為：我如何糾正模型的工作，如何把模型拉回正確軌道，如何把一次次有效的干預提煉成可以重複使用的流程。

對我來說，方法論先存在於工作過程裡。當一個介入方式被反覆驗證有效，它就應該被固定成 Skill，讓模型下次在相似場景裡自動走對的路。

所以我把最近真實使用過的一批 Codex workflow 抽出來，整理成公開 repo：qoli/codex-workflow-skills。這裡不是一包 prompt，而是 6 個可以安裝的 Skill，用來處理上下文恢復、除錯紀律、文字改稿，以及小紅書內容交付。

我怎麼定義一個有效 Skill

我後來用四個問題判斷一個 Skill 是否值得沉澱：

• 觸發條件：什麼情境下應該使用它。
• 觀測順序：執行時應該先看哪些證據，而不是直接猜。
• 安全邊界：哪些行為必須明確禁止，例如洩漏 transcript、提交 .env、自動按下發布。
• 完成驗證：怎樣才算真的做完，而不是只產生一段看似合理的回答。

這樣寫出來的 Skill 就不只是一段 prompt，而是一個可重複執行的工作流。這次公開的 6 個 Skill 都是從實際任務裡留下來的；它們不是為了展示而寫，而是在我反覆遇到同類問題後，被固定成更可靠的流程。

1. 找回上下文：不要讓跨天任務重新開始

第一組是上下文恢復：codex-conversation-lookup 和 codex-session-distill-search。

案例：三天前的任務，不要重新解釋一遍

我給你一段舊 Codex 對話：《修正數據庫 v2 部署辦法》。
先用 codex-conversation-lookup 讀懂這段任務：它在哪個 repo、做到哪一步、
有沒有中斷或未提交變更。不要貼 transcript，給我一張可接續的路線圖。

這就是 codex-conversation-lookup 的典型場景。它的重點不是把舊對話全文貼出來，而是把 thread 轉成一張可接續的路線圖：

• 這段任務在哪個 repo / cwd 發生。
• 當時完成了什麼，卡在哪裡。
• 是否有中斷 turn、未完成 command、patch 或未提交變更。
• 下一步應該從哪個檔案、哪條 log、哪個 branch 開始。

這讓 Codex 不需要靠模糊記憶硬接，也不需要把私人 transcript 暴露出來。

案例：不是找一條 thread，而是看一整天

幫我看看昨天到底做了什麼。
不要只看 session title，請用 codex-session-distill-search 掃本地 Codex logs，
按 repo / 目標 / 完成狀態整理，並指出主線和被中斷的任務。

codex-session-distill-search 解決的是另一個問題：不是接續單一 UUID，而是回顧一段時間。我會問「昨天做了什麼」「今天為什麼這麼累」「這幾天主線是什麼」。它會先掃本地 Codex session，再用 samuelfaj/distill 這條管線做壓縮和索引，最後只打開少量來源 log 驗證。

這段流程有一個實作重點：我使用 samuelfaj/distill 的 CLI / pipeline，但不直接依賴它內建的 local 1.7B 模型。按照我在《初始化並推送私有倉庫》裡的測試，內建模型很快，但在我的 noisy session summary 場景裡不夠穩；我更傾向讓 distill 走本地 oMLX endpoint 的 gemma-4-e4b-it-8bit，先整理 session title、cwd、assistant summary 和命令線索，再回讀少量來源 log 驗證。

重點不是換一個模型崇拜，而是讓「看一整天」這件事比只看 thread title 更可靠。

2. 約束除錯：先縮小未知，再改程式

第二個 Skill 是 observability-first-debugging。

案例：bug 還沒界定，不准先改三個檔案

這個同步流程偶爾失敗，但我還不知道是 API、資料庫、queue 還是 UI 狀態問題。
使用 observability-first-debugging：先列出未知，選最小觀測點，
加必要的 logs / assertions，重現後再決定要不要修 code。
臨時 instrumentation 在定位後要移除。

observability-first-debugging 是我最希望 agent 固化的一條規則：當問題還沒被界定時，不要急著修。先找能縮小未知的觀測點。

這個 Skill 在我的使用裡通常不是我手動點名才啟動，而是模型遇到 debugging、排查、復現、加 log、縮小問題範圍時會自動調用。引入它之後，我能明顯感覺到模型直接猜原因、直接改實作的狀態大幅減少；它更常用「日誌包圍 Bug」的方式，把問題一圈圈框起來，再根據觀測結果漸進式處理。

這裡的重點不是「多加 log」，而是每次只加能回答下一個問題的觀測。例如：

• 狀態來源是哪個分支？
• SQLite 裡是否真的有這筆資料？
• 失敗發生在 request、解析層、外部 API，還是 UI rendering？
• runtime 真壞，還是只有 wrapper 壞？

一旦證據把問題邊界縮小，再動手修。臨時 instrumentation 也應該在問題確認後移除，只留下長期有價值的觀測。

3. 找第二支筆：用 cli-model-chat 改善文字

cli-model-chat 是這批 Skill 裡我最看重的一個工作流。它表面上只是「問 DeepSeek 一個問題」，但真正有價值的是刻意引入一個沒有上下文的新角度。

在持續工作的 Codex session 裡，連續性是優點，也是污染源。前面任何一句話、任何一次修正、任何一個已經形成的偏好，都會留在任務裡，讓後面的判斷越來越像是在沿著既有路線補強，而不是重新檢查問題本身。這對接續開發很有用，但對寫作、審稿和重新判斷主線，反而可能讓我和 Codex 一起陷在同一個框架裡。

所以我需要一個沒有歷史包袱的模型。它只拿到我這次精選給它的問題和摘錄，不知道 repo、不知道前面爭論過什麼、不知道我剛才偏向哪個答案。這不是能力不足，而是設計目的：讓它從 outside the box 的位置看文本。如果它看不懂，往往代表真實讀者也可能看不懂；如果它指出的問題刺耳，也可能正是長 session 裡最容易被我們忽略的盲點。

因此 cli-model-chat 的邊界必須很硬：第二模型不接管 repo、不讀本機、不自動改文件，也不變成多代理共識系統。它只是一個被明確提問、明確退出的外部讀者。

我在 X 上用更直接的方式說過這件事：我始終更喜歡 DeepSeek 的文學水平，因為寫文章不只是把意思說完，還包括敘事、節奏和審美。Codex 很適合作為執行型工作者，但它不應該被默認視為文章審美的最終判斷者。所以我才會寫一個 Python 腳本，把 DeepSeek API 包成單次、無上下文的對話呼叫，讓 Codex 在需要文字判斷時，去請教一個更像外部編輯的模型。

所以第二模型不是備援，而是一個被刻意設計出來的方法論角色：外部編輯。它用沒有上下文的方式，守住文字、敘事和判斷的品質。

案例：不是 MCP 編排，而是一對一第二模型

我只是想讓 Codex 能問另一個模型一句話，拿回回答。
不需要 sub-agent，不需要 workflow，不需要 map-reduce。
如果沒有合適的 MCP，就自己寫一個 CLI + Skill。

這條 workflow 來自《尋找 MCP 模型橋接工具》。一開始我找的是「透過 MCP 和另一個模型通信」的工具，但很快發現很多 MCP 方案不是維護狀態差，就是把問題做得太大。真正需要的只是 narrow bridge：把一個聚焦問題交給 DeepSeek，拿回一段回答。

所以最後做成了 cli_model_chat.py + cli-model-chat Skill：預設模型是 deepseek-v4-pro，credential 只放本機 .env，不寫進 repo；除非我明確說要 Codex provider，否則一律走 DeepSeek。如果真的要用 Codex provider，也要跑在臨時空目錄、read-only、ephemeral、ignore config 的隔離模式裡。這個設計讓第二模型保持「對話工具」，而不是變成另一個可以亂動工作區的 agent。

案例：完整文章審稿，只給文章，不給 repo

請從讀者能否學到可操作方法的角度審稿：
1. 主線是否成立？
2. 哪些段落仍像觀點而不是方法？
3. 最值得保留的 3-5 條可複用指令是什麼？
4. 哪裡應補驗收標準或反例？
5. 圖片位置和文字節奏是否服務主線？
6. 最小修改建議，按優先級排序。

下面只貼完整文章正文和圖片占位，不給 repo、Notion token 或本機路徑。

《整理 Codex 協作經驗》是更典型的內容場景。我當時在寫 RonnieCC / Codex 設計協作文章，目標不是讓模型稱讚文章，而是檢查它是否真的有「乾貨」。我用 cli-model-chat 分別問 DeepSeek 和隔離 Codex，但兩者意見保持分開，不揉成一個平均結論。

這次最有用的不是「第二模型也覺得文章好」，而是它們指出了不同問題：DeepSeek 更關注開頭太長、太晚進入可複用方法；Codex 更關注後半段結構像細節合集。後來修改文章時，也不是全盤接受，而是只採納被我確認有價值的建議。這讓第二模型成為 editor，而不是裁判。

這篇 Skill Blog 本身也用過同一套做法。第一版更像內部決策記錄，DeepSeek 直接指出它不是 public share article，而是 internal log；這個刺耳判斷反而很有用，因為它證明「沒有上下文的讀者」能看出我們在長 session 裡習慣忽略的問題。

4. 拆開內容交付：設計、驗證、發布不能混在一起

第四組是小紅書內容工作流：xhs-figma-cards 和 xhs-publish-handoff。

幕後：為什麼從 HTML 轉向 Figma

我交付一篇 Blog，例如 appinn-draft.md。
先不要急著做圖：先拆成小紅書多圖 markdown 預交流稿，確認卡片順序、文字密度、截圖意圖。
確認後，再用 xhs-figma-cards 寫入 Figma，建立 1080x1440 image cards。
後續我可以直接在 Figma 裡改，你也要從當前畫布繼續，不要回到舊稿。

xhs-figma-cards 不是一開始就長成 Figma-first。它經歷過一次很明確的交付面切換：最早的小紅書工作區是在 aDict landing page repo 裡建立的，當時主路線是 HTML/CSS 生成圖卡。流程是 Blog -> markdown 預交流稿 -> HTML 多圖 -> 視覺檢查 -> 使用者確認 -> 發布交流；Auto-Redbook-Skills 只做尺寸參考，white0dew/XiaohongshuSkills 放在末端發布流程。

HTML 方案的好處是可重複、可版本化、可放進 repo。但真實跑起來後，它的問題也很明顯：圖卡不是只要能生成，還要能被快速預覽、直接介入設計、在同一個畫面上來回改。當參考案例顯示小紅書卡片應該更像「App Store 截圖式賣點圖」而不是長文章拆卡時，HTML 模板的修改成本開始變高。你後來的判斷更直接：Figma 更方便預覽，你可以直接介入設計，Codex 也能操作同一個畫布。於是 runbook 被切到 Figma MCP-first，HTML 只保留為 fallback / historical reference。

後來在《評估 Codex 小紅書價值》裡，Figma-first 的價值更清楚：Card 01 可以先做純文字呼喚，Card 02 可以基於手機截圖和你的審美反饋迭代；如果 Figma MCP 的低階工具不夠，還可以用 imagegen 做 raster poster，再把通過視覺檢查的位圖貼回 Figma。Figma 在這裡不是單純設計工具，而是我和你共同審稿的工作面。

所以 xhs-figma-cards 的價值不是「會寫小紅書文案」，而是把內容設計變成可審、可修改、可追蹤的交付流程。它會先決定路線：

• 可編輯 Figma layout。
• imagegen 生成主視覺，再貼回 Figma。
• 兩者混合：主視覺生成，文字和標籤留在 Figma。

這裡需要一個能操作 Figma 的 adapter。我的流程驗證過 qoli/figma-mcp-go，但 Skill 不應該把它寫死成唯一方案。真正需要的是能力：能 inspect page、create/update frame、edit text layer、import asset，以及在使用者改過畫布後讀取當前狀態繼續工作。只要其他 Figma MCP 或 automation adapter 提供同等能力，也應該可以替換。

案例：卡片已經輸出，進入發布前交付

這 7 張 PNG 已經從 Figma 匯出，請用 xhs-publish-handoff 驗證發布包。
檢查圖片數量、尺寸、排序、標題長度、正文長度、hashtag。
如果我確認，再打開小紅書創作者後台填入內容。
停止在最終「發布」按鈕前，不要替我點擊。

xhs-publish-handoff 只處理發布前交付。它會驗證圖片數量、尺寸、排序、標題、正文、hashtag，再視需要用已登入的瀏覽器 session 打開創作者後台、上傳圖片、填入內容。

但它有一條硬邊界：不自動點擊最終發布。

這很重要。Figma 產圖、瀏覽器填表、平台發布是三種不同風險等級的操作。前兩者可以自動化，最後一步必須保留人工授權。

怎麼安裝

repo 在這裡：

qoli/codex-workflow-skills

如果你使用 Codex，可以把需要的 Skill 目錄 symlink 到 $HOME/.codex/skills：

mkdir -p "$HOME/.codex/skills"
ln -s "$PWD/skills/codex-conversation-lookup" "$HOME/.codex/skills/codex-conversation-lookup"
ln -s "$PWD/skills/codex-session-distill-search" "$HOME/.codex/skills/codex-session-distill-search"
ln -s "$PWD/skills/observability-first-debugging" "$HOME/.codex/skills/observability-first-debugging"
ln -s "$PWD/skills/cli-model-chat" "$HOME/.codex/skills/cli-model-chat"
ln -s "$PWD/skills/xhs-figma-cards" "$HOME/.codex/skills/xhs-figma-cards"
ln -s "$PWD/skills/xhs-publish-handoff" "$HOME/.codex/skills/xhs-publish-handoff"

如果你只需要其中一兩個，也可以只安裝對應目錄。

我刻意沒有公開的部分

另一些 Skill 我仍然留在本機，例如 RonnieCC 發布、Notion Blog、hatch-pet、Syncnext plugin maintenance。不是因為它們不重要，而是它們太依賴我的 repo、資料庫、帳號和發布節奏。

這次公開 repo 的標準很簡單：能離開我的私人環境仍然有用，才公開；綁定私人流程的，只作為文章案例提及。

把工作過程中的方法論提煉成 Skill

這次整理後，我更確定：值得分享的不只是這 6 個 Skill 本身，而是它們代表了一種工作方式。不是先有 Skill，再從 Skill 裡總結方法論；而是在真實工作裡，我已經反覆用某些方法糾正模型、推進任務，當這些方法穩定有效，就應該被提煉成 Skill。

這套方法可以拆成幾個層次：遇到跨天任務時，先把上下文接回真實現場；debugging 時，用證據包圍問題，而不是猜原因；寫作時，引入沒有歷史包袱的外部編輯；到了小紅書這類交付任務，再把設計、驗證、填表和發布授權拆成不同環節。這些方法先在工作中成立，後來才被固定成 codex-conversation-lookup、codex-session-distill-search、observability-first-debugging、cli-model-chat、xhs-figma-cards 和 xhs-publish-handoff。

還有一個 Skill 我沒有放進公開 repo，但很適合作為「方法論如何沉澱成 Skill」的最後例子：ronniecc-content-publisher。它不是寫作 Skill，而是發布與驗證 Skill。它把 Notion Blog database 當成內容源，強制同步到 RonnieCC，重新 build 靜態站，再把需要分發的文章同步到 aDict Blog mirror，檢查 SEO slug、canonical URL、sitemap、GitHub Pages workflow 和 Worker sitemap。

請使用 ronniecc-content-publisher：
從 Notion Blog database 做 full sync，重建 RonnieCC，
再同步 aDict Blog mirror，推送變更，等待 Pages 部署，
最後驗證 live blog index、sitemap 和 Worker sitemap。
不要只告訴我文章已經寫好，要確認它真的可被讀者看到。

這個 Skill 不適合公開原樣分享，因為它太綁我的 Notion database、RonnieCC repo、aDict mirror 和 Worker sitemap。但它說明了同一個方向：當我在知識分享裡反覆需要取材、查證、改稿、審稿和發布驗證，這條方法就應該被固定成可執行的 Skill；人的責任則是決定什麼值得寫、哪些案例成立、哪些細節該刪，以及哪個環節必須保留人工授權。

如果你也在長期使用 Codex 或其他 coding agent，可以先不要急著收集更多 prompt。更值得做的是，回頭看自己最近反覆糾正模型的三個場景：你總是在什麼時候介入？你先看哪些證據？哪些行為你一定會禁止？你怎樣判斷任務完成？

回到前面那四個問題：觸發條件、觀測順序、安全約束、完成驗證。它們不是抽象框架，而是我在反覆介入模型後留下的檢查表。當這些答案穩定下來，就可以把方法寫成 Skill。Skill 不是方法論的來源，而是方法論被反覆驗證後的可執行形態。