怎么判断一个新模型到底行不行？Karpathy 用《指环王》做的实验，把 2026 年的评测方法论讲透了

本文由 莫潇羽@复源AI社区（bbs.fuyuan7.com）撰写，转载请注明出处。

快速摘要

2026 年 8 月，Andrej Karpathy 做了一个很有代表性的实验：他把《指环王》开头第一段文字扔给 Anthropic 新旗舰 Claude Opus 5，给了 100 万 token 的预算（折算成本大约 10 美元），要求用 Three.js 把这段文字渲染成一个三维世界。模型连续工作了约两个小时，写出了 5500 行代码，把霍比特人的袋底洞场景程序化地搭建了出来。作品谈不上精致，但整体能跑。这个实验的价值不在画面，而在方法——它把"短任务跑分"升级成了"长程项目实战"，真正测出了模型的长程工作能力、任务拆解能力、跨领域协调能力和工作耐力，也暴露了当下最扎眼的能力缺口：模型很会生成，却很难自己验收自己的产出。

三个核心结论先放在这里：炫酷 Demo 已经测不出模型真实水平，任务太短、套路太熟、只给你看最成功的一次；判断模型要换一套指标——预算内完成度、人工介入量、规模扩大后的稳定性、长时间后是否还记得最初目标、能不能发现并修复自己造成的问题；2026 年评测生态正在从静态榜单转向交互式、长程化（ARC-AGI-3 主流模型得分不到 1%，SWE-bench Pro 强调防数据污染），普通用户完全可以用一套自测清单自己摸清模型的底细。

想看完整拆解，往下翻。

一、2026 年的模型评测困境：榜单刷不完，Demo 看不尽

先交代一下现在的行业节奏。2026 年这大半年，头部模型基本是"按月换代"：2 月 Google 发了 Gemini 3.1 Pro，3 月智谱的 GLM-5.1 跟上，4 月 Anthropic 的 Opus 4.7、OpenAI 的 GPT-5.5、DeepSeek V4 系列扎堆发布，7 月底 Anthropic 又端出 Opus 5，定价只有新旗舰 Fable 5 的一半，官方口径是"专为日常高频使用设计"。我翻了下各家官方公告和第三方榜单，几乎每一轮发布都配着同样的话术：编程能力提升多少个百分点、推理成绩超过多少人类专家、某个榜单又刷新了纪录。我把 2026 年上半年各家主力型号的时间线拉了一下，方便大家感受这个节奏有多密：

一个月一旗舰，半年七次发布，这就是 2026 年的行业节奏。每条新闻稿都自带一份漂亮的跑分表，但普通用户真正需要的，是一套能穿透这些数字、直接测出"模型在自家场景里好不好用"的方法。

紧接着，社交平台上的演示视频就来了。一句话生成网站、复刻某款知名产品、几十秒做出一个小游戏、让页面里的元素跟着鼠标跳舞。我承认，第一次看这类 Demo 的时候确实会"哇"一声，画面流畅、交互丝滑，观感非常唬人。但看多了之后我发现自己陷入一种奇怪的处境：每个新模型发布，我都知道它"看起来很厉害"，却始终答不上来一个最基本的问题——它到底比上一个模型强在哪？强多少？在什么场景下强？

这个问题的答案，靠刷 Demo 是刷不出来的。我把原因归纳成三条，都是我这两年观察下来觉得绕不开的：

任务太短。 一个 Demo 通常就是一段提示词换一个页面，模型输出几百行代码，几分钟完事。这能证明模型具备一定的代码能力和审美，但证明不了它能扛住一个持续数小时、横跨多个阶段、中间还要不断返工的真实项目。真实项目里最折磨人的从来不是"写出第一版"，而是"改到第 40 版还不崩"。

套路太熟。 不知道大家注意到没有，AI 生成的建站 Demo 翻来覆去就是那几样：渐变背景、玻璃拟态、三栏卡片、滚动动画。这些视觉元素在训练数据里出现频率极高，模型等于在交"标准答案"，而不是在解决你真正的问题。你让它做点反套路的东西试试，立刻露馅。

只看高光。 你看到的永远是剪好的成片。测试者试了多少次、中途改了多少轮、模型犯过多少低级错误、有没有人肉介入修 bug，这些过程一概不会出现在演示里。一套测评如果只展示最成功的结果，它就离广告不远了。

我把"Demo 式测试"和"真实工作场景"的差距拉了一张表，自己对照着看，越看越觉得现在的营销式评测水分很大：

我自己就吃过亏。有段时间我在复源AI社区上折腾一个内部工具，看中某个新模型的网页生成能力，打算让它把后台的一个数据面板重写一遍。单页 Demo 它做得确实漂亮，结果一接真实数据、一加权限逻辑，第 12 轮迭代之后它开始自己改坏自己刚写好的功能，上下文一长，前后矛盾就冒出来了。那一次之后我算是彻底明白：看模型，别只看它状态最好的那三分钟，要看它状态最差的那三小时。

就在这种"榜单越来越卷、Demo 越来越炫、但真实能力越来越看不清"的背景下，Karpathy 在 2026 年 8 月 2 日发了一条帖子，做了一个我今年觉得最有启发性的实验。

二、Karpathy 实验全还原：一段小说、100 万 token、两个小时

先简单说下 Karpathy 是谁，新手朋友可能不熟。Andrej Karpathy，OpenAI 的创始成员之一，后来又去特斯拉做了 AI 总监，在深度学习圈子里属于"祖师爷级"的科普人物，常年喜欢自己动手做各种稀奇古怪的模型实验，然后把过程发出来讲给大家听。他讲东西有一个特点：不喜欢绕弯子，专门挑那些"看起来很简单、细想全是门道"的问题下手。

这次他盯上的问题是：既然"画一只骑自行车的鹈鹕 SVG"这种小任务已经测不动新模型了，那该拿什么来测？

他自己给了一个答案。实验设置是这样的：

先说结果：模型真的把这事儿干成了。它没有靠美术人员手摆模型，而是用代码"程序化生成"——通过数学规则在三维空间里生成地形、树木、圆门、霍比特洞屋这类元素，还给它们编排了动画。5500 行代码，前后逻辑基本自洽，跑起来是一个完整的小世界。

这里给不熟悉三维开发的新手朋友补一个背景：程序化生成（procedural generation）是"用代码规则代替手工建模"的做法。 传统做法里，一个 3D 场景里的树、山、房子，要么是美术人员用建模软件一个个摆出来的，要么是设计师手动拖拽放置的，费时费力。程序化生成则相反——写一段算法，让代码根据随机种子和数学规则自动生成成千上万棵树、起伏的地形、错落的房屋，改一个参数，整个场景跟着变。游戏圈大名鼎鼎的《我的世界》和《无人深空》用的都是这套思路。模型选择程序化路线而不是手工建模，说明它做了个聪明的取舍：5500 行代码里，真正写"内容"的代码很少，大部分是写"生成内容的规则"，用最少的代码量覆盖最多的场景要素。两种路线的差别，我列了个表：

从最终代码量倒推，Opus 5 走的是混合路线的变体：主体靠规则生成，袋底洞、圆门这类故事核心元素单独处理。这个选择本身就在告诉我们，模型面对模糊目标时，是有能力做"成本收益权衡"的——这正是长程任务里最值钱的那种判断力。

但你要是拿"游戏工业标准"去衡量它，那它远谈不上精致。Karpathy 自己在帖子里也承认：部分场景看起来很粗糙，有的动画不够自然，画面里还能看到不少 jank（卡顿、穿模之类的小瑕疵）。把它和专业团队做的作品摆在一起比，差距明摆着。

有意思的地方就在这——Karpathy 真正惊讶的，恰恰不是画面质量，而是模型居然能把这么一大摊子事整体运行起来。他原话的意思大概是：我们已经开始离开"用 SVG 测模型"的时代了。以前你问模型"能不能做 X"，现在要问的是"给它足够的预算和时间，它能把这个没人愿意手写的项目推进到什么程度"。

我把整个实验的推进链路画成了流程图，你感受一下这个任务的复杂程度：

flowchart TD
    A[输入《指环王》第一段文字] --> B[文学理解：拆解场景要素]
    B --> C[空间规划：袋底洞/山坡/道路/人物位置]
    C --> D[技术选型：Three.js 场景搭建方案]
    D --> E[程序化生成地形与物件]
    E --> F[编排动画与镜头运动]
    F --> G[代码自检与修复]
    G --> H{检查结果是否满意?}
    H -- 否 --> E
    H -- 是 --> I[输出 5500 行代码的三维世界]

为什么偏偏选《指环王》第一段？我琢磨了一下，这个选材本身就有讲究。这段文字是纯文学描写，没有任何技术术语，但信息密度很高：有地形（山坡）、有建筑（挖进山里的洞屋）、有物件（圆门、黄铜把手）、有人物（比尔博）、有时间（很久很久以前）、有氛围（宁静、田园、带点神秘）。一段 200 字的小说文字，把"场景、人物、情绪、空间关系"全占了，模型想还原它，光"读懂"还不够，还得"翻译"成三维语言。换一段技术文档就没这个效果——技术文档的要素是确定的，照着实现就行，测不出"理解 + 转译"的功夫。托尔金这段文字还有个好处：它是公认的文学经典，训练数据里一定反复出现过，但"把这段文字做成三维世界"这种用法，几乎不可能出现在训练语料里，等于现场出题，防背题。任务素材是旧的，任务形式是新的，测的就是模型的迁移能力。

看到没有，这里每一个环节单拎出来都不简单。模型要先读懂文学描写，把"一个山丘挖出来的圆门、门上有个黄色的圆把手、霍比特人住在洞里"这种描述转成空间关系：场景里该有什么、东西放哪儿、角色怎么走、镜头怎么动、故事按什么顺序演。然后它要把这些决定落实成几千行代码，并且保证前面的决定和后面的代码不打架——比如第 800 行定义的地形，不能在 3000 行又被另一段逻辑覆盖掉。

这活儿放在真人身上，是一个由语言理解、任务规划、空间推理、视觉表达、动画设计、软件工程六种能力叠在一起的综合项目。任何一环掉链子，最终结果都会乱成一锅粥。更关键的是，Karpathy 只给了目标和预算，没有替它规定任何中间步骤——先干什么、后干什么、遇到问题从哪儿改，全是模型自己拿主意。

我试着把这类任务写成提示词的形态，放在下面，大家感受一下"开放任务"和"普通 Demo 任务"在指令密度上的差别：

【任务背景】
你是一个三维场景构建程序。请根据下面这段文学作品，构建一个可交互的三维世界。

【输入材料】
（《指环王》第一段文字，讲述袋底洞与比尔博·巴金斯）

【约束条件】
1. 预算：整个任务最多消耗 100 万 token，请自行规划每一步的代码产出；
2. 技术栈：Three.js，纯前端可运行；
3. 质量要求：场景要素与原文相符，物体有合理空间关系，包含动画；
4. 过程要求：先规划、再编码、后自检，发现问题自行修复；
5. 交付物：完整可运行的 HTML 文件 + 代码说明。

【特别注意】
任务没有标准答案。请把"做得完整"放在"做得漂亮"之前。

Karpathy 在这个实验里还提了一个特别妙的比喻，他说这类"按需生成的高度定制虚拟世界"，正在变成一种"点单式"的东西——以前你想做一个只属于某一段故事的小世界，人工成本高到没人愿意做；现在模型用几美元的成本、两小时的耐心就能给你拼出来。从"没人会去做"到"为什么不呢"，这就是模型能力上了一个台阶的实感。

不过，实验的看点还不止于此。Karpathy 在帖子里同时指出了一个让他印象很深的短板，这个短板比 5500 行代码本身更值得琢磨。

三、这个实验到底在测什么？五个能力维度一次拆清

传统跑分干的事，是把模型能力拆成一道一道相对独立的题目，一道题测一个点，最后算总分。Karpathy 这个实验走了另一条路：把多种能力塞进同一个项目里，让模型在真实推进任务的过程中被检验。用大白话说，前者是"单科考试"，后者是"综合项目答辩"。

我把这场答辩里被真正考到的能力归纳成五个维度，挨个说清楚。

长程工作能力：两小时不跑题、不崩盘

写一个网页 Demo，模型几分钟就收工，上下文里也没多少历史包袱。但在一个项目上连续工作两个小时，完全是另一码事。模型得记住早期做过的决定——比如"场景基调是夏尔郡的田园风""镜头从山坡缓缓推进到圆门"——然后在中后期每一段新代码里继续遵守这些决定。上下文越来越长，早期内容被压缩、被遗忘的风险越来越大，还要保证新增代码不破坏已有功能。

这就像让一个人连续写两小时长文，前半小时定的行文风格，最后半小时还能不能守住，一测便知。Karpathy 这次给的 100 万 token 预算，本身就是一道"耐力题"：预算内要完成，意味着模型不能无脑堆代码，得学会取舍。

复杂任务拆解能力：没人替它排计划

Karpathy 只给了文学文本和最终目标，中间步骤一个字没提。模型必须自己回答一连串问题：这段文字里哪些要素必须出现？先搭地形还是先写人物？动画逻辑是集中写还是散着写？代码出了错，从哪里下手排查？

这个能力在真实工作里极其值钱。很多任务难的不是执行，而是"不知道先干什么"。模型如果只会照着详细指令一步步做，那它只是台高级复印机；能自己把模糊目标拆成可执行清单，才算有干活的脑子。

跨领域协调能力：在文字、空间、代码之间来回横跳

这个实验最狠的地方在于领域跨度。模型要在文学理解（这段文字在讲什么氛围）、空间推理（圆门应该嵌在山坡的哪个位置）、视觉表达（光线怎么打、颜色怎么配）、动画设计（蝴蝶怎么飞、风怎么吹）、程序逻辑（几百个对象怎么组织、性能怎么控制）之间来回切换。任何一个环节理解偏差，最终画面都会变得莫名其妙。

这恰恰是 2026 年实际工作里最常见的形态：一个任务往往横跨产品理解、技术实现、用户体验好几个领域。只在单一领域强的模型，一到跨界任务就露怯。

工作耐力：愿意干"没人愿意手写"的琐碎活

这一条经常被忽略，但我觉得它可能是这次实验最有商业想象力的一点。现实中有大量项目，不是人类做不了，而是太琐碎、太耗时间，做出来又不怎么值钱，于是永远没人做。给一小段小说配一个专属三维世界，就是典型例子——放在以前，谁疯了才会花几天时间手写几千行 Three.js 代码去实现它。

模型不在乎。只要成本兜得住，它就能带着耐心处理大量繁琐细节。它把"做不做"的成本结构改变了，这才是这类能力最实际的商业含义：以前不值得做的事，现在值得了。

自我验证能力：边做边检查自己

这一条在 Karpathy 的帖子里着墨不多，却是我觉得最有后劲的一条。先记住结论：模型在"产出"和"验收"这两件事上的能力，严重不均衡。

这五个维度看着抽象，其实每个都能对应到你我日常的某个具体场景：长程工作能力，对应的是"让 AI 帮忙维护一个项目一个月，它会不会越改越乱"；任务拆解能力，对应的是"扔给它一句模糊需求，它能不能自己理出步骤"；跨领域协调能力，对应的是"从产品文案到技术实现再到用户界面，它能不能一手抓"；工作耐力，对应的是"几百条琐碎的重复劳动，它能不能不出错地干完"；自我验证能力，对应的是"它交的活，你敢不敢不检查直接用"。这么一映射，你大概就能明白为什么我说传统跑分和真实体验越来越脱节了——跑分考的是单科成绩，而日常使用的感受，取决于这五个维度加在一起的"综合体质"。

五个维度放到一起看，就是下面这张表，我平时测模型的时候基本就按这个框架走：

顺着这套框架，Karpathy 在帖子里顺手把评价模型的标准也更新了一遍。他给出的问题清单我抄下来贴在工位上，现在测任何新模型都会过一遍：

• 在固定预算内，它能把任务完成到什么程度？
• 整个过程中，需要多少人工指导和纠正？
• 项目规模扩大之后，它的表现能否保持一致？
• 工作时间拉长之后，它还理不理解最初的目标？
• 它能不能发现并修复自己造成的问题？

拿这套问题去对照市面上的评测榜单，你会发现多数榜单只回答了半个问题——"它能不能做到"，至于"做到的过程里消耗了多少人力、翻过多少次车、预算内能撑多久"，榜单基本不吭声。而这半个问题，恰恰是真实工作里最贵的部分。

四、最大的短板：模型很会生成，却不会验收自己

Karpathy 这次实验里最诚实的地方，是他主动把模型的毛病也摆了出来。Opus 5 虽然写出了 5500 行代码，但它在"验收自己工作成果"这件事上，表现得相当笨拙。

这话怎么理解？一个人类开发者写完场景代码，会直接进入这个三维世界，控制角色四处走动，看看圆门是不是真的嵌在山坡里、镜头推进时有没有穿模、动画节奏是不是自然、光线是不是把氛围搞对了。这是"沉浸式验收"，看的是动态的、连续的整体体验。

模型做不到。它没有眼睛，也没有手，进不了自己创建的世界。它唯一的验收手段是：在不同时间点截几张图，然后对着静态画面判断代码需不需要改。又慢又糙，还很容易漏问题——穿模在某一帧里可能根本看不出来，动画的卡顿更是截图截不出来的。最终作品里那些粗糙的细节和瑕疵，很大程度上就是栽在这个验收方式上。

这背后是一个我今年反复琢磨的结论：当前模型的自我验证能力，明显落后于它的生成能力。它能写出几千行代码，却未必能准确判断这几千行代码最终创造了怎样的体验；它能生产大量内容，却不一定知道这些内容是不是真的好用、真的对。

为什么验证比生成难？我试着用外行能听懂的方式解释一下。生成是一个"从已知出发"的过程：模型见过海量网页、代码、文案，看到需求就能从记忆里调出最像的答案拼出来，这是它的主场。验证却是一个"从未知出发"的过程：要判断一个东西好不好，你得先建立"好"的标准，再拿产出逐条对照，最后还要处理那些标准没覆盖到的意外——动画卡没卡、穿模没有、用户体验顺不顺。这些判断依赖的是连续的、动态的、带有感官性质的体验，而模型没有连续观看的能力，也没有"上手玩一下"的实体，它只能在离散的静态快照里做有限检查。打个比方：生成像背书，验证像质检，背书可以靠海量记忆，质检却必须亲临现场。 模型背书的功力已经炉火纯青，但它从没真正"到过现场"。

别小看这个缺口，它在工程上的连锁反应很实际。AI 写代码的速度越快，代码量越大，人工验收的负担就越重。以前一个人一天写 200 行代码，花半小时检查就够了；现在模型一小时给你 2000 行，你检查得过来吗？生成端在加速，验证端跟不上，瓶颈就从"写不出来"变成了"验不过来"。 我身边不少团队已经撞上这堵墙了：AI 产出堆积如山，人成了流水线上最慢的一环。

面对这堵墙，2026 年行业里常见的破法有三种，各有利弊。第一种是关键节点人工验收，模型全速产出，人在里程碑处把关，适合质量要求高的场景，缺点是人的瓶颈还在，只是往后移了。第二种是给模型配验证工具，让代码跑测试框架、让页面跑自动化截图、让文案跑事实核查接口，把"人眼验收"部分替换成"程序验收"，这条路正在快速成熟，也是各家 Agent 产品的主攻方向。第三种是让模型互相验收，拿一个模型写、另一个模型查，两个模型互相挑错，效果比自问自答好不少，但成本翻倍，而且两个模型可能共享同样的盲区。我自己在复源AI社区的实践是三种混着用：日常内容走工具核查加抽查，重要项目走人工验收，紧急任务偶尔用双模型互查兜底。没有银弹，但每多一道自动化的验收环节，人的负担就轻一分。

顺着这个思路往行业里看，2026 年的评测风向其实已经悄悄转向了。最典型的是 3 月 25 日 ARC Prize 基金会发布的 ARC-AGI-3——这是 ARC 系列第一个"交互式推理基准"，不再是静态的图案推理题，而是把模型扔进一个全新的回合制环境里，让它自己探索、自己判断目标、自己建立环境模型、自己规划行动。结果相当扎心：所有测试环境都验证过人类可以完整解出，但截至发布时，主流模型整体得分不到 1%。Gemini 3.1 Pro Preview 拿了 0.37%，GPT-5.4 是 0.26%，Opus 4.6 是 0.25%。不是 37%，是 0.37%。

为什么差距这么大？因为 ARC-AGI-3 考的东西，恰恰就是 Karpathy 实验里暴露的短板：在陌生环境里，模型不会像人一样先摸清规则再行动，它既缺乏高效的探索策略，也缺乏"做一步、看一眼、再调整"的闭环验证能力。 生成式模型擅长的是"从见过的模式里找最像的答案"，而交互式任务要求的是"在没见过的环境里试错修正"，这俩根本不是一回事。

我把"生成能力"和"验证能力"的差距画成了一张示意表，放在一起看更直观：

这也解释了为什么"会验收的 AI"会这么值钱。谁先让模型学会"玩自己做的游戏、看自己拍的片子、跑自己写的测试"，谁就先把人从流水线上解放出来。Karpathy 这次的实验与其说是给 Opus 5 做广告，不如说是给整个行业画了一张能力地图：哪些能力已经溢出，哪些能力还在荒芜。好的测评从来不是用来证明模型有多强的，是用来找到它会在哪里翻车的。 如果一项测评只能带来惊叹、暴露不了边界，那它就更接近广告，而不是测评——这句话我建议大家抄下来，以后看任何模型发布会都用得上。

顺着"验证短板"再往深挖一层，它对 2026 年最火的 Agent（智能体）落地有直接含义。现在各家都在推"让模型自己干活"的智能体产品：自己写代码、自己跑测试、自己调 API、自己处理报错。这类产品的核心假设是模型能"闭环"——干活、检查、纠错、再干活。可 Karpathy 实验告诉我们，闭环里最弱的一环恰恰是"检查"。模型干活的环节已经自动化了，检查的环节还严重依赖人。所以现实里大多数 Agent 产品做成了"人机接力"：模型干 80%，人在关键节点验收，出了岔子再踢回去重来。这口锅不该产品设计来背，模型能力现状摆在那儿。谁能先解决"自我验收"，谁才真正解锁了 Agent 的完全体。 看懂这一点，再去看各家 Agent 的发布会，你就知道哪些功能是营销话术，哪些是真刀真枪在补短板了。

五、2026 年主流评测体系全景：榜单背后的门道

讲完 Karpathy 的实验，我们把镜头拉远，看看 2026 年整个评测生态长什么样。毕竟实验方法再好，也得知道市面上已有的工具各自能测什么、测不准什么。

SWE-bench 系列：真实软件工程的照妖镜

SWE-bench 大概是目前代码评测里最被认可的基准，思路很朴素：从真实开源项目的 GitHub Issues 里挑出 bug 报告和功能请求，让模型直接对着真实代码仓库改代码、跑测试，用测试通过率算分