免费模型评测后再付费：AI 编程任务的评估工作流

我在团队聊天中经常看到这样一种模式：有人遇到了一个令人沮丧的 bug，把问题粘贴到他们能访问的最贵的模型里，得到了一个普普通通的答案，然后得出结论"AI 编程工具不好用"。问题通常不在模型本身。而是整个过程根本没有评估环节——没有基线任务、没有对比、没有弄清楚哪类问题才真正需要一个前沿模型。

这篇文章是一套解决这个问题的 workflow。核心理念：在把真正的工作交给付费推理之前，先从你的代码库里构建一个小型的个人基准测试，先在免费模型上跑一遍，只把那些在免费层确实失败的任务升级到付费模型。对于很多团队来说，这只是少数任务。

第一步：从你自己的仓库构建五个任务的基准测试

通用基准测试（HumanEval 风格）对你日常工作几乎毫无参考价值。代わりに，从你过去两周的工作中抽取五个任务：

一个你已经解决的真实 bug（你知道正确答案——这才是关键）。

一个在时间压力下完成的重构任务。

一个为有边界情况的函数编写测试的任务。

一个"解释这段代码"的任务，针对一个令人困惑的遗留模块。

一个acceptance criterion清晰的小功能。

把每个任务写成一个自包含的 prompt，并把相关代码粘贴进去。把它们放在一个文件夹里。这需要花费一个小时，但回报是立竿见影的。

第二步：先在免费模型上跑基准测试

披露：本文是作为 MonkeyCode 产品推广的一部分准备的。我在这里用它作为示例，因为它的免费模型访问和免费服务器选项直接映射到这个 workflow——你可以在无需Billing决策的情况下运行基准测试，并且把对比测试框架托管在免费服务器层上，而不是本地。这个 workflow 本身适用于任何提供免费模型访问的供应商；只需更换端点和 auth 配置，其他不变。

先跑免费模型的重点不是省钱表演。是测量卫生：如果一个免费模型解决了任务，你就不需要为那个任务类别付费。如果它失败了，你就有了一个具体的失败案例可以交给付费模型——这也让付费模型的输出更容易判断。

第三步：用评分表打分，而不是凭感觉

对每个任务，从三个维度打分，0-2 量表：

正确性（0 = 错误，1 = 思路对但代码有bug，2 = 可运行）

局部性（0 = 重写了无关代码，1 = 改动超出必要范围，2 = diff 最小）

解释质量（0 = 自信的胡说八道，1 = 含糊，2 = 你能学到东西）

一个免费模型在五个任务中得到 10-12/30 分仍然有用——在它得 2 分的那些任务上。那就是你的路由表。

产物：一个可复现的对比测试框架

下面是一个极简脚本（提案/伪代码级别——请根据你的供应商适配端点和认证），它把你的基准测试文件夹跑一个模型并记录结构化结果：

#!/usr/bin/env python3
"""Run a folder of task prompts against an LLM endpoint and log scores.
Usage: MODEL=<model-id> python bench.py ./tasks/
Fill in ENDPOINT and scoring after manual review of outputs.
"""
import json, os, sys, time
from pathlib import Path
import urllib.request

ENDPOINT = "https://your-provider.example/v1/chat/completions"  # replace
API_KEY = os.environ.get("PROVIDER_API_KEY", "")
MODEL = os.environ["MODEL"]

def run_task(prompt: str) -> str:
    body = json.dumps({
        "model": MODEL,
        "messages": [{"role": "user", "content": prompt}],
        "temperature": 0.2,  # keep it low; you want comparability, not creativity
    }).encode()
    req = urllib.request.Request(
        ENDPOINT, data=body,
        headers={"Content-Type": "application/json",
                 "Authorization": f"Bearer {API_KEY}"})
    with urllib.request.urlopen(req, timeout=120) as r:
        return json.loads(r.read())["choices"][0]["message"]["content"]

def main(task_dir: str):
    results = []
    for task_file in sorted(Path(task_dir).glob("*.md")):
        prompt = task_file.read_text()
        t0 = time.time()
        output = run_task(prompt)
        results.append({
            "task": task_file.name,
            "model": MODEL,
            "latency_s": round(time.time() - t0, 2),
            "output": output,
            "scores": {"correctness": None, "locality": None, "explanation": None},
        })
    out = f"results_{MODEL.replace('/', '_')}.json"
    Path(out).write_text(json.dumps(results, indent=2))
    print(f"wrote {out} — now review outputs and fill in scores")

if __name__ == "__main__":
    main(sys.argv[1] if len(sys.argv) > 1 else "./tasks")

值得注意的刻意选择：

temperature: 0.2——你在对比模型，所以要降低方差。如果想要一个粗糙的稳定性检查，每个任务跑两次。

分数由人工填写，不是自动评分。在这个阶段用另一个 LLM 自动评分代码任务只是把不确定性转移了一下。对于五个任务，人工审查需要二十分钟。

记录 latency 是因为一个慢但免费的模型会改变交互使用 vs 批量作业的考量。

把这个托管在免费服务器层（而不是本地）很重要，如果你希望团队成员能重新跑相同的基准测试，或者你想让它按计划运行以检测模型行为随时间的变化。

路由：决策表

跑过一次基准测试后，你可以构建一个这样的路由表（你的肯定不一样——这就是重点）：

在大多数版本的这个练习中，一个有趣的发现：那些让你觉得需要最好模型的任务（"这个 bug 很棘手"）和那些真正需要的任务（"修复需要跨四个文件推理"）之间的重叠比直觉想象的要少。

局限性和谁不应该这样做

五个任务是感觉检查，不是统计数据。把结果当作路由提示，而不是值得发表的基准测试。在用它做预算决策之前先扩大任务集。

免费层级会变化。任何免费提供的模型阵容、限制和可用性都会随时间变化。不要把模型名称硬编码到你的路由里；当阵容变化时重新跑基准测试。在依赖它之前，先验证供应商自身文档中当前可用的内容。

不要在未经安全政策负责人批准的情况下，把专有代码粘贴到任何第三方端点——免费的或付费的。使用合成的问题复现而不是真实 bug。

如果你的工作已经被一种任务类别主导，而你已知道它需要前沿推理（例如，大规模架构迁移规划），完全可以跳过这个。如果答案已知，基准测试的开销就不值得。

如果你无法对任务类别的模型输出进行competent审查，也完全跳过。基于无法验证的评分构建的路由表比没有路由表更糟糕。

使用昂贵模型的习惯不是工具问题，是缺少评估的问题。花一个小时构建基准测试，然后用免费层级来跑它，把"我应该用哪个模型？"这个反复争论的问题变成一张每月更新一次的表。如果你想找一个低摩擦的地方尝试这个，MonkeyCode 的免费模型访问和免费服务器选项覆盖了设置的两半——但这个 workflow 本身可以独立运作，无论你已经在用哪家供应商。

你的路由表长什么样？如果你也跑过类似的，我很好奇哪些任务类别让你意外。