教程目标

本教程帮助读者完成一件事：不依赖营销宣传和单一排行榜，用团队的真实编程任务对比多个国内编程大模型及其不同版本，得出可复现的选型结论，并把结论接入日常开发流程。

完成后，你将得到一份评测集、一套统一的调用与评分流程、一张版本对比表，以及一个带降级策略的接入方案。

适用读者

• 开发者：需要选择代码补全、代码审查或代码生成工具的人。
• 技术负责人：需要为团队确定模型和版本，并能说明选择依据的人。
• 运维与平台人员：负责模型接入、配额、监控和成本控制的人。
• 企业用户：需要在数据合规、性能和成本之间做权衡的采购或安全相关人员。

适用场景

1. 新版本模型发布后，判断是否值得升级。
2. 团队在代码补全、缺陷修复、测试生成、代码解释、重构迁移等任务上做选型。
3. 需要按任务难度做成本分层，例如复杂重构用旗舰档，简单补全用轻量档。
4. 对代码不出域、私有化部署有要求的场景。

前置准备

1. 候选模型清单：选定 2 到 3 个候选模型。逐一从各厂商官方文档记录版本号、上下文长度、计费方式、限流规则和可用地域。不要依赖二手转述，因为模型版本和价格可能随时变化。
2. 访问凭证：为每个模型申请独立的测试密钥，存放在环境变量或密钥管理服务中，不要写入代码仓库或日志。
3. 评测数据：从团队近期的真实代码仓库中抽取任务样本。提交前去除密钥、个人信息和未公开的业务细节。
4. 运行环境：一台能访问模型服务端点的机器，安装版本管理工具、脚本运行环境和团队常用的单元测试框架。
5. 基础知识：熟悉 HTTP 请求、JSON 数据格式、单元测试和代码审查流程。

第一步：明确评测目标与任务范围

做什么：列出团队最常见的 4 到 6 类编程任务，例如函数实现、缺陷修复、测试用例生成、代码解释、重构。为每类任务设定权重，权重依据团队在该类任务上的实际工时占比估算。

为什么做：没有明确的任务范围，评测结果就无法回答“对我们有没有用”。通用问答式的测试只能反映模型的一般能力，不能反映它在团队代码库里的表现。

注意什么：任务类别要来自实际工作记录或团队访谈，不要只凭印象设定。权重之和应为 1，便于后续加权汇总。

第二步：构建评测集

做什么：每类任务准备一批样本，建议每类 20 到 50 条。每条样本包含四部分：输入上下文、约束条件、可自动执行的验收测试、权重。

为什么做：可自动判断的验收标准能去掉人工主观打分带来的偏差，也便于反复运行和比较历史结果。

示例结构：

task = {
  "id": "bugfix-017",
  "category": "bug_fix",
  "prompt_context": "相关代码片段 + 问题描述 + 复现步骤",
  "constraints": ["不修改公共接口", "保持原有日志格式"],
  "acceptance_tests": ["test_empty_input", "test_timeout_retry"],
  "weight": 0.2
}

注意什么：

• 样本上下文不要超过候选模型的上下文上限，否则结果会因截断而失真。
• 约束条件要具体，例如“不修改公共接口”比“写得好一点”更容易验证。
• 每个样本都要有对应的测试用例，没有测试的样本只能用于人工抽检，不纳入自动统计。

第三步：统一调用参数与测试环境

做什么：所有模型使用同一套系统提示词、采样参数、最大输出长度、上下文截断策略、超时时间和重试次数。

为什么做：如果各模型的参数不一致，调参差异会被误判为模型能力差异。例如一个模型使用了更高的随机性设置，它在测试中的失败率可能被放大。

示例伪代码：

config = load_eval_config()   # 统一读取配置，包括 temperature、max_tokens、timeout
for model in candidate_models:
    for task in eval_set:
        request = build_request(
            model = model.endpoint_name,
            system_prompt = SHARED_SYSTEM_PROMPT,
            user_content = task.prompt_context,
            temperature = config.temperature,
            max_tokens = config.max_tokens,
        )
        response = call_with_retry(request, timeout = config.timeout, retries = 2)
        save_result(model, task, response)

注意什么：

• 代码类任务通常使用较低的随机性设置，具体数值以各模型官方文档的建议为准。
• 同一任务建议运行 3 次左右取平均或取中位数，因为生成结果有随机性。
• 记录每次运行的时间、模型版本标识和服务端返回的元信息，便于之后复现。

第四步：定义评分维度与加权汇总

做什么：从以下维度给每次生成结果打分，并归一化到 0 到 1 区间。

维度	说明	评分方式
正确性	通过验收测试的比例	自动化测试
指令遵循	是否满足全部约束条件	检查清单
改动范围	是否只修改必要的代码	统计变更文件数与行数
可读性	命名、结构、注释是否符合团队规范	静态检查加人工抽检
响应时间	端到端延迟，取中位数和 P90	计时
单次成本	按官方价格表估算输入与输出费用	计算

加权汇总公式：

总分 = Σ (任务类别权重 × Σ(维度权重 × 归一化得分))

为什么做：单一的正确率无法反映“改得太多”或“输出格式错误”这类问题。多维度评分能更接近工程师的真实感受。

注意什么：

• 正确性的权重最好最高，否则模型可能因为输出漂亮而被高估。
• 延迟和成本是硬约束。如果团队的交互式补全对延迟敏感，可以设定延迟上限，超过则直接淘汰。
• 人工抽检建议覆盖每个模型约 10% 的样本，用于校准自动化评分是否偏离实际判断。

第五步：版本对比的做法

做什么：区分两类对比。

• 纵向对比：同一模型家族的旧版本与新版本在同一评测集上比较，重点看是否有能力回退。
• 横向对比：不同模型在同一档位下比较，例如旗舰档对旗舰档，轻量档对轻量档。

为什么做：轻量档模型通常延迟更低、成本更低，但能力上限也不同。把不同档位放在一起比较，容易把档位差异误读为模型优劣。

版本对比记录模板：

| 模型 | 版本标识 | 档位 | 正确性 | 延迟中位数 | 单次成本 | 评测日期 | 备注 |

注意什么：

• 版本号和发布说明只能作为参考，最终结论以实测为准。
• 记录评测日期。模型服务可能在无公告的情况下更新，过时的结果需要重新运行。
• 如果新版本在某类任务上出现回退，应单独记录，不要因为总分提高就忽略它