左右各放一個聊天,中間留給程式:一款 VS Code 擴充功能把開發流程排成了一個介面
從一個 VS Code 擴充功能的左側圖示與左右雙會話配置看起,觀察獨立開發者如何把 CLI 安裝、並行對話與圖片生成排成一個可操作的介面。
科技 設計評論 約 4 分鐘閱讀
10 月 31 日,V2EX 使用者 ty5yidc 發文分享自己維護的開源專案 Claude Code Config Helper(LLS CCAI),版本更新至 3.2.81。這是一款圍繞 Claude CLI 打造的 VS Code 擴充功能,最初只為了管理模型提供商與設定,後來開發者把日常開發中幾個需要反覆切換工具的步驟收進了同一個地方。
先從入口看起。安裝之後,VS Code 左側工具列會多出一個形似字母 A 的 LLS CCAI 圖示,點進去就是一條被排好順序的引導:下載並驗證 CLI、或直接選用已安裝的版本,接著配置模型提供商與密鑰,最後選定工作區要用的模型、開始聊天。這種把「安裝、設定、使用」排成單一動線的做法,跟多數開發工具把文件丟給使用者自行拼湊的路數不同。CLI 的後續更新也收進設定頁,確認後下載安裝,進度直接顯示在介面裡;來源可選官方 npm 或 npmmirror 鏡像,且不會覆蓋外部安裝的 CLI,舊版檔案會被保留。
左右雙會話:把「不打斷」設計成畫面
這次更新最值得看的一塊,是「並行會話」。開發者的使用情境很具體:主對話正在實作功能,忽然需要查一個報錯或整理介面欄位,又不希望把主對話聊亂。解法是在編輯器左右各放一個聊天視窗,中間留給程式碼。右側寫功能、左側分析報錯,或者一邊改程式、一邊梳理測試場景。
兩個會話各自保留上下文、模型選擇與權限設定,也可以指定不同模型。開發者在文中特意說明,這裡不做自動多 Agent 編排,就只是兩個獨立會話。這個取捨本身誠實:上下文分開了,但工作區檔案並不會自動隔離,同一個檔案若被兩邊同時修改,責任仍在使用者身上。介面提供了注意力上的分工,檔案層面的紀律還是要自己安排。
這種「把並行攤在畫面上」的設計,與我們先前觀察過的Tripo Studio 接進 Codex 的介面取捨有相似的邏輯:工具不假裝自動化一切,而是把需要人判斷的環節做成清楚可見的欄位與入口。
圖片生成收進聊天輸入區
第三塊更新是內建圖片生成。使用者在聊天裡直接描述需求,例如「給這個記帳應用生成一枚簡潔的圖示,顏色跟目前介面一致,小尺寸下也要容易辨認」,聊天模型會結合需求與專案上下文組織提示詞,再調用配置好的圖片模型生成,連尺寸參數也由模型提交。使用者不必先自己寫一大段生圖提示詞。
配置方式有兩種:選擇已支援圖片介面的提供商與模型,或獨立填寫 Base URL、API Key 與模型 ID,不需另外安裝圖片 MCP 套件。生成在背景執行,完成後自動把結果送回發起任務的會話讓模型接手,不必反覆輪詢。圖片與任務記錄直接儲存在工作區的 .LLSOAI/openapi-image-generation/ 目錄下,路徑落在專案內,而不是某個遠端暫存,這對素材的管理與版本控制來說是個務實的選擇。
讓模型代寫提示詞再調用生圖,這條流程其實呼應了近期 AI 工具把多種素材收進同一介面的趨勢,例如先前分析的Reference to Video 小站如何把混亂素材收成一個介面,兩者都在縮短「需求」與「產出」之間的操作距離。
限制寫在明處
開發者把限制說得相當完整:需自備模型服務與密鑰,擴充功能不含免費額度;圖片生成與後續模型處理可能計費,能力以服務商為準,並非所有聊天模型都能生圖;CLI 更新會重啟擴充功能管理的活動會話,運行中的任務可能中斷。這是獨立專案,與 Anthropic 或 Microsoft 都無官方關係。
整體來看,這款擴充功能的價值在於它解決的是開發者自己每天碰到的三個小麻煩:配置麻煩、對話容易混、圖片需求要另切工具。它沒有發明新的互動範式,只是把幾個散落的步驟按使用順序排好,並把不能自動化的部分誠實地留給使用者。對獨立開發者而言,這種節制本身就是一種設計判斷。
主題 介面與互動設計
標籤 #claudecodeconfighelper+介面設計、#vscode擴充功能+開發工具、#並行會話+工作流設計