用可复现基准筛选AI编程模型

大多数针对 AI 编码模型的比较都只是轶事。有人粘贴一条 prompt，凭感觉扫一眼输出，然后写下结论。这几乎说明不了任何问题，因为同一个模型可能在从零开始编写的小片段上表现惊艳，却在你的实际代码库中彻底失灵。

更好的做法是：在把任何模型接入日常工作流之前——更不用说授予它仓库写入权限了——先用一组规模小、内容固定且能够自动检查的任务来测试它。本文将介绍一个可以直接复制、运行和扩展的测试框架。它刻意设计得平淡无奇，而这种“无聊”恰恰是结果可重复的关键。

测试框架的作用

整个思路由三部分组成：

• 固定的任务文件——包含少量 prompt，每条 prompt 都有机器可检查的成功条件，也就是测试命令，而不是凭感觉判断。

• runner 脚本——将每项任务发送给模型，把生成的代码写入临时目录，运行检查，并记录通过/失败状态和延迟。

• 决策表——让比较结果真正服务于选型，而不是沦为博客文章里的主观意见。

所有内容都在临时目录中运行，无法通过网络访问你的真实项目。最后这一点非常重要：模型评估绝不能与任何你在意的代码共享工作目录。

# tasks.yaml
tasks:
  - id: fizzbuzz-edge
    prompt: >
      Write a Python function classify(n) that returns 'fizzbuzz' for
      multiples of 15, 'fizz' for multiples of 3, 'buzz' for multiples
      of 5, and the number as a string otherwise. Handle 0 and negatives.
    check: python test_fizzbuzz_edge.py
  - id: json-repair
    prompt: >
      Write a Python function repair_json(s) that accepts JSON with
      trailing commas and returns a parsed dict, raising ValueError on
      anything still invalid.
    check: python test_json_repair.py

每项检查都是一个简短的 pytest 文件，并且要在看到任何模型输出之前写好。先写测试正是整个方法的关键——它能防止你因为偏爱某个模型，而不知不觉地为它降低标准。

下面的实现刻意保持最小化——只需将 call_model stub 替换成你实际使用的客户端即可：

# runner.py — pseudocode-level skeleton, adapt the client call
import subprocess, time, json, yaml, pathlib

def call_model(prompt: str) -> str:
    """Replace with your model client. Return the generated code text."""
    raise NotImplementedError

def run_task(task, workdir: pathlib.Path) -> dict:
    code = call_model(task["prompt"])
    (workdir / "solution.py").write_text(code)
    start = time.time()
    result = subprocess.run(
        task["check"].split(), cwd=workdir,
        capture_output=True, text=True, timeout=60,
    )
    return {
        "id": task["id"],
        "passed": result.returncode == 0,
        "latency_s": round(time.time() - start, 2),
        "stderr_tail": result.stderr[-500:] if result.returncode else "",
    }

def main():
    tasks = yaml.safe_load(open("tasks.yaml"))["tasks"]
    workdir = pathlib.Path("./scratch")
    workdir.mkdir(exist_ok=True)
    results = [run_task(t, workdir) for t in tasks]
    print(json.dumps(results, indent=2))

if __name__ == "__main__":
    main()

对每个模型完整运行三次全部任务，重点观察一致性，而不只是最佳表现。一个模型在同一项任务上通过两次、失败一次，与连续三次全部通过的模型是两种不同的工具，即使它们单次表现最好的输出看起来完全相同。

将输出转化为决策

最后这一项正是免费访问层真正改变成本计算的地方。当失败的运行不产生费用时，你就能采用更大的任务集并增加重复次数，而这恰恰是让比较结果值得信赖的关键。我正是在这样的背景下关注 MonkeyCode：它提供免费的模型访问，并且可以选择在免费服务器上运行，这意味着上面的 runner 可以持续执行任务，而不必为每次重试都承担计费压力。

披露：本文是 MonkeyCode 产品推广工作的一部分。

具体来说，工作流是这样的：让 call_model 指向你想评估的模型，为所有模型始终使用相同的 tasks.yaml 和相同的预先编写检查，并分别记录每个模型的 JSON 输出。由于任务和检查始终不变，结果上的任何差异都可以归因于模型本身，而不是因为你某天写 prompt 时状态好或不好。免费服务器选项还有一个不那么明显却同样重要的作用：它能消除为了省钱而缩减任务集的诱惑，而大多数自制 benchmark 正是在这里悄无声息地失去价值。

局限性——请务必阅读这一部分

这套方法衡量的是玩具级任务，而不是你的代码库。一个能完美完成 repair_json 的模型，仍然可能把一个 4,000 行的遗留模块改得一团糟。请把这套测试框架视为一种过滤器，用于淘汰明显不合适的模型，而不要把它当作模型胜任实际工作的证明。下一步应该使用同一套测试框架，测试从你自己的代码中提取出来的三个真实函数。

三次运行只是下限，而不是上限。采样过程中的非确定性意味着小样本可能产生误导。如果两个模型的结果非常接近，应增加重复次数后再下结论。

免费层会发生变化。任何免费访问方式——包括 MonkeyCode 提供的免费访问——都可能存在额度限制、排队等待，或者随时间调整的使用条款。设计测试框架时，应确保更换客户端只需要修改五行代码；在 CI 中依赖某项服务之前，也要重新核实现行条款。

不要在没有 sandbox 的环境中运行生成的代码。上面的临时目录只是一种便利措施，并不是安全边界。如果你要执行尚未人工审阅的模型输出，请在没有挂载任何凭据的容器或 VM 中运行。近期关于 AI Agent 边界失效的讨论如此热门，并非没有原因。

如果你只用 AI 助手回答一次性问题，从不在任何地方运行它的输出，那么这样的测试框架确实有些过度——直接使用工具即可。同样，如果你的团队已经拥有 eval 流水线，那就继续使用现有方案；这里的价值主要面向那些目前没有可重复比较方法、仍然凭感觉选择模型的个人和小团队。如果后一种描述符合你的情况，就从自己一周的实际工作中挑选五项任务，先写好检查，然后真正跑起来——MonkeyCode 免费层是一个上手门槛较低的起点，但这套测试框架适用于任何能够接入 call_model 的客户端。

真正有价值的是这套可复用的产物：一旦 runner 建立起来，今后每次评估新模型都只需要花一个下午，而不再是一场信仰之跃。

如需采取进一步措施，你可以考虑屏蔽此人和/或举报滥用行为。