现在本地AI编码已经成为开发者提效的刚需，不用联网、无API费用、代码数据不泄露，相比云端AI有着绝对的隐私和成本优势。最近我基于现成服务器+Ollama，搭配VSCode搭建了一套专属本地AI编码环境，全程无复杂部署门槛，但中途踩了一个很多人都会遇到的大坑：全能大模型编码频繁卡死、无响应。
今天把完整部署流程、踩坑原因、最终优化方案一次性复盘，手把手教大家搞定稳定、流畅的本地AI编码助手。
一、前置环境：零基础复用现有服务
本次搭建无需从零部署Ollama服务，我使用的是已配置完成的现成服务器，Ollama环境完好可用，省去了安装、配置环境、适配显卡驱动的繁琐步骤，直接拉取模型即可使用，极大提升了搭建效率。
核心前置条件：
服务器Ollama服务正常启动、端口通畅，可正常执行模型拉取、推理命令
本地VSCode编辑器正常使用，网络可连通服务器Ollama服务
服务器硬件可支撑30B+参数大模型本地推理
我这里是之前部署Dify购置的服务器，256G内存条+英伟达A100 80G显卡。
二、初始部署：拉取Qwen3.6:35B全能模型配置编码助手
最开始我选择了通义千问最新的Qwen3.6:35B模型，作为全能型大模型，它在文本对话、逻辑推理、文案创作、通用问答等场景表现十分全面，我默认它可以兼顾编码场景，于是开启了第一版配置。
1. 服务器拉取Qwen3.6:35B模型
直接在服务器终端执行Ollama拉取命令，一键下载部署模型：
ollama pull qwen3.6:35b等待模型下载、量化完成后，通过 ollama list 可查看模型已成功入驻本地服务，此时服务器端模型部署完成。
2. VSCode配置Continue插件对接模型
本地VSCode端无需复杂操作，核心依靠Continue插件实现AI编码联动，步骤极简：
第一步：VSCode扩展商店搜索安装 Continue 插件（本地AI编码主流插件，完美适配Ollama）；
第二步：打开插件配置文件 config.yaml，修改对接参数，关联服务器Ollama服务和Qwen3.6:35B模型；
name: Qwen3.6 Agent
version: 1.0.0
schema: v1
models:
- name: Qwen3-Coder
provider: ollama
model: qwen3.6:latest
apiBase: http://192.168.11.119:11434
roles:
- chat
- edit
- apply
第三步：保存配置，重启插件，选择Qwen3.6:35B为默认编码模型，正式开启AI编码体验。
三、核心踩坑：全能模型编码频繁卡死、无响应
本以为部署完成就能顺畅使用，结果实际编码过程中，频繁出现莫名卡死、输入指令无响应、代码生成中断、长时间加载无结果的问题，严重影响开发效率。
排查了网络、服务器端口、插件配置、硬件负载等所有常规问题后，终于找到核心根源：
Qwen3.6:35B是通用全能型大模型，并非专业编码模型。
这类全能模型的训练数据覆盖全场景，编码只是其中一个细分能力。在连续编码、代码补全、bug修复、逻辑迭代的场景下，模型会频繁出现「场景漂移」——写代码的过程中无意识切换为通用对话模式，推理逻辑混乱、上下文偏移。
同时，35B大参数全能模型对编码场景的推理优化不足，单次代码生成的token推理成本更高、冗余计算更多，极易造成Ollama推理线程阻塞，最终表现为：界面卡死、指令无响应、生成中断，这也是绝大多数人本地AI编码踩坑的核心原因。
四、终极优化：替换专业编码模型，彻底解决卡顿
找准问题根源后，解决方案非常清晰：放弃全能通用模型，更换专门针对代码场景优化的Qwen3-Coder专业编码模型。我选择轻量化高性能的 qwen3-coder:30b 模型，兼顾推理速度、编码精度和硬件适配性。
1. 服务器拉取专业编码模型
服务器终端执行拉取命令，下载Qwen3-Coder 30B编码专用模型：
ollama pull qwen3-coder:30b模型下载完成后，通过 ollama list 确认模型部署成功，无需额外启动，Ollama自动托管模型服务。
2. 修改Continue插件config.yaml配置
打开VSCode Continue插件的 config.yaml，将原有Qwen3.6:35B模型配置，全部替换为qwen3-coder:30b，同步核对Ollama服务器地址、端口参数无误，保存配置文件。
name: Qwen3-Coder Agent
version: 1.0.0
schema: v1
models:
- name: Qwen3-Coder
provider: ollama
model: qwen3-coder:30b
apiBase: http://192.168.11.119:11434
roles:
- chat
- edit
- apply
capabilities:
- tool_use
toolCallFormat: json
timeout: 180000
配置修改核心要点：彻底替换模型名称，清空原有全能模型的上下文适配参数，适配编码模型的推理规则。
3. 重启生效，体验质变
配置保存后重启Continue插件，默认选择 qwen3-coder:30b 作为AI编码模型。优化后效果立竿见影：
彻底解决莫名卡死、无响应、加载中断问题；
代码补全、函数生成、bug修复、代码注释生成响应极速；
不会再出现「写代码跑偏成对话」的场景漂移问题；
推理资源占用更合理，服务器负载稳定，连续编码无卡顿。
五、实操总结：本地AI编码避坑核心逻辑
这次部署踩坑给了我很直观的感悟：大模型选型，场景适配远大于参数大小。
很多开发者会陷入「参数越大、模型越强」的误区，盲目选用35B、72B全能大模型做编码开发。但通用全能模型擅长对话、推理、通识问答，在垂直编码场景的优化度、专注度、推理效率，远不如专属编码模型。
简单总结本次部署核心要点：
已有Ollama服务器环境，无需重复部署，直接拉取模型即可快速搭建；
AI编码优先选择专属代码模型，拒绝全能通用模型，避免场景漂移、推理卡死；
Qwen3-Coder:30b是性价比极高的本地编码模型，兼顾精度、速度和硬件门槛；
VSCode+Continue+Ollama的组合，是目前最稳定、最轻量的本地私有化AI编码方案。
六、写在最后
本地私有化AI编码，核心优势就是安全、免费、无依赖云端，适合日常开发、内网开发、敏感项目开发。本次从「卡顿翻车」到「流畅丝滑」的优化全过程，也帮我摸清了本地AI编码的核心避坑点。
如果大家也在用Ollama搭建VSCode AI编码助手，遇到莫名卡死、无响应、代码生成跑偏的问题，不用纠结配置和网络，直接替换专属编码模型，大概率可以一键解决问题！