先坦白一個事我第一次在終端里敲opencode這個命令的時候真沒抱什么指望。那陣子終端 AI 編程助手一個接一個往外冒Claude Code、Codex CLI、Pi我挨個裝過一遍大部分用兩天就吃灰了。但 opencode 不一樣我用了三天之后主動把它寫進了主力工作流還拉了兩個同事一起入坑其中一個就是最開始罵我又在折騰新玩具的那種人。opencode 是一個開源的終端 AI 編程 Agent由 SST 團隊開發(fā)底層用 Go 寫的 TUI 界面就是終端里的圖形交互界面。它的核心定位是模型無關、開源可控、能干實事。你可以讓它讀項目、改代碼、執(zhí)行命令、跑測試、修 bug甚至通過 Skills 機制給它預裝自定義技能。它適合誰用常年泡在終端里的開發(fā)者、想換掉 IDE 全家桶的人、對不同模型有自己偏好的技術選型派、以及想把 AI 編程能力嵌入自動化流程里的工程效率控。這篇文章我按自己真實的實操路徑來寫它到底解決了什么問題、怎么裝、怎么配、核心功能怎么用、生態(tài)怎么接、報錯怎么排所有參數(shù)和坑都是我實測過的照著走基本能復現(xiàn)。1. opencode 到底是什么它從哪里來要解決什么問題1.1 SST 團隊為什么要做這個工具opencode 出自 SST 團隊就是做 Serverless 框架 SST以前叫 Serverless Stack的那幫人。他們?nèi)粘Ｗ鲈茟瞄_發(fā)改一個功能經(jīng)常要同時動基礎設施配置、后端函數(shù)、前端頁面和測試文件屬于典型的高上下文切換開發(fā)場景。市面上的終端 AI 工具要么綁定單一模型廠商要么只能做簡單問答要么沒辦法感知整個項目的狀態(tài)他們等不到完美的現(xiàn)成方案干脆自己做了。我一開始也好奇一個開源框架團隊不好好維護主業(yè)怎么跑去寫 AI 工具了。用了一段時間才明白opencode 本身就誕生于他們自己的開發(fā)流——改一個點要聯(lián)動改整個面的需求恰好是終端 Agent 最擅長的事情。這個背景決定了它的基因不是為了聊天而生的玩具而是奔著進你項目里干活去的。所以它從一開始就有完整的工具調(diào)用鏈、多文件編輯能力、會話管理、非交互式運行模式這些都是工程化工具該有的樣子。1.2 它和 Claude Code、Codex CLI、Pi 的本質(zhì)區(qū)別終端 AI 編程助手這個賽道現(xiàn)在主要幾個玩家Claude CodeAnthropic 官方出品、Codex CLIOpenAI 官方出品、opencodeSST 開源、Pi社區(qū)熱度很高的另一個 agent。表面看都是在終端里和 AI 對話讓它改代碼但實際差異巨大。對比維度opencodeClaude CodeCodex CLI是否開源完全開源否開源模型綁定完全不綁定任選綁定 Claude 系綁定 OpenAI 系模型切換配置即切TUI 一鍵切換受限受限Skills/技能擴展原生支持兼容 SKILL.md有插件生態(tài)有限本地模型支持 Ollama 等受限受限IDE 插件VSCode、JetBrains 都有有有非交互模式支持適合 CI有有最核心的區(qū)別就四個字模型無關。Claude Code 是 Anthropic 的親兒子Codex CLI 是 OpenAI 的親兒子它們和自家模型的綁定深入骨髓。opencode 則把模型層完全抽象了你可以在配置文件里指定任意一個模型服務商、任意一個模型甚至定義多個模型隨時切換。這對開發(fā)者的實際意義是你不必被任何一家模型廠商綁架。寫業(yè)務代碼用某個模型順手做架構梳理另一個模型更強格式化小任務用免費模型全都在同一個工作流里搞定。1.3 什么人適合用 opencode什么人不適合先把丑話說在前面。如果你平時主要生活在 IDE 圖形界面里很少打開終端那 opencode 的第一印象會讓你不太舒服——它的主界面是 TUI所有操作靠鍵盤學習曲線比裝一個 Copilot 插件陡不少。但如果你符合下面任何一條它大概率會變成你的主力工具你是 Neovim、Vim、Emacs 用戶或者習慣輕量編輯器和終端配合開發(fā)你需要 AI 做跨文件重構、跑測試、查調(diào)用鏈這類工程活而不是一問一答的聊天你對模型選型有主見不想被某個廠商的生態(tài)鎖死想自由切換模型你想把 AI 編程能力塞進 CI 腳本、自動化任務里。我自己是重度終端用戶 多模型切換剛需的典型所以 opencode 對我來說幾乎是量身定做的。接下來從頭走一遍安裝和配置流程。2. 安裝與初始化半小時跑通第一個任務2.1 三種安裝方式怎么選opencode 的安裝方式很標準常見有三種我分別說下適用場景。第一種npm 全局安裝npm install -g opencode-ai這是我最推薦的方式一條命令搞定裝完直接opencode --version驗證。前提是機器上有 Node.js 環(huán)境版本建議 18 以上。第二種curl 安裝腳本curl -fsSL https://opencode.ai/install | bash這個方案裝的是獨立二進制不依賴 Node 運行時適合不想為裝個工具再背一個運行時的人。腳本會把程序裝到用戶目錄下并且通常會自動處理 PATH。第三種Homebrewbrew install opencodemacOS 用戶最熟悉的方式但要注意 Homebrew 倉庫里的版本有時會比官方源滯后如果你著急體驗新功能優(yōu)先用前兩種。Windows 用戶同樣可以用 npm 或 curl 方式。不過 Windows 上會踩到一個非常經(jīng)典的坑下一節(jié)單獨說。提示無論用哪種方式裝完先跑opencode --version。如果提示找不到命令先檢查 PATH不要急著重裝。2.2 Windows 最經(jīng)典報錯無法識別 cmdlet 的三種解法這個報錯在搜索里出現(xiàn)了很多次原文是opencode : 無法將“opencode”項識別為 cmdlet、函數(shù)、腳本文件或可運行程序的名稱。我負責任地說Windows 用戶第一次裝 opencode遇到這個的概率非常高。原因一點也不神秘npm 全局安裝后可執(zhí)行文件在 npm 全局 bin 目錄下一般是%APPDATA%\npm但這個目錄沒在系統(tǒng) PATH 環(huán)境變量里。PowerShell 找不到opencode命令就給出這個提示。解法有三條按推薦程度排序。第一條把 npm 全局目錄加進 PATH。先打開 PowerShell 執(zhí)行npm config get prefix假設輸出是C:\Users\你的用戶名\AppData\Roaming\npm然后執(zhí)行[Environment]::SetEnvironmentVariable(Path, $env:Path ;C:\Users\你的用戶名\AppData\Roaming\npm, User)設置完重開終端窗口再跑opencode --version就能識別了。第二條不想動環(huán)境變量的話直接用npx opencode代替opencode。這個辦法省事但每次調(diào)用都會多一層 npm 解析啟動會慢一兩秒體驗略差。第三條干脆不通過 npm直接用 curl 安裝腳本裝獨立二進制。這種方式會裝到用戶目錄下的.opencode/bin安裝腳本一般會順帶把 PATH 配了省心很多。我個人在 Windows 上的建議是直接用 curl 腳本。因為 Windows 下 npm 全局目錄經(jīng)常被各種 node 版本管理工具改來改去排查 PATH 問題的時間夠你重裝三遍了。2.3 首次啟動、模型選擇與免費模型接入裝好之后第一次運行opencode它會引導你選擇模型服務商。這里的自由度和 Claude Code 那種綁定式體驗完全不同官方支持的主流選項包括Anthropic Claude 系列OpenAI GPT 系列Google Gemini 系列OpenRouter 聚合平臺上面有大量模型包括不少免費模型Ollama 本地模型任意兼容 OpenAI 接口的服務商選完之后配置會寫進opencode.json文件。我舉一個用 OpenRouter 接免費模型的例子這個方案對想零成本體驗 opencode 的人來說非常實用{ $schema: https://opencode.ai/config.json, provider: { openrouter: { models: [google/gemma-3-27b-it:free, meta-llama/llama-3.3-70b-instruct:free] } }, model: google/gemma-3-27b-it:free }然后在系統(tǒng)環(huán)境變量里加上OPENROUTER_API_KEY重啟終端就能直接對話了。想接 Anthropic 或 OpenAI 也一樣配置里指定 provider 和 model環(huán)境變量分別設成ANTHROPIC_API_KEY、OPENAI_API_KEY。這里有一個我踩過的坑opencode 的配置文件必須叫opencode.json別手滑寫成opencode.config.json。它的加載順序是項目根目錄優(yōu)先其次用戶主目錄下~/.config/opencode/opencode.json。兩個文件都存在時項目配置覆蓋全局配置的同名字段這個行為我在 2.0 版本里實測過確實如此。2.4 配置文件的幾個細節(jié)環(huán)境變量、記憶機制配置文件里除了 provider 和 model還有一個很容易被忽略但很重要的字段{ instructions: 這是一個全局指令每次對話都會自動附帶。我會在這里寫上團隊的代碼規(guī)范、提交信息格式、測試要求等。, model: anthropic/claude-sonnet-4, temperature: 0.2 }這個instructions字段等于給 AI 設置了一個永久記憶的默認上下文。我把自己團隊最看重的幾條約束寫進去之后AI 干活的質(zhì)量提升是肉眼可見的至少不會每次都問一遍你的項目用 npm 還是 pnpm這種廢話。順帶說一句temperature這個參數(shù)在代碼生成場景里建議設置在 0.1 到 0.3 之間。設太高AI 會發(fā)揮過度生成一些風格飄忽的代碼設太低又容易死板。0.2 是我試了幾輪之后比較舒服的折中點。opencode 還有獨立的 Memory 機制這對應搜索里的 opencode memory關鍵詞。它可以把一些關鍵信息寫入長期記憶文件跨會話保留。我習慣讓它記住本項目前端必須用 Vue 3 TypeScript unplugin-auto-import禁止直接 import Vue這樣即便是全新會話它也知道項目的基本約束。這個功能在長周期項目里非常實用你不需要每次重新解釋背景。3. 核心功能拆解從能用到好用3.1 三種運行模式TUI、命令行、服務器模式opencode 最常用的形態(tài)是 TUI 模式直接運行opencode進入。界面左側(cè)是會話列表中間是對話區(qū)底部有模型切換入口。你會看到 AI 實時輸出思考過程、命令執(zhí)行結(jié)果、文件修改的 diff一目了然。這個界面初看有點密但用半天之后就會覺得比網(wǎng)頁聊天窗口高效太多——信息密度高全程鍵盤操作不打斷思路。第二種是命令行非交互模式適合腳本和 CI 場景opencode run 幫我修復 src/utils/date.ts 里的時區(qū) bug并補充單元測試跑完直接退出不依賴終端圖形界面。我把它接到過 GitHub Actions 里實現(xiàn)推送代碼后自動讓 AI 做一次代碼審查效果還不錯。需要提醒的是在 CI 環(huán)境里跑opencode run要把模型服務商的 API key 通過環(huán)境變量注入進去另外任務耗時會比較長CI 的超時時間要放寬我吃過這個虧。第三種是服務器模式運行opencode serve會啟動一個本地服務。后面講的 IDE 插件和桌面版底層都是通過這個模式和 opencode 通信的。如果你只是日常用 IDE 插件不需要手動啟動它插件會自動拉起。3.2 內(nèi)置工具鏈它能對你的項目做什么opencode 在 Agent 模式下內(nèi)置了一批工具這是它能干活而非聊天的根本原因。我用表格整理一下常用工具工具作用典型使用場景read_file讀取文件內(nèi)容讓 AI 了解現(xiàn)有代碼邏輯write_file寫入新文件或整體覆蓋生成新模塊、新組件edit_file精準修改文件某一部分局部邏輯調(diào)整保留上下文bash執(zhí)行終端命令裝依賴、跑構建、跑測試glob按模式查找文件路徑定位項目結(jié)構grep在代碼中搜索內(nèi)容找函數(shù)定義、引用關系web_search聯(lián)網(wǎng)搜索查文檔、查報錯方案memory讀寫長期記憶跨會話記住偏好和約束這套工具鏈的設計思路其實很樸素人類開發(fā)者怎么操作項目AI 就怎么操作項目?？次募⑺汛a、跑命令、改文件每個動作都是真實可控的。需要注意一個細節(jié)opencode 在寫文件之前通常會在 TUI 里把改動 diff 展示出來讓你確認后再落盤。這個人在回路的機制非常關鍵尤其是讓 AI 做大范圍重構時我不會把改動權限完全交給 AI而是盯著它的每一步修改確認沒問題再放行。3.3 Skills 機制給 AI 預裝技能包Skills 是 opencode 里我認為最值錢的擴展機制對應熱搜里的 opencode skills。它本質(zhì)上是給 AI 預裝一套行為準則 能力包。比如你想讓 AI 在寫前端代碼時自動遵守團隊的組件規(guī)范、命名規(guī)范、測試要求把這些規(guī)則寫成一個 Skill之后對話里讓 AI 直接調(diào)用就行。Skill 的落地形態(tài)是一組文件放在項目或全局的.opencode/skills/目錄下每個 Skill 一個文件夾。目錄結(jié)構大致是.opencode/ └── skills/ └── frontend-code-review/ ├── SKILL.md └── checklist.md其中SKILL.md里寫清楚這個技能的用途、觸發(fā)條件、具體指令。比如我在SKILL.md里定義了前端代碼審查技能要求 AI 檢查組件是否復用了設計系統(tǒng)組件、是否遵循組合式 API 規(guī)范、是否包含必要的單元測試等。這個機制和 Claude Code 的插件生態(tài)很相似所以出現(xiàn)了一個有意思的現(xiàn)象搜索關鍵詞里反復出現(xiàn)的 opencode 安裝 superpowers、oh-my-claudecode本質(zhì)上是把 Claude Code 生態(tài)里成熟的技能包搬到 opencode 上用。因為兩邊 Skill 的目錄結(jié)構和SKILL.md格式基本兼容拷貝過來就能生效遷移成本幾乎為零。我自己就試過把 Superpowers 里的代碼審查Skill 裝進 opencode效果相當不錯。3.4 實戰(zhàn)讓 opencode 接手一個舊項目opencode 接手開發(fā)項目這個搜索詞反映的是大家最真實的訴求——拿到一個陌生項目怎么快速上手。這是 opencode 用得最爽的場景。有一次我接手一個維護了四年的老項目代碼亂、文檔缺、依賴舊第一眼根本不知道從哪下手。以前我會花一下午通讀代碼這次我直接把項目丟給 opencode。進入 TUI 后第一句話我沒有讓它改任何東西而是說先梳理這個項目的整體結(jié)構包括目錄職責、主要依賴、入口文件、現(xiàn)有測試情況整理成一份簡潔的結(jié)構說明。它會自己執(zhí)行查詢命令、讀關鍵文件、翻依賴清單然后輸出一份結(jié)構摘要。這一步其實就是在替代人類開發(fā)者先讀懂項目的過程。接下來我繼續(xù)問用戶認證模塊目前是 session 機制我想改成 JWT先找出所有相關文件和調(diào)用鏈。 它會做代碼搜索、讀文件、追蹤調(diào)用關系然后列出完整的改動影響范圍。這中間最關鍵的一點是不要一上來就讓它改代碼。AI 在理解階段給出的信息越準確后續(xù)改動越靠譜。我見過不少人上來就發(fā)幫我重構整個項目結(jié)果 AI 一通亂改最后連 git 還原都費勁。等方案確認了我會讓它分步執(zhí)行先改核心認證邏輯再改調(diào)用方最后補測試。每完成一步就跑一遍相關測試確認沒有破壞已有功能。實測下來opencode 處理這種多文件聯(lián)動改動的能力比單純用聊天窗口強太多了因為它的工具鏈天然支持跨文件搜索、編輯、執(zhí)行驗證的完整閉環(huán)。順便提一句如果你在 Java/Maven 工程里用 opencode操作邏輯完全一樣只需要確保它能識別pom.xml和相關目錄結(jié)構。AI 會通過bash工具調(diào)用mvn test之類的命令來驗證改動。我在一個 Spring Boot 項目上實測過讓它定位某個接口的 NPE 問題并修復從排查到改完到跑通單測全程不到十分鐘比我手動翻代碼快不少。4. 生態(tài)與集成從終端走向 IDE 和桌面4.1 VSCode 插件和 JetBrains IDEA 插件有一部分人確實用不慣終端 TUI就喜歡在 IDE 里操作。opencode 也鋪了這條路官方提供了 VSCode 插件和 JetBrains 全家桶插件覆蓋了絕大多數(shù)人的主力編輯器。VSCode 插件直接在擴展市場搜 opencode 就能裝。裝上之后側(cè)邊欄會多出一個 opencode 面板它的最大優(yōu)勢是能感知你當前打開的文件、選中的代碼區(qū)域所以提問可以非常精準比如對選中的這段代碼做性能優(yōu)化。插件底層通過本地服務模式和 opencode 通信如果插件提示連接失敗先確認終端里opencode --version能跑通因為插件是靠本地命令拉起服務端的。JetBrains 系IDEA、PyCharm、WebStorm 等同理在插件市場搜 opencode 安裝即可。我自己的主力 IDE 是 IntelliJ IDEA配合插件用下來體驗挺順的代碼補全和 AI 助手在同一個窗口里協(xié)同省去了來回切換焦點的麻煩。這里有一個實操建議在 IDE 里用 opencode 時一定要把項目根目錄作為工作區(qū)打開別只開一個子目錄。有一次我圖省事直接拿子模塊開的窗口結(jié)果 opencode 感知不到完整項目上下文回答質(zhì)量明顯下降排查了半天才發(fā)現(xiàn)是工作區(qū)的問題。4.2 桌面版與 opencode 2.0opencode 官方還出了桌面版應用搜索里的 opencode desktop 說的就是它。桌面版的本質(zhì)是把 TUI 和 IDE 插件的核心能力打包成一個原生應用對不喜歡碰終端的用戶友好很多裝上就能直接用。界面更接近普通聊天軟件但底層還是同一套配置體系——你在終端里配好的模型、Skills、記憶桌面版啟動時會自動讀取兩邊是無縫銜接的。至于 opencode 2.0這是最近一次比較大的版本升級。和 1.x 相比2.0 在 Agent 能力、Skills 加載效率、服務器模式穩(wěn)定性、多會話管理上都有明顯改進。我體感最直觀的變化是處理長任務的上下文留存更好了不再像早期版本那樣聊著聊著就上下文混亂、前后矛盾。如果你是老用戶建議直接升級配置基本兼容遷移成本很低。4.3 CC Switch、Superpowers 等周邊工具的聯(lián)動搜索里有一大串組合詞像ccswitch 配置 opencode、opencode go 需要配合 cc switch、opencode 接入 superpower說明已經(jīng)有不少人在探索生態(tài)聯(lián)動了。這塊我實際配置過說點干貨。先說 CC Switch。它本身是一個管理和切換模型服務商配置的小工具最早在 Claude Code 用戶群里流行解決的是同一套工具想換不同模型服務商的切換痛點。opencode 因為是模型無關設計天然和這種需求高度契合。常見的配合方式有兩種一是在 opencode 配置里通過環(huán)境變量引用 CC Switch 管理的密鑰二是在opencode.json里配置多個 provider然后在 TUI 底部菜單直接切換。我自己試過這兩種方式之后更推薦第二種。直接在 opencode 里配置多個 provider切換邏輯完全在 opencode 內(nèi)部完成不依賴外部工具的狀態(tài)清爽且少踩坑。CC Switch 更適合那些已經(jīng)用它管理了大量 Claude Code 配置、不想重復填寫的用戶。再說 Superpowers。這是一個比較有名的 Claude Code 技能插件集合里面包含大量現(xiàn)成的 Skill覆蓋代碼審查、調(diào)試輔助、架構分析等場景。由于 opencode 的 Skills 格式與 Claude Code 的 SKILL.md 基本兼容把 Superpowers 里的技能目錄復制到 opencode 的.opencode/skills/下就能用。我實際試過里面的代碼審查技能觸發(fā)后 AI 會按照預設的檢查清單逐項過一遍代碼輸出非常結(jié)構化比自己手寫 prompt 穩(wěn)定太多。這里要提醒一句周邊工具迭代速度很快網(wǎng)上教程的版本很可能和你本地版本對不上。遇到配置不生效優(yōu)先去官方文檔確認當前版本的配置格式別盲目照搬舊教程。4.4 成本怎么規(guī)劃開源工具也要花錢嗎搜索里有opencode 套餐這個詞說明很多人關心這個問題。直說opencode 本身完全開源免費但使用它產(chǎn)生的模型 API 費用要看你選擇的服務商和模型。如果你用 Anthropic 或 OpenAI 的官方 API按 token 計費代碼任務用量不小一個月下來幾十到幾百塊人民幣是正常的具體看使用強度。如果只想低成本體驗兩個方案一是用 OpenRouter 上的免費模型帶:free后綴的二是用 Ollama 跑本地開源模型比如 Qwen 系列完全零 API 費用。區(qū)別是免費和本地模型在復雜任務上的能力上限明顯低于頂級閉源模型。我的成本策略是分層日?，嵥槿蝿崭袷交?、補注釋、寫簡單測試用便宜或免費模型核心架構調(diào)整和復雜 bug 排查切到頂級模型。反正切換只是在 TUI 里按一下的事該省省該花花這是 opencode 給我?guī)淼膶嵈驅(qū)嵉暮锰帯?. 常見問題排查實錄報錯與解法速查5.1 unexpected server error 排查順序這個報錯在搜索里出現(xiàn)了完整版opencode error: unexpected server error. check server lo...后面被截斷的部分通常是check server logs。我也遇到過一次當時排查了半天最后發(fā)現(xiàn)是模型服務商那邊返回了異常狀態(tài)。根據(jù)我的經(jīng)驗這種報錯的原因按概率排是這樣的第一模型服務商 API 不穩(wěn)定或限流。免費模型和公共聚合服務尤其容易出現(xiàn)高峰期 5xx 是家常便飯。解決辦法是換時段重試或者換一個模型。我用 OpenRouter 免費模型時遇到過好幾次切換到另一個免費模型立馬正常。第二本地網(wǎng)絡問題。如果 opencode 連不上模型服務商的接口也會冒出這個錯。檢查網(wǎng)絡連接、確認防火墻沒有攔截 opencode 進程必要時用調(diào)試模式看詳細日志。第三配置里的 API endpoint 或 key 寫錯了。檢查opencode.json里的 provider 配置特別是環(huán)境變量的名字。最容易踩的坑是把ANTHROPIC_API_KEY寫成CLAUDE_API_KEY命名稍有出入就讀不到。排查這類問題的正確順序是先用調(diào)試模式啟動 opencode確認請求到底打到哪一步、返回了什么狀態(tài)碼再對癥下藥不要瞎猜。5.2 模型配好了但回答質(zhì)量差問題出在哪很多人配置完成之后感覺回答質(zhì)量不穩(wěn)定時好時壞。這里除了模型本身的能力差異還有兩個經(jīng)常被忽略的變量。第一個是上下文塞太滿。opencode 默認會把項目結(jié)構、打開的文件、會話歷史一起發(fā)給模型。項目一大塞進去的 token 太多模型用于生成回復的注意力就被稀釋了回答自然變得泛泛。解決辦法是縮小工作范圍我在 monorepo 里會把任務拆到子目錄級別讓 AI 只關注當前模塊質(zhì)量立刻回升。第二個是生成參數(shù)沒調(diào)。配置里最好顯式設置max_tokens因為有些默認值對代碼生成場景不夠用尤其是讓 AI 寫整模塊代碼時輸出容易被截斷。我給自己常用模型設置的生成上限是 8192 或 16384具體看模型支持范圍。截斷導致的半截代碼問題設置好這個參數(shù)就能避免絕大多數(shù)。5.3 免費模型下線、質(zhì)量不穩(wěn)怎么辦搜索里有opencode hy3-free 下線了嗎這種問題指向的是免費模型的不確定性。免費模型服務提供商隨時可能調(diào)整策略、下線某個模型這是免費方案的固有風險不是 opencode 本身的問題。我的應對策略很簡單永遠在配置里準備兩到三個備用免費模型別把雞蛋放一個籃子里。出現(xiàn)某個模型不可用或者在opencode里報錯時直接在 TUI 底部切換到備用模型即可三秒鐘的事。如果想要更穩(wěn)定還是那句話核心任務用付費的頂級模型免費模型只用來跑輕量任務。5.4 用 Playwright 測前端 bug 的閉環(huán)方案opencode playwright 怎么測試前端 bug這個話題我特別有發(fā)言權因為我真的用它跑通過一個完整的前端 bug 修復閉環(huán)。先說清楚opencode 本身不內(nèi)置 Playwright 工具但它的 bash 工具可以調(diào)用任何命令行工具Playwright 也不例外。我的操作路徑是第一步先在項目里把 Playwright 基礎環(huán)境裝好npm install -D playwright/test npx playwright install第二步在 opencode 對話里下達測試指令比如用 Playwright 啟動本地開發(fā)服務器模擬用戶登錄點擊頁面上的保存按鈕觀察是否報錯。如果發(fā)現(xiàn)問題定位到具體的代碼文件和行號。opencode 會調(diào)用 bash 工具執(zhí)行 Playwright 腳本讀取輸出再基于報錯信息去搜索相關代碼給出修復方案。實測下來AI 自己跑測試、自己看報錯、自己改代碼的閉環(huán)確實能跑通但前提是 Playwright 環(huán)境已經(jīng)配好不然 AI 會浪費大量時間在環(huán)境安裝上。這里分享一個控制節(jié)奏的經(jīng)驗給 AI 下達先跑測試、根據(jù)失敗修改代碼的指令時一定要加嘗試次數(shù)限制比如同一個錯誤嘗試兩次沒解決就停下來告訴我。否則它可能在同一個坑里反復打轉(zhuǎn)白白消耗時間和 token。我試過一次沒加限制它連續(xù)重試了七八輪才停下來效率極低。6. 實測對比與我的最終工作流6.1 opencode、Codex CLI、Claude Code、Pi 到底選誰這個問題被反復問到網(wǎng)上也吵得很兇。我把幾個主流的都深度用過一段時間給出我個人的真實感受。Claude Code 的優(yōu)勢是 Anthropic 自家模型的代碼能力本來就很強加上官方持續(xù)優(yōu)化開箱即用體驗很好。缺點是模型綁定太死想換別的模型基本做不到而且源碼不開放沒法深度定制。Codex CLI 是 OpenAI 出的GPT 系列模型做代碼任務同樣能打但問題一模一樣綁定 OpenAI 生態(tài)定制性有限。Pi 我也試過熱度很高在某些特定任務上有亮眼表現(xiàn)但生態(tài)成熟度和 IDE 集成方面相對弱一些更適合當嘗鮮工具。opencode 的價值恰恰在于補上了前面兩位的短板開源、模型無關、可深度定制。代價就是選擇的責任交給了用戶你得自己選模型、調(diào)參數(shù)、管理成本。用一句話概括追求開箱即用、不在乎模型綁定的人選 Claude Code 或 Codex CLI 沒問題但如果你想要自由、想在多個模型之間來回切、想讓工具完全貼合自己的工作習慣那 opencode 的上限是最高的。6.2 我最后留下的配置和使用習慣最后分享一套目前讓我比較舒服的 opencode 使用習慣算是這套配置的最終形態(tài)。第一模型分層使用。主力模型固定用一個綜合能力強的日常任務全覆蓋復雜任務臨時切到更強的大杯模型格式化、補注釋、寫簡單測試這類輕活切到免費或低成本模型。切換是在 TUI 里按一下的事成本幾乎為零這個優(yōu)勢一定要用足。第二把團隊規(guī)范沉淀成 Skills。提交信息必須遵循 Conventional Commits、新代碼必須帶單元測試、前端組件必須復用設計系統(tǒng)組件——這些規(guī)則我全部寫進 Skill一次性投入后面每次讓 AI 干活它自動遵守不用重復解釋。第三堅持先看懂再動手的節(jié)奏。接手新項目永遠先讓 opencode 梳理結(jié)構和約束再開始改動。這個順序幫我避開了無數(shù)次改完才發(fā)現(xiàn)改錯地方的尷尬。第四大任務拆小步。我不會讓它一口氣重構整個認證系統(tǒng)而是拆成先改數(shù)據(jù)層、再改接口層、再改前端調(diào)用、最后補測試四五步。每完成一步立刻跑測試驗證出問題能快速定位AI 也不容易在超長任務里迷失方向。opencode 的迭代速度確實快我寫這篇文章時 2.x 已經(jīng)穩(wěn)定了再過幾個月不知道又會長成什么樣。但底層那套模型無關 Agent 工具鏈 開放技能生態(tài)的設計理念我覺得會是接下來終端 AI 編程工具的一個重要方向。如果你也在找一款能真正進項目干活的終端 AI 助理花半小時把它配起來大概率不會后悔。