我一直覺得現(xiàn)在做開發(fā)特別是獨立做小項目、寫腳本、搞自動化的時候一個順手好用的 AI 編程工作臺比單純會背 API 重要得多。這兩年 AI 編程工具、模型更新快得嚇人但大多數(shù)人其實還停在“裝個插件、復(fù)制報錯貼進(jìn)去”的階段這樣根本發(fā)揮不出來。我整理了自己日常在用的 AI 編程工作臺把工具、模型和基礎(chǔ)配置這三塊掰開揉碎了講清楚涉及的關(guān)鍵概念和實操細(xì)節(jié)會盡量展開目的就是讓你看完能直接照著搭自己一套少走點我當(dāng)年踩過的彎路。這套工作臺解決的核心問題其實是三個第一讓 AI 能看懂你當(dāng)前項目的完整上下文而不是只盯著你選中的那幾行代碼第二在不同任務(wù)場景下能用對模型不浪費錢也不浪費時間第三把常用配置、提示詞片段固化下來讓每次新開項目都能快速進(jìn)入狀態(tài)。文章適合正在用或者準(zhǔn)備用 AI 輔助寫代碼的開發(fā)者不管是做前端、寫后端腳本還是搞數(shù)據(jù)分析這套思路都能復(fù)用。1. AI 編程工作臺的整體設(shè)計與選型思路先別急著裝工具。我在第一次搭工作臺的時候順手裝了十幾個插件結(jié)果真正用上的沒幾個反而把編輯器拖得卡頓。后來才明白工作臺不是“越多越好”而是要圍繞幾個核心需求來設(shè)計。1.1 工作臺的分層設(shè)計我習(xí)慣把 AI 編程工作臺分成三層編輯器層、模型層和配置層。這個分層邏輯決定了你的工具選型也決定了后續(xù)擴(kuò)展能力。編輯器層是所有 AI 能力的前端入口你需要一個支持插件生態(tài)的編輯器目前主流選擇基本都是 VS Code 或者它的分支版本。編輯器層干的事是選中代碼區(qū)域、喚起 AI 回復(fù)、以 diff 形式接受或拒絕改動。這一層要解決的問題是“交互順不順”重點看三點補(bǔ)全響應(yīng)速度、diff 視圖好不好用、以及能不能同時掛多個 AI 服務(wù)。模型層是真正的“大腦”包括云端的閉源模型如 Claude、GPT 系列也包括本地部署的開源模型如 Qwen、DeepSeek 等。不同模型在代碼補(bǔ)全、代碼解釋、重構(gòu)建議這些任務(wù)上的表現(xiàn)差異很大推薦的做法是同時配置一個強(qiáng)力的云端模型和一個離線可用的本地模型日常補(bǔ)全貴在快復(fù)雜重構(gòu)貴在準(zhǔn)。配置層是整個工作臺最容易被忽略、但價值最高的部分。它包含你的全局提示詞、項目級指令文件、常用代碼片段、環(huán)境變量管理以及配合 AI 使用 Git 和命令行工具的規(guī)范。沒有好的配置層AI 就只能“看一步走一步”有了完整的配置AI 才能理解你的項目結(jié)構(gòu)和技術(shù)棧輸出更貼合實際的結(jié)果。1.2 為什么選擇這套方案而不是單一工具市面上有很多集成式的 AI 編程工具比如 Cursor、Copilot它們開箱即用體驗也確實好。但我在實際用了一年之后還是回到了“通用編輯器 多模型插件 自定義配置”的組合方案原因有三個組件的靈活替換性。云端模型賬號可能出問題某個模型的供應(yīng)商改了接口或者本地部署的模型效果更好想切換如果用的是集成方案換起來很麻煩而用組件化方案的話只需要改一個配置項。成本的精細(xì)控制。集成方案大多按月訂閱但你實際使用的強(qiáng)度可能波動很大。拆分開來之后日常簡單補(bǔ)全用本地免費模型復(fù)雜任務(wù)調(diào)用云端付費模型成本能控制在很合理的區(qū)間。尤其對獨立開發(fā)者來說這筆賬要算清楚。提示詞和上下文可控。自己搭的工作臺里邊的每一條提示詞、每一份項目說明文檔都是自己寫的AI 的行為風(fēng)格和質(zhì)量標(biāo)準(zhǔn)可以完全掌控。集成工具的黑盒提示詞你只能被動接受出了問題都不知道怎么調(diào)。2. 核心工具選型解析工具選型是整個工作臺最關(guān)鍵的決策點。我自己從 2023 年開始用 AI 輔助編程先后試過 GitHub Copilot、Cline、Continue 插件、以及輕量級的 Codex CLI在這里列出實際體驗過的工具組合和選擇理由供你參考。2.1 編輯器與 AI 插件組合如果你從零開始我推薦“VS Code Continue 插件”作為基礎(chǔ)組合。VS Code 本身不笨重啟動快插件市場豐富而且對各類語言都支持得不錯。Continue 是一款開源插件核心價值在于它支持在同一個界面里配置多個模型你可以把 GPT、Claude、本地 Ollama 模型全部掛進(jìn)去然后根據(jù)需要切換。這個組合的好處是數(shù)據(jù)相對可控。Continue 是本地插件對話記錄、配置信息都存在本地不會強(qiáng)制同步到第三方服務(wù)器。對于公司項目或者涉及業(yè)務(wù)代碼的場景這一點很重要。如果預(yù)算充足進(jìn)階方案是Cursor 編輯器。Cursor 本質(zhì)上是 VS Code 的深度改造版對 AI 交互做了很多針對性優(yōu)化比如代碼上下文自動注入、跨文件重構(gòu)、智能補(bǔ)全等。它帶來的體驗提升確實明顯但要注意它的訂閱價格并不低。我的建議是先用免費的 VS Code Continue 養(yǎng)成使用習(xí)慣確實覺得不夠用了再切 Cursor。2.2 終端與 Git 協(xié)作工具AI 編程工作臺不只是編輯器里的事很大一部分工作發(fā)生在終端。常用終端場景包括用 AI 解釋報錯、生成 Git 提交信息、批量重命名、寫小腳本等。我常用的終端組合是Windows Terminal或 iTerm2 Git GitHub CLI其中 Git 和 GitHub CLI 需要重點提一下因為它們是 AI 編程中容易被忽略的一環(huán)。Git 用于版本控制這在 AI 生成大量代碼改動的情況下尤其重要。AI 助手可能會生成不理想的改動如果沒有 Git 保護(hù)出了問題時想回退就麻煩了。我養(yǎng)成的一個習(xí)慣是每次讓 AI 做什么實質(zhì)性改動之前先確保當(dāng)前分支是干凈的或者至少提交了一個存檔點。GitHub CLI 則能讓 AI 通過終端指令直接操作遠(yuǎn)程倉庫比如快速提 PR、查看 Issue。結(jié)合 AI 來寫 PR 描述和 Commit message能夠極大減輕維護(hù)負(fù)擔(dān)。2.3 提示詞管理與項目級配置提示詞管理是最容易被忽視的一環(huán)。很多人用 AI 編程覺得“效果不穩(wěn)定”很大原因就是提示詞太隨機(jī)。我自己把提示詞分成了三個層級全局級提示詞放一些通用要求比如“請先解釋你要怎么做再給我代碼”“如果建議改動影響范圍較大請先提示風(fēng)險”。這些放在 Continue 或 Cursor 的全局配置里每個會話都會生效。項目級指令文件放在項目根目錄下比如.cursorrules或者 Continue 支持的項目記憶文件。里邊寫清楚這個項目的技術(shù)棧、目錄結(jié)構(gòu)、代碼規(guī)范、常用命令等。AI 讀取這個文件后回答就會明顯更貼合項目實際。會話級提示詞在每次對話時臨時補(bǔ)充比如“只改文件 A不要動其他文件”“用 Python 標(biāo)準(zhǔn)庫實現(xiàn)不要引入第三方依賴”。這一層是最靈活的也是決定單次對話質(zhì)量的關(guān)鍵。維護(hù)提示詞本身也需要版本管理。我建議把常用的提示詞片段放在一個單獨的 markdown 文件里用 Git 管理起來這樣換電腦或換工具時可以直接同步過去。3. 模型選擇與應(yīng)用場景匹配工作臺的“大腦”部分是模型這部分我花了不少精力研究。整體上可以分為兩條路線一條是使用云端大模型 API效果強(qiáng)、配置簡單但要花錢另一條是用本地部署的開源模型數(shù)據(jù)安全、免費但效果受限于機(jī)器配置。兩條路各有優(yōu)劣我目前是并行使用按場景選擇。3.1 云端模型的選型要點與對比目前最常用的云端模型有 Claude 系列、GPT 系列和 Gemini 系列。從我實際測試來看在代碼理解和重構(gòu)任務(wù)上Claude 的表現(xiàn)更符合我的使用偏好特別是在處理大段代碼的語義理解、生成注釋和文檔、以及跨文件修改時顯得更“聰明”。如果你主要用 AI 來寫前端頁面或者做小腳本Claude 和 GPT 的差距其實不大可以看自己的錢包和接入方便程度選擇。使用云端模型最重要的一步是配置好 API Key并且保護(hù)好它不要硬編碼在代碼中不要提交到 Git 倉庫。推薦做法是存在系統(tǒng)的環(huán)境變量里或者用一個.env文件管理并在.gitignore中排除它。另外云端模型有上下文長度限制目前主流模型大概能記住 128K~200K 個 token 的內(nèi)容超出后就會“失憶”之前的上下文。處理大項目時要注意拆分成多個文件來對話而不是一次性把所有代碼塞進(jìn)去。3.2 本地模型的部署與硬件建議本地部署開源模型適合這么幾類場景代碼補(bǔ)全這種高頻低難度任務(wù)因為延遲低、不花錢涉及敏感代碼不想發(fā)到云端以及斷網(wǎng)或網(wǎng)絡(luò)不穩(wěn)定時應(yīng)急使用。部署本地模型我用的工具是Ollama一條命令就可以拉起一個模型服務(wù)然后通過 Continue 直接接入。Ollama 對硬件比較友好配合量化版本的模型文件家用顯卡也能跑起來。如果要跑 7B 級別的代碼模型比如 Qwen2.5-Coder 7B量化后大概需要 8GB 左右的顯存普通中高端顯卡可以順利運行。如果只有 16GB 內(nèi)存沒有獨立顯卡跑 3B~4B 級模型也能勉強(qiáng)接受只是速度和生成質(zhì)量會差一些。模型選型上我推薦從Qwen2.5-Coder系列和DeepSeek-Coder系列入手。這兩個模型的中文理解能力好代碼生成質(zhì)量在開源模型里屬于第一梯隊。更有意思的是本地模型能和云端模型做互補(bǔ)本地模型負(fù)責(zé)快和頻繁調(diào)用云端模型負(fù)責(zé)在需要深度分析時接管這種“雙引擎”配置能讓項目開發(fā)效率和成本控制同時達(dá)到一個比較理想的狀態(tài)。3.3 模型切換與上下文管理的實操建議實際開發(fā)中一個重要經(jīng)驗是“先本地、后云端、換模型先換上下文”。早期新項目剛起步時需求還不明確我會讓本地模型先做一些快速補(bǔ)全、單文件實現(xiàn)反正免費隨便試。等到項目結(jié)構(gòu)穩(wěn)定下來需要做復(fù)雜的重構(gòu)、模塊劃分、性能優(yōu)化時再把上下文整理好切到云端模型做一次深度分析。切換模型之前務(wù)必手動清理一下對話里的無關(guān)內(nèi)容。直接把一堆舊對話帶到新模型里經(jīng)常會讓新模型被之前的錯誤結(jié)論帶偏。我一般會開啟一個新對話把最新的需求、相關(guān)文件路徑、項目結(jié)構(gòu)說明重新粘貼進(jìn)去。看著麻煩但實際效果比“一個對話從頭聊到尾”好得多。很多人有疑問“本地模型生成效果不如云端的那為什么還要用”我的回答是本地模型的核心價值不在“生成效率”而在無縫接入日常高頻操作。就像是隨身帶了個自動補(bǔ)全助手而不是每次都要去打電話找專家求助。高頻低難度的任務(wù)消耗掉之后你再把有限的云端配額花在真正需要深度思考的地方效率和成本就都舒服了。4. 基礎(chǔ)環(huán)境配置與實戰(zhàn)記錄這一部分我直接給出可落地的配置步驟包括基礎(chǔ)工具鏈的安裝、編輯器設(shè)置、Ollama 部署、以及項目級提示詞配置。這些是我在 Windows 和 macOS 上都驗證過的最基礎(chǔ)的路徑。4.1 基礎(chǔ)工具鏈安裝無論用什么模型都需要先裝好以下基礎(chǔ)工具Git用于版本管理和項目存檔無論項目大小都建議安裝。Windows 推薦直接下載官方安裝包macOS 如果裝了 Homebrew 可以一條命令搞定。Node.js LTS很多 AI 插件和工具鏈依賴 Node.js 環(huán)境比如 Continue 插件本身就需要 Node 運行時。安裝 LTS 版本即可不需要追新。Python 3.10很多代碼生成目標(biāo)都是 Python同時也用于跑各種開源工具和數(shù)據(jù)處理腳本。Docker如果需要本地部署模型服務(wù)或者跑一些依賴復(fù)雜的開源項目Docker 能省很多事。安裝完成后建議把 Git 的默認(rèn)分支設(shè)置為main配置好用戶名和郵箱。把 SSH Key 配置好并加到 GitHub 上這樣 AI 生成的代碼改動在推送時不會因為權(quán)限問題卡住。4.2 Continue 插件與云端模型配置在 VS Code 的擴(kuò)展市場搜索 Continue安裝后左側(cè)會多出一個對話面板。按CmdShiftLmacOS或CtrlShiftLWindows可以選中代碼片段直接加到對話上下文里這個操作是使用頻次最高的。接下來配置模型。在 Continue 的配置文件config.yaml中需要按模型提供商的格式填入 API 地址和 Key。下面是一個可參考的配置示例把本地 Ollama 模型和云端模型都掛上去models: - name: GPT-4o provider: openai model: gpt-4o apiBase: https://api.openai.com/v1 apiKey: ${OPENAI_API_KEY} - name: DeepSeek Coder provider: deepseek model: deepseek-coder apiBase: https://api.deepseek.com/v1 apiKey: ${DEEPSEEK_API_KEY} - name: 本地 Claude Code provider: ollama model: qwen2.5-coder:7b apiBase: http://localhost:11434注意apiKey的取值方式我建議用環(huán)境變量引用而不是直接寫死。這樣做的好處是配置文件本身可以放心提交到 Git 倉庫不會泄露密鑰。同時無論后續(xù)是換模型還是換服務(wù)商只改環(huán)境變量就可以了。4.3 Ollama 本地部署與模型拉取Ollama 的安裝非常簡單去官網(wǎng)下載對應(yīng)系統(tǒng)的安裝包裝好后在終端確認(rèn)一下版本即可。安裝完成后拉取模型ollama pull qwen2.5-coder:7b ollama pull deepseek-coder:6.7b我當(dāng)前用的是 Qwen2.5-Coder 7B 的量化版本在 8GB 顯存的顯卡上跑生成速度大約每秒 20-30 個 token用于補(bǔ)全和小范圍改動已經(jīng)很流暢。如果是 24GB 顯存可以考慮上 14B 的版本效果會明顯上一個臺階。要對本地模型做更精細(xì)的控制可以調(diào)整 Ollama 的模型參數(shù)比如溫度、上下文長度。創(chuàng)建一個 Modelfile 文件寫入自定義參數(shù)FROM qwen2.5-coder:7b PARAMETER temperature 0.3 PARAMETER top_p 0.9然后構(gòu)建并運行ollama create my-coder -f Modelfile ollama run my-coder溫度參數(shù)在代碼生成場景下我通常調(diào)得比較低0.2-0.4 之間。這樣能減少模型“自由發(fā)揮”的幾率輸出更穩(wěn)定、更符合規(guī)范。4.4 項目級指令文件的落地示例如果項目使用 Continue可以在項目根目錄創(chuàng)建一個AGENTS.md文件Continue 會自動識別并作為全局上下文。這個文件的價值非常大我強(qiáng)烈建議每個項目都配一份。一個典型的AGENTS.md內(nèi)容示例如下# 項目說明 這是一個 Python FastAPI 后端服務(wù)主要提供數(shù)據(jù)查詢和統(tǒng)計分析接口。 ## 技術(shù)棧 - Python 3.11 - FastAPI - SQLAlchemy 2.0 - PostgreSQL ## 項目結(jié)構(gòu) - app/主應(yīng)用代碼 - app/api/路由入口 - app/services/業(yè)務(wù)邏輯 - app/models/數(shù)據(jù)庫模型 ## 常用命令 - 安裝依賴pip install -r requirements.txt - 啟動服務(wù)uvicorn app.main:app --reload - 運行測試pytest ## 編碼規(guī)范 - 所有函數(shù)必須帶有類型注解 - 禁止使用全局變量 - 數(shù)據(jù)庫查詢必須走 repository 層這樣配置之后每次開啟新的 AI 對話模型都會自動讀取這個文件回答會明顯更貼合項目實際情況。常見的問題比如 AI 總把 Python 包更新寫成 npm install、或者在 FastAPI 項目里生成 Django 風(fēng)格的代碼大概率都能通過這個文件解決。5. 實操中經(jīng)常遇到的坑與排查方法這部分是壓箱底的排查記錄。配置工作臺本身并不難難的是在實際使用中遇到各種詭異問題之后能夠快速定位并解決。5.1 模型上下文長度不足導(dǎo)致的“失憶”現(xiàn)象是聊到后面AI 開始反復(fù)問你之前已經(jīng)說過的內(nèi)容或者干脆說“我沒有看到你之前提到的文件”。排查思路很簡單看當(dāng)前模型剩余上下文還有多少不同模型和提供商的上下文限制不一樣可以在官方文檔中查到準(zhǔn)確的限制數(shù)值。解決辦法主要有三種一是精簡對話把舊的沒必要的內(nèi)容刪掉再開新對話二是把關(guān)鍵信息寫成AGENTS.md或者單獨的.md文件每次對話都先讓 AI 讀取三是改用上下文窗口更大的模型。對于代碼項目來說我更推薦第二種方式因為“精簡對話”往往意味著丟失關(guān)鍵上下文而讓 AI 持久化讀取文件既省 token 又穩(wěn)定。5.2 本地模型反思能力不足導(dǎo)致代碼質(zhì)量下降本地模型的生成速度確實快但其“反思”和“自我糾錯”能力明顯弱于云端大模型。如果你用本地模型做復(fù)雜重構(gòu)經(jīng)常會出現(xiàn)改了一堆文件但邏輯不對的情況。后來我總結(jié)出一個有效的提示詞讓模型“先解釋再生成”。也就是在提示詞里明確要求在生成代碼之前請先解釋你的思路、方案和對應(yīng)的文件改動計劃確認(rèn)無誤后再生成完整代碼。這個簡單的提示詞極大提升了本地模型輸出的質(zhì)量因為它強(qiáng)制模型在生成代碼之前先在語言層面梳理邏輯而不是直接硬寫。5.3 多模型切換后的回答風(fēng)格不一致如果你同時用了多個模型會發(fā)現(xiàn)它們的回答風(fēng)格差異很大有的喜歡詳細(xì)解釋有的直接給代碼還有的會把代碼和注釋混在一起。這種風(fēng)格差異影響協(xié)作效率尤其當(dāng)你需要把 AI 生成的內(nèi)容整合到團(tuán)隊項目里時。解決辦法是在全局提示詞里顯式規(guī)定回答格式例如回答要求 1. 如果問題涉及代碼修改請先簡述修改思路再給出修改后的完整代碼塊。 2. 所有代碼塊需標(biāo)注語言類型。 3. 盡量避免輸出與問題無關(guān)的背景知識除非我主動詢問。 4. 代碼改動較大時請單獨列出改動文件清單。這套格式放在全局提示詞里所有模型都會遵循風(fēng)格問題基本解決。5.4 配置修改后不生效的排查順序如果改完配置沒反應(yīng)經(jīng)常遇到的情況包括配置文件路徑不對、格式縮進(jìn)錯誤、插件沒有重載、API Key 沒設(shè)置正確。排查順序我建議是先看插件輸出面板有無報錯再檢查配置文件是否能正常解析然后用終端手動測試 API 是否連通最后重啟編輯器。這個順序能覆蓋百分之八十的問題。比如你用 Ollama 跑本地模型但 Continue 連不上第一步應(yīng)該先測試本地服務(wù)是否正常ollama list curl http://localhost:11434/api/tags如果這兩個命令有輸出說明本地服務(wù)正常問題大概率出在 Continue 的配置格式上。問題現(xiàn)象可能原因排查優(yōu)先級AI 不讀取 AGENTS.md文件不在項目根目錄或名稱拼寫錯誤高補(bǔ)全速度極慢本地模型未量化、顯存不足高API Key 報錯但重試后能用網(wǎng)絡(luò)波動或 Key 權(quán)限過期中代碼生成后亂改無關(guān)文件對話上下文缺少改動范圍限制中6. 后續(xù)可以繼續(xù)擴(kuò)展的方向工作臺搭好之后可以繼續(xù)擴(kuò)展的方向還有很多。比如把 AI 接入到會讀倉庫 Issue 的智能體工作流里或者用 AI 做自動代碼評審、自動生成變更日志、自動補(bǔ)測試用例、自動重構(gòu)遺留代碼等?？偠灾劝咽诸^的工作臺通過這幾步配好AI 編程的效率提升就已經(jīng)遠(yuǎn)遠(yuǎn)超過絕大多數(shù)普通開發(fā)者了。我個人在實際操作中的體會是AI 編程工作臺這個東西不要神話它也不要低估它。它真正改變的不是“能不能寫代碼”而是讓人從重復(fù)勞動里抽身把時間花在想清楚問題、設(shè)計好架構(gòu)上。而這一切的前提就是先把工具、模型和基礎(chǔ)配置這三件基礎(chǔ)事做扎實后續(xù)你想怎么折騰都行。