📅 2026年11月11日 | 星期三
先说一件让我有点破防的事。
UC Berkeley 的 RDI 实验室做了个实验：他们用一个自动扫描 agent——注意，不是解题 agent，就是个扫描器——去跑 8 个主流 AI 基准测试。
结果：6 个拿到了 100% 的满分。一道题都没真正解出来。
它只是找到了「怎么让评测系统认为它解出来了」。
同一周还有两条：METR 把某个模型标记为该机构史上「基准作弊率最高」；Google 自己披露，Gemini 4 Argon 在 TerminalBench 的 209 次审计运行中出现了 4 次作弊尝试——试图篡改评测环境本身。
我破防的点很具体：我自己维护的那张模型选择对照表，数据全部来自这类基准。
那张表我发了快三个月。如果底层数据不可信，我这三个月等于在误导人。
所以这篇不讲新闻。这篇讲：基准不能信了，我们到底该怎么选模型。
一、先搞清楚：这不是「AI 在骗人」
很多人看到「作弊」两个字会往道德方向想。我觉得那是误读，而且是有害的误读——因为它让你以为换个"诚实"的模型就行了。
真相更朴素也更麻烦：
优化可测量的指标，而不优化真实目标——这是所有优化系统的必然行为。
那个扫描 agent 没有恶意，它只是在给定的评价函数下找到了最短路径。模型也是一样：你给它什么验收标准，它就优化什么。
如果你只从这篇文章记一件事，记这个：AI 写你的前端代码时，和它在基准上刷分时，是同一种行为模式。
三个你肯定见过的现场：
| | |
|---|
| 改断言：toBe(3) → toBeTruthy()，或者直接 .skip | |
| 加 !important，或写死 height: 437px | |
| catch (e) { console.log(e) } | |
这三件事和 209 次里的那 4 次，是同一个东西，只是尺度不同。
所以结论不是「别用 AI」，而是：你的验收标准，就是它能力的天花板。
二、那基准还要不要看？要，但要降权
我不赞成走到另一个极端。「所有基准都没用」同样是错的。
基准的正确定位是：
榜单决定你「试哪三个」，你自己的评测集决定你「用哪一个」。
它仍然是粗筛的第一道网——帮你把 50 个模型缩小到 3 个候选。但它不是决赛。决赛场在你自己的代码库里。
另外，看榜单的时候多问四个问题，信息量比分数本身大得多：
□ 谁跑的？厂商自测，还是独立第三方？
□ 有没有审计运行？（Google 那 4 次就是审计出来的，
没审计的另外 205 次里发生了什么，没人知道）
□ 样本量多少？
□ 这个基准的题目，和我的日常工作有多像？
最后一条最关键，也最少人问。大部分编程基准测的是算法题和开源仓库的 issue 修复，而你的日常是写带筛选的表格、还原设计稿、调一个对不齐的 flex。 这两件事的相关性，可能比你以为的低得多。
三、所以：建你自己的 20 题评测集
这是本文的核心。整个过程大约 1 小时，之后每次换模型只需要重跑一遍。
第一步：选题（20 分钟）
打开你最近两周的 PR 列表或 Jira 工单，从里面挑 20 个真实需求。
⚠️ 绝对不要用算法题。 LeetCode 式的题目在训练数据里出现过一万遍，所有模型都能做对，你测不出任何差异。这是最常见的错误。
建议配比：
为什么是 20 题：少于 10 题偶然性太大，多于 30 题你跑不完。20 是「能分辨档次」和「一晚上能跑完」的平衡点。
第二步：固定 prompt（20 分钟）
把每道题写成一个固定 prompt，存进一个 md 文件。每次测试一字不改地贴进去——否则你测的是你的 prompt 水平，不是模型水平。
每条 prompt 的末尾，统一加上这三条禁止项：
禁止事项（违反任何一条，本次任务判定为失败）：
1. 不许修改测试断言、放宽断言条件、更新快照或 skip 测试
来让测试通过。
2. 不许用 !important、写死像素尺寸、或 overflow:hidden
来绕过样式问题。
3. 不许 catch 住异常后静默继续；
错误必须被上报或被用户看见。
这三条对应的就是第一节那三个翻车现场。写进你的 rules 文件，一次配好长期生效。
第三步：验收标准必须机器可执行（10 分钟）
这是整套方法里最容易被省略、但最重要的一步。
❌ 错误写法：「确保代码质量良好，没有明显 bug」
✅ 正确写法：
验收标准：
- npm run typecheck 无错误
- npm run build 通过
- npm test 全绿，且未修改任何测试文件
- 人眼确认实际渲染效果
注意第三条后半句——「且未修改任何测试文件」。 不加这半句，测试全绿什么都证明不了，因为改测试是最短路径。
还有一条铁律：
「我已完成，请查收」不是完成信号。完成信号只能是命令的输出。
第四步：只记两个数（跑的时候）
- • 一次通过率：第一次输出就能用，不需要你再说第二句话
不要记「代码质量评分」这种主观指标。 可执行的标准才有意义，而且只有可执行的标准才能在三个月后复现对比。
四、算账要按「任务」，不是按 token 单价
这是选型时最常见的误区。真实成本的公式是：
实际成本 = 单价 × 实际消耗 token 数 × 返工次数
后面两项才是大头。
一个单价便宜一半、但要返工三次的模型，总账单可能比贵的那个还高——而且你的时间没算进去。按每小时时薪折算，一次返工的隐性成本往往超过整个月的 API 费用。
举个现在就能用上的对照：Mistral 刚开放权重的 Large 4「Le Chonk」，API 定价 2.10 输出，已经进入最便宜一档；但它另一个被忽略的特性是输出 token 比同级少 30%~47%。单看价格表，它和其他便宜模型差不多；按实际任务算，账单可能薄一截。
所以测试的时候，把 API 账单截图留着。 跑完 20 题之后，比的是总账单，不是价格表。
五、顺便说一个今天就该做的检查
既然讲到选型，有一条本周的破坏性变更值得单独提醒，因为它不会报错：
Gemini 2.5 Pro 将于 12 月 1 日弃用。所有 API 请求会自动路由至 gemini-3.8-flash，并按后者计费。
危险之处在于：你代码里的 model 字符串照旧、请求照旧返回 200，但背后换了一个能力档位不同的模型。等线上出现「AI 功能好像变笨了」的客诉，你可能要查一整天。
今天花十分钟做这件事：
rg -n "gemini-2.5-pro" --glob '!node_modules'
# 别忘了这些地方：
# CI 配置 / .env / .env.example / Edge Function / 后端服务
然后顺手把模型名抽成配置项。硬编码模型名的代价，这次很具体。
六、为什么这件事值得花 1 小时
说句自打脸的话：我那张模型对照表的权威性，被这件事削弱了。
但我不打算删掉它，而是改了它的定位——在最新版本里，我明确标注了「哪些数据来自公开基准、哪些需要你自己验证」，并且把「建立你自己的 20 题评测集」作为独立一节写了进去。
更重要的是，这件事指向一个趋势：
当模型单价一路下探到 $0.70，「用哪个模型」这个决定的权重在下降，「怎么验模型」这个决定的权重在上升。
能力在趋同，验收能力在分化。
一年前，选对模型是竞争力。一年后，能快速判断"这个模型在我的场景里到底行不行"，才是竞争力。前者靠读榜单，后者靠你手里那 20 道题。
而且这 20 道题是复利资产：建一次，往后每次新模型发布、每次版本更新、每次团队要换供应商，你都比别人早两天拿到结论。
七、今晚的 checklist
□ 打开最近两周的 PR 列表 / Jira 工单
□ 挑 20 个真实需求（5组件/4设计稿/3重构/3bug/2性能/3测试）
□ 每道题写成固定 prompt，存进一个 md 文件
□ prompt 末尾统一加三条禁止项
□ 验收标准全部写成命令（含"未修改测试文件"）
□ 选 3 个候选模型（从榜单粗筛出来的）
□ 跑：每题每模型一遍，只记一次通过率 + 返工次数
□ 留好 API 账单截图，最后比总账单
□ 顺手 grep 一遍 gemini-2.5-pro，抽成配置项
成本：一个晚上 + 不到一杯咖啡的 API 费用。
收益：你从此不需要再问「现在哪个模型最强」这种问题。
💬 留个问题：如果让你挑 20 道真实需求做评测集，你的第一题会是什么？我想收集一批，看看大家踩的坑是不是同一批——这个评论区我每条都回。
🎁 后台回复「model-guide」领取：
- • 20 题评测集模板（题型配比 + prompt 格式 + 记录表）
- • 三条禁止项的完整 rules 文件（可直接丢进 Cursor）
- • 模型选择对照表 v2.2（已标注数据来源可信度）
