OpenCode，終端機裡的 AI 程式助手，現在我會怎麼用
前言
我這一年試過不少 AI coding tool，最後一個很明顯的感覺是：如果你平常本來就住在 terminal，很多 GUI 工具再漂亮，用久了還是會覺得哪裡不太對。
因為你的工作節奏不是滑滑鼠，而是 git status、grep、docker compose logs、跑測試、看 error、再改一次。事情本來就發生在 shell 裡。
OpenCode 吸引我的地方就在這裡。它不是那種裝完就會立刻讓所有人驚呼好順的工具，可是如果你本來就是 terminal heavy user，它很容易接上你的手感。說白一點，它比較像把 AI 拉進你原本就在走的流程，而不是逼你換一套節奏。
什麼人用起來會比較順
如果你符合下面這兩點，我覺得可以直接試：
- 你平常本來就常用終端機
- 你不排斥自己準備 API key，或本來就有在用多家模型
如果你只是想找一個打開就用、介面點一點、最好連 provider 都別管的工具，那 OpenCode 不一定是最舒服的第一站。它自由度高，東西也接得開，可是代價就是你得稍微理解模型、provider、權限、工作目錄這些事。
我沒有把它當成 Cursor 替代品
很多人看到這類工具，第一個問題通常都是：
那它能不能直接取代 Cursor？
我自己的答案一直都偏向：不一定要用取代的角度看。
對我來說，OpenCode 的價值比較像這幾件小事累積起來：
- 它就在專案目錄裡工作，不太需要你切換腦袋
- 很多事情本來就要跑指令，它只是幫你把這一段自動化
- 你可以自己決定要用哪一家模型，不會被單一平台綁死
那種感覺其實滿像你旁邊多了一個真的會用 terminal 的助手。不是什麼都替你做掉，而是幫你把那些本來就會發生的查、改、跑、驗證接起來。
安裝不算麻煩，但別一開始就丟大任務
OpenCode 官方文件目前還是以 CLI 體驗為主，安裝方式不算複雜。常見做法像下面這樣：
1
npm i -g @anthropic/opencode
安裝完之後，我通常不會馬上把大專案丟進去。我反而會先進一個自己很熟的小專案，跑最簡單的互動。
1
2
cd my-project
opencode
如果你的環境要先補 provider 或 API key，這一步就會開始遇到設定。我自己的習慣很保守：
- 先只接一個最穩的模型來源
- 先拿小任務測試，例如讀 README、幫我解釋某段 code
- 確認它能正常讀檔、改檔、跑測試，再去玩更複雜的代理流程
不要一開場就丟「幫我重構整個專案」這種任務。你連它怎麼看目錄、怎麼回報錯誤、會不會自己重跑測試都還沒摸熟，這樣只會很容易翻車。
我後來更在意的是，它會不會打亂我原本的做事方式
我現在看 CLI agent，最在意的反而不是它能不能說很多大道理，而是它能不能乖乖融進我原本的 shell 節奏。
因為我平常做的事其實都很普通：
- 先看專案結構
- 搜關鍵字
- 開某幾個檔案
- 改完跑測試
- 看 log
- 視情況再改一次
這些事情本來就不是靠 UI 解決的，是靠一串手感很熟的操作節奏解決。
OpenCode 好用的地方，就是它比較容易貼上去。你可以很自然地丟這種話給它：
1
幫我找出登入流程相關的檔案，先不要改，整理出一條排查路線
或者：
1
幫我看目前測試失敗的原因，先修最小範圍，修完自己重跑
這種感覺跟 IDE 裡那種「幫我改這塊」不太一樣，比較像你在帶一個真的會用 terminal 的人做事。
如果再接 oh-my-opencode / oh-my-openagent，味道會更完整
這一塊我後來越用越有感。
很多人還是習慣叫它 oh-my-opencode，不過新 repo 名稱其實已經是 oh-my-openagent。它做的事情也不是單純補幾個快捷指令，而是把代理分工、背景任務、LSP、AST 搜尋、官方文件查詢這些能力，整理成一套比較像樣的工作台。1
我很喜歡它有一點講得很直：不同模型就適合不同角色，不要硬拿一個模型打天下。2
例如現在它對模型的分工，大概會長這樣：
- 主 orchestrator 偏向
Claude/GLM - 深度執行工作偏向
GPT - 搜尋與輕量任務常搭配
Gemini Flash、MiniMax - 視覺或前端任務對
Gemini會比較友善
這種分法我自己滿認同。真實世界裡，模型很少是在比誰永遠第一，而是在比你把它放在哪個位置。
我自己現在怎麼用它
如果今天是一個中小型 side project，我大概會把 OpenCode 放在這幾種場景：
1. 先做探索，不急著下刀
像是我看到一個 bug，但我還不確定是在前端、API 還是資料層，我會先讓它整理線索，而不是立刻要求它改。
這樣比較實際。先確認它有沒有讀懂專案，不然一開始就改，常常一刀下去方向就歪了。
2. 幫我跑那些我懶得自己一個個敲的流程
例如：
- 找出某個函式在哪幾個檔案被用到
- 幫我加測試並重跑
- 做一輪小型 refactor
這種事情很適合它。重複、瑣碎，可是又不是完全沒腦的體力活。
3. 在 CLI 世界裡把「查、改、驗證」接起來
AI 會改 code，現在真的不稀奇。比較稀奇的是它改完會不會自己驗證。
我現在對這類工具的標準很簡單：
不是只會寫，而是寫完要自己去驗證。
如果一個工具每次都只是吐一段 patch 給我，後面還要我自己把測試、驗證、收尾通通補完，那它比較像會打字，不太像真的有幫到忙。
OpenCode 現在的優點
優點一：很適合已經習慣 shell 的人
這點是最核心的優勢。
你不用切出編輯器和對話框來回跳，很多事就在原地完成。
優點二：模型來源比較自由
這也是我自己很在意的地方。現在多模型混用幾乎已經是常態，如果工具只能綁一個 provider，後面很容易卡死。
優點三：跟自動化流程比較容易接
像是測試、建置、簡單腳本、甚至 shell pipeline，CLI 工具本來就比較好接。這一點在團隊或 side project 都很實用。
目前我還是會皺眉的地方
1. 新手一開始會有點不知道該怎麼下指令
它能做很多事，反過來也表示新手很容易不知道該怎麼開口。這問題不只 OpenCode 有，CLI agent 幾乎都會遇到。
2. 多模型與多 provider 一旦放進來，心智負擔會變高
如果你今天只是想要「寫點程式」，但還得先想：
- 我要走哪一家 provider？
- 哪個模型適合哪個角色？
- 成本會不會爆？
這時候就會比單一平台麻煩。
3. 它很吃使用者本來的工作習慣
你本來就是 terminal heavy user，通常會覺得很順。
但如果你平常幾乎不碰 shell，只想要視覺化操作，那它的門檻會比你想像中高一截。
第一次碰的人，我會怎麼帶
第一次玩這種工具，我通常會叫你先這樣做：
- 找一個你熟的小專案
- 先只接一個模型來源
- 先讓它做閱讀、搜尋、解釋這類低風險任務
- 再慢慢放大到改 code、跑測試、做 refactor
不要一開始就把它當全自動工程師。這樣幾乎一定會失望。
我現在不會把 OpenCode 吹成萬能工具，也不會硬說它比所有 GUI 工具都強。
但如果你本來就習慣在 shell 裡工作，它真的很容易變成那種你會一直留在手邊的工具。不是因為它什麼都最好，而是它跟你的節奏比較合。這點其實比一堆花俏功能更重要。