本地AI编程实战：Ollama+Continue+CodeLlama内网离线开发环境搭建指南

前段时间接了一个内部工具需求，代码必须全程留在公司内网，不允许上传任何第三方服务器。这意味着我平时用得顺手的云端AI编程助手基本全部出局。调研了一圈，最后落地的方案是 VS Code + Continue + Ollama + CodeLlama，四样东西组合起来，补全、聊天、代码解释、单测生成都能在本地完成。这篇文章把我从零搭建到日常使用中踩过的坑、调过的参数、对比过的模型整理一遍，给同样有代码保密需求、或者单纯想低成本体验 AI 编程的朋友一份可以直接抄作业的参考。

先说结论：本地 AI 编程不是替代 GitHub Copilot 的方案，而是补足“代码不出内网”这个空缺的方案。只要你吃透了这一点，后面所有配置都不难。

1. 为什么我放弃了云端助手，转投本地模型

1.1 代码不能离开内网的四类场景

很多人觉得本地跑模型是折腾，但我实际接触下来，有几类需求是云端助手永远满足不了的：

第一类是涉密项目和政务外包。甲方合同里可能明确写了“源代码不得上传至第三方服务器”，这时候不管 Copilot 多好用，合规上就过不去。第二类是金融、医疗等行业客户的内网开发环境，机器物理隔离，外网都连不上，更别提云端 API。第三类是公司自研代码还没公开，不想把核心算法、业务逻辑的上下文发给外部模型，哪怕是大厂的企业版也觉得不放心。第四类是出差或网络不稳定的场景，高铁上、客户现场，断网之后云端助手直接罢工，本地模型反而稳定。

我遇到的这个项目属于第一类和第三类的混合体，代码不给上传，但又想要 AI 辅助，所以本地模型几乎是唯一解。

1.2 本地方案的真实能力边界：什么能做，什么别指望

搭完这套链路之后，我的实际体感是：本地 CodeLlama 能够稳定承担的活儿有三类：

• 代码补全：函数体内补全、重复性样板代码、常见的算法片段，生成速度快，基本可用。
• 代码解释：把一段不熟悉的代码贴进聊天框，让模型用自然语言讲一遍逻辑，准确率相当高。
• 单测与脚手架生成：对已有函数生成单元测试用例，或者生成一个模块的基础结构，能省不少事。

但别抱幻想的地方也很多。7B 和 13B 级别的本地模型，上下文理解能力比 GPT-4 级别的云端模型差了一大截，跨文件的重构建议、复杂业务逻辑的架构设计、需要读懂整个项目意图的“大活”，基本干不了。我测试过一次让 7B 模型做“找出这个项目里所有循环引用的地方”，结果它开始一本正经地编造不存在的文件，这就是本地小模型的幻觉上限。

1.3 硬件门槛：显存、内存与模型规模的换算

本地跑模型，先要搞明白你手里的机器能撑起多大参数量的模型。这里有个非常粗略的经验公式：

• 7B 模型做 4-bit 量化，大约需要 4GB 到 6GB 空间，推理时显存占用 5GB 左右，16GB 内存的笔记本可以硬跑；
• 13B 模型 4-bit 量化，大约需要 8GB 到 10GB，建议至少 8GB 显存；
• 34B 模型 4-bit 量化，需要 20GB 左右显存，基本告别普通消费级显卡。

我用的是 8GB 显存的 RTX 4060 笔记本，跑 13B 的 CodeLlama 非常勉强，7B 的 Q4 量化模型比较流畅。如果手里没有 NVIDIA 显卡，纯 CPU 推理也不是不能跑，但补全速度会掉到每秒几个 token，体验会差很多。

2. Ollama 环境搭建：下载慢、装D盘、手动导入模型都在这

2.1 安装 Ollama 并迁移模型目录

Ollama 是目前本地跑大模型最省事的运行时，一条命令就能拉取模型并启动本地 API 服务。官网下载 Windows 版安装包，双击安装即可，没有太多选项。

装完之后有一个很容易被忽略的问题：模型默认存放在 C 盘用户目录下的 .ollama\models 文件夹里。一个 7B 模型动辄四五个 GB，装两三个模型 C 盘就满了。我安装完第一个模型就发现 C 盘空间告急，果断做了迁移：

1. 先把 C:\Users\<你的用户名>\.ollama\models 整个文件夹复制到 D:\ollama_models。
2. 打开系统环境变量设置，新建用户变量 OLLAMA_MODELS，值填 D:\ollama_models。
3. 重启 Ollama，运行 ollama list 确认模型还在。

这一步强烈建议在下载模型之前就做，省得后面搬几个 GB 的文件浪费时间。

2.2 解决下载慢：从国内模型仓库拿 GGUF 再导入

Ollama 默认从官方仓库拉模型，在国内网络环境下速度经常让人崩溃，几 GB 的模型可能下到一半断掉。搜索结果里也有很多人问“ollama下载太慢了”和“ollama国内镜像源”，我试过一些社区镜像，但说实话稳定性参差不齐，今天能用明天可能就挂了。

我最后用的方案是：从国内模型仓库下载 GGUF 格式文件，再手动导入 Ollama。具体流程：

1. 在 ModelScope（魔搭社区）搜索 CodeLlama-7B-Instruct 的 GGUF 量化版本。
2. 下载 Q4_K_M 或 Q5_K_M 这种常见量化文件，这个格式是性能和体积的平衡点。
3. 在本地新建一个目录，里面放一个 Modelfile 文件，内容就一行：

bash复制FROM ./codellama-7b-instruct.Q4_K_M.gguf

4. 打开终端，进入该目录，执行导入命令：

bash复制ollama create codellama-7b-instruct -f Modelfile

5. 等待几秒钟，ollama list 就能看到模型了。

这个方法的优点是走国内 CDN 速度很快，而且模型文件的来源可控。缺点是需要手动敲两行命令，但总比挂着下载进度条等半小时强。

2.3 CodeLlama 模型怎么选：后缀含义与拉取命令

CodeLlama 是 Meta 开源的代码专用模型，在 Ollama 里对应的名称是 codellama。选版本的时候要看清后缀，不同后缀能力侧重点完全不同：

我日常配置是两个模型并存：补全用 codellama:7b-code，聊天用 codellama:7b-instruct。如果想省事，直接在终端执行：

bash复制ollama pull codellama:7b-instruct

它会自动下载官方构建的版本，省去手动导入的步骤。前提是你的网络能撑得住。

2.4 服务自检：三条命令确认一切正常

配置完 Ollama 之后，别急着打开 VS Code，先在命令行里做三件事，确定底层服务是健康的：

bash复制ollama list

看模型列表是否正常。

bash复制ollama ps

看当前加载了哪些模型、占用了多少显存。

bash复制curl http://localhost:11434/api/tags

这是请求 Ollama 的本地 API，如果返回一长串 JSON，说明服务端口正常。Ollama 默认监听 11434 端口，所有第三方插件都是通过这个端口和本地模型通信的，端口不通后面什么都白搭。

3. Continue 插件接入与配置逐层拆解

3.1 安装 Continue，认识三个核心入口

Continue 是 VS Code 里一款开源 AI 编程插件，Github 上有不少 star，最大的优势是支持接入 Ollama、LM Studio、llama.cpp 等本地模型后端，不像某些插件那样强制绑定云端 API。

在 VS Code 扩展市场搜索 Continue，安装完成后侧边栏会出现 Continue 图标。它有三个核心入口：

• Chat 面板：交互式对话，可以选中代码问问题，也可以让 AI 生成新代码。
• Autocomplete（补全）：写代码时自动提示，按 Tab 接受。
• Inline Edit（行内编辑）：选中一段代码，让 AI 直接修改，diff 预览后手动确认。

这三个入口对应了日常开发最常用的三个场景，比单纯一个聊天框实用得多。

3.2 config.json 里到底要配哪些字段

Continue 安装后会在用户目录下生成一个 config.json，所有模型接入配置都在这一个文件里。第一次打开 Continue 时，它会引导选择模型提供商，选 Ollama 就行。但引导生成的配置往往比较粗糙，我建议手动打开配置文件精调。

我的一份可用配置如下：

json复制{
  "models": [
    {
      "title": "CodeLlama 7B Instruct",
      "provider": "ollama",
      "model": "codellama:7b-instruct",
      "apiBase": "http://localhost:11434",
      "roles": ["chat", "edit"]
    },
    {
      "title": "CodeLlama 7B Code",
      "provider": "ollama",
      "model": "codellama:7b-code",
      "apiBase": "http://localhost:11434"
    }
  ],
  "tabAutocompleteModel": {
    "title": "CodeLlama 7B Code",
    "provider": "ollama",
    "model": "codellama:7b-code",
    "apiBase": "http://localhost:11434"
  }
}

几个字段的作用得说清楚：

• provider 必须是 ollama，其他云服务商的配置不通用。
• apiBase 要写 Ollama 服务地址，http://localhost:11434，注意不要画蛇添足加多余的路径。
• roles 决定这个模型用在哪些功能上，chat 表示聊天，edit 表示行内编辑。
• tabAutocompleteModel 专门用来配置 Tab 补全的模型，我建议和聊天模型分开，避免两个功能挤在同一个模型上，互相抢显存。

3.3 提示词模板：CodeLlama 为什么必须走 [INST] 格式

这一步是很多人配置完之后发现“模型回答完全不对”的头号原因。CodeLlama 的 instruct 系列模型在训练时用的是特定的对话格式，请求必须按照它的格式来写，否则模型就不知道你是在问问题还是在让它续写代码。

CodeLlama instruct 的标准格式长这样：

bash复制[INST] 你的指令 [/INST]

Continue 虽然在底层做了封装，但不同版本对本地模型的模板支持程度不一样。如果你发现模型回答牛头不对马嘴，或者答非所问，可以在 Continue 的模型配置里手动指定模板。Continue 的配置支持 template 字段，类似这样：

json复制{
  "title": "CodeLlama 7B Instruct",
  "provider": "ollama",
  "model": "codellama:7b-instruct",
  "apiBase": "http://localhost:11434",
  "template": {
    "chat": {
      "system": "",
      "user": "[INST] {{user}} [/INST]",
      "assistant": ""
    }
  }
}

写完之后重启 VS Code，再试试聊天，基本就正常了。这里有个判断技巧：如果模型输出的内容把你的问题又复述了一遍，那大概率是模板格式错了。

3.4 用好上下文：@codebase、@文件与 Tab 补全

Continue 不只是个简单的聊天框，它的上下文机制是核心优势。在聊天输入框里输入 @，会弹出一堆上下文来源：

• @文件名：把某个文件的完整内容带进对话。
• @codebase：把整个项目代码库的关键文件信息作为上下文。
• @diff：把当前工作区的文件改动作为上下文。
• @终端：把最近终端的输出带进来。

这对本地小模型特别重要，因为小模型本身上下文窗口有限，你手动缩小范围，它给出的答案质量会明显提升。我实际使用中的经验是：不要直接问“帮我改一下这个项目”这种模糊问题，而是先 @ 具体文件，再精准描述需求。

另外一个容易被忽略的功能是高亮代码后按 Cmd+L（Windows 是 Ctrl+L），这会直接把选中代码塞进聊天上下文，后面再问问题，模型就不会凭空瞎编了。

4. 插件生态横评：Continue 凭什么排第一

4.1 市面上做本地 AI 编程的主流插件

既然标题是“主流插件推荐清单”，那除了 Continue 之外，我还想把市面上其他几款能接本地模型的插件拉出来对比一下。这类插件我实际试用过的包括 Tabby、CodeGPT、Cline，以及国内用户常用的通义灵码、CodeGeeX 等。

先说一个通用结论：能直接对接 Ollama 的插件不多，大部分插件要么只支持云端 API，要么需要额外搭一套服务器。 能“装上就能用”且体验完整的，Continue 确实是目前平衡性最好的。

4.2 六款插件的定位对比

这张表做完，你应该能看清一个事实：真正把“本地模型”作为一等公民对待的，只有 Continue 和 Tabby，Cline 属于勉强能接。Tabby 更适合团队场景，因为它的服务端可以部署在公司内网，团队成员共用一套补全服务；但它的聊天功能基本是摆设，也没有 Continue 那种 @codebase 的上下文整合。Cline 能跑 Agent 流程，但接本地小模型后，每次决策都要等模型推理，一次小改动可能要等几十秒，急性子根本受不了。

4.3 选型结论：按你的场景对号入座

所以我的结论很直接：

• 个人电脑、代码不能上云、想要“装完就能用”：选 Continue，没有之一。
• 团队内网、需要统一管理补全模型、聊天需求不强：选 Tabby。
• 不介意代码上云、只想要最聪明的模型：别折腾本地了，直接用云端 Copilot 或通义灵码更省心。

这里多说一句，很多人在选型时容易陷入“哪个模型强选哪个”的误区，但在本地 AI 编程这条路上，插件链路的稳定性比模型参数大小更重要。Ollama 服务挂了、配置写错了、模板格式不对，任何一个环节出问题，模型再好都白搭。Continue 的配置文件相比其他插件更透明，出问题能快速定位，这在实际使用中比“开箱即用”更重要。

5. 模型对比与实测：7B 不够用，34B 带不动，怎么办

5.1 本地编程模型横向对照

CodeLlama 虽然经典，但 2024 年之后本地编程模型更新很快，我在配置完 Continue 之后陆陆续续换过好几个模型，有些效果确实比 CodeLlama 更惊艳。

我在 8GB 显存的笔记本上实际跑下来，Qwen2.5 Coder 7B 的中文代码解释效果比 CodeLlama 7B 明显更好，DeepSeek Coder 6.7B 的代码补全质量也很能打。如果你的主要痛点是要“读懂代码并解释”，我建议优先试 Qwen2.5 Coder；如果你只是要“快、稳定、不折腾”，CodeLlama 7B 依然够用。

5.2 一次二分查找任务的补全与对话实测

我拿一个简单的 Python 二分查找函数做了测试，把函数签名和文档字符串写出来，让 Continue 用 CodeLlama 7B 补全函数体。模型给出来的代码逻辑是对的，但边界条件处理有些粗糙，比如 left 和 right 指针容易写反。换成 Qwen2.5 Coder 7B 后，同样的任务补全质量就好一些，还自带了一个简单的 while left <= right 判断。

聊天场景下，我把一个稍微复杂的装饰器代码贴给它，问“这段代码在干什么”。CodeLlama 7B 的回答虽然能说到“检测函数执行时间”这个层面，但遇到 functools.wraps 的细节解释就含糊了。34B 模型在这方面的表现明显要好，能讲清楚为什么要保留原函数的 __name__ 和 __doc__ 属性，代价是推理速度慢得让人分神。

5.3 三个关键参数：temperature、maxTokens、stop

如果你和我一样用 Ollama 做后端，可以在调用参数上做点文章。Ollama 默认的生成参数是通用的，但对代码任务来说，默认值不一定是最优的。

• temperature（温度）：代码补全要稳定，设为 0.1 到 0.2 之间即可。设置太高模型会“发挥想象力”，生成一些语法正确但逻辑完全不对的代码。聊天任务可以放宽到 0.6 到 0.8，让回答更自然。
• maxTokens（最大生成长度）：补全任务设 256 到 512 就够，聊天任务可以设 1024。没必要设成超大值，因为本地模型推理速度慢，一次生成太长会让你等得怀疑人生。
• stop（停止符）：这是防止模型“刹不住车”的关键。不设置 stop，模型可能回答完问题之后还在继续输出无关的内容，甚至把下一段代码也脑补出来。对 CodeLlama 而言，建议设置 ["[INST]", "[/INST]"] 作为停止符，模型一旦生成到这些标记就立刻停下。

在 Continue 的配置里，可以通过 completionOptions 字段传参：

json复制"completionOptions": {
  "temperature": 0.1,
  "maxTokens": 512,
  "stop": ["[INST]", "[/INST]"]
}

改完配置记得重启 VS Code，否则不会生效。

6. 高频故障排查链路：连接失败、乱续、幻觉

6.1 Ollama 连接失败的四步排查

Continue 最常见的报错就是连不上 Ollama，表现是聊天框转圈一会儿后报错。遇到这种情况，我建议按以下顺序排查，不要瞎改配置：

1. 确认 Ollama 服务在运行。看系统托盘有没有 Ollama 图标，没有就打开应用。
2. 在终端执行 curl http://localhost:11434/api/tags，如果不通，说明 Ollama 的 API 服务没监听 11434 端口。
3. 打开 Continue 配置文件，检查 apiBase 是否写错。最常见的坑是拼成 http://localhost:11434/ 或者多了 /v1，Ollama 原生 API 路径是 /api/tags，Continue 会自己拼路径，apiBase 只要写到端口号即可。
4. 查看 VS Code 输出面板，切换输出源到 Continue，里面会有详细的请求日志，能直接看到具体 HTTP 错误码。

我遇到过最离谱的一次是 Ollama 装完一直没真正启动，Windows 托盘图标有，但服务进程没起来，重装一遍才好。所以第一条“确认进程真的活着”别跳过。

6.2 补全乱续的根因与停止词配置

还有一个高频问题是补全时模型“发疯”，明明只想补一个函数体，它直接帮你脑补了一个跟当前业务毫无关系的新文件。这种乱续问题，根因通常是下面三个之一：

• 没有配置 stop，模型在完成补全后继续胡编。
• 上下文太长被截断，模型的注意力集中在前面，生成的代码和当前代码风格脱节。
• 选的模型不对，比如用通用聊天模型做自动补全，它天然就会延续对话而不是补代码。

解决办法就是把 codellama:7b-code 这种 code 后缀模型专门配给 tabAutocompleteModel，同时在补全配置里显式声明 temperature: 0.1。实测这样配置之后，补全准确率明显提升，乱续概率大概能下降一半。

6.3 显存不够的应急方案

本地跑模型最现实的问题就是显存不够。Ollama 在显存不足时会自动回退到 CPU 推理，速度会暴跌到每秒一两个 token，体验基本属于不可用状态。

应急方案有三个，按优先级排列：

1. 换更小参数的量化模型。比如 7B 的 Q4_K_M 如果跑不动，可以换 3B 型号，或者用更低比特的 Q3_K_M 量化，体积缩小接近一半。
2. 减少并发模型。同时加载 codellama:7b-instruct 和 codellama:7b-code 会双份吃显存，如果显存紧张，只留一个聊天模型，补全模型可以临时换成更小的 StarCoder2 3B。
3. 设置 OLLAMA_MAX_LOADED_MODELS=1 环境变量，强制 Ollama 同时只保留一个模型在内存里，换模型时自动卸载旧模型释放显存。

6.4 一个从报错到修复的实际案例

最后分享一个我印象很深的排查案例。有一次 Continue 突然报错，错误信息大概是无法从 Ollama 获取模型列表，但 curl 测试明明正常。我打开 Continue 日志，发现请求路径是 http://127.0.0.1:11434/v1/models，和 Ollama 官方 API 路径对不上。

排查之后发现是配置文件里把 provider 写成了 openai 风格的配置，导致 Continue 走了 OpenAI 兼容接口路径，而 Ollama 的 OpenAI 兼容接口需要额外开启。修正方式很简单：把 provider 改回 ollama，并把 apiBase 的路径修正掉，重启 VS Code 后一切恢复正常。

这个案例的教训是：很多配置问题不是配置文件写错了，而是配置的“流向”走错了，插件按照错误配置去请求了一个不存在的接口。 看日志永远比瞎猜高效，这也是为什么我一直强调 Continue 的日志功能很重要。

我目前的固定配置是：聊天用 Qwen2.5 Coder 7B，补全用 DeepSeek Coder 6.7B，底层全部走 Ollama，日常写 Python 和 TypeScript 完全够用。如果你想照抄这套配置，重点记住三条：Ollama 端口是 11434 别改；CodeLlama 必须走 [INST] 模板；补全模型和聊天模型分开配。跑通之后你会发现，本地 AI 编程虽然聪明程度比云端差一截，但那种断网也能干活的踏实感，云端工具给不了。