# 策展 · X (Twitter) 🔥

> 📖 本站完整內容索引（documentation index）：[llms.txt](/llms.txt)

> 作者：Nick (@nickbaumann_) · 平台：X (Twitter) · 日期：2026-04-11

> 原始來源：https://x.com/nickbaumann_/status/2042705384306336083

## 中文摘要

# 我提供給 Codex 最好的工具是客製化的 CLI

當工具可以表達為精確的指令時，Codex 在使用工具方面的表現非常出色。

這聽起來很顯而易見，但它改變了我思考如何讓 Codex 存取我日常使用工具的方式。

Connector 或 MCP server 對於存取資料非常有用。我就是這樣使用 Slack、Linear 和 Sentry 的。但有時原始輸出的資料量太大、太雜亂，或者直接丟給 Codex 處理顯得太過笨拙。在這些情況下，我通常希望有一個輔助工具：一個帶有旗標 (flags)、穩定 JSON 格式、可預測錯誤訊息以及說明視窗的指令。

![](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/1775914828593-iaHFkkQDdaUAAT3Nfjpg.jpg)

這賦予了 Codex 它本來就非常擅長使用的東西。

它可以進行搜尋、縮小範圍、重試、透過管道 (pipe) 傳輸輸出、將大型結果寫入文件、檢查 `--help`，並根據上一次的結果組合出下一個指令。這幾乎不需要什麼繁瑣的準備工作。

如果你只是想要這套操作手冊，我已經在這裡寫下了如何讓 Codex 建立一個這樣的工具：

> 建立一個 Codex 可以使用的 CLI：https://developers.openai.com/codex/use-cases/agent-friendly-clis

第一部分是使用 Codex 來建立 CLI。第二部分是將該 CLI 封裝成一個 Skill，以便未來的 Codex 執行緒知道首先要執行哪些指令、要提取多少輸出，以及哪些操作需要經過批准。

以下是我實際以這種方式使用的三個 CLI。它們並非 Connector 的替代品。當我希望 Codex 在處理大型資料來源，卻又不想將整個資料拖入執行緒時，它們就會與 Connector 並肩運作。

## Codex 執行緒

我過去的 Codex 執行緒中充滿了有趣的模式，我希望從中學習並將其編碼為未來有用的 Skill 和自動化流程。

我一直讓 Codex 參考它自己的執行緒。我還有一個自動化程式，會掃描最近的執行緒，找出值得保存為 Skill 的模式。

原始的對話存檔太過雜亂，不適合直接丟給 Codex。它包含了工具輸出、部分的嘗試，以及僅在當下有用的上下文。你可以告訴 Codex 直接讀取它的執行緒。這確實可行，但如果你頻繁這樣做，速度會變慢且資訊會變得雜亂。

![](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/1775914828597-iaHFkkdkuakAATXIdjpg.jpg)

所以我使用了 `codex-threads`。

```bash
codex-threads --json sync
codex-threads --json messages search "build a CLI" --limit 20
codex-threads --json threads resolve "tweet idea"
codex-threads --json threads read <session-id>
codex-threads --json events read <session-id> --limit 50
```

它會在 `~/.codex/sessions` 維護一個可供本地搜尋的索引，然後提供指令給 Codex 來搜尋、解析和讀取舊的執行緒。

當我想要將一個執行緒轉化為 Skill 時，這特別有用。許多優秀的 Skill 都是從「找到執行順利的那條執行緒，然後保留該模式」開始的。

## Slack

當答案隱藏在一個我無法手動找到的執行緒中時，我會要求 Codex 讀取 Slack：例如為什麼會做出某個 app-server 驗證決策、其他人是否也遇到了同樣的本地開發錯誤，或者審查人員在發布頻道中已經同意了什麼。

![](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/1775914828588-iaHFkg17wakAUjQn5jpg.jpg)

Slack Connector 很有用，但當 Codex 擁有指令形式的工具時，重複的研究會變得更容易：

```bash
slack-cli search "app server auth" --all-pages --max-pages 3 --json
slack-cli resolve-permalink "https://openai.slack.com/archives/..."
slack-cli read-thread L143 123522523239.633199 --json
slack-cli context R152 25723525099.626199 --before 5 --after 5 --json
```

這讓 Codex 可以進行廣泛搜尋、解析確切的執行緒、提取周邊的上下文，並引用重要的訊息。

`slack-cli` 仍然使用經過批准的 Codex apps 閘道。它不是一種繞過權限的方法。它採用相同的存取模型，只是將其塑造成 Agent 可以組合的指令。

## Typefully

我經常使用 Codex 來撰寫和排程內容，而我使用 Typefully 來處理這些工作。

Typefully 有一個很好的 API，但我不需要 Codex 每次在我需要草稿協助時都重新學習整個 API。我只需要我實際會用到的那幾個操作：

```bash
typefully-cli --json drafts list --social-set <id> --limit 20
typefully-cli --json drafts read --social-set <id> <draft-id>
typefully-cli --json drafts create --social-set <id> --body-file draft.json
typefully-cli --json media upload --social-set <id> ./image.png
typefully-cli --json queue schedule-read --social-set <id>
```

所以我讓 Codex 讀取 API 文件並建立 `typefully-cli`，這是一個我可以從任何儲存庫執行的輕量級 Rust 二進位檔。

圍繞它的 Skill 與二進位檔本身一樣重要。它告訴 Codex 要使用 JSON、預設建立草稿、在 Shell 引號變得麻煩時使用 body file，並且除非我明確要求，否則永遠不要發布、排程、刪除或覆寫任何內容。

最後這一點才是重點。我不希望每次請求協助撰寫貼文時，都要不斷輸入「不要發布這個」。

## 建立一個

有用的部分其實很簡單：如果我一直把同樣的文件、匯出資料、日誌或 API 的怪異之處丟給 Codex，我通常會希望停止解釋這些，而是直接給它一個指令。

然後，我將該 CLI 封裝成一個 Skill，這樣 Codex 就會記住如何使用它。如果你希望 Codex 為你自己的工具建立其中一個工具，我已經在這裡寫下了操作手冊：

使用案例：https://developers.openai.com/codex/use-cases/agent-friendly-clis

$cli-creator：https://github.com/openai/skills/tree/main/skills/.curated/cli-creator

## 標籤

Codex, CLI, MCP, Skills, OpenAI, Codex