Codex CLI 讓你在終端寫程式

我把這篇 Codex 上手說明拆成了終端可直接用的工作流模板。

我用過不少 AI 寫 code 工具，最煩的不是它們不會寫，而是太愛搶方向。你叫它補一個函式，它順手把整個模組改掉；你想在終端先跑一小步，它偏要把 IDE、插件、帳號、訂閱全綁進來。最後的感覺就是：工具很多，手感很差。

我這次拆的是知乎這篇 《如何配置使用 Codex 編寫代碼 — 完整上手指南（更新VScode安裝codex插件使用入口）》。原文有一句我覺得講得很準：

如果你重視靈活性和多模型支持，或者是在 Linux 伺服器上工作，Codex CLI 是首選；如果更習慣在 IDE 內工作，可以考慮 Cursor；如果已經有 GitHub Copilot 訂閱，可以繼續保留。

這句話其實把重點說透了：別把 AI 編程想成單一產品，要把它當成一套工作方式。

我把它拆開後發現，真正有價值的不是「裝了哪個插件」，而是你怎麼把終端、編輯器、模型和權限邊界拼在一起。下面我按這個思路講，順手給你一個能直接抄的版本。

先別問哪個最強，先問你在哪寫 code

原文先用工作場景分流，我覺得這比談功能清楚多了。工具不是越全越好，越貼近你現在環境越好。Linux 伺服器、SSH、容器、純終端，這些場景裡你根本不想先折騰一個重 IDE；反過來，如果你每天都在 VS Code 裡切檔案、看報錯、跳定義，那 IDE 內助手就比終端裡來回切窗舒服得多。

我自己最早踩的坑，就是把「能不能寫」當成第一標準，結果裝了一堆擴充套件，最後每次都要先想：我到底是在本地改、遠端改，還是在容器裡改？一旦上下文不清，AI 的建議就會越來越像瞎猜。

翻譯一下就是：先選入口，再選模型。你不是在選信仰，你是在選工作姿勢。

• 終端優先：適合 Linux、SSH、容器、腳本式改動。
• IDE 優先：適合日常函式修改、重構、定位錯誤。
• 訂閱優先：如果你已經有 Copilot，不必為了「統一」硬換工具。

我建議你先把入口想清楚，再談模型。入口錯了，後面全是補丁。

Codex CLI 的價值，不是酷，是少折騰

我看 Codex CLI 的第一個感受，不是「哇好潮」，而是它把很多中間層砍掉了。你不用先打開一個重型介面，不用為了一個小任務在多個面板裡找按鈕，也不用擔心插件版本和編輯器版本互相打架。它比較像把「寫 code」變成一個命令列任務。

我理解這種工作流的意思是：你給它一個目錄、一段上下文、一條修改目標，它就開始幹活。對我這種常常在 repo 裡來回切換的人來說，這種方式很省腦子。

我之前跑類似流程時最明顯的感受是，終端裡做事更像「發工單」。你可以明確告訴它改哪裡、別碰哪裡、做完後跑什麼檢查。這個邊界感很重要，因為 AI 最怕的就是自由發揮。

實操上，我會把 CLI 使用拆成四步：

• 先進入正確的 repo 和分支。
• 只給當前任務相關的檔案和說明。
• 明確要求它先列計畫，再動手。
• 改完立刻跑測試或 lint，不要拖。

如果你在伺服器上工作，這種方式尤其順手。遠端環境裡最煩的就是圖形介面不穩、插件不相容、同步慢。CLI 沒那麼多戲，反而更穩。

IDE 不是落後，只是更適合另一種節奏

原文提到 Cursor 作為 IDE 內工作的一種選擇，這點我同意。Cursor 的優勢在於，它把 AI 放進你本來就在用的編輯流程裡，而不是逼你切到另一個工作台。你在看 code、改 code、看 diff 的時候，助手就在旁邊，這種連續性很值錢。

它的實際意義是：當你需要頻繁跳轉、快速看上下文、邊改邊看結果時，IDE 內助手更順手。尤其是重構、補測試、看錯誤鏈路這種活，編輯器裡的上下文窗口比命令列更直觀。

但我也得說，IDE 內工具很容易讓人變懶。因為它太方便了，你會不自覺地讓它接管太多判斷。結果是 code 看起來改得很快，實際你根本沒消化它為什麼這麼改。

我自己的做法是把 IDE 工具限制在「局部協助」上：補全、解釋、生成測試、輔助重構。涉及架構邊界、狀態流、權限邏輯，我還是會回到更顯式的流程裡確認。

實操寫法很簡單，如果你偏 IDE，我建議你把它當成「增強編輯器」，不是「自動交付系統」。

• 先讓它解釋現有 code，再讓它改。
• 優先用在單檔案或小範圍重構。
• 每次改動都看 diff，不要只看結果。
• 把測試和靜態檢查當成強制步驟。

如果你常用 VS Code，那就更簡單了：讓工具貼著編輯器走，但別讓它替你做判斷。

Copilot 不是必須替換，別做工具潔癖

原文裡有一句我很認同：如果已經有 GitHub Copilot 訂閱，可以繼續保留。這個判斷很務實，因為很多人一看到新工具就想「統一 stack」，最後把自己折騰得很累。實際上，AI 編程工具之間並不天然衝突，關鍵是你怎麼分工。

我把這句話翻成工程語言，就是：不同工具解不同層次的問題。一个工具負責編輯器內的即時補全，一個工具負責終端裡的批量任務，一個工具負責更複雜的多模型呼叫。你沒必要強行讓一個產品吃掉全部場景。

我見過最沒必要的浪費，是明明 Copilot 已經覆蓋日常補全，還非要為了「統一體驗」硬換到另一個系統。結果新工具還沒熟，生產力先掉一截。說到底，訂閱費不是唯一成本，切換成本也很貴。

實操上，我會先列出你現在的工作流，再決定保留什麼：

• 日常補全和提示：保留 Copilot 這類編輯器內工具。
• 批量修改和腳本任務：交給 CLI。
• 複雜上下文和跨檔案重構：看 IDE 與 CLI 誰更順手。

如果你現在已經有一套能跑的組合，就別為了「最新」去折騰。能穩定交付的工具鏈，比看起來統一的工具鏈更值錢。

多模型支持真正值錢的地方，是你不用賭一個答案

原文提到 Codex CLI 的一個優勢是多模型支持。這點我特別在意，因為單模型工作流最容易出問題的，不是它不會答，而是它總在同一種錯誤裡循環。你一旦把所有任務都押在一個模型上，遇到不擅長的場景就會很難受。

我理解多模型支持的價值，不是「模型越多越厲害」，而是你可以按任務切換。寫測試、解釋遺留 code、生成遷移腳本、整理註解，這些任務的最佳模型並不一定一樣。能切換，就意味著你不用把所有問題都塞給同一種思路。

我自己最常見的用法是：先用一個模型做粗分解，再用另一個模型復核邊界。這樣比單次問到底可靠得多。尤其是涉及副作用、資料結構、權限路徑的時候，第二個視角經常能幫你抓出前一個回答裡的漏點。

實操寫法不要把多模型支持理解成「到處試」。你應該把它變成固定流程：

1. 先讓一個模型列出修改計畫。
2. 再讓另一個模型檢查風險點。
3. 最後只在當前 repo 裡落地改動。

這樣做的好處是，你得到的不是一堆花俏答案，而是更像 code review 的過程。這個過程比「直接生成一坨 code」可靠得多。

把 AI 放進終端，最大好處是權限邊界更清楚

如果你經常在 Linux 伺服器上幹活，你會很快發現一件事：終端天然適合做邊界控制。哪些目錄能看，哪些命令能跑，哪些操作需要你確認，這些都比圖形介面更明確。Codex 這類工具的優勢就在這裡，它更容易嵌進你已有的運維和開發習慣裡。

我跑遠端開發時最怕的不是慢，而是失控。圖形介面一多，視窗一多，工具一多，你很容易忘了自己到底改了什麼。終端工作流反而逼你更清楚地寫出目標、命令和檢查步驟。

這也是為什麼我會建議把 AI 當成「受控執行者」，不是「全權代理」。你讓它做事，但你保留最後的確認權。尤其是 code 提交前，必須有人類看過 diff 和測試結果。

實操上，我會給終端工作流加三條硬規則：

• 任何自動修改都必須能回滾。
• 任何跨檔案改動都必須先列計畫。
• 任何提交前都必須跑測試或至少靜態檢查。

如果你的團隊已經有 shell script、Makefile、任務編排工具，那就更適合把 Codex CLI 接進去。別改習慣，順著習慣接工具，效果通常更好。

真正該抄的不是工具名，是這套分工邏輯

看完這篇知乎內容，我最大的收穫不是「我該裝哪個」，而是「我該怎麼分工」。終端負責批量和受控修改，IDE 負責局部編輯和上下文查看，Copilot 負責日常補全。如果你再加上多模型切換，那就是一套挺實用的組合拳。

我以前總想找一個「全能入口」，後來發現這想法本身就有問題。寫 code 這件事本來就分層：想法、定位、修改、驗證、提交。AI 工具也應該分層，而不是一個按鈕包辦一切。

如果你要立刻開始，我建議先別折騰太多擴充套件。先選一個主入口，再補一個輔助入口，最後把驗證步驟固定下來。這樣你會更快知道工具到底有沒有幫到你，而不是只是在介面上更熱鬧。

你可以直接複製的工作流模板

# Codex / IDE 混合工作流模板

## 1. 先選入口
- 終端優先：Codex CLI
- 編輯器優先：VS Code / Cursor
- 已有訂閱：保留 GitHub Copilot

## 2. 每次開始任務前先寫清楚
- repo 路徑：
- 當前分支：
- 目標：
- 不能改的檔案：
- 必須通過的檢查：

## 3. 給 AI 的標準指令
請先不要直接改 code。
先做三件事：
1. 用 3-5 條列出你理解的任務
2. 標出可能影響的檔案
3. 說明你會怎麼驗證結果

確認後再開始修改。

## 4. 修改規則
- 只改當前任務相關檔案
- 跨檔案改動先說明原因
- 任何生成內容都要看 diff
- 不允許跳過測試

## 5. 驗證規則
- 先跑單元測試
- 再跑 lint / typecheck
- 失敗就回到修改步驟，不要硬提交

## 6. 推薦分工
- Copilot：日常補全
- Codex CLI：終端裡的批量任務、腳本、受控修改
- Cursor / VS Code：局部編輯、重構、看上下文

## 7. 提交前檢查
- [ ] diff 看過了
- [ ] 測試通過了
- [ ] 沒碰不該碰的檔案
- [ ] 變更原因寫清楚了
- [ ] 可以回滾

這套模板的重點不是「最先進」，而是「能落地」。你拿去改成自己的 repo 流程，基本就能開幹。

如果你要追原文，出處是知乎專欄文章 《如何配置使用 Codex 編寫代碼 — 完整上手指南（更新VScode安裝codex插件使用入口）》。我這裡做的是拆解和重組，不是原文複述；真正的工具選擇和配置細節，還是建議回到原文核對。另有工具與產品連結我已分別標出，方便你直接對照。