1. 为什么要在编辑器里实时挑选 AI 模型最近在开发 AI 辅助编码工作流时我遇到了一个很实际的问题不同模型在不同任务上的表现差别很大。有的模型写 Python 小工具很快但做长文档总结就啰嗦有的模型响应速度快但代码正确率不够还有的模型在深夜调用高峰期延迟特别高。如果每次都在编辑器里手动切换模型再复制粘贴同一段代码去试效率太低了。其实很多开发者已经有同样的感受编辑器里的 AI 能力越来越强但“选哪个模型”成了一个新问题。VS Code 里装了 Continue、Cline 这类插件后可以同时配置多个模型服务商但真正选型时往往靠的是印象流或者临时看排行榜。这种方式的痛点在于模型能力变化很快不在真实任务上跑一下很难知道当前哪个模型最适合你的场景。本文要解决的问题就是“如何在编辑器里实时挑选最佳 AI 模型”。我会从核心概念讲起再给出一个可落地的方案用 Python 写一个轻量模型评测与路由脚本在 VS Code 里通过任务命令一键运行把多个候选模型放到同一组测试样本上跑实时对比响应质量、耗时和 token 消耗最终选出最适合当前任务的模型。这套方案适合三类读者正在使用 AI 编程助手想自己搭建模型对比测试的开发者。需要在本地方案和在线模型之间做选型评估的技术负责人。对模型路由、评测维度、自动切换机制感兴趣的后端工程师。读完本文后你会掌握模型评测的关键指标、配置驱动的模型管理方式、在编辑器里运行和查看结果的完整流程以及生产环境落地时需要注意的坑。2. 核心概念模型、Provider、Token、路由与评测在动手写代码之前需要先把几个基础概念讲清楚。这些概念在日常使用 AI 模型时经常混在一起但实际上它们属于不同层次。2.1 模型Model与 Provider 的区别很多人说“我用的 ChatGPT”其实这里的说法包含了两个含义一个是模型本身比如 GPT 系列另一个是模型服务商Provider也就是通过什么平台访问这个模型。同一个模型可能由不同平台提供同一个平台也可能提供多个模型。在实际开发中我们通常会把模型和服务商分开配置概念含义示例模型某个具体的模型名称某个厂商的 chat 模型、推理模型Provider提供模型 API 的服务平台自建网关、云服务商、本地推理服务Base URLAPI 访问地址平台提供的接入点API Key访问凭证需要妥善保存的密钥这里要特别提醒本文的示例不会绑定任何特定平台而是采用“配置优先”的方式。你在配置文件中写入自己的模型名称、接口地址和密钥即可。2.2 Token 与上下文长度Token 是模型处理文本的基本单位。一个中文汉字可能对应 1 到 2 个 Token英文单词通常也是 1 到 2 个 Token。了解 Token 很重要因为它直接关系到两个问题成本大多数在线模型按 Token 计费。上下文窗口每个模型能处理的最大 Token 数不同。在评测模型时如果两个模型输入相同、输出质量接近那么谁消耗的 Token 更少谁就更省钱。2.3 模型路由是什么模型路由是指根据任务类型、成本预算、延迟要求等条件自动选择合适的模型来处理请求。比如简单问答路由到轻量模型。代码生成路由到代码能力强的模型。长文档总结路由到上下文窗口大的模型。本文实现的“实时挑选”本质上就是一个简化版模型路由器预先给出一组候选模型通过实际任务测试来评分然后按评分自动选择最优模型。2.4 评测维度有哪些要对比模型好坏不能只看一个指标。我常用的评测维度有五个维度说明获取方式答案质量输出是否符合预期、是否包含关键信息人工评分或规则匹配响应耗时从发出请求到收到完整响应的耗时程序计时输出长度输出 Token 数量API 返回值输入长度输入 Token 数量用于估算成本API 返回值稳定性多次调用的结果波动情况多次重复测试这套维度足够覆盖大多数场景。如果你对某个场景有特殊要求可以在脚本中扩展自定义评分函数。3. 环境准备与方案选型3.1 整体方案说明我采用的技术方案是编辑器VS Code使用其任务Task功能来运行评测脚本。脚本语言Python 3.10 以上使用标准库和 requests。配置管理JSON 文件保存模型候选列表和 API 配置。评测方式把一组固定测试问题发送给所有候选模型收集结果并评分。这样设计的好处是不依赖特定插件不锁定某个平台代码量可控可以轻松扩展到新的模型服务商。3.2 环境准备python -m venv .venv source .venv/bin/activate # Windows 下使用 .venv\Scripts\activate pip install requests版本说明本文示例以 Python 3.10 和 requests 2.x 为准。如果你使用的是 3.12 以上版本requests 的用法完全兼容如果你用异步框架或 OpenAI SDK需要按实际版本调整导入方式。3.3 项目结构model-eval/ ├── config.json # 模型候选配置 ├── test_cases.json # 测试用例 ├── eval_runner.py # 评测主脚本 ├── model_client.py # 模型调用封装 ├── scorer.py # 评分逻辑 └── README.md # 使用说明4. 配置驱动的模型管理4.1 为什么用配置文件而不是写死在代码里在实际项目中模型列表、接口地址、密钥都是经常变化的。如果把模型信息写死在代码里每次增删模型都要改代码、测代码既慢又容易出错。更好的方式是使用配置文件让脚本在启动时读取配置运行时动态加载。4.2 模型候选配置先看config.json的设计。这里采用了一个通用结构{ providers: [ { id: provider-a, name: 示例服务商A, base_url: https://api.example-a.com/v1, api_key_env: MODEL_API_KEY_A, models: [ { id: model-a-fast, display_name: A-快速模型, max_tokens: 2048, temperature: 0.2, weight: 0.8 }, { id: model-a-quality, display_name: A-高质量模型, max_tokens: 4096, temperature: 0.2, weight: 1.0 } ] }, { id: provider-local, name: 本地方案, base_url: http://localhost:11434/v1, api_key_env: , models: [ { id: local-model, display_name: 本地模型, max_tokens: 2048, temperature: 0.2, weight: 0.9 } ] } ] }这里有几个设计要点api_key_env指定环境变量名而不是直接写入密钥避免密钥泄露。脚本从环境变量读取 API Key。temperature默认设为 0.2是为了让模型输出更稳定减少随机性对评测结果的影响。weight是评分权重表示该模型在“综合分”里的权重系数可以根据费用、偏好等调整。4.3 测试用例配置测试用例放在test_cases.json中[ { id: python-regex, category: code, prompt: 请用 Python 写一段代码提取字符串中所有合法的 URL并解释思路。, keywords: [http, https, re, url] }, { id: config-explain, category: explain, prompt: 请用通俗语言解释什么是数据库索引并给出一个实际场景。, keywords: [索引, 查询, 磁盘] }, { id: refactor-sql, category: sql, prompt: 有一条 SQL 查询特别慢表有百万行数据请给出优化建议。, keywords: [索引, where, 执行计划] } ]其中的keywords用于简单的关键词命中评分。如果你想让评测更准确可以用这个字段做基础质量判断也可以后续扩展为模型打分比如用一个“裁判模型”来评分。5. 核心代码实现5.1 模型调用封装为了兼容不同服务商的 API我写了一个model_client.py。核心思路是统一把请求转换成 Chat Completions 风格然后通过 HTTP 发送。# 文件路径model_client.py import json import os import time import requests class ModelClient: 统一的模型调用封装兼容 OpenAI 风格的 Chat Completions API。 def __init__(self, provider_config, model_config): self.provider_id provider_config[id] self.provider_name provider_config[name] self.base_url provider_config[base_url].rstrip(/) self.api_key_env provider_config.get(api_key_env, ) self.api_key os.environ.get(self.api_key_env, ) if self.api_key_env else self.model_id model_config[id] self.display_name model_config.get(display_name, self.model_id) self.max_tokens model_config.get(max_tokens, 2048) self.temperature model_config.get(temperature, 0.2) self.weight model_config.get(weight, 1.0) def chat(self, prompt, timeout60): 发送对话请求返回响应文本和原始元数据。 url f{self.base_url}/chat/completions headers { Content-Type: application/json, } if self.api_key: headers[Authorization] fBearer {self.api_key} payload { model: self.model_id, messages: [ {role: user, content: prompt} ], max_tokens: self.max_tokens, temperature: self.temperature, } start_time time.time() response requests.post(url, headersheaders, jsonpayload, timeouttimeout) elapsed_ms int((time.time() - start_time) * 1000) if response.status_code ! 200: return { success: False, error: fHTTP {response.status_code}: {response.text[:200]}, elapsed_ms: elapsed_ms, output_text: , prompt_tokens: 0, completion_tokens: 0, total_tokens: 0, } data response.json() output_text data[choices][0][message][content].strip() usage data.get(usage, {}) return { success: True, error: , elapsed_ms: elapsed_ms, output_text: output_text, prompt_tokens: usage.get(prompt_tokens, 0), completion_tokens: usage.get(completion_tokens, 0), total_tokens: usage.get(total_tokens, 0), } def to_dict(self): 返回模型标识信息用于结果展示。 return { provider_id: self.provider_id, provider_name: self.provider_name, model_id: self.model_id, display_name: self.display_name, }要点解释base_url采用/v1形式的地址末尾/chat/completions会被拼上。如果没有配置api_key_env则不添加 Authorization 头适用于本地方案。使用timeout参数控制请求超时避免某个模型卡住整个评测流程。返回值中同时包含成功状态、输出文本、耗时和 Token 使用量供评分模块使用。5.2 评分逻辑scorer.py负责把模型输出转换成可比较的分数。综合分越高代表越适合当前任务。# 文件路径scorer.py class Scorer: 综合评分器结合关键字命中、耗时、Token 消耗计算得分。 def __init__(self, result, case_keywordsNone): self.result result self.case_keywords case_keywords or [] def keyword_score(self, max_score60): 关键词命中评分。 if not self.result.get(success): return 0 text self.result.get(output_text, ) hit_count 0 for kw in self.case_keywords: if kw.lower() in text.lower(): hit_count 1 if not self.case_keywords: return max_score * 0.7 ratio hit_count / len(self.case_keywords) return max_score * ratio def speed_score(self, max_score20): 耗时评分响应越快得分越高。 elapsed_ms self.result.get(elapsed_ms, 0) if elapsed_ms 0: return 0 # 以 10 秒为满分线超过 30 秒给低分 if elapsed_ms 10000: return max_score if elapsed_ms 30000: return 2 return max_score * (1 - (elapsed_ms - 10000) / 20000) def token_score(self, max_score20): Token 消耗评分总 token 越少得分越高。 total_tokens self.result.get(total_tokens, 0) if total_tokens 0: return max_score * 0.5 # 以 800 token 为基准超过 4000 给低分 if total_tokens 800: return max_score if total_tokens 4000: return 3 return max_score * (1 - (total_tokens - 800) / 3200) def failed_score(self): 请求失败时返回 0。 if not self.result.get(success): return 0 def total(self): 综合分。 if not self.result.get(success): return 0 return self.keyword_score() self.speed_score() self.token_score()说明评分规则里的阈值10 秒、800 token 等是我在常见场景下使用的经验值你可以根据实际任务调整。如果你的任务更复杂可以替换为“裁判模型评分”或“执行测试用例验证结果是否正确”。5.3 评测主脚本eval_runner.py是入口脚本它读取配置和测试用例遍历所有候选模型输出一个按综合分排序的结果表格。# 文件路径eval_runner.py import json import sys from model_client import ModelClient from scorer import Scorer def load_config(path): with open(path, r, encodingutf-8) as f: return json.load(f) def load_test_cases(path): with open(path, r, encodingutf-8) as f: return json.load(f) def build_clients(config): clients [] for provider in config[providers]: for model in provider[models]: clients.append(ModelClient(provider, model)) return clients def run_evaluation(clients, test_cases): 对每个模型执行所有测试用例返回明细和汇总。 details [] summaries [] for client in clients: total_score 0.0 total_time 0 total_tokens 0 success_count 0 case_results [] for case in test_cases: prompt case[prompt] keywords case.get(keywords, []) result client.chat(prompt) scorer Scorer(result, keywords) score scorer.total() total_score score total_time result.get(elapsed_ms, 0) total_tokens result.get(total_tokens, 0) if result.get(success): success_count 1 case_results.append({ case_id: case[id], score: score, success: result.get(success), elapsed_ms: result.get(elapsed_ms, 0), total_tokens: result.get(total_tokens, 0), output_preview: result.get(output_text, )[:100], error: result.get(error, ), }) avg_score total_score / len(test_cases) if test_cases else 0 avg_time total_time / len(test_cases) if test_cases else 0 summaries.append({ client: client.to_dict(), avg_score: round(avg_score, 2), avg_time_ms: int(avg_time), total_tokens: total_tokens, success_count: success_count, total_cases: len(test_cases), }) details.append({ client: client.to_dict(), cases: case_results, }) return details, summaries def print_summary(summaries): 按平均分降序输出汇总表格。 print( * 70) print(模型评测汇总按综合分降序) print( * 70) sorted_summaries sorted( summaries, keylambda s: s[avg_score], reverseTrue ) header f{排名:4}{模型:20}{综合分:10}{平均耗时(ms):16}{成功数:8}{总Token:10} print(header) print(- * 70) for idx, s in enumerate(sorted_summaries, start1): model_name s[client][display_name] print( f{idx:6}{model_name:22}{s[avg_score]:12} f{s[avg_time_ms]:18}{s[success_count]}/{s[total_cases]:8} f{s[total_tokens]} ) print( * 70) best sorted_summaries[0] print( f推荐模型: {best[client][display_name]} f(provider: {best[client][provider_name]}) ) print( * 70) def print_detail(details): 按用例输出明细。 print(\n用例明细) for item in details: print(f\n--- {item[client][display_name]} ---) for case in item[cases]: status 成功 if case[success] else 失败 print( f [{case[case_id]}] {status} | 得分 {case[score]} | f耗时 {case[elapsed_ms]}ms | Token {case[total_tokens]} ) if case[output_preview]: preview case[output_preview].replace(\n, ) print(f 预览: {preview}...) def main(): config_path config.json test_cases_path test_cases.json show_detail --detail in sys.argv try: config load_config(config_path) test_cases load_test_cases(test_cases_path) except FileNotFoundError as e: print(f找不到配置文件: {e}) sys.exit(1) except json.JSONDecodeError as e: print(fJSON 解析失败: {e}) sys.exit(1) clients build_clients(config) if not clients: print(配置中没有可用模型请检查 config.json。) sys.exit(1) print(f共发现 {len(clients)} 个候选模型测试样例 {len(test_cases)} 条。\n) details, summaries run_evaluation(clients, test_cases) print_summary(summaries) if show_detail: print_detail(details) if __name__ __main__: main()5.4 在 VS Code 中配置任务为了让评测脚本在编辑器里一键运行我在.vscode/tasks.json中配置了一条任务{ version: 2.0.0, tasks: [ { label: eval: 跑模型评测, type: shell, command: python, args: [ eval_runner.py, --detail ], options: { cwd: ${workspaceFolder}, env: { PYTHONIOENCODING: utf-8 } }, presentation: { reveal: always, panel: shared }, group: { kind: build, isDefault: true } } ] }这样配置后在 VS Code 里按Ctrl Shift B就可以直接运行评测任务所有输出会显示在集成终端中。如果你的脚本不在工作区根目录需要修改cwd。6. 运行与验证6.1 准备 API Key在运行前你需要把 API Key 放到环境变量中。假设你在config.json中配置了MODEL_API_KEY_A那么在终端里执行export MODEL_API_KEY_A你的密钥Windows PowerShell 下使用$env:MODEL_API_KEY_A你的密钥如果使用本地方案可以不设置 API Key。6.2 运行评测在终端中执行python eval_runner.py --detail预期输出大致如下共发现 3 个候选模型测试样例 3 条。 模型评测汇总按综合分降序 排名 模型 综合分 平均耗时(ms) 成功数 总Token ---------------------------------------------------------------------- 1 A-快速模型 95.20 842 3/3 1520 2 本地模型 88.50 1260 3/3 1890 3 A-高质量模型 85.33 2870 3/3 2450 推荐模型: A-快速模型 (provider: 示例服务商A) 这里的关键是看三列综合分、平均耗时、成功数。如果某个模型出现 0/3 成功需要回到config.json检查接口地址、密钥和模型名称是否配置正确。6.3 把结果保存成报告如果你希望把评测结果保存到文件可以将脚本的输出重定向python eval_runner.py --detail report.txt也可以修改脚本把结果写成 JSON方便后续接入自动化和 CI 流程。这里不做扩展但接口设计已经预留了details和summaries两个数据结构直接序列化即可。7. 常见问题与排查思路在实际使用中有几个问题比较常见。我整理成表格方便你快速定位。问题现象常见原因解决思路所有模型都返回失败环境变量没有设置或设置错误检查 API Key 环境变量名是否与config.json中一致模型 A 成功模型 B 失败模型名称写错或服务商未开放该模型权限在服务商控制台确认模型 ID请求超时网络环境不稳定或模型响应太长调大chat方法的 timeout 参数减少max_tokensJSON 文件解析失败配置里多了逗号或注释用 VS Code 的 JSON 格式化功能检查中文标题输出乱码终端编码不是 UTF-8在tasks.json中设置PYTHONIOENCODINGutf-8评分出现 0.0关键词没有命中或请求失败查看--detail输出中的错误信息和预览排查建议按顺序进行先确认配置文件能否被读取。直接在终端运行python -c import json; print(json.load(open(config.json)))。再确认 API Key 是否可用。用 curl 或 Postman 单独测试一个接口。再确认单个模型调用是否成功。可以在eval_runner.py中临时只保留一个模型调试。最后才关注评分逻辑。8. 最佳实践与工程建议8.1 用环境变量管理密钥永远不要把你的 API 密钥写进config.json、代码仓库或博客示例中。推荐做法本地开发时使用.env文件通过python-dotenv加载。CI/CD 环境中使用流水线的变量管理功能。生产环境使用密钥管理服务。# 如果使用 python-dotenv from dotenv import load_dotenv load_dotenv()8.2 控制随机性模型输出本身带有随机性。评测时建议把temperature调到 0.2 以下并且每个用例跑多次取平均值这样得到的结论更稳定。如果某次结果特别异常可以先看是不是网络波动导致的超时。8.3 评测任务要与实际场景对齐“最佳模型”没有绝对标准只有相对场景。如果你的主要任务是写 SQL那么评测用例就应该以 SQL 优化、建表、索引设计为主如果你的主要任务是阅读代码仓库那么评测用例就应该包括代码解释和 Bug 定位。建议把测试用例按类别组织并在汇总结果里按类别分别统计。8.4 引入自动路由在评测脚本的基础上可以进一步做一个自动路由函数# 伪代码示意 def route_request(prompt, scoring_result): 根据评测得分选择最优模型。 best_model scoring_result[best_model] return model_clients[best_model].chat(prompt)在编辑器里你可以把路由函数包装成一个命令让 AI 助手调用。这样每次请求时模型选择不再是手工操作而是由评测结果自动决定。8.5 关注成本与命中率平衡在选择模型时不要只看性能和准确率还要考虑成本。一个质量稍差但便宜很多的模型可能更适合高并发场景。你可以给每个模型增加一个cost_per_1k_tokens配置在打分时把成本作为一个负向指标加权。8.6 安全边界与合规提醒在对接模型服务时要注意数据安全。不要把敏感业务数据、数据库连接串、用户隐私数据发送到不可信的第三方模型服务。建议在配置文件中明确标注某个 Provider 是否允许外部发送数据并增加脱敏逻辑。涉及生产环境变更时先在测试环境验证再决定是否引入新的模型供应商。9. 总结与后续方向本文从“编辑器里怎么实时挑模型”这个问题出发梳理了模型、Provider、Token、路由、评测等核心概念然后给出了一套可直接运行的 Python 评测方案。你可以在 VS Code 里一键运行评测脚本让多个候选模型在同一组测试用例下对比得分并自动获得当前场景的推荐模型。核心收获有四个模型评测不能只看响应速度要综合质量、耗时、Token 消耗和稳定性。配置驱动的方式让模型列表的增删变得简单不需要改动代码。VS Code 的 Task 机制可以把评测脚本集成到编辑器中形成一次按键出结果的工作流。评分规则不是固定的需要根据你的实际任务不断调整。接下来你可以继续做几件事扩展测试用例库覆盖代码生成、SQL 优化、文档总结、错误排查等场景。引入一个“裁判模型”对候选模型的答案进行质量打分替代简单的关键词命中。把评测脚本接入 CI在模型版本更新时自动跑一轮回归测试防止模型表现退化。在编辑器里写一个自定义命令把路由结果直接注入到当前编辑中的代码或文档里。如果你在配置过程中遇到报错建议回到第 7 节按顺序排查。挑选模型不是一锤子买卖保持测试、统计、更新配置的循环才能让编辑器里的 AI 一直处于“最佳状态”。希望这套方案对你的实际项目有所帮助。 编辑器内实时挑选最佳AI模型：Python评测与路由方案
1. 为什么要在编辑器里实时挑选 AI 模型最近在开发 AI 辅助编码工作流时我遇到了一个很实际的问题不同模型在不同任务上的表现差别很大。有的模型写 Python 小工具很快但做长文档总结就啰嗦有的模型响应速度快但代码正确率不够还有的模型在深夜调用高峰期延迟特别高。如果每次都在编辑器里手动切换模型再复制粘贴同一段代码去试效率太低了。其实很多开发者已经有同样的感受编辑器里的 AI 能力越来越强但“选哪个模型”成了一个新问题。VS Code 里装了 Continue、Cline 这类插件后可以同时配置多个模型服务商但真正选型时往往靠的是印象流或者临时看排行榜。这种方式的痛点在于模型能力变化很快不在真实任务上跑一下很难知道当前哪个模型最适合你的场景。本文要解决的问题就是“如何在编辑器里实时挑选最佳 AI 模型”。我会从核心概念讲起再给出一个可落地的方案用 Python 写一个轻量模型评测与路由脚本在 VS Code 里通过任务命令一键运行把多个候选模型放到同一组测试样本上跑实时对比响应质量、耗时和 token 消耗最终选出最适合当前任务的模型。这套方案适合三类读者正在使用 AI 编程助手想自己搭建模型对比测试的开发者。需要在本地方案和在线模型之间做选型评估的技术负责人。对模型路由、评测维度、自动切换机制感兴趣的后端工程师。读完本文后你会掌握模型评测的关键指标、配置驱动的模型管理方式、在编辑器里运行和查看结果的完整流程以及生产环境落地时需要注意的坑。2. 核心概念模型、Provider、Token、路由与评测在动手写代码之前需要先把几个基础概念讲清楚。这些概念在日常使用 AI 模型时经常混在一起但实际上它们属于不同层次。2.1 模型Model与 Provider 的区别很多人说“我用的 ChatGPT”其实这里的说法包含了两个含义一个是模型本身比如 GPT 系列另一个是模型服务商Provider也就是通过什么平台访问这个模型。同一个模型可能由不同平台提供同一个平台也可能提供多个模型。在实际开发中我们通常会把模型和服务商分开配置概念含义示例模型某个具体的模型名称某个厂商的 chat 模型、推理模型Provider提供模型 API 的服务平台自建网关、云服务商、本地推理服务Base URLAPI 访问地址平台提供的接入点API Key访问凭证需要妥善保存的密钥这里要特别提醒本文的示例不会绑定任何特定平台而是采用“配置优先”的方式。你在配置文件中写入自己的模型名称、接口地址和密钥即可。2.2 Token 与上下文长度Token 是模型处理文本的基本单位。一个中文汉字可能对应 1 到 2 个 Token英文单词通常也是 1 到 2 个 Token。了解 Token 很重要因为它直接关系到两个问题成本大多数在线模型按 Token 计费。上下文窗口每个模型能处理的最大 Token 数不同。在评测模型时如果两个模型输入相同、输出质量接近那么谁消耗的 Token 更少谁就更省钱。2.3 模型路由是什么模型路由是指根据任务类型、成本预算、延迟要求等条件自动选择合适的模型来处理请求。比如简单问答路由到轻量模型。代码生成路由到代码能力强的模型。长文档总结路由到上下文窗口大的模型。本文实现的“实时挑选”本质上就是一个简化版模型路由器预先给出一组候选模型通过实际任务测试来评分然后按评分自动选择最优模型。2.4 评测维度有哪些要对比模型好坏不能只看一个指标。我常用的评测维度有五个维度说明获取方式答案质量输出是否符合预期、是否包含关键信息人工评分或规则匹配响应耗时从发出请求到收到完整响应的耗时程序计时输出长度输出 Token 数量API 返回值输入长度输入 Token 数量用于估算成本API 返回值稳定性多次调用的结果波动情况多次重复测试这套维度足够覆盖大多数场景。如果你对某个场景有特殊要求可以在脚本中扩展自定义评分函数。3. 环境准备与方案选型3.1 整体方案说明我采用的技术方案是编辑器VS Code使用其任务Task功能来运行评测脚本。脚本语言Python 3.10 以上使用标准库和 requests。配置管理JSON 文件保存模型候选列表和 API 配置。评测方式把一组固定测试问题发送给所有候选模型收集结果并评分。这样设计的好处是不依赖特定插件不锁定某个平台代码量可控可以轻松扩展到新的模型服务商。3.2 环境准备python -m venv .venv source .venv/bin/activate # Windows 下使用 .venv\Scripts\activate pip install requests版本说明本文示例以 Python 3.10 和 requests 2.x 为准。如果你使用的是 3.12 以上版本requests 的用法完全兼容如果你用异步框架或 OpenAI SDK需要按实际版本调整导入方式。3.3 项目结构model-eval/ ├── config.json # 模型候选配置 ├── test_cases.json # 测试用例 ├── eval_runner.py # 评测主脚本 ├── model_client.py # 模型调用封装 ├── scorer.py # 评分逻辑 └── README.md # 使用说明4. 配置驱动的模型管理4.1 为什么用配置文件而不是写死在代码里在实际项目中模型列表、接口地址、密钥都是经常变化的。如果把模型信息写死在代码里每次增删模型都要改代码、测代码既慢又容易出错。更好的方式是使用配置文件让脚本在启动时读取配置运行时动态加载。4.2 模型候选配置先看config.json的设计。这里采用了一个通用结构{ providers: [ { id: provider-a, name: 示例服务商A, base_url: https://api.example-a.com/v1, api_key_env: MODEL_API_KEY_A, models: [ { id: model-a-fast, display_name: A-快速模型, max_tokens: 2048, temperature: 0.2, weight: 0.8 }, { id: model-a-quality, display_name: A-高质量模型, max_tokens: 4096, temperature: 0.2, weight: 1.0 } ] }, { id: provider-local, name: 本地方案, base_url: http://localhost:11434/v1, api_key_env: , models: [ { id: local-model, display_name: 本地模型, max_tokens: 2048, temperature: 0.2, weight: 0.9 } ] } ] }这里有几个设计要点api_key_env指定环境变量名而不是直接写入密钥避免密钥泄露。脚本从环境变量读取 API Key。temperature默认设为 0.2是为了让模型输出更稳定减少随机性对评测结果的影响。weight是评分权重表示该模型在“综合分”里的权重系数可以根据费用、偏好等调整。4.3 测试用例配置测试用例放在test_cases.json中[ { id: python-regex, category: code, prompt: 请用 Python 写一段代码提取字符串中所有合法的 URL并解释思路。, keywords: [http, https, re, url] }, { id: config-explain, category: explain, prompt: 请用通俗语言解释什么是数据库索引并给出一个实际场景。, keywords: [索引, 查询, 磁盘] }, { id: refactor-sql, category: sql, prompt: 有一条 SQL 查询特别慢表有百万行数据请给出优化建议。, keywords: [索引, where, 执行计划] } ]其中的keywords用于简单的关键词命中评分。如果你想让评测更准确可以用这个字段做基础质量判断也可以后续扩展为模型打分比如用一个“裁判模型”来评分。5. 核心代码实现5.1 模型调用封装为了兼容不同服务商的 API我写了一个model_client.py。核心思路是统一把请求转换成 Chat Completions 风格然后通过 HTTP 发送。# 文件路径model_client.py import json import os import time import requests class ModelClient: 统一的模型调用封装兼容 OpenAI 风格的 Chat Completions API。 def __init__(self, provider_config, model_config): self.provider_id provider_config[id] self.provider_name provider_config[name] self.base_url provider_config[base_url].rstrip(/) self.api_key_env provider_config.get(api_key_env, ) self.api_key os.environ.get(self.api_key_env, ) if self.api_key_env else self.model_id model_config[id] self.display_name model_config.get(display_name, self.model_id) self.max_tokens model_config.get(max_tokens, 2048) self.temperature model_config.get(temperature, 0.2) self.weight model_config.get(weight, 1.0) def chat(self, prompt, timeout60): 发送对话请求返回响应文本和原始元数据。 url f{self.base_url}/chat/completions headers { Content-Type: application/json, } if self.api_key: headers[Authorization] fBearer {self.api_key} payload { model: self.model_id, messages: [ {role: user, content: prompt} ], max_tokens: self.max_tokens, temperature: self.temperature, } start_time time.time() response requests.post(url, headersheaders, jsonpayload, timeouttimeout) elapsed_ms int((time.time() - start_time) * 1000) if response.status_code ! 200: return { success: False, error: fHTTP {response.status_code}: {response.text[:200]}, elapsed_ms: elapsed_ms, output_text: , prompt_tokens: 0, completion_tokens: 0, total_tokens: 0, } data response.json() output_text data[choices][0][message][content].strip() usage data.get(usage, {}) return { success: True, error: , elapsed_ms: elapsed_ms, output_text: output_text, prompt_tokens: usage.get(prompt_tokens, 0), completion_tokens: usage.get(completion_tokens, 0), total_tokens: usage.get(total_tokens, 0), } def to_dict(self): 返回模型标识信息用于结果展示。 return { provider_id: self.provider_id, provider_name: self.provider_name, model_id: self.model_id, display_name: self.display_name, }要点解释base_url采用/v1形式的地址末尾/chat/completions会被拼上。如果没有配置api_key_env则不添加 Authorization 头适用于本地方案。使用timeout参数控制请求超时避免某个模型卡住整个评测流程。返回值中同时包含成功状态、输出文本、耗时和 Token 使用量供评分模块使用。5.2 评分逻辑scorer.py负责把模型输出转换成可比较的分数。综合分越高代表越适合当前任务。# 文件路径scorer.py class Scorer: 综合评分器结合关键字命中、耗时、Token 消耗计算得分。 def __init__(self, result, case_keywordsNone): self.result result self.case_keywords case_keywords or [] def keyword_score(self, max_score60): 关键词命中评分。 if not self.result.get(success): return 0 text self.result.get(output_text, ) hit_count 0 for kw in self.case_keywords: if kw.lower() in text.lower(): hit_count 1 if not self.case_keywords: return max_score * 0.7 ratio hit_count / len(self.case_keywords) return max_score * ratio def speed_score(self, max_score20): 耗时评分响应越快得分越高。 elapsed_ms self.result.get(elapsed_ms, 0) if elapsed_ms 0: return 0 # 以 10 秒为满分线超过 30 秒给低分 if elapsed_ms 10000: return max_score if elapsed_ms 30000: return 2 return max_score * (1 - (elapsed_ms - 10000) / 20000) def token_score(self, max_score20): Token 消耗评分总 token 越少得分越高。 total_tokens self.result.get(total_tokens, 0) if total_tokens 0: return max_score * 0.5 # 以 800 token 为基准超过 4000 给低分 if total_tokens 800: return max_score if total_tokens 4000: return 3 return max_score * (1 - (total_tokens - 800) / 3200) def failed_score(self): 请求失败时返回 0。 if not self.result.get(success): return 0 def total(self): 综合分。 if not self.result.get(success): return 0 return self.keyword_score() self.speed_score() self.token_score()说明评分规则里的阈值10 秒、800 token 等是我在常见场景下使用的经验值你可以根据实际任务调整。如果你的任务更复杂可以替换为“裁判模型评分”或“执行测试用例验证结果是否正确”。5.3 评测主脚本eval_runner.py是入口脚本它读取配置和测试用例遍历所有候选模型输出一个按综合分排序的结果表格。# 文件路径eval_runner.py import json import sys from model_client import ModelClient from scorer import Scorer def load_config(path): with open(path, r, encodingutf-8) as f: return json.load(f) def load_test_cases(path): with open(path, r, encodingutf-8) as f: return json.load(f) def build_clients(config): clients [] for provider in config[providers]: for model in provider[models]: clients.append(ModelClient(provider, model)) return clients def run_evaluation(clients, test_cases): 对每个模型执行所有测试用例返回明细和汇总。 details [] summaries [] for client in clients: total_score 0.0 total_time 0 total_tokens 0 success_count 0 case_results [] for case in test_cases: prompt case[prompt] keywords case.get(keywords, []) result client.chat(prompt) scorer Scorer(result, keywords) score scorer.total() total_score score total_time result.get(elapsed_ms, 0) total_tokens result.get(total_tokens, 0) if result.get(success): success_count 1 case_results.append({ case_id: case[id], score: score, success: result.get(success), elapsed_ms: result.get(elapsed_ms, 0), total_tokens: result.get(total_tokens, 0), output_preview: result.get(output_text, )[:100], error: result.get(error, ), }) avg_score total_score / len(test_cases) if test_cases else 0 avg_time total_time / len(test_cases) if test_cases else 0 summaries.append({ client: client.to_dict(), avg_score: round(avg_score, 2), avg_time_ms: int(avg_time), total_tokens: total_tokens, success_count: success_count, total_cases: len(test_cases), }) details.append({ client: client.to_dict(), cases: case_results, }) return details, summaries def print_summary(summaries): 按平均分降序输出汇总表格。 print( * 70) print(模型评测汇总按综合分降序) print( * 70) sorted_summaries sorted( summaries, keylambda s: s[avg_score], reverseTrue ) header f{排名:4}{模型:20}{综合分:10}{平均耗时(ms):16}{成功数:8}{总Token:10} print(header) print(- * 70) for idx, s in enumerate(sorted_summaries, start1): model_name s[client][display_name] print( f{idx:6}{model_name:22}{s[avg_score]:12} f{s[avg_time_ms]:18}{s[success_count]}/{s[total_cases]:8} f{s[total_tokens]} ) print( * 70) best sorted_summaries[0] print( f推荐模型: {best[client][display_name]} f(provider: {best[client][provider_name]}) ) print( * 70) def print_detail(details): 按用例输出明细。 print(\n用例明细) for item in details: print(f\n--- {item[client][display_name]} ---) for case in item[cases]: status 成功 if case[success] else 失败 print( f [{case[case_id]}] {status} | 得分 {case[score]} | f耗时 {case[elapsed_ms]}ms | Token {case[total_tokens]} ) if case[output_preview]: preview case[output_preview].replace(\n, ) print(f 预览: {preview}...) def main(): config_path config.json test_cases_path test_cases.json show_detail --detail in sys.argv try: config load_config(config_path) test_cases load_test_cases(test_cases_path) except FileNotFoundError as e: print(f找不到配置文件: {e}) sys.exit(1) except json.JSONDecodeError as e: print(fJSON 解析失败: {e}) sys.exit(1) clients build_clients(config) if not clients: print(配置中没有可用模型请检查 config.json。) sys.exit(1) print(f共发现 {len(clients)} 个候选模型测试样例 {len(test_cases)} 条。\n) details, summaries run_evaluation(clients, test_cases) print_summary(summaries) if show_detail: print_detail(details) if __name__ __main__: main()5.4 在 VS Code 中配置任务为了让评测脚本在编辑器里一键运行我在.vscode/tasks.json中配置了一条任务{ version: 2.0.0, tasks: [ { label: eval: 跑模型评测, type: shell, command: python, args: [ eval_runner.py, --detail ], options: { cwd: ${workspaceFolder}, env: { PYTHONIOENCODING: utf-8 } }, presentation: { reveal: always, panel: shared }, group: { kind: build, isDefault: true } } ] }这样配置后在 VS Code 里按Ctrl Shift B就可以直接运行评测任务所有输出会显示在集成终端中。如果你的脚本不在工作区根目录需要修改cwd。6. 运行与验证6.1 准备 API Key在运行前你需要把 API Key 放到环境变量中。假设你在config.json中配置了MODEL_API_KEY_A那么在终端里执行export MODEL_API_KEY_A你的密钥Windows PowerShell 下使用$env:MODEL_API_KEY_A你的密钥如果使用本地方案可以不设置 API Key。6.2 运行评测在终端中执行python eval_runner.py --detail预期输出大致如下共发现 3 个候选模型测试样例 3 条。 模型评测汇总按综合分降序 排名 模型 综合分 平均耗时(ms) 成功数 总Token ---------------------------------------------------------------------- 1 A-快速模型 95.20 842 3/3 1520 2 本地模型 88.50 1260 3/3 1890 3 A-高质量模型 85.33 2870 3/3 2450 推荐模型: A-快速模型 (provider: 示例服务商A) 这里的关键是看三列综合分、平均耗时、成功数。如果某个模型出现 0/3 成功需要回到config.json检查接口地址、密钥和模型名称是否配置正确。6.3 把结果保存成报告如果你希望把评测结果保存到文件可以将脚本的输出重定向python eval_runner.py --detail report.txt也可以修改脚本把结果写成 JSON方便后续接入自动化和 CI 流程。这里不做扩展但接口设计已经预留了details和summaries两个数据结构直接序列化即可。7. 常见问题与排查思路在实际使用中有几个问题比较常见。我整理成表格方便你快速定位。问题现象常见原因解决思路所有模型都返回失败环境变量没有设置或设置错误检查 API Key 环境变量名是否与config.json中一致模型 A 成功模型 B 失败模型名称写错或服务商未开放该模型权限在服务商控制台确认模型 ID请求超时网络环境不稳定或模型响应太长调大chat方法的 timeout 参数减少max_tokensJSON 文件解析失败配置里多了逗号或注释用 VS Code 的 JSON 格式化功能检查中文标题输出乱码终端编码不是 UTF-8在tasks.json中设置PYTHONIOENCODINGutf-8评分出现 0.0关键词没有命中或请求失败查看--detail输出中的错误信息和预览排查建议按顺序进行先确认配置文件能否被读取。直接在终端运行python -c import json; print(json.load(open(config.json)))。再确认 API Key 是否可用。用 curl 或 Postman 单独测试一个接口。再确认单个模型调用是否成功。可以在eval_runner.py中临时只保留一个模型调试。最后才关注评分逻辑。8. 最佳实践与工程建议8.1 用环境变量管理密钥永远不要把你的 API 密钥写进config.json、代码仓库或博客示例中。推荐做法本地开发时使用.env文件通过python-dotenv加载。CI/CD 环境中使用流水线的变量管理功能。生产环境使用密钥管理服务。# 如果使用 python-dotenv from dotenv import load_dotenv load_dotenv()8.2 控制随机性模型输出本身带有随机性。评测时建议把temperature调到 0.2 以下并且每个用例跑多次取平均值这样得到的结论更稳定。如果某次结果特别异常可以先看是不是网络波动导致的超时。8.3 评测任务要与实际场景对齐“最佳模型”没有绝对标准只有相对场景。如果你的主要任务是写 SQL那么评测用例就应该以 SQL 优化、建表、索引设计为主如果你的主要任务是阅读代码仓库那么评测用例就应该包括代码解释和 Bug 定位。建议把测试用例按类别组织并在汇总结果里按类别分别统计。8.4 引入自动路由在评测脚本的基础上可以进一步做一个自动路由函数# 伪代码示意 def route_request(prompt, scoring_result): 根据评测得分选择最优模型。 best_model scoring_result[best_model] return model_clients[best_model].chat(prompt)在编辑器里你可以把路由函数包装成一个命令让 AI 助手调用。这样每次请求时模型选择不再是手工操作而是由评测结果自动决定。8.5 关注成本与命中率平衡在选择模型时不要只看性能和准确率还要考虑成本。一个质量稍差但便宜很多的模型可能更适合高并发场景。你可以给每个模型增加一个cost_per_1k_tokens配置在打分时把成本作为一个负向指标加权。8.6 安全边界与合规提醒在对接模型服务时要注意数据安全。不要把敏感业务数据、数据库连接串、用户隐私数据发送到不可信的第三方模型服务。建议在配置文件中明确标注某个 Provider 是否允许外部发送数据并增加脱敏逻辑。涉及生产环境变更时先在测试环境验证再决定是否引入新的模型供应商。9. 总结与后续方向本文从“编辑器里怎么实时挑模型”这个问题出发梳理了模型、Provider、Token、路由、评测等核心概念然后给出了一套可直接运行的 Python 评测方案。你可以在 VS Code 里一键运行评测脚本让多个候选模型在同一组测试用例下对比得分并自动获得当前场景的推荐模型。核心收获有四个模型评测不能只看响应速度要综合质量、耗时、Token 消耗和稳定性。配置驱动的方式让模型列表的增删变得简单不需要改动代码。VS Code 的 Task 机制可以把评测脚本集成到编辑器中形成一次按键出结果的工作流。评分规则不是固定的需要根据你的实际任务不断调整。接下来你可以继续做几件事扩展测试用例库覆盖代码生成、SQL 优化、文档总结、错误排查等场景。引入一个“裁判模型”对候选模型的答案进行质量打分替代简单的关键词命中。把评测脚本接入 CI在模型版本更新时自动跑一轮回归测试防止模型表现退化。在编辑器里写一个自定义命令把路由结果直接注入到当前编辑中的代码或文档里。如果你在配置过程中遇到报错建议回到第 7 节按顺序排查。挑选模型不是一锤子买卖保持测试、统计、更新配置的循环才能让编辑器里的 AI 一直处于“最佳状态”。希望这套方案对你的实际项目有所帮助。