AI编程工作台搭建实战：从编辑器到Agent的完整配置指南

这些年我用AI写代码从最初的“偶尔用Copilot补全一下”到现在基本上每天的工作流都跑在一个自己搭的AI编程工作台上。期间折腾过不少工具、换过好几轮模型也踩过不少坑。这篇文章想把我目前这套“AI编程工作台”的整体思路、工具选型、模型配置和一些基础配置细节完整记录下来既有给新手参考的落地步骤也有给已经在用的朋友的一些优化建议。先说清楚这篇文章说的“AI编程工作台”不是某一个软件而是一整套组合你用来写代码的编辑器、终端、版本管理工具、AI编程助手插件或独立应用以及底层接入的大模型、Agent和自定义的Skill再加上让它们协同工作的配置文件。如果你现在的问题不是“AI不够聪明”而是“AI不知道我项目的上下文”、“AI改完代码总是把别的地方弄坏”、“每次都要反复解释需求”那这篇文章大概率能帮上忙。我先聊聊工作台的整体设计思路再把每一层的工具和配置展开讲。1. 工作台搭建前先想清楚四件事很多人一上来就装各种AI编程插件结果装了一堆写代码效率反而更低了。我自己的经验是搭建AI编程工作台之前先想清楚下面四件事比直接动手装工具重要得多。1.1 工作台不是装一堆插件而是一条协作链路我见过不少同行的“AI编程工作台”就是编辑器里装五六个AI插件哪个火了装哪个。结果每个插件都有自己的对话面板各自的上下文互不相通代码建议互相打架最后代码库里混入了不同模型给出的风格完全不一致的代码。我自己现在的工作台核心只有一条链路编辑器作为统一入口把需求、代码、报错信息完整地交给模型模型给出方案我再通过Agent去执行跨文件的修改最后由我来审查改动。插件不在多而在整个链路是否完整。这条链路里有几个关键角色编辑器承载代码阅读、补全、Diff审查。目前我主力用Cursor后面会细说。终端跑命令、看日志、执行脚本。我用Tabby跨平台颜值和功能都够用。模型负责理解需求和生成代码。我会按任务难度分流不把鸡蛋放一个篮子里。Agent与Skill负责把“对话”变成“可执行的任务”比如重构、写测试、查错误。配置.cursorrules或CLAUDE.md把项目的技术栈、代码风格、目录结构告诉模型。这个链路的核心思想是让AI在正确的位置介入每一次介入都有足够上下文并且有办法控制输出质量。1.2 我的选型原则单一入口、统一上下文、可回滚工具选型我有一条很朴素的原则能在一个入口里完成的事绝不用两个工具。原因很简单频繁切换上下文对AI来说成本极高对你来说也一样。举个例子早期的方案是“用VS Code写代码 用ChatGPT网页版复制粘贴”。听着没什么问题但实际用起来非常难受你复制一段代码进网页粘贴回来报错再复制报错信息进去它给你改一版你粘回去又报新的错……来回十几次光复制粘贴就消耗了大量精力。后来我改用编辑器内的AI工具错误信息自动带入上下文改动以Diff形式直接呈现效率不是一个量级。“统一上下文”的意思是AI能看到的代码、报错、文件结构越完整给出的答案越靠谱。这要求工具本身能理解你在项目里的状态而不是孤立地看一条问题。“可回滚”则是底线。AI改代码不像人改代码它可能一次改动多个文件有些改动是隐性的。所以我会把工作台接入版本管理每次Agent执行完大批量改动我先看Diff再提交出问题就回滚。这个习惯救我很多次。1.3 哪些工具适合你按场景对号入座我列一个简单的选型地图方便你对照自己的情况使用场景推荐方案说明前端/Vue/React项目写页面Cursor Claude 或 GPT 系模型对CSS、组件库理解强改样式直观后端/Java/Go/微服务JetBrains全家桶 Copilot/AI Assistant重构、搜索调用链更顺手跨文件重构、自动化测试Cursor Agent用Agent批量改文件效率极高服务器运维、脚本编写终端内AI工具 Claude日志分析、脚本调试上下文在终端里更直接本地隐私敏感项目本地模型 编辑器插件代码不出本机牺牲部分智能度2. 编辑器与终端工作台的物理入口这一层是工作台的地基。编辑器选不好后面模型再强也施展不开。终端也类似AI编程不只是写代码还涉及跑命令、看日志、调试终端是整个工作台和系统交互的窗口。2.1 编辑器到底选哪家VS Code、Cursor还是JetBrains全家桶关于编辑器选择我身边分成两派一派是JetBrains的死忠一派是VS Code系的支持者。我自己是从VS Code过渡到Cursor的现在主力机上的静态语言项目偶尔还用JetBrains但Cursor覆盖了大部分场景。Cursor本质上是一个“加了AI能力的VS Code分支”所以VS Code的大部分插件它能直接用迁移成本很低。它最核心的优势是对上下文的处理可以把当前文件、选中的代码、项目规则文件一起打包给模型还支持codebase这种方式让模型搜索整个代码库找到相关实现再回答问题。拿一个实际例子说我在一个老项目里发现某个API调用总是超时用Cursor直接把报错信息选上按快捷键调出AI让它“找到这个API的定义以及所有调用点”它能在几十秒内把调用链路梳理出来给出超时的可能原因和修复建议。这个过程如果换成网页版ChatGPT我需要手动打开相关文件、复制代码效率差很多。JetBrains家的AI Assistant也有类似能力而且如果你是重度使用重构、调用链追踪的Java开发者JetBrains的原生体验更顺滑。但它的订阅价格不低插件生态也不如VS Code丰富。我的建议是如果你已经重度使用VS Code没必要换如果你还没入坑可以直接从Cursor开始。2.2 终端工具的选择与配置从Windows Terminal到Tabby终端是AI编程工作台里最容易被忽略的一环。你写代码跑不起来第一件事必然是去终端看报错AI要帮你分析问题也经常需要你贴终端输出。所以一个好用、能分屏、能记录会话的终端很重要。Windows用户我首推Windows Terminal微软官方的免费开源支持多标签页和PowerShell、WSL配合都很好。macOS用户自带的Terminal其实够用但我更推荐iTerm2虽然现在很多AI终端也在崛起比如Warp但从稳定性和通用性来说iTerm2更成熟。我自己在多个系统之间切换最后选了Tabby。它是一个跨平台终端Windows、macOS、Linux都能跑配置可以同步内置了SFTP图形化文件管理自带分屏和快捷键管理。最让我喜欢的是它的会话日志功能之前排查一个线上偶发问题时就是用Tabby的日志回放找到了上次手动操作的记录。终端里我还会配一个轻量级的AI命令行工具比如用aichat之类的命令行工具直接在终端里问AI问题。写脚本时尤其方便不用切窗口问完把命令直接复制到终端执行。2.3 版本管理与AI改代码的冲突处理版本管理和AI编程的关系很多人没意识到有多重要。AI批量改动代码时经常会出现“它觉得这里有bug顺手改了”的情况。如果没有版本管理兜底你很难看出它默默改了哪些地方。我的做法很简单但很有效AI每次批量改动前我先在Git里基于当前分支建一个临时分支比如ai-refactor-temp让Agent在临时分支上操作每次改完后我逐个文件看Diff确认没问题再合并回主开发分支。如果用的是Cursor它每次改动会以Diff形式展示逐条审查后可以Accept或Reject。但注意如果一次改动涉及10个文件而Diff窗口只有几百行我相信绝大多数人不会认真看完。所以我会要求Agent一次只改一个模块或者一个文件改动量小审查压力小出错率也低。3. 模型接入与组合策略工具层定了之后重头戏就是模型。市面上的模型很多能力边界各不相同性价比也不一样。我的原则是不迷信某个模型而是根据任务的类型选择最合适的模型。3.1 当前主流模型的能力边界与选型先说几类我实际用过的模型说说它们的能力边界Claude系列特别是 Claude 3.5 Sonnet / Claude 4 系列目前我个人最常用在编程场景的模型。它的优势在于对长上下文的处理、代码规范的理解和自然语言表达的准确性。写复杂函数、理解设计模式、生成完整的模块代码质量都很高。用它改老代码特别是没有注释的代码时它给出的注释和重构建议经常让我惊讶。GPT系列GPT-4o、GPT-4.1 等OpenAI的模型综合能力强尤其是涉及泛化知识问答、技术方案对比、写文档这类任务时很稳。代码生成的风格偏向“标准答案”如果需求描述得清晰它给出的代码结构可读性很强。缺点是价格偏高长上下文对话成本上升很快。本地模型CodeLlama、DeepSeek-Coder、Qwen2.5-Coder 等适合对数据隐私要求极高的项目或者离线环境。但本地模型的智能度和云端模型有明显差距尤其是跨文件理解、复杂重构方面。我一般只在网络隔离环境里用它们日常云上开发还是用云端模型。选模型的建议是日常小改动用便宜的、响应快的模型复杂任务才调用最强的模型。比如前端改一个CSS样式、后端改一个DTO字段完全没必要动用顶级模型用低配模型或者快速模式反而更快、更省。3.2 我的模型接入规则什么任务交给什么模型为了避免模型选择困难我自己总结了一套“任务分流”规则分享一下任务类型推荐模型理由变量重命名、注释补全、单文件内的代码补全模型快速档如GPT-4o mini或本地小模型响应快、成本低、任务简单模块级功能开发、复杂算法实现Claude 3.5 Sonnet / Claude 4对需求理解深、代码质量高跨文件重构、项目搬迁Claude Agent长上下文能力强能理解全貌写单元测试、Mock数据GPT系列生成速度快、模式固定、不容易发散查报错、分析日志任意模型终端上下文关键是给足上下文模型差异不大技术方案设计、架构评审Claude 或 GPT的高端型号推理能力强、能给出多方案对比这里有个小技巧不要在同一个会话里既让它写业务代码又让它做方案设计。模型在长对话里容易“人格漂移”开始回答很专业聊了几十轮之后容易忘掉之前的约束。我会按任务类型拆对话一个会话只干一件事。3.3 本地模型与云端模型的配合使用本地模型比如通过Ollama、LM Studio跑起来的Qwen2.5-Coder的优势是隐私和离线可用但智能度确实有差距。我的做法是“分层使用”敏感项目代码完全不出内网用本地模型跑基础补全、简单问答。日常项目云端模型为主本地模型作为备胎。网络抖动时自动切到本地模型至少不中断工作流。配置上我用的是continue.dev这个开源编辑器插件它支持同时配置多个模型源并设置路由规则。比如我可以设置.go文件用本地模型.ts和.py文件用云端Claude。这样在同一个编辑器里模型根据项目类型自动切换体验是无感的。如果你认真想要搭建工作台强烈建议研究一下 Continue 或者类似的支持多模型路由的方案它能让你在模型选择上保留“冷切换”的能力而不是被绑定在某一家厂商。4. Agent与Skill从“问答式”到“自动驾驶式”AI编程助手最早期是“问答式”你问一句它答一段。后来演化出“补全式”你写一半它续写。现在真正拉开效率差距的是“Agent式”你给一个目标它自己拆解任务、读取文件、修改代码、运行测试直到达成目标。这一步是整个工作台进阶的关键也是很多教程里讲得最含糊的部分。4.1 可编程智能体Agent到底改变了什么Agent和普通对话的本质区别在于它可以操作你的代码库而不只是“建议”代码。它在执行过程中可以自己打开文件、搜索符号、修改代码、运行命令、查看结果然后根据结果决定下一步动作。这就像你从“让AI当顾问”变成了“让AI当实习生”。我用得最多的场景是跨文件重命名以前用IDE的重构功能遇到动态语言就经常失效。现在让Agent自己搜引用、逐个文件改遇到模糊匹配的地方它会停下来问我。批量补充测试一个老模块有几百个函数没有测试。让Agent对着代码逐个生成测试用例它能自己创建测试文件、写数据构造逻辑、跑测试并修正失败的用例。升级依赖版本依赖升级最怕的就是API变化。Agent能自己搜索新版本的API文档、修改旧调用点、跑编译、继续修编译错误循环往复。这个任务如果我手动做可能需要半天Agent半小时就搞完初稿。这其中最关键的还是“拆解任务”的能力。Agent不是一个简单的if-else脚本而是模型在每一步根据当前状态作出判断。所以Agent的上限取决于底层模型的推理能力也取决于你给它设置的边界条件。4.2 如何编写一套属于自己的SkillSkill技能是Agent的“操作手册”。通俗地说你不希望每次让Agent做某类任务时都从头解释一遍规则Skill 把这些规则固化下来让Agent在遇到特定任务时自动加载。以我常用的一个“写测试”Skill为例我在 Cursor 的.cursor/skills目录下定义了一个技能核心内容大致如下# Skill: generate_unit_tests 命令: /test 描述: 为当前模块生成单元测试。 规则: 1. 先读取当前模块的源码理解公开函数和业务逻辑。 2. 测试文件放在 tests/ 目录下命名以 test_ 开头。 3. 必须覆盖主要成功路径和至少两个边界条件。 4. 使用 pytest 风格断言使用 assert。 5. 不修改被测模块的任何业务代码。 6. 生成完成后运行 pytest 并报告结果。之后我只需要在对话中输入/testAgent就会自动按这个流程执行不需要我每次重复“请帮我写测试注意放在tests目录下用pytest风格……”这一段话了。Skill的价值不在于花哨而在于把团队的编码规范固化下来。比如你的项目要求所有SQL必须走预编译、不允许字符串拼接把这些规则写进SkillAgent生成的代码就会自动遵守。这比每次在对话里叮嘱有效一百倍。4.3 实际案例让Agent帮我重构一个老模块这里分享一个实际案例。我们有个老的服务端模块代码有几千行里面全是if-else嵌套逻辑混乱一直没有测试。我花了一个下午搭了一个针对这个模块的Agent任务第一步我先把需求写清楚将模块拆分成若干独立函数每个函数职责单一保留对外接口签名不变新增单元测试覆盖率不低于80%。第二步我把模块的技术栈、目录结构、代码风格要求写在配置里让Agent先通读模块输出它理解的业务流程并列出拆分方案。第三步确认拆分方案没问题后让Agent按方案逐步实施每拆一个函数就停下来让我审查。因为改动范围可控Diff直观我能及时发现模型理解偏差的地方。整个过程花了大概一个半小时人和AI配合如果是纯手工做我估计得两天。现在这个模块的代码可读性提升了很多测试也能稳定跑通后续任何人维护都不会像以前那样如履薄冰。这个案例想说明的是Agent能大幅提升效率但前提是你得清楚地定义任务边界并且保持人工审查。如果你丢给它一个“帮我优化这段代码”这种模糊指令它给你的结果大概率也是模糊的。5. 基础配置的实战写法工具选好、模型接通但如果你不做基础配置工作台的威力只能发挥三成。配置的核心目的是让AI在理解你项目的技术栈和代码规范的前提下工作而不是以“通用程序员”的角色来猜。5.1 项目级配置从.cursorrules到CLAUDE.md现在主流的AI编程工具都支持项目级规则文件。Cursor 用的是.cursorrules旧版或最近的CLAUDE.md新版其他工具也有类似机制比如 Continue 的continue.json、Copilot 的.github/copilot-instructions.md。这类文件的作用就是告诉AI“在这个项目中你需要注意这些事项”。我的一个.cursorrules模板大概长这样# 项目背景说明 这是一个基于 Go 的微服务项目遵循 clean architecture 分层。 # 技术栈 - 语言Go 1.22 - 框架gin - 数据库PostgreSQL sqlc - 消息队列RabbitMQ - 缓存Redis # 代码风格约束 - 所有错误必须显式处理禁止使用 _ 忽略错误。 - 日志使用项目统一的 slog 封装禁止直接使用 fmt.Println 输出日志。 - 对外API接口必须包含请求参数校验。 - 数据库访问层只允许通过 repository 包访问业务层禁止直接拼 SQL。 # 文件结构 - handler 层处理HTTP请求和参数绑定 - service 层业务逻辑 - repository 层数据访问 - 新增功能按此分层每层职责边界要清晰。配置这个文件之后AI生成的代码明显更符合项目规范。之前它经常无视项目已有的分层结构直接把数据库操作写在handler里配置后基本不再犯。你也可以根据项目定制这个文件本身很重要建议至少花半小时认真写。5.2 忽略文件与权限控制AI编程工具在读取项目上下文时如果没有任何忽略机制它可能会把node_modules、dist、.git、敏感配置文件等大量无关内容读进来既浪费上下文窗口又可能引入安全隐患。以 Cursor 为例它支持.aiexclude和.gitignore配合使用。我会在项目根目录的.cursorignore文件里配置node_modules/ dist/ build/ .git/ *.secret .env *.key *.pem vendor/这样AI搜索代码库时就不会把这些目录纳入范围既加快了响应速度也避免了局部敏感信息被送进云端模型。这点在做外包项目、政务项目时尤其重要客户对代码出网有严格红线忽略文件是第一道防线。如果你的项目运行在企业内网还应该配置网络代理层面的大模型访问策略但这已经超出“基础配置”的范畴了这里不展开。5.3 一套可以复制的配置模板最后给一套我个人比较满意的、可以直接复制的配置模板。这套配置适用于一个典型的Web后端项目Go或Java都可以重点是结构配置思路。首选编辑器配置。以 Cursor 为例用户级配置settings.json里我推荐几个高频项{ cursor.chat.defaultModel: claude-3.5-sonnet, cursor.generation.optimizeFor: speed, editor.inlineSuggest.enabled: true, cursor.terminal.useInTerminal: true, cursor.generation.codeStyle: project, files.autoSave: afterDelay, editor.formatOnSave: true, git.enableSmartCommit: true }这几个配置的意义分别是defaultModel设置默认的聊天模型减少手动切换。generation.optimizeFor优先速度还是质量日常写代码我选速度批量重构时再改质量。terminal.useInTerminal允许AI读取终端输出这个非常关键能让AI看到报错信息并给出更精准的回答。codeStyle按项目规则生成代码而不是通用风格。再来一份项目根目录的CLAUDE.md核心模板把项目结构和约定写清楚# 项目指南 ## 项目简介 这是一个用户权限管理微服务提供用户登录、角色管理、权限分配等接口。 ## 技术栈 - 框架gin - ORMsqlc - 鉴权JWT casbin - 数据库PostgreSQL ## 目录结构 - cmd/: 程序入口 - internal/handler/: HTTP层 - internal/service/: 服务层 - internal/repository/: 数据访问层 - internal/model/: 数据模型 - migrations/: 数据库迁移文件 ## 约束 - 新增接口必须写 OpenAPI 注释 - service 层不能直接操作数据库 - 错误统一通过 apierror.New 构造 - 单元测试必须使用 testify 框架配置文件的奥义是用最少的话把项目最关键的信息和约束传达到位。AI不需要你把每一行代码都解释清楚它需要的是“边界”。6. 常见问题与排查技巧实录搭建和使用AI编程工作台的过程中我几乎每天都会遇到这样那样的问题。整理一下高频问题和排查思路希望能帮你少走弯路。6.1 高频问题速查表问题现象可能原因解决思路AI生成的代码风格和项目不一致没有配置项目规则文件写.cursorrules或CLAUDE.md明确代码风格约束AI找不到相关文件或报错“不在上下文中”项目太大上下文窗口被无关文件占满配置.cursorignore排除大目录直接引用指定文件AI改完代码其他文件编译报错批量改动时未充分了解调用关系让Agent先梳理调用关系再动手每次改动范围控制在单文件终端里的报错信息AI看不到未开启AI读取终端能力检查编辑器的terminal选项开启useInTerminal长对话之后AI变得“蠢”了对话上下文污染、约束被遗忘新开对话把关键需求重新说一遍把约束写进配置文件本地模型生成的代码质量太差本地模型能力边界有限把简单任务交给本地模型复杂任务留给云端模型模型推荐了不存在的API或过时用法模型训练数据有截止日期要求模型查阅当前项目依赖版本必要时把依赖文档片段喂给它Agent执行到一半停住或“想不起来”下一步长任务中上下文不够清晰把任务拆成更小的子任务每步给出明确输出验收标准6.2 我的避坑心得排第一位的心得是别让AI直接改生产分支。AI毕竟是概率模型你不能排除它哪次突然抽风给出一个逻辑“看似合理”但实际有严重问题的改动。我见过有同事让AI直接修线上bugAI还信誓旦旦说已经修好了结果是改了个寂寞。所以AI的所有改动都要先过本地分支过审查过测试。第二上下文宁可多给也不要少给。很多人问“为什么AI帮我找bug找不到”我看了下他的提问方式“这段代码报错帮我看看”。可报错信息呢相关函数的完整代码呢依赖的版本呢啥都没有。AI不是神仙你给它一个孤零零的报错片段它只能靠猜。正确做法是把报错堆栈完整贴出来、选中相关代码块、说明你期望的行为、贴上实际的输出。上下文给足了AI的成功率会翻倍。第三小心“过度维护”。AI有时候会主动“优化”你没让它改的代码。比如你让它修一个bug它修完之后顺手重构了相邻的函数、改了变量名、加了一些“更优雅”的写法。这种行为非常危险尤其是把别人维护了很久的逻辑随手换成自己觉得更好的版本。所以我现在的指令里通常会加一句“只修改解决该问题必须改动的代码不要额外重构”作为兜底限制。第四做一次“AI代码审查”。我现在写完一版代码会刻意让AI以“代码审查者”的身份重新看一遍专门找潜在的边界条件漏洞、并发问题、资源泄漏。这个用法其实很香相当于免费请了一个思维严谨的结对程序员。写在最后工作台的价值取决于你的使用姿势工具、模型和配置说到底都只是“加速器”。真正决定效率的还是使用姿势你有没有把需求想清楚有没有给足上下文有没有在关键节点做人工审查有没有把重复的工作沉淀成规则和Skill我个人目前这套工作台的形态大概率半年后又会有很大变化因为AI编程工具链迭代太快了。但底层的方法论——以编辑器为唯一入口、按任务匹配模型、用配置文件沉淀项目上下文、以Agent规模化执行、用Git兜底审查——是相对稳定的。如果你刚开始搭自己的AI编程工作台不用追求一步到位。先把编辑器、模型、基础配置这三件事跑通每天优化一点点用着用着你就知道自己的项目到底需要什么了。等哪天你发现AI不再只是“给你建议”而是真的能帮你把活干了你就算真正入了门。