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