AI编程这两年迭代太快了工具链、模型、配置方法几乎是周更我自己的开发机和工作流程也跟着调了好几轮。今天不聊虚的就把我目前这套“AI 编程工作台”从头到尾拆一遍从工具选型、模型取舍到底层配置把每一步的思考逻辑和踩过的坑都写出来给正在折腾或者准备入坑的朋友一个直接能抄作业的参考。先说我这个工作台到底解决什么问题。日常开发里大量时间其实花在“找到正确的代码”、“写胶水逻辑”、“查文档试错”、“为重复性样板代码按回车”这些事情上。AI编程工具帮我压缩的就是这部分时间但前提是环境要搭得顺手。那这个问题拆开看无非三大块用哪些工具承载 AI 编程流程、接哪些模型来干不同类型的话、以及最容易被忽略的基础配置怎么梳理。这篇文章就是围绕这三块展开适合已经用过一两款 AI 编程工具但觉得工作机制不顺、以及刚开始想系统搭建 AI 编程环境的新手阅读。1. 工作台整体思路先拆需求再选型我见过不少朋友一上来就装一堆插件、接一堆模型结果整个 IDE 卡成幻灯片上下文互相打架最后得出的结论是“AI 编程都是噱头”。这类问题基本不是 AI 本身不行而是工作台没有结构。1.1 把自己的需求分层拆解我习惯把 AI 编程工作台分成三层来思考。最底层是模型层负责真正理解需求、生成代码像是 ChatGPT、Claude 这类背后的大语言模型或者本地跑的量化小模型中间是工具层负责把模型和编辑器、终端、代码仓库串联起来像 Cursor、Continue 插件、Copilot还有 Aider、Claude Code 这样的命令行工具最上层是配置层包括 API Key 管理、模型路由、提示词模板、代码库索引这些。三层各自独立演进又互相配合。这么拆有两个好处。第一模型迭代太快了今天觉得好用的模型下周可能就被另一个超越只要工具层把模型接口标准化换模型就只是改一行配置的事而不是推倒整个环境重来。第二不同任务对模型的要求差异很大补全用轻量模型就够重构和写测试则需要更强推理的模型分层之后可以按任务路由成本和效果都能兼顾。1.2 工具选型的三个原则这半年我反复试错下来总结出三个选型原则可替换、可组合、可观测。可替换意味着所有关键组件尽量用开放标准去接入避免被某个厂商的闭源生态锁死比如我不用 IDE 内置的 AI 功能而是用支持多模型的插件这样哪天出了更强的模型接入成本很低。可组合强调工具之间数据能打通编辑器和终端里的 AI 助手共用同一套代码上下文而不是各记各的。可观测就更实际了每次 AI 调用花了多少 token、用了哪个模型、耗时多久都要有日志可查不然月底账单来了才发现某次批量操作烧掉一大笔费用。这三个原则直接决定了我后面所有的选型决策。接下来我按工具、模型、配置三大块具体讲讲自己是怎么落地的。2. 工具链拆解编辑器、终端与工作流工具链这块水很深不同岗位、不同开发语言适合的工具组合其实不太一样但底层逻辑是一致的AI 必须出现在你写代码的每个高频操作节点上而不是要你用额外的动作去“召唤”它。2.1 编辑器内嵌 AI主力 IDE 的选择我在主力 IDE 上折腾过 Visual Studio Code、JetBrains 系和 Cursor。最终方案是 VS Code 加 Continue 插件作为主力JetBrains 系留作前端和部分 Java 场景Cursor 用来做快速原型验证。Continue 插件我觉得是个被很多国产教程低估的宝藏。它支持自定义模型接入也支持在代码库内做问答最关键的是它的 prompt 和模型选择完全透明能在同一个对话里同时路由到不同的后端模型。举个例子我在 Continue 的配置里同时配了 OpenAI 兼容接口和本地 Ollama 服务日常补全走本地小模型涉及跨文件重构的问题走云端强推理模型切换只靠一个下拉框。而很多人刚开始时容易犯的错是同时装了一堆 AI 插件Copilot、Continue、通义灵码、CodeGeeX 全开着彼此之间还会抢 Tab 补全和快捷键。我现在只保留一个 Tab 补全来源其余全部禁用这样才不会出现按下 Tab 键都不知道是哪家 AI 在响应的情况。2.2 终端里的 AI从 Aider 到 Claude Code编辑器内的 AI 适合逐行补全和单文件修改但一旦任务变成“跨 20 个文件做一次大规模重构”或者“把这个 Python 脚本迁移成 Go 服务”我建议放到终端里的 AI 编程工具来做。这类工具的代表是 Aider 和 Claude Code它们本质上是让你通过自然语言下达任务然后 AI 直接修改代码库文件、运行测试并迭代修复。相比 IDE 插件终端 AI 工具有个巨大优势它能看到完整的 git diff并且每个改动都有独立的提交记录出了问题直接回滚对版本控制非常友好。说说我自己的工作流。接到一个任务后先在终端里把需求描述给 AI例如“把这个模块的错误处理从返回码改成异常捕获并更新所有调用方”AI 会列出改动清单我确认后才开始批量修改。整个过程并不是放手不管而是像带一个执行能力很强但需要明确边界的新人把大任务拆成小步骤逐步验证。2.3 用 git worktree 隔离 AI 实验AI 生成的代码有一个特点看着能把功能跑通但很可能带了不该有的依赖或者影响现有逻辑。直接在主线分支上让 AI 反复试错很容易把仓库搞脏。我用了一个非常简单但好用的技巧git worktree。具体操作是在项目目录旁边单独建一个 AI 实验工作区签出同一个仓库的独立分支。所有 AI 修改先落在这个 worktree 里我在里面跑测试、做代码审查确认没有问题了才合并回主分支。这个思路本质上是用 git 天然的隔离能力给 AI 生成代码一个“缓冲区”成本几乎为零但是安全边际非常高。工作流大概是这样的# 在项目仓库旁边建一个 AI 实验区基于当前主线创建新分支 git worktree add ../project-ai-agent -b feat/ai-candidate # 在 project-ai-agent 目录里启动终端 AI 工具 cd ../project-ai-agent claude-code # AI 完成改动后审查 diff git diff main...feat/ai-candidate # 确认没问题回到主仓库合并 cd ../project git merge feat/ai-candidate这套玩法在多人协作的团队里尤其好用AI 生成的代码不会污染别人的工作区自己审查起来也很清晰。我强烈建议每个用 AI 编程工具的人把这个流程建立起来。2.4 工具链组合的推荐搭配用表格总结一下我当前的主力工具组合和适用场景方便你对照自己的情况来选场景工具模型来源备注日常代码补全VS Code Continue本地量化小模型低延迟免费保护隐私单文件问答与重构Continue 对话云端强推理模型看上下文跨文件理解跨文件批量修改Claude Code / Aider云端强推理模型必须配合 git worktree快速原型验证Cursor 独立窗口内置模型一次性 demo不保留环境代码审查辅助终端 AI git diff云端强推理模型让 AI 找潜在问题人来决策我特别想强调一点工具不是越多越好每个工具最好只承担一个核心角色。把所有功能往一个工具里塞表面上省了切换成本实际上是牺牲了灵活性和稳定性。3. 模型选型开源与商业模型怎么搭配工具定好了接下来就是最核心的一层——模型。很多人问“哪家模型写代码最强”这个问题其实没有标准答案因为“写代码”本身是个宽泛的任务补全、解释、重构、测试、修 bug 对模型能力的要求各不相同。3.1 模型竞技场用真实任务评估别只看跑分在选模型这件事上我建议大家不要只看基准测试榜单要自己搭一个“模型竞技场”用真实项目片段去测。我的方法很简单从自己的代码库里抽出 10 个典型任务包括一个跨文件重构、一个写单元测试、一个解释遗留代码、一个性能优化、一个正则编写、一个代码审查然后用同一套提示词分别发给候选模型对比输出质量和风格。实测下来商业模型和开源模型的差距在普通任务上已经很小了差距主要体现在长上下文的连贯性和复杂架构设计的把控上。但开源的本地模型有一个无可替代的优势代码不会离开你的机器。对于一些还没上市的项目、金融或医疗相关的代码把源码发给第三方 API 本身就是合规风险这时候本地模型即使效果稍差也仍然是最稳妥的选择。3.2 开源模型与本地部署的取舍本地部署这块我一直在用 Ollama 跑模型。它支持的模型很多像 CodeLlama、Qwen2.5-Coder、DeepSeek-Coder 都有对应的量化版本。笔记本电脑上跑 7B 到 14B 模型基本流畅如果机器有 64G 内存或者一块 24G 显存的显卡可以上到 32B 级别的量化模型。这里需要提醒一个新概念transformer 的参数规模不等于效果但上下文长度是实打实影响使用体验的。模型架构决定了它能记住多长的上下文如果你的任务涉及多文件代码库上下文窗口短了AI 就会“顾头不顾尾”。选本地模型时要特别关注上下文长度至少要能容纳整个目标文件或者一组相关函数。我自己在本地跑的是 Qwen2.5-Coder 32B 的量化版配合 64G 内存复杂任务它也能给出不错的思路。不过实话实说在极其复杂的架构设计上本地 32B 模型和商业旗舰模型还是有肉眼可见的差距所以我的分工是本地模型负责快而廉价的代码补全和简单解释商业模型负责真正烧脑的重构和设计任务。3.3 商业模型怎么选择与切换策略商业模型这边我目前主要用 Claude 系列和 GPT 系列。Claude 在长上下文的保持力和代码生成的“自然度”上更舒服GPT 系列在工具调用和结构化输出上更稳定。至于一些国产商业模型看具体场景部分场景性价比很高尤其中文注释和文档生成但遇到复杂逻辑推演时表现有时不稳定。我的建议是不要对任何一家产生忠诚度始终用“任务路由”的思路去选择最优模型。具体切换我是靠统一的 API 网关层实现的这一步我会在下一节详细讲。这里先给个结论把模型选择从业务代码中剥离出去让工具层始终面对同一个接口你在背后怎么切换模型都是自由的。3.4 从“人写提示词”到“工程化提示词”模型选好之后你还需要一套稳定的提示词模板。很多人以为提示词就是“帮我写个排序算法”但在 AI 编程工具里提示词更像是在给一个经验不错但容易自作聪明的新同事派活需要明确四件事背景信息、目标输出、约束条件、验收标准。我常用的一个通用模板是背景这是一个用 Python FastAPI 写的微服务主要处理用户订单状态流转。 任务帮我新增一个接口支持按订单ID和状态列表进行过滤查询。 约束遵循项目现有的分层结构不要引入新的第三方依赖使用项目已有的日志和异常处理方式。 验收提供接口代码、对应的单元测试并更新 OpenAPI 文档。把提示词当成代码来维护而不是随手打的自然语言效果差距非常明显。我会把高频使用的提示词模板保存为 Markdown 文件放在项目的.ai/prompts/目录下这样团队里所有人都能复用也方便版本管理。4. 基础配置实战把环境打磨顺手的关键细节工具和模型都定了但真正决定工作台好不好用的是那些看起来不起眼的配置。配置做得好AI 工具就像是长在项目里的配置做得糙每次用都像在跟工具搏斗。4.1 用统一网关管理 API 与模型路由我强烈建议不要在每个工具里直接填各自模型的 API Key而是搭建一个轻量的“模型网关”服务。这个网关本质是一个符合 OpenAI 接口规范的反向代理统一管理 API Key、模型路由、重试与降级策略。这样做的好处太明显了。首先安全API Key 只存在服务器环境变量里前端工具永远不会直接接触到密钥其次灵活当任务需要从模型 A 切换到模型 B 时只需要在网关配置里改一行规则所有下游工具自动感知最后省钱可以在网关层做预算限制和调用统计清楚知道每个月每个模型烧了多少钱。一个简化的网关配置示例使用 Node.js Expressimport express from express; import { createProxyMiddleware } from http-proxy-middleware; const app express(); const modelRoutes { fast: http://localhost:11434/v1, // Ollama 本地 powerful: https://api.example.com/v1, // 云端旗舰 cheap: https://api.example2.com/v1 // 云端经济款 }; // 根据请求体里的 model 前缀动态转发 app.use(/v1, (req, res, next) { const model req.body?.model || fast; if (model.startsWith(local-)) { req.url /v1/chat/completions; req.headers[x-api-key] process.env.LOCAL_KEY; return createProxyMiddleware({ target: modelRoutes.fast, changeOrigin: true })(req, res, next); } // 其他模型类似处理 }); app.listen(8080);核心思想是工具永远只配一个 base URL 指向网关具体用哪个模型由网关根据请求内容自动决定。比如你在 Continue 插件里设置模型为local-qwen网关识别前缀local-就转发到本地 Ollama设置为cloud-claude则转发到云端的 Claude 接口。4.2 令牌上下文管理避免 AI 失忆AI 对话的天然限制是上下文窗口不管模型号称多大代码文件、依赖说明、历史对话都会迅速把窗口塞满。一旦超过窗口模型要么直接报错要么“忘记”最早的内容导致前后逻辑不一致。我的经验是在配置里开启自动摘要功能。以 Continue 和 Claude Code 为例工具支持在上下文快满时先把之前的对话压缩成摘要但这需要你在提示词里明确推动它不能让 AI 自己决定。我通常在任务描述最前面加一句“请先记录当前需求的核心目标和已完成步骤在后续对话中始终优先回顾这条摘要。”另外手动控制提交给 AI 的代码范围也很重要。不要一股脑把整个项目目录都塞进上下文多数工具支持.aiignore或.continueignore文件把node_modules、dist、.git、build这些目录排除掉这样既能提高响应速度也能减少模型的干扰信息。4.3 自定义模型接入的完整步骤说到“自定义模型”很多人被这个词吓到了觉得是不是得懂模型训练。其实在大多数 AI 编程工具里自定义模型指的是“接入一个自己配置的在线或本地模型服务”完全不需要训练。以 Continue 插件为例接入本地 Ollama 模型的基本流程是这样的安装并启动 Ollama拉取一个代码模型比如ollama pull qwen2.5-coder:7b。在 VS Code 的 Continue 插件设置中添加一个新 provider类型选择Ollama地址填http://localhost:11434模型名填qwen2.5-coder:7b。在 Continue 的模型下拉框里选中这个模型测试一下补全和对话是否正常。如果要接入一个兼容 OpenAI 规范的第三方 API同样添加 provider类型选择OpenAI把 base URL 换成网关地址填入对应的模型名即可。整个过程最多十分钟但要注意一个很容易踩的坑本地模型的上下文长度和工具默认配置不一致时容易出现截断或报错。解决办法是在模型配置里显式设定上下文长度比如 Ollama 的num_ctx参数或者在 Continue 的模型配置里把max_length调整为模型实际支持的窗口大小。4.4 环境变量与密钥管理最后说一个虽然基础但极其重要的部分密钥管理。很多人图省事直接把 API Key 硬编码在配置文件里甚至一键上传到 GitHub 公共仓库这等于把自家钥匙挂在门口。这类泄漏事故在网络上一搜一大把造成的经济损失和信誉损失都相当大。我个人的规范是这样所有密钥都放在项目根目录的.env文件里.env文件不提交到 git在.gitignore中显式排除。工具运行时通过dotenv库或 shell 环境变量读取。更严格一点CI/CD 流水线的密钥应该使用云服务商提供的密钥管理服务比如 AWS Secrets Manager 等这些内容这里不展开但基本逻辑是代码库里的任何文件都不得出现明文密钥。顺带一个不成熟的建议团队协作时可以在项目里放一个.env.example把变量名和注释写好但不填真实值这样同事拉代码后复制一份.env.example为.env再填入自己的密钥即可兼顾安全与协作效率。4.5 让代理人更懂你的项目代码库索引与规则文件配置的进阶操作是给 AI 工具一份“项目地图”。目前多数主流 AI 编程工具都支持通过配置文件告诉它项目的结构、技术栈和编码规范。比如在项目根目录放一个AGENTS.md或CLAUDE.md内容可以写清楚项目用的是什么语言和框架构建和测试命令是什么代码目录分别存放什么模块新增代码应该放在哪里项目的命名规范、错误处理规范、日志规范哪些目录是自动生成的AI 不应修改。这类规则文件比你在每次对话里反复说明要高效得多。AI 工具会自动读取并把它作为系统提示词的一部分让项目上下文从“每次重新解释”变成“一次配置持续生效”。这也是很多人觉得自己在用 AI 和别人的差距所在别人家的 AI 像项目组老人自己家的 AI 像每句话都要解释一遍的实习生。5. 常见问题与排查技巧实录配置这套工作台的过程中我遇到过不少问题有些是工具文档里不会写的有些是特定组合才会出现的。我把最有代表性的几个整理出来按症状、原因、解决方案三个维度讲。5.1 对话到一半模型突然“失忆”这不是玄学基本是上下文窗口撞顶了。工具只能把最近的对话和文件发给模型最早的指令被丢弃了。排查方法看这次调用的输入 token 数量如果接近模型上限那就是被截断了。解决方案有两个方向一是用摘要功能压缩历史二是把关键约束条件从历史对话中移出来放到系统提示词或规则文件里保证它们永远在上下文中占用稳定的位置。我发现后者比前者更可靠所以现在重要的项目约束都会写在AGENTS.md里。5.2 补全结果不稳定一个风格一个样原本 AI 补全的风格还可以结果某一天突然变了个样子代码缩进、引号、命名习惯全变了。这种情况多半是切换了模型不同模型在风格跟随上的能力差异很大。解决办法是显式指定风格要求。在配置里加入一段风格说明例如“字符串使用单引号变量命名使用 camelCase函数前必须有 docstring”如果模型支持 stylus 或类似机制也可以一并打开。不要指望模型自己从代码库里学除非它明确表明自己有仓库级的学习能力否则请把风格要求写进规则文件。5.3 本地模型运行占满内存机器卡死本地跑大模型对硬件的要求远超大家的直觉。一个 7B 的模型FP16 精度光权重就要 14G 内存加上 KV cache 和运行时开销16G 内存的机器跑起来已经很吃力了32B 的模型没有 64G 内存基本别想流畅。解决思路是合理使用量化模型。量化可以理解为把模型参数从高精度压缩到低精度换取更小的内存占用和更快的推理速度代价是效果的轻微下降。实测 4-bit 量化在代码生成任务上损失很小但内存占用直接少了一半多。另一个思路是按需加载模型不用的时候把模型从内存卸载而不是常驻。Ollama 默认会保持模型加载一段时间可以通过环境变量OLLAMA_KEEP_ALIVE调整驻留时间。5.4 多个任务同时跑API 被限流当你在终端 AI 工具里批量跑任务时云端 API 很容易触发限流。限流的表象是突然报 429 错误。我最初以为是代码问题查了很久才发现是请求太密集。解决方案是给网关加上请求排队和指数退避重试。所谓指数退避就是第一次失败后等 1 秒再试再失败等 2 秒4 秒、8 秒逐步拉大重试间隔而不是疯狂重试把接口打爆。另外充分利用模型的流式输出让它逐块返回内容而不是等整段生成完再一次性接收也能显著降低超时概率。5.5 问题排查速查表症状常见原因快速解决补全速度突然变慢本地模型被换到云端检查当前模型路由配置返回值格式不对模型不支持或没启用 JSON 模式在请求体中显式指定 response_formatgit diff 一片混乱AI 改动了无关文件用规则文件限制可修改目录提交前审查 diff中文注释质量差模型对中文语料覆盖不足换对中文支持更好的模型或强制英文写注释提示词太长被截断超过模型最大输入限制精简提示词把公共内容移到规则文件同一个问题每次回答不同模型温度参数太高在配置里把 temperature 调到 0.2 以下6. 一些提高日常使用效率的进阶经验配置做顺了之后AI 编程工具才真正进入“生产力”阶段。这个阶段拼的不是某个单独技巧而是把 AI 嵌入到工作节奏里的能力。6.1 用 AI 写测试再让测试反过来约束 AI我现在养成一个习惯写业务代码之前先让 AI 根据需求写一轮单元测试然后让 AI 实现功能去让测试变绿。这个过程把“测试驱动开发”和“AI 驱动开发”结合起来了效果出乎意料地好。原因是测试本身就是需求的可执行描述它比自然语言提示词精确很多。AI 写实现代码时测试文件就等于一份带校验逻辑的规格说明书模型生成时就有了明确的验收标准而不是靠猜。这比修完再回头看“哎呀这不对”要便宜得多。6.2 建立个人“AI 提示词片段库”我在实际开发中积累了一堆小而高频的提示词片段比如“评估这段代码的性能瓶颈并给出优化建议”、“为这个函数补充边界条件测试”、“把这个代码改成异步并发实现并说明改动理由”。这些片段不同于规则文件它们是即时发挥作用的具体指令。我会把它们保存为一个轻量的 Markdown 和脚本片段文件需要用的时候直接复制或者绑定成编辑器里的快捷命令。这个库越攒越多实际就是一份属于自己工作习惯的小型知识库任何 AI 工具换进来都能靠这套片段快速对齐到自己的预期。6.3 通过日志和会话记录做复盘最后我想说AI 编程工作台也需要“复盘”。很多工具会自动保存历史会话记录我会定期翻一翻不是看 AI 写得对不对而是观察自己提问的方式有没有问题。比如某个任务反复让 AI 修改了很多次才通过那通常是因为最初的上下文没给够下一次我会把背景描述得更充分而不是抱怨模型不够聪明。查看每次会话的 token 消耗和耗时也能帮自己总结出哪些任务适合交给本地模型省成本哪些任务完全可以交给云端模型减少沟通时间时间长了整个工作流会越来越顺手。这些经验是我这两年实践下来最有价值的部分。工具和模型会不断更替但分层架构的思路、任务路由的取舍、把配置当成代码来管理的习惯这些底层方法不会过时。希望这篇文章能让你少走一些弯路尽快搭建出一套真正属于你自己的 AI 编程工作台。