1. 从零到一AI 编程工作台的搭建思路1.1 我理解的“工作台”是哪几块如果只看标题很多人会以为“AI 编程工作台”就是装一个插件、绑一个 API Key、然后在 IDE 里问问问题。我真正用起来之后发现这套东西应该拆成四个模块编辑接入层、模型层、上下文层、工程化辅助层。编辑接入层解决“在哪里跟 AI 对话”模型层解决“让哪个模型来干活”上下文层解决“AI 有没有足够信息理解我的项目”工程化辅助层解决“代码写完之后怎么让 AI 帮忙收尾”。这个拆分不是学术上的分类而是我踩坑踩出来的。一开始我只有一个聊天窗口代码写不出来就复制报错过去问虽然能用但每次都像在两个软件之间反复横跳。后来我把 AI 插件直接放进 VS Code让它可以读取选中代码、当前文件和 Git diff整个体验完全不一样。再往后我加了本地模型、统一环境变量、项目级提示词才算把工具、模型与基础配置真正拼成一个完整工作台。这套工作台能解决的核心问题说白了就是三件事降低从“想法”到“代码”的摩擦减少查文档和复制报错的次数以及让 AI 生成的代码更贴近你项目的真实写法。适合的人群也很明确已经会用 ChatGPT 写点零散代码但觉得不系统或者在团队里想把 AI 编程固化成一整套流程。如果你目前只是偶尔玩一玩不看这篇也能活但一旦开始追求效率这套配置思路能让你少走很多弯路。1.2 选型原则不追新只求稳我见过太多朋友一上来就装五六个 AI 插件Cline、Continue、Codeium、GitHub Copilot 全塞进 VS Code结果每个插件都扫描一遍索引电脑风扇起飞明明只想补全一行代码结果弹出一堆重复建议。AI 编程工具的入口非常多但真正的瓶颈不是工具数量而是你有没有一个稳定的上下文和模型调用管道。我自己定的选型原则是每天必须用的主工具不超过三个编辑器、补全插件、终端辅助各一个。模型层面核心模型固定一个备用模型一个本地模型按需再开。这个原则看起来很保守但实际用下来效率最高。因为频繁切换工具的隐性成本非常大你换一次插件快捷键要重新适应上下文要重新建立连注释风格都可能不一致。与其追逐每天冒出来的新框架不如先把一套组合用到顺手。选择工具时我还有一个判断标准是否支持自定义模型接入。有些商业插件很好用但闭源、模型绑定、上下文黑盒一旦你觉得它不行迁移成本高得吓人。我更倾向开源或者至少有标准接口的工具比如 VS Code 生态里的 Continue标准 OpenAI 兼容接口本地模型能接云端模型也能接。这样今天用 Qwen明天换 DeepSeek只需要改配置不用换工具。1.3 先决条件硬件、账号与数据安全搭建之前必须想清楚一个现实问题你的机器能跑什么你的代码能不能出内网。如果只是用云端 API比如 DeepSeek、通义、Kimi、智谱这类服务电脑 8GB 内存就可以很流畅。因为真正的计算都在云端本地只负责编辑和请求。如果你打算跑本地模型那硬件门槛就上来了。以 Qwen2.5-Coder 7B 为例Q4 量化版本通常需要 6GB 左右显存如果还要长上下文内存 16GB 会比较稳。再想跑 32B 级别的模型那就需要 24GB 以上显存普通开发机基本吃不消。数据安全是更容易被忽略的问题。如果你写的是公司内部代码尤其涉及业务逻辑和敏感数据把代码直接发给云端大模型是非常危险的事。我见过有同事用 AI 插件时不小心把整个项目索引发给外部接口虽然没有出大事但事后想想冷汗都出来了。现在我的处理方式是普通开源项目和高敏项目分开高敏项目只用本地模型或者只让 AI 处理脱敏后的片段。这一条应该放在所有配置之前。2. 工具链配置把编辑器、终端和 Agent 串起来2.1 编辑器与插件VS Code Continue编辑器我选 VS Code不是因为它最新而是因为生态最成熟。最关键的插件我用 Continue它的核心能力是允许你在编辑器里直接跟多个模型对话可以读取选中代码、当前文件、终端输出也支持自定义模型供应商。Continue 的优势是配置透明你可以在 JSON 配置里看清楚它到底把请求发给了谁不用猜。我建议在 VS Code 插件市场安装 Continue 后先不要急着加一堆模型而是把最常用的两个模型配置好。一个留给日常对话和代码生成一个留给本地补全。示例如下{ models: [ { title: qwen2.5-coder:7b, provider: ollama, model: qwen2.5-coder:7b }, { title: deepseek-chat, provider: openai, model: deepseek-chat, apiBase: https://api.deepseek.com/v1, apiKey: ${DEEPSEEK_API_KEY} } ] }这里有两个关键点。第一本地模型走 Ollama 的 provider不需要 API Key云端模型走 OpenAI 兼容协议在 apiBase 里填供应商地址。第二apiKey 不要直接写成明文我习惯写成环境变量${DEEPSEEK_API_KEY}这样即使配置目录泄露也不会把密钥带走。配置完重启 VS Code在 Continue 面板右上角就能切换模型。2.2 终端与 Shell 配置让 AI 能“看懂”报错编辑区搞定了终端也不能空着。AI 编程工作台里终端是最容易被低估的一环因为很多报错只在终端出现而你复制给 AI 的文本往往被截断、转义或者丢失了关键前缀。我习惯用 tmux 把我的一整套开发环境拆成多个窗口一个窗口开编辑器一个窗口跑程序一个窗口放日志。这样即使 AI 补全出了问题我也不会因为终端任务挂掉而手忙脚乱。更重要的是我会在运行命令后面加一个“导出日志”的动作比如把输出重定向到文件python train.py 21 | tee train.log这样做的目的很直接AI 对话上下文有限一段超长报错塞进去模型很容易丢失重点。把日志写到文件后我可以让 AI 只读文件尾部的错误段先定位 Traceback再分析是环境问题还是代码问题。对于经常跑的构建命令我也写了几个简短的 shell 函数比如runpy、runnode让 AI 在帮我生成命令时更贴近我的习惯。如果你在终端里也想用 AI推荐尝试 Aider 这类开源终端结对编程工具。它的核心思路是基于 Git diff 工作AI 改完代码后你可以逐个 hunk 确认然后由 Aider 自动提交。对于大范围重构我一直觉得终端 Agent 比编辑器内对话更好用因为它会把整个仓库的 Git 历史当成上下文而不是只盯着你打开的那一个文件。2.3 版本控制与自动化AI 辅助提交和 Code Review很多 AI 工作台配置都漏掉了一个重要模块提交信息生成和 Code Review。其实这个环节最适合用 AI因为它的输入输出都很标准化。我会准备一套固定提示词把git diff交给模型要求它生成 Conventional Commits 格式的提交信息。例如根据以下 git diff 生成 commit message使用 conventional commits 格式必须包含 type 和 scope控制在 50 个字符以内用中文描述。把这套提示词固化成一个命令后基本不用每次手写。关键是不要让模型只看到单个文件的 diff要让整个 commit 的上下文一起给进去。不同文件的改动可能存在逻辑关联只给一个文件会让提交信息支离破碎。Code Review 也一样。我每次写完一个 feature 分支会让 AI 扮演无情的 reviewer按照“可读性、边界条件、错误处理、测试覆盖”四个维度提意见。再把建议和 diff 放到本地模型里做一轮“脱敏审查”确认不存在明显问题后再给人做正式评审。这样做的收益不是 AI 真能替代人而是它能把低级问题提前拦下来让人把精力花在架构和业务逻辑上。3. 模型选择云端 API、本地模型与混合策略3.1 主要场景下的模型怎么搭配模型选择这一块很多人会陷入“哪个模型最强”的焦虑。我的经验是AI 编程工作台里不存在万能模型只有“场景匹配”的模型。要按任务类型来搭而不是按排行榜来搭。我目前的搭配如下场景推荐模型选择原因行内补全Qwen2.5-Coder 3B/7B 本地延迟低不打断思路敏感代码不出本机日常问答与代码生成DeepSeek-V3 / GLM-4 等云端 API长上下文理解强对工程问题回答稳定大范围重构DeepSeek-R1 或 Claude 系列推理型模型能拆解复杂任务但成本和速度较高测试用例生成Qwen2.5-Coder 32B 或 GPT-4.1结构清晰模板化程度高模型越大效果越稳这个表格背后有一个原则延迟敏感、低价值的任务尽量本地化高价值、需要深度理解的任务放在云端。本地模型哪怕只有 7B做补全也足够快而且不产生额外费用。云端大模型适合处理一次性的复杂问题比如重新设计一个模块或者解释一段完全陌生的代码。还有一个备用原则。云端 API 偶尔会抖动一家接口超时另一家不一定超时。所以我会在 Continue 里至少配两个云端模型主模型响应不了时一键切换不用改代码。这里要注意两个模型尽量不要都吃同一路接口避免单点故障。3.2 本地模型部署的基础配置本地模型我目前用 Ollama 管理配置最简单社区模型也齐。安装 Ollama 之后拉模型只需要两条命令ollama pull qwen2.5-coder:7b ollama run qwen2.5-coder:7b拉完模型后Ollama 默认会在本机启动一个服务地址是http://localhost:11434。Continue 里如果配置了provider: ollama它会自动找到这个服务不需要额外启动。如果你在别的电脑上跑 Ollama也可以在配置里填具体的 URL但要记得把监听地址从 localhost 改成局域网地址。这里有几个参数需要认真调。第一是量化版本常见的有q4_K_M、q8_0等。对代码补全来说q4_K_M效果足够好显存占用低对代码生成和重构场景q8_0会更稳但显存需求会高不少。第二是上下文长度默认值往往只有 4096对代码项目远远不够。可以在运行模型时手动指定OLLAMA_CONTEXT_LENGTH16384 ollama run qwen2.5-coder:7b第三是温度参数。代码生成我习惯把温度调低到 0.2 左右太高容易产出结构奇怪、变量命名不稳定的代码。Ollama 默认温度不低如果你发现本地模型输出“飘”先去查温度设置而不是急着换更大的模型。3.3 提示词与系统提示固化模型再强没有稳定的提示词也会浪费。我参考了社区里的做法把“人设 输出约束 项目背景”三层结构写进系统提示里。基础层提示词大概是这样你是一位资深全栈工程师擅长 Python、TypeScript 和 DevOps。回答时要给出可运行的具体代码不要只讲思路。优先考虑可读性、边界条件和测试覆盖。如果信息不足明确说不确定不要编造 API 或函数。在 Continue 里可以用 slash command 或项目级AGENTS.md把它固化下来。我在仓库根部放了一个AGENTS.md里面写清楚当前项目的目录结构、构建命令、测试命令、代码风格约定以及禁止事项。这样每次打开项目AI 都能从项目文件里读到背景信息而不是靠用户手动粘贴。上下文管理还有一个很重要的细节不要只有“项目背景”还要有“任务背景”。我每次让 AI 改代码前会先告诉它“这个模块是做什么的”“为什么要有这次改动”“你只需要改哪个文件”。这些信息不一定全部进 AGENTS.md因为它们随着任务变化。但把不变的部分和变化的部分分开管理是 AI 编程工作台稳定运行的关键。4. 基础配置里的关键细节从零搭一个可用环境4.1 版本管理先解决 Python 和 Node 的环境隔离很多 AI 生成的代码依赖不同的 Python 或 Node 版本如果基础环境一团糟AI 再聪明也白搭。我推荐用pyenv管理 Python 版本用nvm管理 Node 版本然后用direnv让不同项目自动加载不同的环境变量。具体来说每个项目根目录放一个.envrc文件export PYENV_VERSION3.12.4 export NODE_VERSION20.11.1 export DEEPSEEK_API_KEYsk-xxxx配合 direnv进入项目目录时这些变量会自动加载离开目录自动清空。这样做的好处是AI 生成代码时我可以在提示词里直接说“当前 Python 是 3.12环境变量都在项目内”它就不用再纠结版本兼容问题。对我来说这也是一种给 AI 的“隐藏上下文”。4.2 密钥与环境变量避免把 API Key 写进代码这是我踩过最痛的坑。早期为了让 Continue 能连上云端模型我直接在配置文件里写了明文 API Key结果项目不小心被同步到仓库密钥就泄露了。后来我统一改成环境变量读取凡是要写 API Key 的地方都用${变量名}替代。如果是团队使用我更建议用.env文件配合 direnv 管理同时把.env加入.gitignore。配置模板可以提交到仓库但真实密钥绝不进入 Git。这样做还有一个好处同一套配置在不同的电脑上都能跑只要各自环境变量不同不需要反复改代码。这里多说一句很多云平台自带密钥轮换和用量监控日常开发最好定期检查 API 调用记录发现异常消耗时要立刻生成新 Key并禁用旧 Key。看似基础但这是 AI 编程工作台能长期稳定使用的底线。4.3 最少必要配置清单如果你现在开始搭建我建议按下面这个清单执行优先级从高到低。优先级配置项说明1安装 VS Code Continue核心编辑入口2确认硬件资源看显存和内存决定是否本地模型3配置云端模型 API Key用环境变量管理不要写死4安装 Ollama 并拉取本地模型用于补全和敏感代码处理5建立项目级 AGENTS.md给 AI 提供项目背景和规则6配置终端日志导出方便把报错精准喂给 AI7配置 Git 提交信息生成提高日常提交效率8设置每日检查命令确认模型可用、显存未爆这个清单不是越多越好。每新增一个配置你都要支付维护成本。我见过有人把所有插件全部装齐结果为了调一条补全路径花了一个下午。真正稳定的是那几条核心路径而不是工具的数量。5. 常见问题与排查技巧实录5.1 补全结果“跑偏”先查上下文和温度AI 补全跑偏是最常见的现象。明明上一个函数写得好好的下一个补全突然风格全变甚至出现不存在的库。我排查这类问题时有三个顺序。第一上下文长度是否足够。很多模型默认只看当前文件的一部分如果你的项目有大量跨文件类型定义它很可能看不到关键信息。我通常会把相关的类型定义放在同一个文件里或者在当前文件顶部提前写一段注释说明数据模型。第二温度是不是太高。补全任务讲究确定性温度设为 0.2 能大幅减少“发挥过度”。第三插件是不是同时开了多个补全源。如果 VS Code 里装了不止一个 AI 插件它们会抢占 Tab 键导致补全结果忽高忽低直接停用其中一个通常能解决。如果这三步都排查过还是飘那就考虑换一个更大的模型。补全场景下7B 到 14B 是一个明显的台阶。不要指望小模型解决所有问题它适合处理“短、快、简单”片段。5.2 本地模型占显存或推理太慢量化、分层、减上下文本地模型最容易遇到的问题就是显存不够启动时报CUDA out of memory。遇到这种情况第一步是检查 Ollama 当前加载的模型是否太多用ollama ps查看然后通过ollama stop释放不用的模型。第二步是换成更低的量化版本比如从q8_0降到q4_K_M显存占用能明显下降补全质量损失不一定感知得到。如果显存足够但推理太慢问题往往出在上下文长度设得太大。上下文 16384 和 4096 的推理速度差距很大尤其是大参数模型。我的做法是分层处理补全用 3B 或 7B 小模型短上下文对话和重构才用 14B 以上大模型长上下文。不要指望一台普通开发机同时跑多个大模型那是服务器该做的事。另一个实用技巧是 GPU 显存不足时可以限制 Ollama 的并发请求数在启动时加上OLLAMA_NUM_PARALLEL1避免多个请求抢占显存导致频繁换出。对于长时间跑的本地服务我还会写一个简单监控脚本定时检查显存和推理延迟一旦指标异常就重启模型服务。5.3 多模型切换后上下文不连续统一密钥注入与场景固化多模型切换最烦人的问题是“换了一个模型它好像忘了我们刚才在聊什么”。这不是错觉不同模型服务之间的上下文的确不共享。我解决这个问题的方法是把上下文写在项目文件里而不是依赖聊天窗口的记忆。具体来说我会在修改代码前要求 AI 先输出“计划”把要改哪些文件、每一处改什么原因写出来。然后我把这份计划粘贴到项目文档里即使切到另一个模型也能通过读取文档恢复上下文。这看起来多了一步但能避免二次解释带来的时间浪费。密钥注入不统一也会影响多模型体验。如果每个模型都在不同配置面板里填 API Key一旦 Key 轮换你得挨个去改。统一用环境变量注入之后切换模型只是改一个变量名所有配置都从同一个环境变量池读取不会出现“这个模型能用那个模型突然 401”的情况。5.4 AI 生成的代码在本地一运行就报错必须建立验证闭环AI 生成代码最大的问题是“看起来对跑起来错”。常见原因有用了不存在的 API、依赖版本不匹配、缺少初始化步骤。我现在的习惯是每次 AI 生成完代码不直接粘贴而是让它先提供运行命令和预期输出。然后在终端里执行一遍如果出错把完整 Traceback 再次喂回给模型。这个闭环看起来简单但非常重要。很多人只做“生成”和“复制”省略了“验证”于是错误一轮一轮堆积最后 debug 的时间比手写还长。把验证纳入工作台后AI 才真正从“工具”变成“结对程序员”。我个人会把这套流程固化在 AGENTS.md 里AI 生成代码之后默认要附上最小可运行的测试或运行步骤否则视为未完成。6. 一些实操中沉淀下来的小技巧6.1 让 AI 先复述需求再动手这是我从实际项目里总结出的最有效的小技巧。遇到复杂任务时不要直接说“帮我写登录模块”而是先给 AI 一小段项目背景然后问它“你现在对这次任务的理解是什么”。让它复述需求能提前筛掉大量因为理解偏差导致的返工。比如我想让它改一个支付回调函数我不会只把函数贴给它而是先写清楚原来的回调流程、哪一步出了问题、期望改成什么。然后问它“请先用三句话描述你准备怎么改说明会动到哪些文件。”等它给出计划我再让它写代码。这个过程看似多花了 1 分钟却能避免 AI 把整个流程重写一遍。6.2 给 AI 设置明确的输出边界很多人对 AI 编程的期待是“全自动”但现实中大部分任务都是半自动更可靠。我给 AI 设置的边界是不允许擅自修改与当前任务无关的文件不允许安装新的依赖包除非在计划中明确说明不允许在不确定 API 的情况下硬写。这些边界不是限制 AI而是保护项目结构。AI 很容易为了完成一个需求顺手给你重构了另一个模块或者在项目里引入了新依赖。如果这些变更没有经过 review代码库存债的速度会非常快。我一般会要求 AI 在输出中专门列出“本次改动的文件和风险点”我确认之后再落盘。6.3 每天开工前的固定检查最后再说一个每天开工前的小习惯。我会把 AI 编程工作台的检查项压缩成一条命令检查 Ollama 服务是否正常、Continue 配置里的模型是否能连通、磁盘有没有被模型文件塞满、日志文件是否还在增长。检查一遍大约两三分钟但能避免整天都在跟“环境坏了”作斗争。工具和模型永远在变但这个检查习惯不变。我的感受是AI 编程工作台不是一个“装完就完”的东西它更像一个需要持续维护的开发环境。你今天多花十分钟调稳定一个配置后面每天都能省出至少半小时这笔账怎么算都划算。