前言
自從2022年,OpenAI家的ChatGPT問世,到之後偏向專業用戶的Anthropic家的Claude崛起,Blog主其實這幾年日常有在用AI,但工作上只有10%的時候才用。到了去年(2025年),身邊有不少工程師好友,還有家裡的老哥也是,都開始跟我說現在工作幾乎80%都用AI解決了。當時Blog主也都只是聽聽,畢竟自己工作上大部分內容都能自己解決。
直到2026年初開始,工作上有了變化,開始有新的大量的開發工作降到身上,而當PM的同事是一位很厲害的工程師,他自己是自掏腰包用Claude Code,Blog主這才實際去了解了一遍。不過並不想一開始就課金的Blog主,想尋求open source的方案,後來找到了OpenCode,基本上是Claude Code的開源替代版,可以連接現在五花八門的AI供應商,其中也包含Self-hosting的選項,基本上只要硬體到位,也可以無課金建立自己的AI開發環境。
本文主要是紀錄Blog主初試OpenCode的內容,這不是教學,也不是分享什麼很炫炮的技巧,只有個人經歷跟心得而已。
OpenCode初試
OpenCode本體
OpenCode本身算是一個TUI的操作軟體,把你的本地電腦的操作權限跟LLM處理事務的能力合在一起。跟其他相近的TUI軟體一樣,有Plan mode跟Build mode可以上保險,使用者可以確認接下來要執行的內容,討論過後再放行,能減少誤執行的情況發生。而OpenCode最大的魅力就是上述的,可以連接五花八門的AI供應商,包含Self-hosting的選項。現在各家供應商大多有定額制的方案,但是都有Token的使用量限制,在OpenCode的其中一個好處是,當一家的額度用完時,可以在同一個介面,同一個自訂Agent設定,自訂Skill下,同個對話紀錄,操作紀錄裡面,直接切換供應商,繼續執行目前的任務。
有好處也有壞處,譬如裡面的功能比較基本,有些Claude Code新增的炫砲功能不會有(或著目前沒有)。還有一些AI供應商的合約裡面禁止連接類似OpenCode的軟體,並且會Ban違規者,像是Anthropic家的Claude就是如此,還有Google的Gemini服務也是,兩者雖然都能夠接上OpenCode,但都有被Ban的危險。以下Blog主介紹的AI供應商/供應服務則是(2026/05當下)明確能夠接上OpenCode不會被Ban的。最後,儘管有些服務能接上OpenCode,但當供應商對API有變更時,會有OpenCode連接失敗的情況發生,這點也是Blog主實際經歷過的。
LLM/AI來源
Ollama local
Ollama大概是近年最廣泛的Self-hosting LLM/AI的軟體之一,Blog主也是在接觸OpenCode之前就有用過,當時是配Open WebUI當前端使用。而在OpenCode的使用情境下,只需要後端的Ollama就夠了,OpenCode這邊只要簡單設置一個json檔案定義連接情報就行。當時Blog主使用的是24G的P6000跑,實際用下來,在Coding方面的任務,最好用的是Qwen3 Coder的30B版本,更新的版本可能更好用,不過Blog主沒有試。
Blog主自己的感覺是,當文件量少,討論的內容不多時,24G能撐起來的LLM還勉強可用,code的品質也還可以,但真正的問題是文件的量稍微增加,討論變多之後,速度會降超級慢,甚至常常跑不動了,工作效率很低,不太適合商用任務。儘管在玩OpenCode之前,Blog主很傾向Self-hosting的各種軟體,包含LLM/AI模型。但實際使用過後,Blog主私心認為,假設沒有48G以上的顯存,就算去用目前商業提供的低階模型,也能超越本地模型的效果,而且消耗credit的速度也不快,譬如Claude Haiku 4.5,收費也夠便宜,速度快,不用擔心前後文太長,文件太多。
Github Copilot
當Blog主在找尋划算又實用的AI供應服務來配OpenCode,第一個找上的是Github Copilot,這邊是官方承認過,能放心接著OpenCode用,不過沒多久,這個服務就改惡了。當時Blog主使用時,還有一個月的免費試用,11USD的方案,也可以用Claude的Haiku,Sonnet,甚至是Opus,Blog主也在這邊用了快半個月的Sonnet,靠這個進入AI Agent coding的世界,每個月的額度在當時似乎也夠用。
不過好景不常,之後11USD的方案砍了Opus,調整了各個模型的額度倍率,Blog主看額度消耗得越來越快,最後轉去下面要介紹的Codex。儘管如此,Blog主目前仍然有保留Github Copilot的約,因為作業量很多時,Codex偶爾也會額度見底,這時候可以用這邊的Sonnet來進行一些偏向文書類的任務。
ChatGPT Codex
自從GPT-5.5系列發表後,看到當時不少對Opus 4.7失望的使用者轉移過去,Blog主在Github Copilot改惡後,想說試一下GPT-5.5好了,就訂閱了Plus方案,大約是3000日幣/月,不過目前有優惠方案,第一個月免費。Blog主也沒有用傳說中的GPT-5.5 Pro,但光是一般版的GPT-5.5,就已經讓Blog主拋棄Sonnet,95%的任務都用這邊的模型了。而且目前Plus方案就算Blog主作業量最多的時候,也足夠撐到一個禮拜的Credit重置,只有一兩次碰到5小時的限量。這時候就休息一下,不然就切回Github Copilot用Sonnet,做一些比較簡單的作業。
文件.Coding本身
仕様駆動開発
Blog主目前公司的幾個核心的工程師,最常講的是這個,「仕様駆動開発」,中文應該是「規格驅動開發」,核心概念應該是,讓AI從規格就非常仔細的策劃,並且由人審核,讓未定義的曖昧空間壓到最小,這時再讓AI開始照著非常詳細的文件Coding,就能把預想外的程式行為減少。這與另外一個方式「Vibe Coding」可以說是光譜的正反面,只用幾句簡單的指令就讓AI完成整個實作,通常導致的是難以維修的成品。實際與OpenCode進行一段時間後,Blog主也同意AI時代,目前可行的進行方式應該是「仕様駆動開発」,雖然這代表人類仍要花非常多時間制定,規劃與檢查,但能兼顧品質與速度。這也關連到以下幾點Blog主的想法・實際進行方式。
一步一腳印
自從AI出現,從身邊的工程師開始使用,到自己使用,其實大家反而是越用AI越忙,不是因為效率變差,而是產出變多,能做的任務變多變廣,工作量再增加。另一個是AI進行的速度很快,人也要花時間跟上去確認內容。Blog主自己很愛講的是,陪AI走每一步,發現錯誤就要一起檢討,修改目前任務的細節,避免在無人監控下自己越走越偏,雪球越滾越大,最後要面對大難題的還得是人。而進行一段時間,發現一些重複的錯誤,就要檢討是否更新Agent的指令,新增Skill或修改現存的Skill。
「因為AI出現了,工程師就能優閒的躺著讓AI包辦一切」這種廣告情節,似乎離現實還遠,假設如此,那公司還需要工程師幹嘛?上司還需要你做什麼?這是非常現實的問題,因為假設AI真的能從頭包辦所有事,那工程師勢必要開始做其他AI無法單獨完成的事情,勞動這件事長遠來說,是無法避免的,這是價值問題(除非該任務逆轉,變成AI的勞力成本比人事成本還高)。
代理操作
Blog主都只有最基本的代理操作,沒有在OpenCode額外裝MCP。目前也有聲音說,網上多數的MCP都存在資安疑慮,而且使用MCP過度消耗Token,有CLI就用CLI,比較節省Token。Blog主平常會讓AI執行的只有基本的網頁讀取文字,在監視下執行Python Script,操作Github CLI來讀取與寫入issue或PR,還有留言。另外還有Terraform的指令,平常最多只讓AI進行到Terraform的plan階段,確認實際要建立的resource內容,但最後的確認以及Terraform apply仍是手動執行。最後,還有偶爾讓AI執行Azure CLI基礎的確認resource指令。
基本上,80%的時候都只會與AI一起使用Github CLI,一起確認issue,分割issue,把目前進行的過程以及方向記錄在issue的comment,進行issue後,本地操作git以及建立檔案,再建立PR,對應reviewer的質疑,修改PR。剩下的15%是為了確認網路上某技術的最新文件,Best practice,需要確認網頁內容,最後的5%才是建立或確認resource相關的CLI。
總結
本文從OpenCode本身的介紹,到使用的AI服務,再到進行任務的思想以及方式。Blog主應該是比較晚進入這個領域的,儘管已經事前知道大略的內容,剛接觸的時候還是蠻新鮮的,進入新世界的感覺。未來因為公司方針的關係,會再接觸Claude Code,也許到時再上來分享一下跟OpenCode的差異,我們下次見。







































