从网页对话到AI编程工作台：本地模型、模型网关与提示词实战

最近大半年，我把自己的开发环境逐步从“编辑器 + 浏览器问AI”切换成了一整套真正意义上的 AI 编程工作台。这里说的“工作台”不是某个软件，而是一套组合：终端、编辑器、本地模型、云端 API、提示词模板和自动化脚本协同工作，目的是让 AI 不只是停留在聊天窗口里，而是直接参与写代码、改 bug、补测试这条主流程。如果你也每天和代码打交道，被网页版对话“上下文断裂”搞得很烦，或者手里有好几个模型却不知道怎么统一调度，这篇文章值得从头看到尾。

这套工作台我目前每天都在用，它解决的痛点非常具体：同一段需求，在网页对话里要手动贴代码、贴报错、再贴输出，来回切换；而在工作台里，AI 能直接读文件、跑命令、看 git diff，我只需要把任务说清楚。下面我按方案选型、工具与模型选择、基础配置、完整实操和问题排查五个部分展开，内容会比较长，但每一步都是可复现的。

1. 工作台方案选型：为什么要把 AI 嵌进日常开发流

1.1 网页对话模式到底问题出在哪

先别急着否定网页对话，它确实方便，打开浏览器就能用。但一旦进入真正的项目开发，你会发现几个绕不开的坑。

第一是上下文断裂。网页里只能靠手动粘贴代码片段，可真实项目里一个功能往往牵扯好几个文件，函数定义在 A，调用在 B，数据流在 C。你贴了 A 和 B，AI 理解不了 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 上用 Ghostty，Linux 上用 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_PARALLEL=1 export OLLAMA_MAX_LOADED_MODELS=1

第二个是换用国内镜像源。Ollama 本身支持通过环境变量指定模型仓库地址，我用的配置类似这样：

export OLLAMA_HOST=127.0.0.1:11434 export OLLAMA_ORIGINS=*

模型文件下载慢时，还可以直接把 Hugging Face 的下载端切到镜像站，例如：

export HF_ENDPOINT=https://hf-mirror.com

这样拉模型的速度会明显改善。跑起来之后验证一下：

ollama list curl http://127.0.0.1:11434/api/tags

能看到模型列表就是正常状态。

3.3 模型网关：统一管理 API Key 与模型路由

手头模型一多，管理就成了问题。OpenAI 一个 key，Claude 一个 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_url：http://127.0.0.1:4000，key 随便填一个能过校验的字符串。这样换模型、开新 key、做成本统计都集中在一个入口，不用每个 CLI 工具单独维护配置。

3.4 把工作台做成 PWA：manifest 与 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 rel="manifest" href="/manifest.json"> <meta name="theme-color" content="#1e1e2e">

Service 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 worker：

if ('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-sig，Excel 打开会乱码；字段顺序和前端预期不一致；空数据时没有返回提示。

所以拿到结果后我会先 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 高频问题速查表

先给一个我在社区和实践中整理出的速查表，覆盖了工作台搭建初期最容易踩的坑。

5.2 上下文溢出的处理思路

这是大模型编程最头疼的问题。项目代码一多，很容易超出模型的上下文窗口。

我的经验是主动裁剪而不是硬塞。对于大型项目，我会先用tree命令列出目录结构，把相关文件路径喂给 AI，而不是把整个文件内容贴进去。让 AI 自己按路径去读取关键文件，上下文占用会小很多。

另外，拆对话也是好办法。一次会话只解决一个任务，任务完成就新开对话，把关键结论和设计决定用文字带过去，而不是让模型反复读旧代码。

5.3 模型生成质量不稳定的排查方向

如果同一个提示词，上午跑得好好的，下午就明显变差，可以从这几个方向排查。

先看是不是模型路由变了。如果走的是模型网关，很可能配置正在多个模型之间轮询。打开网关日志，确认请求打到了哪个模型。

再看上下文里是否混入了历史噪音。某些工具会把之前的对话记录自动带上，历史一长，模型注意力被稀释。必要时清空会话重来。

最后看参数设置。temperature 调太高会导致发散，编程场景我一般设置在 0.2 到 0.4 之间。如果模型开始胡说，优先检查是不是这个参数没控制住。

搭建这套 AI 编程工作台，我最大的体会是：工具和模型永远在变，今天用这个，明天可能就有更好的，但“人负责判断、AI 负责执行”的分工原则是稳定的。工作台的核心价值不是让你变成“只写提示词的人”，而是让你把时间花在真正需要思考的地方——需求拆解、方案审核、代码审查。我最后再分享一个小技巧：每次用 AI 写出好用的提示词，当天就存进 Obsidian，不要攒到周末一起整理。这样你积累的知识不是一次性的，而是会像滚雪球一样，越滚越厚。