Continue API 配置：分清聊天与自动补全角色
在 Continue 中分别配置聊天、编辑和自动补全角色，接入兼容端点，并检查 Responses API 选择、模型限制与真实调用费用。
发布 2026-09-29 · 更新 2026-09-29 · KeepRouter Editorial · 4 分钟阅读
在 Continue 中配置兼容模型，使用 provider: openai、准确型号和 apiBase，并只分配本次需要验证的角色。聊天、编辑、应用补丁、自动补全和向量检索是不同任务，聊天成功不能证明其他角色也可用。
如果只是替换付费聊天模型，可以保留已经好用的本地补全模型，先缩小变更范围。
明确一条聊天配置
Continue OpenAI 配置说明介绍了自定义 API 地址和 useResponsesApi；配置参考定义角色与能力。
name: KeepRouter chat trial
version: 1.0.0
schema: v1
models:
- name: KeepRouter text check
provider: openai
model: free
apiBase: https://keeprouter.com/v1
apiKey: REPLACE_WITH_YOUR_KEEPROUTER_KEY
useResponsesApi: false
roles:
- chat这是本地配置模板。按所用版本支持的方式保存凭证，不要提交填入真实 Key 的文件。free 用于简单文本连接验证，付费代码模型需要另外测试能力与预算。
基础地址写到 /v1，由客户端补齐操作路径。新建一段聊天，确认界面实际选择了新增模型，而不是原来的默认项。
让模型角色对应具体工作
| 角色 | 验证任务 | 单纯聊天发现不了的问题 |
|---|---|---|
| chat | 解释短函数 | 上下文遗漏 |
| edit | 修改一个行为 | 编辑格式或需求理解错误 |
| apply | 应用已确认补丁 | 补丁位置错误 |
| autocomplete | 补齐表达式 | 延迟与无效建议 |
| embed | 索引、检索代码 | 向量或端点不兼容 |
自动补全会产生很多短请求，部分建议从未被接受。适合长篇解释的模型，不一定适合用户正在输入时的即时补全。成本也应按被接受的建议与节省的工作量判断。
检查客户端实际选择的 API
Continue 有与型号相关的 Responses API 行为。遇到路径错误时先查看实际操作，本文用 useResponsesApi: false 明确选择 Chat Completions。
不要把 useLegacyCompletionsEndpoint 当作万能修复。旧 Completions 与 Chat Completions 的请求结构不同，改完可能只是换一种错误。
先不声明图片或工具能力，确认具体线路支持后再开启。配置项会影响请求，但不会增加上游本来没有的功能。
用同一个小项目比较聊天与编辑
准备函数、测试和一个无关文件。先让模型解释行为，再修改一个要求明确的功能，不改变公共签名。检查实际 diff 和测试输出。
例如字符串函数只去掉首尾空格，保留中间空格；让模型补充空字符串测试，确认它没有顺便删除所有内部空格。不同候选从同一仓库版本开始，并提供相同上下文。
分开排查配置与任务失败
| 现象 | 排查方向 |
|---|---|
| 找不到新模型 | YAML 格式与当前加载配置 |
| 401 | 目标服务和凭证 |
| 404 | API 模式与重复路径 |
| 聊天正常、编辑失败 | 对应角色的提示词与补丁处理 |
| 补全迟缓 | 请求频率、延迟、角色选择 |
| 花费超出估算 | 后台调用、未接受建议与重试 |
按 Continue 接入说明建立基本连接，到目录选准确型号，用费用计算器估算试验预算。每个新角色通过自己的测试后再替换旧配置。
常见问题
一个模型能负责全部 Continue 角色吗？
可能可以，但每个角色都需要自己的能力和延迟验证。聊天成功不能证明补全、向量或补丁应用质量。
为什么 Continue 请求 responses？
端点选择可能与型号和配置有关。按官方说明，为本次线路明确设置 useResponsesApi。
可以用免费线路评价代码能力吗？
免费线路仅用于基本文本连接检查。代码评估应使用实际候选型号，验证任务、能力和当前价格。
参考的一手资料
本文最近复核 2026-09-29