最近大半年我把自己的开发环境逐步从“编辑器 浏览器问AI”切换成了一整套真正意义上的 AI 编程工作台。这里说的“工作台”不是某个软件而是一套组合终端、编辑器、本地模型、云端 API、提示词模板和自动化脚本协同工作目的是让 AI 不只是停留在聊天窗口里而是直接参与写代码、改 bug、补测试这条主流程。如果你也每天和代码打交道被网页版对话“上下文断裂”搞得很烦或者手里有好几个模型却不知道怎么统一调度这篇文章值得从头看到尾。这套工作台我目前每天都在用它解决的痛点非常具体同一段需求在网页对话里要手动贴代码、贴报错、再贴输出来回切换而在工作台里AI 能直接读文件、跑命令、看 git diff我只需要把任务说清楚。下面我按方案选型、工具与模型选择、基础配置、完整实操和问题排查五个部分展开内容会比较长但每一步都是可复现的。1. 工作台方案选型为什么要把 AI 嵌进日常开发流1.1 网页对话模式到底问题出在哪先别急着否定网页对话它确实方便打开浏览器就能用。但一旦进入真正的项目开发你会发现几个绕不开的坑。第一是上下文断裂。网页里只能靠手动粘贴代码片段可真实项目里一个功能往往牵扯好几个文件函数定义在 A调用在 B数据流在 C。你贴了 A 和 BAI 理解不了 C 的存在给出的方案表面上合理实际落到代码里就是各种对不上的报错。第二是没法执行验证。网页对话只能“说”不能“做”AI 给出一段代码它自己并不会去跑测试确认对不对。而在编辑器或终端工作台里AI 可以读文件、执行命令、看报错再自我修正这才是“编程助手”而不是“代码生成器”。第三是知识管理成本太高。网页对话记录散落在不同服务里想回头找一个月的某个方案翻聊天记录翻到崩溃。工作台模式下提示词和对话记录都能沉淀成 Markdown 文件和项目代码放在一起需要时全局搜索就行。1.2 工作台式开发的核心优势把 AI 嵌入开发主流程之后最明显的变化是“改代码”变成了“审代码”。我自己常用的路径是让 AI 先给出方案和 diff我确认思路没问题再让它落地修改。这样核心设计决策仍然由人把控AI 负责把重复劳动吃掉。另外工作台天然适合多模型并行。比如我本地跑一个开源模型处理简单重构云端模型处理复杂架构设计通过统一网关切换。提示词模板也能沉淀下来遇到“写测试”“解释这段代码”“分析性能瓶颈”这类高频任务直接调用模板不用每次从零写。说白了工作台不是花架子是把 AI 从“偶尔问一嘴的专家”变成“随叫随到的结对程序员”。2. 工具与模型怎么选从编辑器到终端从本地到云端2.1 编辑器侧Continue 与 Cline 的分工先说编辑器侧我用的主力是 VS Code 系和 JetBrains 系AI 插件选了 Continue 和 Cline 两个。Continue 适合“对话式辅助”优势是上下文管理比较舒服。它能把当前打开的文件、选中的代码、终端输出自动带入对话不需要手动贴。我平时让它解释老代码、生成单测、做重构建议都会先选 Continue。Cline 则更适合“自主执行型”任务。它可以直接修改文件、运行命令、安装依赖算是一个半自动 Agent。用的时候要小心权限边界我一般只在明确的沙箱项目里让它放手干活生产仓库还是走 Continue 加人工确认的模式。选择这两者的核心逻辑很简单复杂任务要给人留确认空间简单重复任务可以交给 Agent 自动跑。插件本身不贵关键是模型调用费用要控制住这就引出了下面的终端侧和模型网关。2.2 终端侧OpenCode 与 Aider 的实战感受终端侧我试过不少工具目前固定下来的是 OpenCode偶尔用 Aider 做对比验证。OpenCode 是开源 CLI 工具支持多家模型服务商也能配本地 Ollama。它的交互方式很对我胃口直接在终端里描述需求它会列出将要修改的文件和命令确认后执行。整个流程特别像在带一个实习生你交代任务它给出执行计划你批不批。Aider 则是更老牌的方案特色是自动把 git diff 结构化喂给模型。Aider 里 AI 每次修改后都会生成清晰的 commit 信息配合 git 历史看非常直观。如果你重度依赖 git 做回滚Aider 的配合度会更高。终端工具和编辑器插件不冲突。我的习惯是简单改动用编辑器插件批量重构或跨文件动作用 CLI遇到多项目并行任务再用 git worktree 拆工作区。这个组合实测下来最稳。2.3 本地模型与云端模型怎么分工模型选型是工作台的核心。我的原则是不迷信单一模型按任务类型分派。本地模型用 Ollama 跑重点推荐 qwen2.5-coder 系列和 deepseek-coder 系列。本地模型的优势是隐私、离线、免费适合处理内部代码、脱敏日志、简单格式化重构。劣势是上下文窗口和推理能力弱于云端大模型复杂架构设计容易答非所问。云端模型则应对重活大范围重构、跨模块需求分析、疑难 bug 排查。这类任务往往需要超大上下文本地模型撑不住。我常接的云端服务有 Claude 系和 OpenAI 系价格不便宜所以必须做好提示词精简和成本控制。另外提一下 OpenCode 默认可以连一些免费模型端点适合预算敏感的同学先用起来把流程跑通再升级模型。2.4 AI 编程提示词的核心写法很多朋友觉得提示词玄学其实编程提示词有非常清晰的套路。我在工作台里用到的模板大概是这样的结构角色 任务背景 目标输出 约束条件 输出格式。举个例子让 AI 给一个函数写测试我不会只说“帮我写测试”而是这样写你是资深 Python 开发者。项目路径是 src/order.py里面有一个 calculate_discount(order) 函数。 请为它补充 pytest 单元测试覆盖满减、折扣叠加、异常入参。 测试文件放在 tests/test_order.py使用 pytest 风格不要引入额外依赖。 输出只给代码和简要说明。注意几个细节路径一定要给全约束一定要明确格式一定要指定。AI 不像人你不说它就可能自由发挥写出一堆花哨但不实用的东西。还有一个反直觉的经验让 AI “说不知道”比逼它“硬想”更重要。提示词里可以加一句“如果不确定某段逻辑请明确说无法推断不要猜测”。这能明显降低幻觉概率。3. 基础配置实操一步步搭出自己的 AI 编程工作台3.1 终端与 Shell 基础环境工作台首先要有顺手的终端。我目前在 macOS 上用 GhosttyLinux 上用 WezTerm两个都是 GPU 加速渲染打开快字体渲染好看。配置方面我坚持用 dotfiles 仓库管理 zsh、tmux、git 的配置换机器十分钟就能恢复环境。Shell 我选 zsh oh-my-zsh 的轻量组合插件只保留语法高亮和自动建议。tmux 则是多任务神器配合终端 AI 工具时尤其重要——左边跑 AI 对话右边跑测试上下分屏看日志效率完全不一样。如果从零开始建议先花半天把终端环境理顺。终端都不顺后面的 AI 工作流全是空中楼阁。3.2 本地模型Ollama 安装与国内镜像配置Ollama 是目前最省事的本地模型运行器一条命令就能跑模型。安装方式很简单curl -fsSL https://ollama.com/install.sh | sh装完之后拉取模型ollama pull qwen2.5-coder:7b ollama pull deepseek-coder:6.7b国内网络下载模型经常很慢我实测两个提速办法。第一个是设置下载并发和超时export OLLAMA_NUM_PARALLEL1 export OLLAMA_MAX_LOADED_MODELS1第二个是换用国内镜像源。Ollama 本身支持通过环境变量指定模型仓库地址我用的配置类似这样export OLLAMA_HOST127.0.0.1:11434 export OLLAMA_ORIGINS*模型文件下载慢时还可以直接把 Hugging Face 的下载端切到镜像站例如export HF_ENDPOINThttps://hf-mirror.com这样拉模型的速度会明显改善。跑起来之后验证一下ollama list curl http://127.0.0.1:11434/api/tags能看到模型列表就是正常状态。3.3 模型网关统一管理 API Key 与模型路由手头模型一多管理就成了问题。OpenAI 一个 keyClaude 一个 key本地 Ollama 又是一个地址每个工具都要单独配。我建议上一套轻量模型网关把后端模型统一成一个 OpenAI 兼容接口。常用的方案有 one-api 和 LiteLLM。我自己用 LiteLLM 比较多因为它配置简单直接写一个 config.yaml 就能路由多个模型。示例配置大致长这样model_list: - model_name: claude-sonnet litellm_params: model: anthropic/claude-sonnet-4 api_key: sk-xxxx - model_name: local-coder litellm_params: model: ollama/qwen2.5-coder:7b api_base: http://127.0.0.1:11434启动网关litellm --config config.yaml --port 4000之后所有 AI 工具只需要配一个 base_urlhttp://127.0.0.1:4000key 随便填一个能过校验的字符串。这样换模型、开新 key、做成本统计都集中在一个入口不用每个 CLI 工具单独维护配置。3.4 把工作台做成 PWAmanifest 与 Service Worker这里要分享一个比较特别的玩法把自己的本地工作台页面做成 PWA支持安装到桌面和离线访问。需求其实很简单就是给“小小工作台”加上 manifest 和 service worker。首先准备一个 manifest.json{ name: AI Coding Workbench, short_name: Workbench, start_url: /, display: standalone, background_color: #1e1e2e, theme_color: #1e1e2e, icons: [ { src: /icon-192.png, sizes: 192x192, type: image/png }, { src: /icon-512.png, sizes: 512x512, type: image/png } ] }然后在 HTML 里引用它link relmanifest href/manifest.json meta nametheme-color content#1e1e2eService worker 的作用是缓存页面资源实现离线可用。最简版本长这样const CACHE_NAME workbench-v1; const ASSETS [/, /index.html, /manifest.json, /icon-192.png, /icon-512.png]; self.addEventListener(install, (event) { event.waitUntil(caches.open(CACHE_NAME).then((cache) cache.addAll(ASSETS))); }); self.addEventListener(fetch, (event) { event.respondWith( caches.match(event.request).then((cached) { return cached || fetch(event.request).then((response) { const clone response.clone(); caches.open(CACHE_NAME).then((cache) cache.put(event.request, clone)); return response; }); }) ); });注册 service workerif (serviceWorker in navigator) { window.addEventListener(load, () { navigator.serviceWorker.register(/sw.js).then(() { console.log(Service Worker registered); }); }); }这样你的页面就能像原生 App 一样从桌面启动断网也能打开。如果你用 Vite 或 Next.js 这类框架甚至可以引入 vite-plugin-pwa 自动化这个过程省去手写注册代码的麻烦。3.5 用 Obsidian 沉淀提示词与对话记录AI 编程工作台不能只有代码还得有“记忆”。我习惯把高频提示词、模型实测对比、踩坑记录全部落到 Obsidian 仓库里用 Markdown 管理。具体做法是建三个文件夹prompts/存模板experiments/存模型测试结果lessons/存踩坑笔记。每次发现一个好用的提示词变体就复制进 prompts 里的对应文件标注适用场景和效果。这样积累两个月你就拥有了一份私人定制的 AI 编程手册。Obsidian 的双链和全局搜索在这里特别有用我经常搜“上下文溢出”“Ollama 速度”这些关键词直接翻到当时的处理记录比回忆快得多。4. 一个实际任务的完整流程演示4.1 从需求到提示词的任务拆解说一个我上周做过的真实例子。需求是给项目的订单模块加一个“批量导出 CSV”功能。传统做法是打开编辑器翻代码定位订单查询逻辑手写导出函数再写测试。我现在的流程是这样先简述需求给 OpenCode让它列出涉及的文件和改动点。它会自动读项目结构给出涉及 order_service.py、views.py、tests 的清单。我确认后它会生成一段实现代码并主动指出需要哪些依赖比如 csv 标准库就够了。这个环节的关键是把模糊需求翻译成 AI 能理解的指令。我的提示词大概是这样项目是 Django 订单系统。order_service.py 有 get_orders_by_date(start, end) 方法。 给订单列表增加 CSV 导出文件名按日期命名字段包含订单号、用户、金额、状态。 导出逻辑放在 services/export_service.py用 csv 标准库实现。 输出代码和测试文件。4.2 结果审查与迭代修正AI 给出的第一版代码大概率能跑但细节常见问题有CSV 中文编码没有用 utf-8-sigExcel 打开会乱码字段顺序和前端预期不一致空数据时没有返回提示。所以拿到结果后我会先 review再让 AI 补一轮修正。提示词类似导出的 CSV 用 utf-8-sig 编码保证 Excel 打开无乱码。 字段顺序调整为订单号、用户、金额、状态、下单时间。 当订单列表为空时返回提示信息不生成空文件。实测这种“初版生成 定向修正”的方式比一次性要求完美更靠谱。因为模型在长指令下容易顾此失彼拆成两轮反而更精准。4.3 用 git worktree 管理并行改动多任务并行时git worktree 是我的得力助手。假设我在 main 分支上已经有一套稳定代码现在要同时开发导出功能和修复另一个 bug可以开两个 worktree互不干扰git worktree add ../project-export -b feature/export git worktree add ../project-bugfix -b fix/cart-bug这样两个任务的依赖、测试、甚至 AI 工具的会话都彼此隔离。AI 在 A 目录里改代码不会影响到 B 目录。配合上面的工作台我常常一边让 AI 做导出功能一边自己修 bug完全并行。用完记得清理git worktree remove ../project-export git branch -d feature/export这个技巧对独立开发者尤其友好相当于不花一分钱给自己的开发流程加了“多开工作区”。5. 常见问题与排查技巧实录5.1 高频问题速查表先给一个我在社区和实践中整理出的速查表覆盖了工作台搭建初期最容易踩的坑。现象可能原因解决办法本地模型响应慢显存不足或模型过大换小参数模型关闭并行加载调低上下文长度返回内容被截断max_tokens 设置过小调大 max_tokens或者让 AI 分步骤输出AI 答非所问上下文缺失或提示词太含糊按“角色背景目标约束格式”重写提示词API 请求超时网络不稳或模型网关排队设置合理的超时重试本地与云端模型做故障转移Ollama 模型下载慢默认源速度不理想配置镜像源或挂代理下载后导入本地多个 AI 工具配置重复缺少统一网关上 LiteLLM 或 one-api统一 base_url并行开发互相影响单分支多任务冲突用 git worktree 拆独立工作区5.2 上下文溢出的处理思路这是大模型编程最头疼的问题。项目代码一多很容易超出模型的上下文窗口。我的经验是主动裁剪而不是硬塞。对于大型项目我会先用tree命令列出目录结构把相关文件路径喂给 AI而不是把整个文件内容贴进去。让 AI 自己按路径去读取关键文件上下文占用会小很多。另外拆对话也是好办法。一次会话只解决一个任务任务完成就新开对话把关键结论和设计决定用文字带过去而不是让模型反复读旧代码。5.3 模型生成质量不稳定的排查方向如果同一个提示词上午跑得好好的下午就明显变差可以从这几个方向排查。先看是不是模型路由变了。如果走的是模型网关很可能配置正在多个模型之间轮询。打开网关日志确认请求打到了哪个模型。再看上下文里是否混入了历史噪音。某些工具会把之前的对话记录自动带上历史一长模型注意力被稀释。必要时清空会话重来。最后看参数设置。temperature 调太高会导致发散编程场景我一般设置在 0.2 到 0.4 之间。如果模型开始胡说优先检查是不是这个参数没控制住。搭建这套 AI 编程工作台我最大的体会是工具和模型永远在变今天用这个明天可能就有更好的但“人负责判断、AI 负责执行”的分工原则是稳定的。工作台的核心价值不是让你变成“只写提示词的人”而是让你把时间花在真正需要思考的地方——需求拆解、方案审核、代码审查。我最后再分享一个小技巧每次用 AI 写出好用的提示词当天就存进 Obsidian不要攒到周末一起整理。这样你积累的知识不是一次性的而是会像滚雪球一样越滚越厚。