对待每个新开源模型要像升级依赖：预检门控 checklist

模型发布日从表面看无害：一份更新日志、几张图表、一堆热点解读。但在产品团队内部，它更像是一次带有未知 breaking change 的依赖升级。模型 ID 变了，但你的解析器、重试逻辑、prompt 和下游任务还是原样。

所以真正有用的问题不是"这个新的开源模型强不强"，而是更窄、更贴近运维的角度：它还能不能满足我的系统已经依赖的契约？

不要从公开分数开始。从你的代码实际触达的接口开始。

值得测试的失败模式

大多数模型迁移失败，不是因为新模型不会推理。而是微小行为漂移演变成了事故：

• 一个 worker 期望严格的 JSON，现在收到的是包裹在 JSON 外层的散文；
• 一个分类器以前返回一个标签，现在编造出一个听起来更自信的变体；
• 一个摘要器保留了原意但丢掉了必需的前置元数据；
• 在你实际使用的 prompt 规模下延迟变得毛刺丛生，触发超时；
• 拒绝出现在旧模型会提问澄清的地方。

基准测试很少测量这些边界，因为它们是本地的、无聊的、特定于你技术栈的。但这些也恰恰是生产环境出问题的地方。

更好的循环：契约、行为、成本

不要用"试试模型看看"，而是按顺序跑三个关卡。

关卡 1 — 契约：输出可解析、必填字段存在、禁用文本不存在、长度在预算内。

关卡 2 — 行为：已知的棘手输入仍然路由到正确的操作、工具参数保持有效、不确定的情况保持不确定。

关卡 3 — 成本形态：在你的 prompt 分布上比较延迟和失败率，然后判断质量是否值得这笔运维代价。

只有三个关卡全部通过后，才值得讨论这个模型是否总体上令人印象深刻。

artifact：一个极简 Node 预飞检查运行器

这是一个可运行的 sketch，不是框架。Node 18+ 即可，因为它使用内置 fetch。把 BASE_URL 和 CANDIDATE_URL 指向两个兼容的聊天端点。

// preflight.mjs
import fs from 'node:fs/promises';

const BASE = process.env.BASE_URL;
const CANDIDATE = process.env.CANDIDATE_URL;
const MODEL = process.env.MODEL_ID || 'candidate-model-id';

const checks = {
  json: (s) => { try { JSON.parse(clean(s)); return true; } catch { return false; } },
  hasKey: (s, k) => { try { return Object.hasOwn(JSON.parse(clean(s)), k); } catch { return false; } },
  lacks: (s, bad) => !s.toLowerCase().includes(bad.toLowerCase()),
  underWords: (s, n) => s.trim().split(/\s+/).length <= Number(n),
  matches: (s, re) => new RegExp(re, 'i').test(s)
};

function clean(s) {
  return s.trim().replace(/^```
{% endraw %}
(?:json)?/i, '').replace(/
{% raw %}
```$/i, '').trim();
}

async function call(url, c) {
  const t0 = performance.now();
  const r = await fetch(url, {
    method: 'POST',
    headers: { 'content-type': 'application/json' },
    body: JSON.stringify({
      model: MODEL,
      temperature: 0,
      messages: [
        { role: 'system', content: c.system },
        { role: 'user', content: c.input }
      ]
    })
  });
  const ms = Math.round(performance.now() - t0);
  if (!r.ok) return { ok: false, ms, error: `HTTP ${r.status}` };
  const j = await r.json();
  return { ok: true, ms, text: j.choices?.[0]?.message?.content ?? '' };
}

function grade(c, out) {
  if (!out.ok) return { pass: false, ms: out.ms, failed: ['http'], error: out.error };
  const failed = c.expect
    .filter(([kind, arg]) => !checks[kind](out.text, arg))
    .map(([kind, arg]) => `${kind}:${arg}`);
  return { pass: failed.length === 0, ms: out.ms, failed };
}

const cases = (await fs.readFile('cases.jsonl', 'utf8'))
  .trim().split('\n').map(JSON.parse);

const rows = [];
for (const c of cases) {
  const base = grade(c, await call(BASE, c));
  const next = grade(c, await call(CANDIDATE, c));
  rows.push({ id: c.id, base, next, regression: base.pass && !next.pass });
}
console.table(rows.map(r => ({
  id: r.id,
  base: r.base.pass,
  next: r.next.pass,
  regression: r.regression,
  baseMs: r.base.ms,
  nextMs: r.next.ms,
  failed: r.next.failed.join('|')
})));

cases.jsonl 应该从真实流量中构建，去掉 secrets。每个 case 一行：

{"id":"sql-migration","system":"Return only JSON with keys risk, statement, rollback.","input":"ALTER TABLE accounts ADD COLUMN tier TEXT DEFAULT 'free';","expect":[["json"],["hasKey","risk"],["hasKey","rollback"],["lacks","as an ai"],["underWords",180]]}
{"id":"release-note","system":"Emit YAML front matter with title, date, breaking. Then one paragraph.","input":"Draft notes for dropping Node 16 support and adding retry jitter.","expect":[["matches","^---\\n[\\s\\S]*breaking:"],["lacks","certainly"],["underWords",220]]}

重要的设计选择与一个好的测试套件相同：确定性断言优先。判断模型可以在之后对两个都通过的答案排序，但不应该作为决定流水线是否安全的第一道关卡。

从事故中构建测试套件，而非想象

有用的 case 文件通常来自四个来源：

过往故障：每个糟糕的解析、奇怪的拒绝或格式错误的工具调用都成为一个永久 case。

对抗性用户：合法但令人困惑的 prompt、混合语言、超大尺寸、或满是本应被忽略的指令。

边界对象：空数组、Unicode 名称、超长 ID、边界附近的日期、注释看起来像命令的代码。

静默漂移探测：那些旧答案不是"正确的"、但足够稳定以至于变化应该被人审查的 case。

保持 case 丑。干净的演示 prompt 让人安心但大多没用。

把输出变成迁移决策

不要以竖拇指结束。要以路由决策结束。

注意遗漏的东西：炒作、社区共识和排行榜名次。这些可以是安排测试的理由，绝不是跳过测试的理由。

开源权重和免费基础设施适合在哪里

开源发布之所以重要，主要是因为外部人员可以检查行为，而不是信任一篇发布公告。但仅能下载并不足以让模型可审计；你仍然需要一些便宜的地方来运行重复对比。

披露：本文是 MonkeyCode 产品推广的一部分。如果账单设置是推迟评估的原因，MonkeyCode 的免费模型访问和免费服务器选项可以成为这种预飞循环的实用候选运行器，同时你确认当前条款并避免发送敏感数据。关键不是免费基础设施让模型更好；而是消除当新开源模型出现时跳过验证的一个常见借口。

限制以及谁应该跳过这些

这检查的是兼容性，不是安全性。Prompt 注入、数据泄露和工具边界滥用需要单独的对抗性测试工具。

确定性规则无法评估品味。设计批评、细致审查和开放式写作仍然需要抽样人工审查或明确标记的判断模型。

极小的测试套件会产生自信的废话。可以小步开始，但期望当生产教会你东西时文件会增长。

免费层和社区端点会变化。把可用性当作临时的，隔离凭证，如果合规重要的话保持一个本地 fallback 运行器。

如果你的模型使用只是一个人在浏览器里聊天，这就是过度工程。当输出喂给自动化时才值得：CI 机器人、Agent、队列、ETL、支持工具或代码生成。

持久优势不是预测哪个发布会赢。而是让每个发布都可以廉价检验：相同的 case、相同的关卡、相同的决策表、新的候选。当评估变成例行公事，模型发布就不再是紧急情况，而是开始看起来像它们本来的样子——必须证明自己才能进入的升级。