怎么判断一个新模型到底行不行：从榜单跑分到长程实测的完整评估方法论（2026 实操版）

本文由 辛梓煜@词元2号站（www.ciyuanerhao.com）撰写，转载请注明出处。

快速摘要

判断一个新模型行不行，最不该看的就是官方榜单和社交平台上那些一句话生成网页的截图。2026 年真正有区分度的测法只有一种思路：给模型一个开放、没有标准答案的目标，配一个明确的预算（token 或钱），让它连续工作几十分钟到几小时，然后同时记录三件事——它把任务推进到了什么程度、需要你插手几次、它有没有能力自己发现自己搞坏了什么。今年最有代表性的一次公开实验，是把《指环王》开篇一段文字丢给 Opus 5，给约 100 万 token 预算（成本大约 10 美元），要求用 Three.js 把这段文字变成能在浏览器里跑的三维场景。模型连续干了将近两个小时，写出约 5500 行代码，场景能跑但相当粗糙。真正的信息量不在画面，而在它暴露的短板：模型能造出一个世界，却没办法进去逛一圈验收自己的活，只能靠在不同时间点慢慢截图来猜哪里出了问题。

这就是当前这一代模型最要紧的一条能力落差：生成能力已经跑到了前面，自我验证能力还留在后面。 顺着这条落差往下推，你会发现今年一大批评测审计论文说的其实是同一件事——榜单上那点差距，很可能根本没被测出来。

下面这篇长文我会一层层拆开讲：一次性 Demo 测试到底哪里失效了；这次长程实验的参数、难点和它同时压测的六种能力；为什么"验证"会成为整个智能体工程的瓶颈；2026 年的评测审计浪潮给出了哪些具体数字；以及最重要的部分——我自己在用的一套七步模型验收流程、四种可以落地的确定性观察回路，还有国内环境下怎么选型、怎么控成本、怎么把评测集攥在自己手里。想看完整拆解，往下翻。

一、先说结论：为什么"看 Demo"这条路已经走到头了

现在这个行业的节奏，差不多每隔一两个月就要出现一个"史上最强"。榜单刷新，编程能力涨几个百分点，推理成绩号称超过多少人类专家。紧接着社交平台上开始刷屏：一句话生成一个落地页、三十秒复刻某款热门产品的界面、几分钟做一个能玩的小游戏、随手来一段 SVG 动画。

我自己是每次都点开看的。看完的感受也很一致：炫，但看完之后我依然回答不出那个最朴素的问题——这个新模型，到底比上一个强在哪儿？

原因不复杂。当主流模型全都能生成一张像样的网页时，"能生成一张像样的网页"这件事本身就不再是区分项了。它变成了及格线，而及格线不能用来排名。

更麻烦的是，这类演示的展示形式天然屏蔽了最关键的信息。你看到的是最终那一张截图、那一段流畅的录屏，你看不到的是：测试者试了几次？中间改了多少轮提示词？模型第一版是不是完全跑不起来？有没有人工手动补了几十行代码？这些过程一旦被剪掉，一个原本用来判断能力的测试就悄悄变成了一次产品营销。

所以我的结论放在最前面：2026 年评估模型，评估对象必须从"一次生成的产物"换成"一段有预算约束的工作过程"。

这句话拆开是三层意思。

第一层，任务要够长。短任务测不出长任务的问题。一个模型写 200 行代码不出错，完全不代表它写到第 3000 行时还记得第 400 行定义过什么。上下文越长，早期决策的遗忘、前后逻辑的自相矛盾、新代码破坏旧功能这些问题才会浮上来。

第二层，任务要够开放。有标准答案的题目，模型有机会靠"见过类似的"蒙过去。没有标准答案的目标，模型必须自己做规划、自己排优先级、自己决定什么算完成——这才是真实工作里最耗人的那部分。

第三层，必须记录成本和干预次数。同一个任务，A 模型花 3 美元、需要你纠正 2 次就做完了，B 模型花 12 美元、你插手 9 次才勉强跑通，这两者的差距远比榜单上那 1.5 个百分点更有意义。我现在验收任何一个新模型，成本和干预次数是必填项，不填等于没测。

辛梓煜@词元二号站在这里插一句实话：这三层要求执行起来是有成本的，一次严肃的长程实测可能要占掉你半天时间加十几美元额度。但跟"选错模型、接进生产、三周后才发现它在长任务上不可靠"相比，这笔前置投入实在便宜得离谱。

二、鹈鹕骑车的黄昏：一次性生成测试的三个结构性缺陷

在讲那次长程实验之前，得先说清楚它想取代的是什么。

过去两年，圈内流行一个非常朴素的"手感测试"：让模型生成一张"鹈鹕骑自行车"的 SVG 矢量图。这个测试最早是 2024 年 10 月被提出来的，出发点其实是个玩笑——自行车结构难画，鹈鹕体型难画，两个凑一起在训练数据里几乎不可能有现成范例，所以模型不能靠背答案过关。

结果它意外地好用。一个模型画鹈鹕骑车的水平，跟它的综合能力居然呈正相关。这个梗后来传播得非常广，一度被各家厂商的发布会和研究论文引用过。到 2026 年 4 月还出现过很有意思的对照：有人拿本地跑的一个二十来 GB 的开源量化模型和某个云端闭源旗舰同时画鹈鹕，本地小模型画出来的车架结构反而更正确。

我先说这个测试的价值，它确实有价值：便宜、快、抗污染。一分钱不花，三十秒出结果，而且因为组合足够生僻，模型很难提前"背题"。作为快速体检，它到今天依然合格。

但它测不出 2026 年真正要紧的东西。缺陷有三个，我按严重程度排。

2.1 缺陷一：单次生成 = 只测一个瞬间

一次性生成测的是"模型在一次输出里能做到多好"。这是一个瞬时切片。

而真实工作是连续的。你让模型改一个线上系统的模块，它要先读懂现有代码、判断改哪里、动手改、跑测试、看报错、回头修自己刚引入的 bug——这个循环可能要转几十轮。单次生成里完全没有这个循环，所以它对"模型在第 30 轮循环时还清不清醒"这件事零信息量。

我自己踩过的坑就是这个。有个模型单轮表现漂亮，接进一个多步骤的数据清洗流程后，前五步完美，第六步开始悄悄改变了字段命名规则，后面全崩，而它自己一路都很自信。

2.2 缺陷二：前端任务的模式高度同质

这一点是我在看了几十个建站演示之后才慢慢意识到的。

渐变背景、玻璃拟态（一种半透明磨砂质感的界面风格）、三栏卡片、滚动淡入动画——这几样东西几乎成了 AI 建站演示的固定视觉语汇。你很难说这是模型"理解"了设计，更像是它从训练数据里高频出现的网页范式中抽出了一个"看起来不会错"的标准答案，再被流行组件库和默认提示词进一步强化。

换句话说，模型生成的是一个安全解，不是一个对的解。你要一个面向老年用户的挂号页面，它照样给你上玻璃拟态加渐变，字号还偏小。这种时候截图很好看，但需求根本没被满足。

用一张表把两类测试的覆盖面摆清楚：

结论很清楚：这两类测试不是替代关系，是筛选层和决策层的关系。手感题用来快速判断"值不值得深入试"，长程实测用来决定"敢不敢用"。

2.3 缺陷三：只展示成功案例

第三个缺陷最隐蔽，因为它不在模型身上，在人身上。

社交平台上流传的演示，是筛选后的结果。没人会发第七次尝试才成功的那次尝试记录。于是所有观众看到的都是各家模型的最优表现包络线，而不是它们的期望表现。这在统计上叫什么，我就不用术语了——说白了就是你在拿别人的最好成绩跟自己的平均需求做匹配，必然失望。

一个好的评测有个反直觉的标准：它必须能暴露失败边界。只能带来惊叹、不能告诉你"它会在哪儿掉链子"的测试，本质上更接近广告。这一点是判断任何评测（包括我这篇文章里推荐的方法）值不值得信的第一道筛子。

三、拆解这次实验：一段小说文字 + 100 万 token 预算 + Three.js

现在进入正题。2026 年 8 月 2 日，Andrej Karpathy 在海外社交平台上发了一条帖子，公布了一次挺有意思的实验。他现在的身份是 Anthropic 预训练团队成员，此前是 OpenAI 创始成员之一，也做过特斯拉的 AI 负责人——这个背景之所以值得提一句，是因为他既懂模型内部，也懂工程落地，出的题一般不会是外行题。

实验设置极其简洁，一句话就能说完：

把《指环王》开篇的第一段文字交给 Opus 5，给约 100 万 token 的预算（他自己估算成本大约 10 美元），只提一个要求——用 Three.js 把这段文字渲染成一个能在浏览器里观看和交互的三维场景。

然后他就不管了。模型自己跑了将近两个小时，最终产出约 5500 行代码，用程序化生成的方式长出了一个能跑的中土世界。他自己的评价是有点粗糙但挺好玩，同时明确承认成品里留下了不少错位、穿模和不自然的细节。

先把关键参数列清楚，这些数字后面反复要用：

3.1 为什么这道题比"写一个网页"难一个量级

很多人第一反应是：不就是写个 Three.js 页面吗，模型早就会了。

真正的难点不在 Three.js 的 API 上。难点在于，输入是文学语言，输出是三维坐标，中间那段转换没有任何人替它做。

一段小说描写里有什么？有环境（丘陵、洞屋、小径）、有对象（人物、门、树）、有氛围（时间、光线）、有隐含的空间关系（谁在谁旁边、路通向哪里）。这些东西在文字里是模糊的、可意会的。但代码不接受模糊。模型必须给每一个物体一个确定的 (x, y, z)，必须决定镜头从哪个角度切进来、什么时候平移、角色以什么速度沿什么路径移动、故事按什么顺序演出。

人类三维设计师是怎么做这件事的？打开建模软件，用鼠标把形状拉出来，眼睛实时看着结果调。模型没有这个界面，它只能写代码：算出每一块多边形素材该落在哪个坐标、彼此的相对关系是什么，再写出让它们动起来的动画逻辑。

它是闭着眼睛在摆积木。 这个类比不夸张——它写下 position.set(12.4, 0, -30.7) 的那一刻，是没有办法立刻看到这块石头到底落在哪儿的。

3.2 程序化生成是什么：一句白话加一段代码

前面提到"程序化生成"，术语第一次出现我解释一下：它指的不是逐个手工摆放物体，而是写一套规则，让程序自己长出场景。地形用噪声函数生成起伏，树木用随机分布加规则约束批量种，房屋用参数化模板复制变形。

为什么必须走这条路？因为手工摆放的信息量太大了。一片有几百棵树的丘陵，逐个写坐标要写几千行还容易写乱；写成规则只要几十行。

拿一段简化到极致的示意代码就能看明白差别：

// 做法 A：逐个手工摆放（信息量爆炸，且极难自查）
scene.add(makeTree(12.4, 0, -30.7));
scene.add(makeTree(15.1, 0, -28.2));
scene.add(makeTree(9.8,  0, -33.5));
// ……再写 397 行

// 做法 B：程序化生成（写规则，让程序自己长）
function scatterTrees(count, area, seed) {
  const rand = makeSeededRandom(seed);      // 固定种子，保证可复现
  const trees = [];
  for (let i = 0; i < count; i++) {
    const x = (rand() - 0.5) * area;
    const z = (rand() - 0.5) * area;
    const h = terrainHeightAt(x, z);        // 贴合地形高度
    if (h < WATER_LEVEL) continue;          // 水里不种树
    if (nearPath(x, z, 2.5)) continue;      // 小径两侧留空
    trees.push(makeTree(x, h, z, 0.8 + rand() * 0.6));
  }
  return trees;
}
scene.add(...scatterTrees(400, 120, 20260802));

注意做法 B 里那几行 continue。它们才是这道题真正考的东西——约束的表达。水里不能长树、路上不能挡道、房子不能陷进地面，这些常识在小说原文里一个字都没写，模型得自己补上。补不全就会出现穿模和错位，而这次实验的成品里确实出现了。

3.3 这次实验最值得记住的一句话

Karpathy 自己最惊讶的点不是画面质量，是模型居然能把这个项目整体运行起来。他还提了一个我认为今年最值钱的判断：

模型有全世界最好的耐心，所以一件事的性质会发生变化——从"没人会花时间去做"变成"做了也没什么损失，反正几乎等于免费"。

这句话值得单独拎出来。现实中大量项目不是人类做不到，而是它太琐碎、太耗时间，投入产出算不过来。不会有人为了给一段小说做个可视化，专门花几天写几千行三维代码。但模型的耐心是可以买的，而且很便宜。过去需要一个小团队排期几周才能做出来的高度定制内容，现在变成了一次十几美元、两小时的即时任务。

从评估角度看，这带来一个新的观察量：同样的预算，不同模型能把任务推进到什么程度。这个量比任何单一分数都更接近真实使用体验。

四、这套测法真正在测什么：六种能力被同时压测

传统跑分的做法是把能力拆成一道道相对独立的题目：数学一套、代码一套、常识一套。这么做的好处是干净，坏处是真实任务从来不是干净的。

Karpathy 这个实验的价值在于，它把多种能力塞进同一个项目里，让它们在互相牵制的状态下接受检验。我把被压测的能力拆成六项，逐条讲。

4.1 长程执行：两小时不是十分钟的十二倍

生成一个网页要几分钟，在一个项目上连续工作两小时是完全不同的挑战，难度不是线性叠加。

模型在这两小时里要同时维持三件事：记住早期做过的决定（地形高度函数是哪个、坐标系朝向怎么定的）、管理一个不断膨胀的上下文、避免新写的代码破坏已经跑通的部分。

第三条最容易出问题。我自己做长任务时最常见的失败模式就是"修好了 A，顺手弄坏了 B，而且没意识到"。因为模型每一步都在局部最优，它没有全局回归测试的概念，除非你给它。

4.2 复杂任务拆解：没人替它写规格说明

这次实验里，输入只有一段小说文字和一个最终目标，中间步骤全部空白。

模型必须自己决定：先建地形还是先建房子？镜头系统什么时候搭？动画在场景稳定之前做还是之后做？出了问题从哪一层往回改？

这是很多人低估的能力。日常用模型时我们习惯把任务切得很细再喂给它，切任务这个动作本身就替它完成了最难的规划部分。一旦不切，模型的规划水平立刻暴露。

4.3 跨领域协调：四种语言之间来回翻译

文字、三维空间、动画时间轴、程序逻辑——这四套表示体系互不相同，模型要在它们之间不断转换。

文字说"小径蜿蜒向前"，翻成空间是一条曲线的控制点；翻成动画是角色沿曲线的位移函数；翻成代码是一段插值逻辑。任何一环偏一点，最终结果就会显得别扭。而且这类偏差往往不报错，只是"看着不对"。

4.4 空间推理：这一项以前根本测不到

这是我认为这次实验最有技术含量的一层。

以前的评测里，空间推理基本只能靠几何题来间接测。这次是直接测：给你一个抽象描述，你把物体放到具体坐标上，放对没有肉眼可见。

而且这一项还有个特殊性——它没法靠语言流畅度掩盖。一段文字写得漂不漂亮见仁见智，一块石头有没有插进墙里是客观事实。

4.5 成本纪律：预算是新的评分维度

给定 100 万 token，怎么花？这本身是个决策问题。

花太多在前期探索上，后面没预算收尾；花太少在验证上，成品全是错位。一个成熟的模型应该表现出某种预算感——知道什么时候该停下来检查，什么时候该继续推进。

我现在做模型对比，会强制固定预算做横向对照：同样给 50 万 token，A 和 B 各能做到什么程度。这比"谁最终能做出来"更实用，因为生产环境里预算永远是有限的。

4.6 工作耐力：一个长期被忽视的指标

前面引过那句关于耐心的话，这里补一个从评估角度的解读。

耐力指的是在收益递减的阶段仍然保持工作质量的能力。项目做到第 90 分钟，剩下的都是琐碎的细节修正，没有任何"成就感"可言。人在这个阶段会开始糊弄，模型呢？有的模型会开始偷懒——生成占位注释、跳过检查、给出"这部分留作练习"式的输出。这是一个非常实际的观察点。

六项能力汇总成一张表，方便你直接拿去当评测表头用：

评价标准也要跟着换。以前我们问的是"它能不能做"，现在这个问题几乎没有信息量了，应该换成下面这五问：

1. 在固定预算内，它能把任务完成到什么程度？
2. 它需要多少次人工指导和纠正？
3. 项目规模扩大之后，它能否保持前后一致？
4. 工作时间拉长之后，它是否还记得最初的目标？
5. 它能不能发现并修复自己造成的问题？

这五个问题里，第五个最关键，也最容易被忽略——它问的不是模型会不会犯错，而是模型犯错之后有没有能力自己发现。

五、验证瓶颈：模型能造出一个世界，却不会验收自己的世界

这一章是全文我最想让你记住的部分。

这次实验主动暴露了一个短板：Opus 5 能生成三维世界，却很难有效验收自己的工作。

它没办法像人一样连续观看整段动画，也不能真正进入这个游戏世界，控制角色四处走动，检查场景有没有穿模、镜头是否合理、节奏是否自然。为了检查结果，它只能缓慢地在不同时间点截图，再根据静态画面推断代码要不要改。这个过程既低效，也极容易漏掉问题。成品里那些粗糙细节和错误，很大程度上就是这个限制的直接后果。

Karpathy 自己的总结相当直白：智能体目前还没有能力高效地、原生地感知视频，或者在自己造出来的世界里玩起来；原始的多模态自我审计仍然是明显缺失的能力之一。

用一句更工程化的说法：它写下了 5500 行代码，却不一定知道这 5500 行代码最终创造出了怎样的体验。

5.1 这不是画面问题，是能力结构问题

我一开始也以为这是个多模态能力的小缺口，后来越想越觉得不是。

把生成和验证放在一起看，会发现二者的性质完全不同。生成是发散的——只要产出一个看起来合理的方案就行，容错空间大。验证是收敛的——你必须遍历所有可能出问题的地方，任何一个漏掉都算失败。

对模型来说，发散恰好是它的强项，收敛恰好是它的弱项。它可以生产大量内容，却不一定知道这些内容是否真的好用。

这个落差在学术上有个说法叫生成—验证差距（生成能力与验证能力之间的能力差）。用一个记号写出来大概是这个意思：

[

\text{Gap}(f, g) = \mathbb{E}\big[, U(\text{best-of-}n \text{ selected by } g) - U(\text{single sample from } f) ,\big]

]

其中 (f) 是生成器，(g) 是验证器，(U) 是效用（可以理解成"这个结果有多好"）。当 (g) 和 (f) 是同一个模型时，这个差距就是自我改