昨天，趁著鐵人挑戰賽走過一半，我先暫停實作，整理了使用 Codex Sol、Terra 和 Luna 的心得。

今天繼續插播另一個我在開發過程中愈來愈常被問到的問題：Codex CLI 版和 App 版，到底有什麼不同？又該怎麼選？

我一開始主要使用 CLI。打開終端機、切進專案目錄、輸入需求，Codex 就能讀程式、修改檔案、執行測試，甚至一路操作 Git、gcloud 和部署流程。後來做 LINE Cafe Bot 的 Rich Menu 時，我第一次改用 App 走完比較完整的開發流程。

真正用過兩邊後，我的答案不是哪一個比較強，而是：它們適合讓我看見工作的不同部分。

CLI：想到事情，就在原本的終端繼續做

CLI 最吸引我的地方，是它幾乎沒有切換成本。

平常已經在終端裡看 log、執行測試或操作 Cloud Run 時，只要進入專案目錄就能開始：

cd my-project
codex

不需要先整理畫面，也不用離開原本的工作節奏。尤其在追查部署問題時，我可以讓 Codex 接著檢查 build、revision、health endpoint 和 webhook 狀態，所有資訊都沿著同一條終端流程往下走。

這種方式很適合：

• 已經清楚知道要修改哪個專案；
• 工作以程式碼、指令、測試和 log 為主；
• 正在遠端環境或習慣以鍵盤完成操作；
• 想把固定任務接進 script 或 CI。

CLI 還有一個 App 很難取代的特點：它本身就是命令列工具。除了互動式使用，也能用 codex exec 非互動執行。例如官方文件提供的做法，可以把過程輸出成 JSONL，交給其他程式繼續處理：

codex exec --json "summarize the repo structure" | jq

如果一件事未來會重複執行，或要成為自動化流程的一部分，CLI 會讓我覺得很自然。

App：不只知道檔案產生了，還能直接看它長什麼樣子

我真正感受到 App 差異的時刻，是製作 LINE Rich Menu。

那次程式成功產生了一張符合規格的 PNG，終端也顯示：

Generated rich-menu.png (405615 bytes)

尺寸正確、檔案小於 1 MB，從程式和檢查結果來看，一切都成功了。

但我在 App 裡直接打開圖片後，才發現咖啡杯和問號圖示壓在中文字上。這不是 TypeScript build 或單元測試會報出的錯誤；如果只看終端輸出，我很可能會把一張技術上合格、視覺上不能交付的圖片部署出去。

App 對我最大的幫助，是把對話、檔案、終端結果、Git diff 和視覺預覽放在同一個工作空間。修改 SVG、重新產生 PNG、打開成品、再檢查 diff，不必一直在不同視窗之間來回找東西。

官方文件也把這種工作方式寫得很具體：可以從整合式終端啟動網站，在內建瀏覽器打開頁面，把實際畫面和程式 diff 放在一起檢查，甚至直接在畫面上留下修改意見。

因此遇到以下工作時，我會更想開 App：

• 要反覆查看圖片、網頁或文件成品；
• 修改橫跨多個檔案，需要隨時掌握整體 diff；
• 任務時間較長，希望把對話、檔案與結果集中管理；
• 我還在探索問題，需要一邊看、一邊決定下一步。

App 的優點，不只是「畫面比較漂亮」

一開始我以為 App 只是替 CLI 加上圖形介面。實際使用後，我覺得更大的差異是驗收方式。

在 CLI 裡，我很自然會問：

指令有沒有成功？
測試有沒有通過？
部署狀態是不是正常？

到了 App，我會更容易多問一層：

實際畫面看起來對嗎？
這次到底改了哪些檔案？
成品和我的需求是不是一致？

兩組問題都重要。前者確認系統能不能運作，後者確認結果能不能交付。

Rich Menu 的經驗讓我發現，當工作包含視覺成品時，「看得到」本身就是開發流程的一部分，而不是最後才補做的動作。

CLI 的優點，也不只是「比較工程師」

反過來說，CLI 也不是 App 出現後就只剩下懷舊價值。

很多時候，我不需要完整工作台，只想快速進入某個 repo，確認問題、修改程式、跑測試，再離開。CLI 的直接感在這種情境反而更舒服。

更重要的是，終端裡的操作容易留下可重複的指令。今天手動執行一次的檢查，明天可以放進 script；原本與 Codex 的互動，也可以進一步用 codex exec 接到自動化流程。這是 CLI 很明確的優勢。

所以我不會把它們理解成「初階版和進階版」，而是兩種入口：

我的使用方式：不是二選一，而是隨工作切換

現在開始一個任務前，我會先問：這次最需要看見的是什麼？

如果答案是指令、測試、部署狀態和 log，我通常直接留在 CLI。如果答案包含圖片、網頁、跨檔案變更或需要反覆比較的成品，我會打開 App。

有時候我也會混著使用。先在 CLI 快速確認環境和問題，等工作進入需要整理與視覺驗收的階段，再回到 App；或者在 App 裡完成設計和 diff 檢查後，把可重複的部分整理成 CLI 指令。

它們不是兩套互相競爭的工作方式，而是同一段開發流程裡，不同時刻適合使用的視角。

最後：工具沒有換，驗收的視野變大了

從 CLI 換到 App 的那次 Rich Menu 實作，Codex 並沒有突然變成另一個 AI。真正改變的是，我不再只看它做了哪些指令，也能直接看見那些指令最後產生了什麼。

CLI 讓我快速進入工作、貼近系統，也很容易走向自動化；App 則讓我把更多上下文留在同一個空間，尤其適合需要視覺判斷與整體檢查的任務。

如果要替這次心得留下一句話，我會寫：

要快速操作與重複執行，我會選 CLI；要看見成品並掌握整體變化，我會選 App。

真正重要的從來不是固定站在哪一邊，而是讓工作過程和最後的驗收，都發生在最適合它的地方。

延伸閱讀

• 上一篇：不是越強越好——我的 Codex Sol、Terra、Luna 實戰心得
• Codex App + Sol：LINE Cafe Rich Menu 實作
• OpenAI 官方：Codex Developer Commands
• OpenAI 官方：Non-interactive mode
• OpenAI 官方：Browser preview workflow