👁 53 次阅读
配图
为什么值得把代码补全放在本地
本地运行代码补全，最直接的变化是代码片段不必离开开发机。对于公司内网、客户项目、尚未公开的算法和带有密钥的脚本，这一点比补全速度更重要。Ollama 把模型封装成本地 HTTP 服务，VS Code 插件通过本机地址调用它，形成一条可审计、可离线的链路。它的代价也很明确：模型能力受硬件限制，首次配置比安装云端插件麻烦，遇到复杂代码时补全质量不一定追平云端服务。因此更合理的定位是：把本地补全当作日常写样板代码、补全函数签名、生成测试骨架和减少重复输入的助手，而不是完全替代人工 review 与测试。
配图
方案总览与适用场景
整套方案由四部分组成：Ollama 负责运行模型，代码模型负责生成补全，VS Code 负责编辑体验，Continue 插件负责把编辑器请求转发给 Ollama。配置完成后，你在编辑器里正常写代码，插件在光标附近给出灰色建议，按 Tab 接受或按 Esc 忽略。下表把本地补全与常见云端补全做定性对比，便于判断是否适合自己。
| 对比项 | 本地 Ollama 补全 | 云端补全服务 |
|---|---|---|
| 代码去向 | 默认留在本机与本地网络 | 需上传到服务商 |
| 离线能力 | 模型下载后可离线使用 | 通常依赖网络 |
| 首次部署 | 需要安装运行时、下载模型、改配置 | 登录后即可使用 |
| 延迟来源 | 本机算力、显存、模型大小 | 网络与服务端负载 |
| 复杂代码能力 | 取决于本地模型，普遍弱于大型云端模型 | 通常更强 |
| 费用结构 | 硬件与电力成本为主 | 按订阅或用量计费 |
| 可维护性 | 配置与升级由自己负责 | 由服务商维护 |
如果更看重隐私、离线可用和成本可控，本地方案值得投入；如果更看重开箱即用和复杂重构能力，云端服务仍有优势。实际工作中也可以混合使用：敏感项目用本地模型，公开项目用云端服务。
准备硬件与软件环境
硬件方面，先确认内存和显存是否足够。代码补全模型会在首次加载时占用较多内存，之后常驻内存以降低延迟。普通轻薄本可以尝试小参数代码模型，但响应速度和补全长度要保守设置；有独立显卡或大内存的机器更适合中等参数模型；较大参数模型通常需要更充足的显存，否则会回退到 CPU，速度明显下降。软件方面，需要较新的 VS Code、可用的终端，以及能访问本地回环地址的网络环境。先检查工具是否已安装：
ollama --version
code --version如果命令不存在，先完成 Ollama 安装并重新打开终端；VS Code 的 code 命令可在命令面板中安装，也可以直接使用图形界面。
安装 Ollama 并确认本地服务
在 macOS 或 Linux 上，可以用官方脚本安装；Windows 用户下载安装包后按向导完成即可。安装脚本示例：
curl -fsSL https://ollama.com/install.sh | sh安装完成后，Ollama 通常会自动启动本地服务。若没有启动，可手动运行：
ollama serve另开一个终端，检查服务是否可访问：
curl http://127.0.0.1:11434/api/tags如果返回模型列表的 JSON，说明服务正常。默认端口通常为 11434，若被其他程序占用，需要调整 Ollama 的监听地址并同步修改插件配置。不要把本地服务随意暴露到局域网，除非你清楚访问控制与防火墙设置。
拉取适合代码补全的模型
代码补全和代码聊天对模型的要求不完全一样。补全更看重低延迟和短上下文，聊天与编辑更看重理解能力。建议先选一个代码专用模型跑通流程，再根据硬件和体验替换。下面以模型库中常见的代码模型标签为例，实际名称以 ollama list 和模型库显示为准：
ollama pull qwen2.5-coder:7b
ollama list如果机器资源有限，优先选择更小的参数版本或量化版本；如果显存充足，可以尝试更大的代码模型，但要注意首次加载时间和常驻占用。模型档位与使用策略可参考下表。
| 模型档位 | 适合任务 | 资源感受 | 补全策略 |
|---|---|---|---|
| 小参数代码模型 | 单行补全、注释转代码、样板代码 | 响应较快，普通笔记本更容易承受 | 短上下文、短输出 |
| 中等参数代码模型 | 函数级补全、简单重构建议 | 需要较充足内存，独立显卡更稳 | 控制上下文，避免整文件输入 |
| 较大参数代码模型 | 跨文件理解、复杂逻辑草稿 | 对显存和加载时间要求更高 | 更适合聊天与编辑，不只做自动补全 |
先做一次命令行验证
在接入编辑器之前，先用命令行确认模型能正常生成代码。运行：
ollama run qwen2.5-coder:7b进入交互后，输入一个具体任务，例如：用 Python 写一个读取 JSON 文件并返回字典的函数。观察模型是否能给出可读代码。第一次运行会加载模型，等待时间可能较长；后续请求会快一些。输入 /bye 退出交互。还可以用下面的命令查看当前已加载的模型：
ollama ps如果命令行都不可用，先不要急着改 VS Code 配置，优先解决 Ollama 服务、模型名称和资源占用问题。
在 VS Code 安装 Continue 插件
打开 VS Code 扩展市场，搜索 Continue 并安装。也可以在终端尝试：
code --install-extension Continue.continue安装后侧边栏会出现 Continue 入口。首次打开时，插件会引导你选择模型提供方；这里不要选云端服务，而是选择本地 Ollama，或直接编辑配置文件。不同版本的 Continue 可能使用 config.yaml 或 config.json，较新版本常见的是 config.yaml。下面用 YAML 示意，若你的版本仍是 JSON，把相同字段填入对应结构即可。
配置 Ollama 作为补全提供方
在 Continue 的设置中打开配置文件，写入本地模型与自动补全模型。示例配置如下：
name: local-ollama
version: 0.0.1
schema: v1
models:
- name: Qwen Coder Chat
provider: ollama
model: qwen2.5-coder:7b
apiBase: http://127.0.0.1:11434
roles:
- chat
- edit
- apply
tabAutocompleteModel:
name: Qwen Coder Autocomplete
provider: ollama
model: qwen2.5-coder:7b
apiBase: http://127.0.0.1:11434
tabAutocompleteOptions:
debounceDelay: 400
maxPromptTokens: 1024
maxCompletionTokens: 128这里的关键字段是 provider、model 和 apiBase。model 必须与 ollama list 显示的名称一致，包括冒号后的标签；apiBase 指向本地 Ollama 服务；tabAutocompleteModel 单独指定自动补全使用的模型。如果插件没有出现补全，先检查这三个字段，再重启 VS Code 窗口。
让自动补全真正好用的参数与习惯
补全体验不只由模型决定，参数和写作习惯同样重要。debounceDelay 控制停止输入后多久请求补全，数值太小会增加请求频率，数值太大则显得迟钝；maxPromptTokens 控制送给模型的上下文预算，本地模型上下文有限，不要把整个大文件都塞进去；maxCompletionTokens 控制一次补全的最大长度，自动补全场景下不宜过长，否则容易生成大段无关代码。建议从较短输出开始，稳定后再逐步增加。
写作习惯方面，可以这样做：
- 先把函数名、参数和返回类型写清楚，再让模型补全函数体。
- 用一句简短注释描述意图，例如输入校验、重试逻辑、解析配置，比空光标更容易得到可用建议。
- 把相关小文件保持打开，减少无关文件干扰；不要依赖模型一次性理解整个仓库。
- 接受补全前快速扫一眼边界条件、异常处理和命名风格，避免把看似合理的错误代码合入。
- 关键逻辑仍然要写测试，尤其是涉及金额、权限、并发和文件写入的代码。
用项目规则和上下文提升补全质量
本地模型的上下文窗口通常不如云端大模型宽裕，因此要主动做上下文管理。项目根目录的 README、代码规范、接口说明和测试用例，都是比随机打开文件更有价值的上下文。补全时尽量让光标处附近包含类型定义、调用示例和错误处理模式，模型更容易延续现有风格。对于跨文件任务，可以先用聊天能力生成方案，再回到编辑器里分段实现，而不是期待自动补全一次完成大型重构。若团队有统一命名、日志格式和异常类型，建议写成简短的项目说明，并在提问或注释中引用。
排查常见问题
第一类问题是插件连不上本地服务。先在终端执行 curl http://127.0.0.1:11434/api/tags，确认 Ollama 是否在运行；如果失败，运行 ollama serve 查看日志。第二类问题是模型名称不匹配。执行 ollama list，把输出中的完整名称复制到配置里，注意标签和大小写。第三类问题是补全很慢。优先换更小的模型或量化版本，降低 maxPromptTokens 与 maxCompletionTokens，关闭占用显存的其他程序，并适当增大 debounceDelay。第四类问题是完全没有灰色建议。检查 tabAutocompleteModel 是否配置、插件是否启用、当前文件语言是否受支持，必要时重启 VS Code。第五类问题是显存不足导致回退到 CPU，表现为首次响应特别慢，这时应换小模型，而不是反复重试。
安全、隐私与维护
本地补全减少了代码离开设备的机会，但不等于零风险。Ollama 默认监听本机回环地址，不要随意改成公网可访问；如果多人共用一台开发机，要区分系统账户和模型缓存目录。VS Code 插件可能带有遥测或使用统计选项，建议在设置中检查并关闭不需要的数据上报。模型文件占用磁盘较大，定期用 ollama list 查看并删除不再使用的模型；升级 Ollama 或 Continue 后，如果补全异常，先回看配置字段是否变化。团队内部可以固定模型标签和配置文件，避免每个人使用不同版本导致体验不一致。
结尾建议
建议先不要追求一次到位：用一个小参数代码模型和上面的最小配置跑通自动补全，确认本地服务、插件和配置文件三者连通；然后只在一个真实项目里试用几天，记录补全延迟、接受率和误报情况，再决定是否换更大模型或调整上下文长度。把自动补全限制在单行或短片段，关键代码必须人工审查并补测试，这样本地 Ollama 才能成为稳定、可控的生产力工具，而不是新的干扰源。