我一直觉得现在做开发特别是独立做小项目、写脚本、搞自动化的时候一个顺手好用的 AI 编程工作台比单纯会背 API 重要得多。这两年 AI 编程工具、模型更新快得吓人但大多数人其实还停在“装个插件、复制报错贴进去”的阶段这样根本发挥不出来。我整理了自己日常在用的 AI 编程工作台把工具、模型和基础配置这三块掰开揉碎了讲清楚涉及的关键概念和实操细节会尽量展开目的就是让你看完能直接照着搭自己一套少走点我当年踩过的弯路。这套工作台解决的核心问题其实是三个第一让 AI 能看懂你当前项目的完整上下文而不是只盯着你选中的那几行代码第二在不同任务场景下能用对模型不浪费钱也不浪费时间第三把常用配置、提示词片段固化下来让每次新开项目都能快速进入状态。文章适合正在用或者准备用 AI 辅助写代码的开发者不管是做前端、写后端脚本还是搞数据分析这套思路都能复用。1. AI 编程工作台的整体设计与选型思路先别急着装工具。我在第一次搭工作台的时候顺手装了十几个插件结果真正用上的没几个反而把编辑器拖得卡顿。后来才明白工作台不是“越多越好”而是要围绕几个核心需求来设计。1.1 工作台的分层设计我习惯把 AI 编程工作台分成三层编辑器层、模型层和配置层。这个分层逻辑决定了你的工具选型也决定了后续扩展能力。编辑器层是所有 AI 能力的前端入口你需要一个支持插件生态的编辑器目前主流选择基本都是 VS Code 或者它的分支版本。编辑器层干的事是选中代码区域、唤起 AI 回复、以 diff 形式接受或拒绝改动。这一层要解决的问题是“交互顺不顺”重点看三点补全响应速度、diff 视图好不好用、以及能不能同时挂多个 AI 服务。模型层是真正的“大脑”包括云端的闭源模型如 Claude、GPT 系列也包括本地部署的开源模型如 Qwen、DeepSeek 等。不同模型在代码补全、代码解释、重构建议这些任务上的表现差异很大推荐的做法是同时配置一个强力的云端模型和一个离线可用的本地模型日常补全贵在快复杂重构贵在准。配置层是整个工作台最容易被忽略、但价值最高的部分。它包含你的全局提示词、项目级指令文件、常用代码片段、环境变量管理以及配合 AI 使用 Git 和命令行工具的规范。没有好的配置层AI 就只能“看一步走一步”有了完整的配置AI 才能理解你的项目结构和技术栈输出更贴合实际的结果。1.2 为什么选择这套方案而不是单一工具市面上有很多集成式的 AI 编程工具比如 Cursor、Copilot它们开箱即用体验也确实好。但我在实际用了一年之后还是回到了“通用编辑器 多模型插件 自定义配置”的组合方案原因有三个组件的灵活替换性。云端模型账号可能出问题某个模型的供应商改了接口或者本地部署的模型效果更好想切换如果用的是集成方案换起来很麻烦而用组件化方案的话只需要改一个配置项。成本的精细控制。集成方案大多按月订阅但你实际使用的强度可能波动很大。拆分开来之后日常简单补全用本地免费模型复杂任务调用云端付费模型成本能控制在很合理的区间。尤其对独立开发者来说这笔账要算清楚。提示词和上下文可控。自己搭的工作台里边的每一条提示词、每一份项目说明文档都是自己写的AI 的行为风格和质量标准可以完全掌控。集成工具的黑盒提示词你只能被动接受出了问题都不知道怎么调。2. 核心工具选型解析工具选型是整个工作台最关键的决策点。我自己从 2023 年开始用 AI 辅助编程先后试过 GitHub Copilot、Cline、Continue 插件、以及轻量级的 Codex CLI在这里列出实际体验过的工具组合和选择理由供你参考。2.1 编辑器与 AI 插件组合如果你从零开始我推荐“VS Code Continue 插件”作为基础组合。VS Code 本身不笨重启动快插件市场丰富而且对各类语言都支持得不错。Continue 是一款开源插件核心价值在于它支持在同一个界面里配置多个模型你可以把 GPT、Claude、本地 Ollama 模型全部挂进去然后根据需要切换。这个组合的好处是数据相对可控。Continue 是本地插件对话记录、配置信息都存在本地不会强制同步到第三方服务器。对于公司项目或者涉及业务代码的场景这一点很重要。如果预算充足进阶方案是Cursor 编辑器。Cursor 本质上是 VS Code 的深度改造版对 AI 交互做了很多针对性优化比如代码上下文自动注入、跨文件重构、智能补全等。它带来的体验提升确实明显但要注意它的订阅价格并不低。我的建议是先用免费的 VS Code Continue 养成使用习惯确实觉得不够用了再切 Cursor。2.2 终端与 Git 协作工具AI 编程工作台不只是编辑器里的事很大一部分工作发生在终端。常用终端场景包括用 AI 解释报错、生成 Git 提交信息、批量重命名、写小脚本等。我常用的终端组合是Windows Terminal或 iTerm2 Git GitHub CLI其中 Git 和 GitHub CLI 需要重点提一下因为它们是 AI 编程中容易被忽略的一环。Git 用于版本控制这在 AI 生成大量代码改动的情况下尤其重要。AI 助手可能会生成不理想的改动如果没有 Git 保护出了问题时想回退就麻烦了。我养成的一个习惯是每次让 AI 做什么实质性改动之前先确保当前分支是干净的或者至少提交了一个存档点。GitHub CLI 则能让 AI 通过终端指令直接操作远程仓库比如快速提 PR、查看 Issue。结合 AI 来写 PR 描述和 Commit message能够极大减轻维护负担。2.3 提示词管理与项目级配置提示词管理是最容易被忽视的一环。很多人用 AI 编程觉得“效果不稳定”很大原因就是提示词太随机。我自己把提示词分成了三个层级全局级提示词放一些通用要求比如“请先解释你要怎么做再给我代码”“如果建议改动影响范围较大请先提示风险”。这些放在 Continue 或 Cursor 的全局配置里每个会话都会生效。项目级指令文件放在项目根目录下比如.cursorrules或者 Continue 支持的项目记忆文件。里边写清楚这个项目的技术栈、目录结构、代码规范、常用命令等。AI 读取这个文件后回答就会明显更贴合项目实际。会话级提示词在每次对话时临时补充比如“只改文件 A不要动其他文件”“用 Python 标准库实现不要引入第三方依赖”。这一层是最灵活的也是决定单次对话质量的关键。维护提示词本身也需要版本管理。我建议把常用的提示词片段放在一个单独的 markdown 文件里用 Git 管理起来这样换电脑或换工具时可以直接同步过去。3. 模型选择与应用场景匹配工作台的“大脑”部分是模型这部分我花了不少精力研究。整体上可以分为两条路线一条是使用云端大模型 API效果强、配置简单但要花钱另一条是用本地部署的开源模型数据安全、免费但效果受限于机器配置。两条路各有优劣我目前是并行使用按场景选择。3.1 云端模型的选型要点与对比目前最常用的云端模型有 Claude 系列、GPT 系列和 Gemini 系列。从我实际测试来看在代码理解和重构任务上Claude 的表现更符合我的使用偏好特别是在处理大段代码的语义理解、生成注释和文档、以及跨文件修改时显得更“聪明”。如果你主要用 AI 来写前端页面或者做小脚本Claude 和 GPT 的差距其实不大可以看自己的钱包和接入方便程度选择。使用云端模型最重要的一步是配置好 API Key并且保护好它不要硬编码在代码中不要提交到 Git 仓库。推荐做法是存在系统的环境变量里或者用一个.env文件管理并在.gitignore中排除它。另外云端模型有上下文长度限制目前主流模型大概能记住 128K~200K 个 token 的内容超出后就会“失忆”之前的上下文。处理大项目时要注意拆分成多个文件来对话而不是一次性把所有代码塞进去。3.2 本地模型的部署与硬件建议本地部署开源模型适合这么几类场景代码补全这种高频低难度任务因为延迟低、不花钱涉及敏感代码不想发到云端以及断网或网络不稳定时应急使用。部署本地模型我用的工具是Ollama一条命令就可以拉起一个模型服务然后通过 Continue 直接接入。Ollama 对硬件比较友好配合量化版本的模型文件家用显卡也能跑起来。如果要跑 7B 级别的代码模型比如 Qwen2.5-Coder 7B量化后大概需要 8GB 左右的显存普通中高端显卡可以顺利运行。如果只有 16GB 内存没有独立显卡跑 3B~4B 级模型也能勉强接受只是速度和生成质量会差一些。模型选型上我推荐从Qwen2.5-Coder系列和DeepSeek-Coder系列入手。这两个模型的中文理解能力好代码生成质量在开源模型里属于第一梯队。更有意思的是本地模型能和云端模型做互补本地模型负责快和频繁调用云端模型负责在需要深度分析时接管这种“双引擎”配置能让项目开发效率和成本控制同时达到一个比较理想的状态。3.3 模型切换与上下文管理的实操建议实际开发中一个重要经验是“先本地、后云端、换模型先换上下文”。早期新项目刚起步时需求还不明确我会让本地模型先做一些快速补全、单文件实现反正免费随便试。等到项目结构稳定下来需要做复杂的重构、模块划分、性能优化时再把上下文整理好切到云端模型做一次深度分析。切换模型之前务必手动清理一下对话里的无关内容。直接把一堆旧对话带到新模型里经常会让新模型被之前的错误结论带偏。我一般会开启一个新对话把最新的需求、相关文件路径、项目结构说明重新粘贴进去。看着麻烦但实际效果比“一个对话从头聊到尾”好得多。很多人有疑问“本地模型生成效果不如云端的那为什么还要用”我的回答是本地模型的核心价值不在“生成效率”而在无缝接入日常高频操作。就像是随身带了个自动补全助手而不是每次都要去打电话找专家求助。高频低难度的任务消耗掉之后你再把有限的云端配额花在真正需要深度思考的地方效率和成本就都舒服了。4. 基础环境配置与实战记录这一部分我直接给出可落地的配置步骤包括基础工具链的安装、编辑器设置、Ollama 部署、以及项目级提示词配置。这些是我在 Windows 和 macOS 上都验证过的最基础的路径。4.1 基础工具链安装无论用什么模型都需要先装好以下基础工具Git用于版本管理和项目存档无论项目大小都建议安装。Windows 推荐直接下载官方安装包macOS 如果装了 Homebrew 可以一条命令搞定。Node.js LTS很多 AI 插件和工具链依赖 Node.js 环境比如 Continue 插件本身就需要 Node 运行时。安装 LTS 版本即可不需要追新。Python 3.10很多代码生成目标都是 Python同时也用于跑各种开源工具和数据处理脚本。Docker如果需要本地部署模型服务或者跑一些依赖复杂的开源项目Docker 能省很多事。安装完成后建议把 Git 的默认分支设置为main配置好用户名和邮箱。把 SSH Key 配置好并加到 GitHub 上这样 AI 生成的代码改动在推送时不会因为权限问题卡住。4.2 Continue 插件与云端模型配置在 VS Code 的扩展市场搜索 Continue安装后左侧会多出一个对话面板。按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的取值方式我建议用环境变量引用而不是直接写死。这样做的好处是配置文件本身可以放心提交到 Git 仓库不会泄露密钥。同时无论后续是换模型还是换服务商只改环境变量就可以了。4.3 Ollama 本地部署与模型拉取Ollama 的安装非常简单去官网下载对应系统的安装包装好后在终端确认一下版本即可。安装完成后拉取模型ollama pull qwen2.5-coder:7b ollama pull deepseek-coder:6.7b我当前用的是 Qwen2.5-Coder 7B 的量化版本在 8GB 显存的显卡上跑生成速度大约每秒 20-30 个 token用于补全和小范围改动已经很流畅。如果是 24GB 显存可以考虑上 14B 的版本效果会明显上一个台阶。要对本地模型做更精细的控制可以调整 Ollama 的模型参数比如温度、上下文长度。创建一个 Modelfile 文件写入自定义参数FROM qwen2.5-coder:7b PARAMETER temperature 0.3 PARAMETER top_p 0.9然后构建并运行ollama create my-coder -f Modelfile ollama run my-coder温度参数在代码生成场景下我通常调得比较低0.2-0.4 之间。这样能减少模型“自由发挥”的几率输出更稳定、更符合规范。4.4 项目级指令文件的落地示例如果项目使用 Continue可以在项目根目录创建一个AGENTS.md文件Continue 会自动识别并作为全局上下文。这个文件的价值非常大我强烈建议每个项目都配一份。一个典型的AGENTS.md内容示例如下# 项目说明 这是一个 Python FastAPI 后端服务主要提供数据查询和统计分析接口。 ## 技术栈 - Python 3.11 - FastAPI - SQLAlchemy 2.0 - PostgreSQL ## 项目结构 - app/主应用代码 - app/api/路由入口 - app/services/业务逻辑 - app/models/数据库模型 ## 常用命令 - 安装依赖pip install -r requirements.txt - 启动服务uvicorn app.main:app --reload - 运行测试pytest ## 编码规范 - 所有函数必须带有类型注解 - 禁止使用全局变量 - 数据库查询必须走 repository 层这样配置之后每次开启新的 AI 对话模型都会自动读取这个文件回答会明显更贴合项目实际情况。常见的问题比如 AI 总把 Python 包更新写成 npm install、或者在 FastAPI 项目里生成 Django 风格的代码大概率都能通过这个文件解决。5. 实操中经常遇到的坑与排查方法这部分是压箱底的排查记录。配置工作台本身并不难难的是在实际使用中遇到各种诡异问题之后能够快速定位并解决。5.1 模型上下文长度不足导致的“失忆”现象是聊到后面AI 开始反复问你之前已经说过的内容或者干脆说“我没有看到你之前提到的文件”。排查思路很简单看当前模型剩余上下文还有多少不同模型和提供商的上下文限制不一样可以在官方文档中查到准确的限制数值。解决办法主要有三种一是精简对话把旧的没必要的内容删掉再开新对话二是把关键信息写成AGENTS.md或者单独的.md文件每次对话都先让 AI 读取三是改用上下文窗口更大的模型。对于代码项目来说我更推荐第二种方式因为“精简对话”往往意味着丢失关键上下文而让 AI 持久化读取文件既省 token 又稳定。5.2 本地模型反思能力不足导致代码质量下降本地模型的生成速度确实快但其“反思”和“自我纠错”能力明显弱于云端大模型。如果你用本地模型做复杂重构经常会出现改了一堆文件但逻辑不对的情况。后来我总结出一个有效的提示词让模型“先解释再生成”。也就是在提示词里明确要求在生成代码之前请先解释你的思路、方案和对应的文件改动计划确认无误后再生成完整代码。这个简单的提示词极大提升了本地模型输出的质量因为它强制模型在生成代码之前先在语言层面梳理逻辑而不是直接硬写。5.3 多模型切换后的回答风格不一致如果你同时用了多个模型会发现它们的回答风格差异很大有的喜欢详细解释有的直接给代码还有的会把代码和注释混在一起。这种风格差异影响协作效率尤其当你需要把 AI 生成的内容整合到团队项目里时。解决办法是在全局提示词里显式规定回答格式例如回答要求 1. 如果问题涉及代码修改请先简述修改思路再给出修改后的完整代码块。 2. 所有代码块需标注语言类型。 3. 尽量避免输出与问题无关的背景知识除非我主动询问。 4. 代码改动较大时请单独列出改动文件清单。这套格式放在全局提示词里所有模型都会遵循风格问题基本解决。5.4 配置修改后不生效的排查顺序如果改完配置没反应经常遇到的情况包括配置文件路径不对、格式缩进错误、插件没有重载、API Key 没设置正确。排查顺序我建议是先看插件输出面板有无报错再检查配置文件是否能正常解析然后用终端手动测试 API 是否连通最后重启编辑器。这个顺序能覆盖百分之八十的问题。比如你用 Ollama 跑本地模型但 Continue 连不上第一步应该先测试本地服务是否正常ollama list curl http://localhost:11434/api/tags如果这两个命令有输出说明本地服务正常问题大概率出在 Continue 的配置格式上。问题现象可能原因排查优先级AI 不读取 AGENTS.md文件不在项目根目录或名称拼写错误高补全速度极慢本地模型未量化、显存不足高API Key 报错但重试后能用网络波动或 Key 权限过期中代码生成后乱改无关文件对话上下文缺少改动范围限制中6. 后续可以继续扩展的方向工作台搭好之后可以继续扩展的方向还有很多。比如把 AI 接入到会读仓库 Issue 的智能体工作流里或者用 AI 做自动代码评审、自动生成变更日志、自动补测试用例、自动重构遗留代码等。总而言之先把手头的工作台通过这几步配好AI 编程的效率提升就已经远远超过绝大多数普通开发者了。我个人在实际操作中的体会是AI 编程工作台这个东西不要神话它也不要低估它。它真正改变的不是“能不能写代码”而是让人从重复劳动里抽身把时间花在想清楚问题、设计好架构上。而这一切的前提就是先把工具、模型和基础配置这三件基础事做扎实后续你想怎么折腾都行。