企业官网建设流程全解析

1. 本地代码补全基准：为什么要在 VS Code + Remote-SSH 里跑 Ollama

代码补全这件事，最怕的不是模型不够强，而是你没法判断它到底强不强。同一个函数，今天补得顺，明天换个项目就拉胯，你很难说清是模型问题、prompt 问题，还是网络抖动。所以我一直想搭一套可复现的补全基准：固定模型、固定 prompt、固定用例，把首 token 延迟和补全通过率记下来，横向对比不同模型和不同 endpoint。

这套方案的核心是三个东西：Ollama 负责在本地或远程开发机上跑 deepseek-coder，Continue 作为 VS Code 插件负责把补全请求发出去，Remote-SSH 让你在远程开发机上跑同一组用例。这样做的价值在于，你的评测环境是隔离的，不会因为本地机器性能差异导致结果不可比。Ollama 的模型拉取和推理都在远程机器上，VS Code 只负责发请求和展示结果，首 token 延迟测的是真实链路。

适合谁？如果你正在选代码补全模型，或者想验证某个 endpoint 的补全质量，这套流程可以直接跟做。deepseek-coder 系列在代码补全上表现稳定，6.7b 适合快速验证，33b 适合追求质量，v2 则在两者之间找平衡。Continue 的配置文件可以随时切换模型，不用改代码。Remote-SSH 则保证你在远程开发机上跑用例时，环境变量、模型路径、端口都一致。

我试过在本地笔记本上直接跑 Ollama，结果 33b 模型加载就吃掉大半内存，补全延迟高得没法用。后来把模型放到远程开发机，本地只跑 VS Code 和 Continue，延迟立刻降下来。所以这套基准的关键不是模型本身，而是把推理和编辑分离，让评测可复现。

2. TaoToken 前置：把 endpoint 抽象成可切换的配置项

在搭基准之前，先想清楚一件事：你的补全请求最终发到哪里。Ollama 本地推理是一个 endpoint，TaoToken 的 API 是另一个 endpoint。Continue 的配置里，provider 和 model 决定了请求走向。如果你只测本地 Ollama，那配置很简单；但如果你想做对照验证，就需要把 endpoint 抽象出来，方便切换。

TaoToken 在这里的角色是提供一个可对照的 API endpoint。它的 API 地址是 https://taotoken.net/api，你可以在 Continue 的配置里把它写成 openai 兼容的 provider。这样同一组用例，你可以先跑 Ollama 本地，再跑 TaoToken，对比首 token 延迟和补全通过率。注意，TaoToken 不是替代 Ollama，而是作为另一个可选的推理后端，让你在评测时有参照系。

前置准备包括：一个远程开发机（或者本地机器也行，但远程更接近真实开发环境），Ollama 已安装，Continue 插件已装好，以及一个 TaoToken 的 API Key。API Key 可以在 https://taotoken.net/api-keys 获取，拿到后先存好，后面配置里要用。如果你还没决定用哪个模型，可以先从 deepseek-coder:6.7b 开始，体积小、加载快，适合跑通流程。

这里要提醒一点：Ollama 默认监听 127.0.0.1:11434，如果你在远程开发机上跑，VS Code 通过 Remote-SSH 连接后，Continue 发出的请求需要能访问到这个端口。通常 Remote-SSH 会自动做端口转发，但如果你改了 Ollama 的监听地址，就要确保 Continue 配置里的 endpoint 和实际一致。TaoToken 的 endpoint 则是公网地址，不需要端口转发，但需要 API Key 鉴权。

3. 可复制配置：Continue config.json + Ollama 拉取命令 + 固定 prompt 模板

这一节直接给可复制的配置。先看 Ollama 的模型拉取命令。在远程开发机上执行：

# 拉取 deepseek-coder 6.7b，适合快速验证 ollama pull deepseek-coder:6.7b # 拉取 deepseek-coder-v2，平衡质量和速度 ollama pull deepseek-coder-v2:latest # 如果需要更高精度，可以拉 33b，但显存要求高 ollama pull deepseek-coder:33b-instruct-fp16

拉取完成后，用ollama list确认模型存在。然后启动 Ollama 服务，注意模型存储路径，避免默认路径空间不足：

export OLLAMA_MODELS=/root/autodl-tmp/models/ollama export OLLAMA_FLASH_ATTENTION=1 export OLLAMA_NUM_PARALLEL=16 export OLLAMA_MAX_LOADED_MODELS=1 nohup ollama serve > /root/autodl-tmp/log.ollama.log 2>&1 &

接下来是 Continue 的配置文件。在 VS Code 中，Continue 的配置文件通常位于~/.continue/config.json。下面是一个可复制的片段，同时包含 Ollama 本地和 TaoToken 两个 provider：

{ "models": [ { "title": "deepseek-coder-6.7b (Ollama)", "provider": "ollama", "model": "deepseek-coder:6.7b", "apiBase": "http://127.0.0.1:11434" }, { "title": "deepseek-coder-v2 (Ollama)", "provider": "ollama", "model": "deepseek-coder-v2:latest", "apiBase": "http://127.0.0.1:11434" }, { "title": "deepseek-coder (TaoToken)", "provider": "openai", "model": "deepseek-coder", "apiKey": "你的_TaoToken_API_Key", "apiBase": "https://taotoken.net/api" } ], "tabAutocompleteModel": { "title": "deepseek-coder-6.7b (Ollama)", "provider": "ollama", "model": "deepseek-coder:6.7b", "apiBase": "http://127.0.0.1:11434" }, "tabAutocompleteOptions": { "maxPromptTokens": 1024, "debounceDelay": 300 } }

注意tabAutocompleteModel是控制 Tab 补全的模型，models列表里的模型用于聊天和编辑。如果你只想测补全，重点配置tabAutocompleteModel。TaoToken 的 provider 写成openai，因为它是 OpenAI 兼容接口，apiBase填https://taotoken.net/api，apiKey填你申请到的 Key。

固定 prompt 模板方面，Continue 的补全 prompt 是自动生成的，但你可以通过tabAutocompleteOptions控制上下文长度和延迟。为了可复现，建议固定maxPromptTokens和debounceDelay，这样每次补全的输入条件一致。如果你要测聊天式续写，可以在 Continue 的聊天窗口里用固定 prompt，比如：

请根据以下代码上下文，补全下一个函数。只输出代码，不要解释。 上下文： def calculate_total(items): total = 0 for item in items: total += item.price return total def apply_discount(total, discount_rate):

这个 prompt 模板可以保存成文件，每次评测时粘贴使用。关键是保持上下文和指令一致，这样不同模型的结果才有可比性。

4. 验证请求：记录首 token 延迟与补全通过率

配置完成后，先做一次验证请求。在 VS Code 里打开一个 Python 文件，输入部分代码，看 Continue 是否触发补全。如果没反应，检查 Ollama 服务是否在跑，以及 Continue 的日志。你可以打开 Continue 的输出面板，看请求是否发到了http://127.0.0.1:11434。

首 token 延迟的测量，最直接的方法是在 Continue 的日志里看时间戳。但更可控的方式是用 curl 直接请求 Ollama 的 API，记录从发送到收到第一个 token 的时间。比如：

time curl -s http://127.0.0.1:11434/api/generate -d '{ "model": "deepseek-coder:6.7b", "prompt": "def calculate_total(items):\n total = 0\n for item in items:\n total += item.price\n return total\n\ndef apply_discount(total, discount_rate):", "stream": false, "options": { "num_predict": 64 } }' | head -c 200

这个命令会返回补全结果，time会给出总耗时。但首 token 延迟需要流式请求才能测准。你可以用stream: true，然后看第一个 chunk 到达的时间。在 Continue 里，补全延迟通常体现在 UI 上，但为了精确，建议用脚本记录。

补全通过率的定义可以自己定：比如补全结果能直接运行不报错，或者补全的函数签名和预期一致。我一般准备 20 个用例，每个用例有标准答案，然后人工或脚本判断补全结果是否通过。记录表格如下：

跑完 Ollama 后，把tabAutocompleteModel换成 TaoToken 的配置，再跑同一组用例。注意 TaoToken 的 endpoint 是https://taotoken.net/api，provider 是openai，model 填deepseek-coder。这样你就能得到两组数据，对比本地推理和 API 推理的差异。

验证时如果遇到 401，说明 API Key 不对或没填。如果遇到local proxy failed，检查 Remote-SSH 的端口转发是否正常。如果日志里出现reading choices相关错误，通常是响应格式不匹配，检查 provider 是否写成了openai。这些报错在下一节详细说。

5. 常见错排查：401、local proxy failed、reading choices、OAuth

这一节列几个真实会遇到的报错和排查方法。第一个是 401 Unauthorized。如果你在 Continue 里用 TaoToken 的 endpoint，但没填 API Key 或填错了，就会报 401。解决方法是检查config.json里的apiKey字段，确保和 https://taotoken.net/api-keys 里生成的一致。注意不要有多余空格。

第二个是local proxy failed。这个通常出现在 Remote-SSH 场景下，Continue 试图访问127.0.0.1:11434，但端口没有正确转发。解决方法是确认 VS Code 的 Remote-SSH 是否自动转发了 11434 端口。你可以在远程终端里执行curl http://127.0.0.1:11434/api/tags，如果能返回模型列表，说明 Ollama 正常。然后在本地 VS Code 的终端里也执行同样的 curl，如果失败，就是端口转发问题。可以在 VS Code 的端口面板手动添加 11434。

第三个是reading choices相关错误。这通常发生在用 OpenAI 兼容 provider 时，响应格式和预期不符。比如 TaoToken 返回的 JSON 里没有choices字段，或者 Continue 解析失败。解决方法是检查apiBase是否写成了https://taotoken.net/api，不要多加/v1或斜杠。同时确认 model 名称是否正确，TaoToken 的模型 ID 可以在模型对话页面查看。

第四个是 OAuth 相关报错。如果你在 Continue 里配置了需要 OAuth 的 provider，但没完成授权，就会报错。对于 Ollama 和 TaoToken 的 API Key 方式，一般不会触发 OAuth。如果你看到 OAuth 错误，检查是否误选了需要 OAuth 的 provider，比如某些云厂商的默认配置。改成ollama或openai即可。

另外，如果你在配置里同时写了 Ollama 和 TaoToken，切换模型时要注意tabAutocompleteModel是否同步更新。Continue 的 Tab 补全只认tabAutocompleteModel，聊天模型在models列表里选。如果你发现补全没走 TaoToken，检查tabAutocompleteModel的 provider 和 apiBase 是否改对了。

还有一个坑是模型名称。Ollama 的模型名称必须和ollama list里显示的一致，比如deepseek-coder:6.7b，不能写成deepseek-coder-6.7b。TaoToken 的模型 ID 则要看它的文档，通常和官方名称一致。如果模型名称写错，会报模型不存在。

6. 语义一致 CTA：把 endpoint 切到 TaoToken 做对照验证

跑完本地 Ollama 的基准后，把tabAutocompleteModel改成 TaoToken 的配置，再跑同一组用例。这一步的目的是对照验证：同样的 prompt、同样的用例，本地推理和 API 推理在首 token 延迟和补全通过率上有什么差异。TaoToken 的 API 地址是 https://taotoken.net/api，你可以在 https://taotoken.net/api-keys 生成 Key，然后在 Continue 配置里把 provider 改成openai，apiBase 填https://taotoken.net/api，model 填deepseek-coder。

如果你更关注长期编码和 Agent 场景，可以了解 Coding Plan：https://taotoken.net/coding-plan。如果你只是想快速验证模型对话效果，可以用模型对话页面：https://taotoken.net/models。接入文档在 https://taotoken.net/doc，里面有详细的配置说明。Claude Code 相关的接入可以参考 https://taotoken.net/claude-code。

对照验证时，建议把两组数据放在同一张表里，对比首 token 延迟和通过率。如果 TaoToken 的延迟更低，说明 API 推理链路更优；如果通过率更高，说明模型版本或推理参数有差异。无论结果如何，这套基准都能让你在选型时有数据支撑，而不是凭感觉。

最后一步是固化配置。把config.json备份，把用例和 prompt 模板存成文件，下次换模型或换 endpoint 时直接复用。这样你的补全基准就是可复现的，而不是一次性的测试。