模型设计的界面怎样才算好

TL;DR

新模型发布时，“擅长 UI”通常配着几张精致截图或一段快进录屏。成品看着确实不错，但看不出它是一次生成的还是从多次结果里挑出来的，也说不清它究竟在哪些具体要求上做对了。说一个 UI 好，总是在某几项要求上好；每一项要求都得有人或程序对照明确的标准实际检查过，才算有了证据。以两个场景为例：照着房源照片搭一座能在浏览器里走进去的三维房子，租客看一两回就关掉；实验室的仪器预约页要用好几个月，每隔一两周就冒出新需求。要求之间首先差在要观察多久：文字溢出在一帧画面里就能看到，预约能不能用得真约一次，新加的培训限制会不会弄坏旧预约，要等几周后改需求时才见分晓。其次差在拿什么标准去比：墙体漏光、文字溢出放在任何作品里都是缺陷，判断时不需要知道作品本该是什么样（integrity）；光照、构图这类设计讲究（craft）只有一小部分能写成规则；卧室窗户该开在哪面墙，必须对照房源照片才知道（correctness）；而如果租客想发给只会在手机上滑动、不会用键盘漫游的父母看，房子还原得再准对他们也没有用，这类标准（fit）握在具体用户手里，只有等真实用户带着用途来用、或者直接问他们才能知道。一项检查能不能自动化，取决于它的标准在生成之前是否已经存在、掌握在谁手里。

今天的自动化评价主要有两种：让多模态大模型（VLM）对照 rubric 给截图打分，或者让 browser agent 按预设步骤操作页面、统计通过率。两者依据的都是出题人在生成之前写好的规则。VLM 能分清差距悬殊的作品，汇总出的模型排名也相当稳定，但两版作品水准相近时就判不准，文字溢出这类几个像素的几何缺陷也常常看不出来；agent 照着人写好或逐条审过的测试去跑，结论和真人高度一致，让它自己决定测什么，就会漏掉大部分缺陷。没有参考录像的动画、第一次来的人和残障用户实际遇到的困难、prompt 之外的用途、跨几周的修改，这四类要求在现有基准里很少被评到。训练能大规模使用的也是这类便宜、能自动算出的信号，由此可以推断各项能力的进步有先后：作品从破损到完整进步最快，第一眼的整洁观感很可能随之提升；功能和内容的正确性其次，因为测试要事先写好预期结果、在浏览器里跑起来也贵，核对内容又需要现成的参照；界面普遍整洁以后，候选之间只差细节，VLM 给不出稳定的高下，更高层次的设计打磨就会慢下来；那四类很少被评到的要求最慢。所以排行榜分数上涨，说明不了这些深层要求是否改善。交付时能补上一部分检查：系统只服务眼前这一个需求，掌握标准的用户也在场，可以在动手前问清用途，把用户的预期写成每次修改后都重跑的测试，并保留每个版本，改坏了就退回。不过第一次来的人和残障用户遇到的困难，仍然要等这些人亲自用过才会暴露。

上一篇文章讨论了生成的界面为什么往往第一眼就好看，以及说一个模型“有品味”到底是在评价什么。如今新模型发布时，“擅长 UI”几乎成了标配的宣传语，旁边总少不了几张精修截图或一段快进录屏：提示词刚敲进去，屏幕上就出现一个精致的落地页、能玩的赛车游戏，或者一座可以漫游的三维房子。但录屏往往掐头去尾，只留最初那句话和最终成果；中间模型可能已经自己默默跑了几十分钟，反复写代码、截屏检查、再接着改，最后端出来的，也可能是多次生成里挑出的最好一版。

设想两个场景。一个是三维房子：租客看中了一套待租公寓，把房源页上的十几张照片喂给模型，想搭一座能在浏览器里走进去逛的房子。几十分钟后，屏幕上真的渲染出了客厅、厨房和两间卧室，家具摆好了，阳光透进窗户，按键盘就能在房间之间走动。另一个是实验室的仪器预约页：agent 搭好第一版后，组里同学每天在上面预约、取消，记录写在一张共享表格里；每隔一两周就有新需求冒出来：加一台新仪器，只让培训过的人预约，或者把日历改成按月显示。

三维房子看上一两回就会关掉，关键在户型画得准不准、和照片对不对得上；预约页要用好几个月，关键在预约和取消别出错，更不能每次改需求都把历史数据冲掉。一张静态截图只能定格某个瞬间、某个视角：凭它确实能看出客厅布局清不清楚，但其他房间对不对得上照片，得切好几个视角去比；预约功能到底灵不灵，得真去点几下操作；至于改版有没有把旧功能改坏，更要等到连改几轮或者下一版上线才能见分晓。

让机器花几十分钟生成代码，算的是算力成本，随着模型和硬件升级成本在下降；模拟点击、核对提交结果也可以交给程序，前提是得有人预先写好测试用例和预期断言；甚至拿照片检查房间对不对，都能让多模态模型来跑一轮。但唯独“下一个需求”没法靠算力加速。组里同学会遇到什么新麻烦、想加什么新限制，必须实实在在等上几个星期。

熟悉这一行的人会说，UI 早有一整套自动化评价手段：把截图喂给能看图的大模型（VLM），让它当 judge，照着一份评价准则（rubric）打分，也就是常说的 LLM-as-a-judge；复杂一点的，就交给能操作浏览器的 agent（browser agent）按预设步骤走一遍，统计任务通过率。公开的 UI 基准很多基于这两种做法或其组合，几秒到几分钟就能评完一件作品。但这套流水线能说明多少，全看 VLM 在截图里能分辨出什么、agent 实际执行了哪些操作，以及预设的 rubric 和测试用例到底写了什么。出题人写下这些规则时，手里既没有租客面对的那些真实房源照片，更预料不到实验室几周后的新要求。

什么算 UI，不同的 UI 要做对什么

如今在聊天窗口里生成的界面，早就不局限于网页和应用，还包括幻灯片、海报、图表、内部工具、游戏、物理模拟、三维场景乃至 CAD 模型。Claude 的 Artifacts 允许在同一个窗口内反复修改网页、SVG、流程图和可交互的 React 组件 (Anthropic, 2026)，Gemini 的 Canvas 也能直接生成并预览网页应用、小游戏和交互模拟 (Google, 2025)。这些东西原本分属不同的行当，生成机制大同小异：模型先写出代码或结构化描述（比如 HTML、SVG、组件树或一段三维场景定义），再由浏览器、渲染器或相应的运行时解析为人眼能看、双手能操作的结果。本文把这类由模型生成、可渲染或可运行的产物统称为 artifact。至于模型直接画出的一张静态网页图，充其量只能算视觉提案，既没有可运行的交互行为，也无法针对底层代码做检查和修改，因此不在讨论之列。

无论哪类 artifact，都可以拆解为内容与呈现两面。内容决定作品在表达什么：数据、公式和文字是否准确，构建的实体是否符合现实。三维房子的内容就是公寓本身：有几间房、门窗开在何处、客厅和厨房如何连通，必须和房源照片严格对得上。呈现则关乎这些内容怎样递到人眼前：信息层级、构图、字体与配色，决定了人先看到什么。在三维房子里，空间格局理应比木地板的纹理更早被看清。

按主要的使用方式，artifact 大致可以分成四类（图 1 给出了直观分布）。不同类别之间没有非黑即白的界限，更无高下之分：三维房子既要像户型图那样交代空间关系，又得支持第一人称视角漫游；而一张准确且信息密度极高的数据图表，实现难度完全可能超过一个简单的输入表单。

Presentational artifact MacBook Pro · structured SVG Claude Fable 5.1

Task-oriented interface Orbit Analytics dashboard GPT 5.6 Sol

Interactive experience Realtime fluid simulation DeepSeek V4 Flash

Spatial artifact 3D rocket launch scene Claude Fable 5.1

除开通用的内容与呈现，每一类 artifact 还各自背负着一道核心要求。展示型（presentational）重在阅读与浏览，幻灯片、海报、流程图和图表的画面排布必须严格服务于内容逻辑：柱状图的纵轴如果不从零起步，细微的数据波动在视觉上就会显得像翻了一倍。任务型（task-oriented）用来支撑操作，比如表单、dashboard 和内部工具，核心在于多步操作之间的状态流转不能脱节。预约页便是典型：选时段、提交、取消，每一步都在读写同一份共享记录；两个人同时抢同一个时段时，系统必须把后到者拦在外面，绝不能悄悄覆盖先到者的记录。到了交互型（interactive），交互过程本身就是内容核心，像物理模拟、互动讲解和游戏，输入、状态与时间必须严密协同：滑块拖到哪里，绑定的物理量就得实时跟到哪里；按下一键重置，系统要干脆利落地恢复到一致的初态。而像三维场景与 CAD 这类空间型（spatial）artifact，更要处理三维结构在二维视口中的投影关系：三维房子换个视角看，遮挡与透视比例要前后自洽，转弯穿门时视点绝不能穿模卡进墙里；CAD 零件改了一处尺寸，关联装配的几何体也得同步更新。

三维房子与预约页的另一大分水岭，在于生命周期的长短。三维房子往往看个新鲜，预约页的每一版是下一版的基石：加一台仪器、添一项培训门槛、换成按月展示，每次改动都发生在已经沉淀了数月真实数据的页面上。对长期演进的 artifact 而言，每一次迭代都必须在满足新需求的同时护住既有资产：历史预约绝不能丢，增加了培训限制后原有的取消逻辑仍要走得通，甚至管理员手动在源码里微调过的文案，也不该在模型下一次全量重新生成时被无声抹去。这些隐患在第一版的截图上毫无痕迹，全看代码架构如何解耦。如果预约数据与日历视图各自独立，改成按月显示时就只需替换展示层，存留的预约记录自然分毫不受影响。

上述挑战究竟有多少需要模型独立承担，很大程度上取决于它身处的生成环境。在 Claude Artifacts 或 Gemini Canvas 这类独立画布里，模型必须从零写出完整代码，内容、视觉与交互全得靠自己把控。到了 Google A2UI 这类声明式协议下，模型只需要说明调用哪些组件、绑定哪些数据，具体绘制由宿主应用从事先审核过的组件中调取完成 (Google A2UI Team et al., 2026)，视觉呈现与基础交互大多由宿主兜底，组件是否违规也更容易做自动化静态检查。而在团队已有的 design system（统一的组件、样式与规范）和成熟代码库里做生成时（例如 Claude Design (Anthropic, 2026)），视觉与交互规范早已确立，模型的核心任务转变为如何让新增代码与既有的设计资产保持风格自洽。

一个模型即便能照着照片搭出一座不穿模、空间准确的三维房子，一次生成就足以交付，也推不出它能做好一套实验室预约页。预约页既要把多个步骤串成可靠的交互流程，还要在数月周期里经受住反复修改。脱离场景谈论“擅长 UI”往往遮蔽了真正的难点，这句话背后至少包含三个未曾明说的条件：做的是哪一类 artifact，用一次还是长期维护，以及它是在完全从零开始的沙盒里写代码，还是在已有规范兜底的环境里生成。

观察的时长和对照的标准

发布会上的演示录屏往往只走预先设计好的黄金路径：镜头从三维房子的玄关一路漫游进客厅，预约页也只展示空荡荡的初始周视图。那些镜头没扫到的角落、未曾触发的状态，观众根本无从判断。要衡量一项要求是否达标，需要依据证据的性质拆出两个维度（图 2）。其一是观测的时间跨度：是单个静态画面（frame），是一段连续操作过程（sequence），还是连改几轮甚至跨越数周的前后版本（versions）。其二是评判时依据的对照标准：任何 artifact 都应守住的质量底线（integrity），作品在呈现和交互上的设计讲究（craft），内容与运行结果必须符合的客观事实（correctness），以及最终是否满足特定用户的真实用途（fit）。

刚打开时的第一屏，充其量只是无数可能画面中的一帧。只有走进另一间卧室、输入超长标题、把浏览器视口缩窄，或者灌入真实的业务数据，新的画面才会显现，许多破面、遮挡与文本溢出往往在这时才暴露出来。连续的过程则必须带着具体任务操作上几分钟才能检验：穿过门道时镜头会不会卡进门框，点下提交后记录是否真的写入了底表，全得实地操作一轮。至于跨版本的差异，更要等新需求出现后才能观察：预约页加上培训限制之后，不仅要看新规则有没有生效，还要核对历史记录与旧功能是否完好。观测跨度拉得越长，就越需要有人去深度交互或者耐心等待。单看录屏的观众无法代劳，能对比前后版本的人，通常是真正接手维护这个 artifact 的人：维护者、协作成员，以及在下一轮对话中尝试修复代码的模型自己。

三维墙体漏光破面、模型穿模错位、文本超出容器边框，哪怕换一套公寓户型、换一段文本内容，这些也毫无疑问是缺陷。识别这类问题根本不必知道作品本该是什么样，这类通用的底线就是 integrity。而房间的光照是否显得发平、镜头高度是否符合人体工学的视平线，则依赖摄影与室内设计等专业行当沉淀的审美经验。craft 指的正是这类设计上的讲究，针对作品如何呈现以及如何回应操作。它衡量的往往是做得有多好，很少有非黑即白的损坏边界；其中能够明确提炼为固定规则的部分（比如正文单行字数不超过七八十个字符），便可以像 integrity 一样交由自动化程序检查。

相比之下，卧室窗户到底该开在哪面墙上，必须对照这套公寓的真实照片才能判断；提交预约后底表里该多出哪一条记录，也必须有人预先写好预期结果才能核验。这类判断必须依赖作品外部一份具体的客观参照，对应的标准是 correctness，它涵盖了事实内容的准确与业务功能的实现。各类 artifact 额外要做对的核心考题（例如预约系统的状态流转、物理引擎中滑块位移与参量响应的映射），大都属于 correctness 的范畴，并且往往要经过一段连续的交互过程才能真正观测到。

还有一类评价，即便外部参照完全一致，只要换一个使用对象或切换一个应用场景，结论就可能彻底反转。如果租客希望把三维房子分享给远方的父母参谋，而父母只习惯在手机浏览器上滑动预览，根本不会用键盘方向键去控制空间漫游，那么这座即便还原精准、渲染精美的三维房子，对他们来说依然毫无用处。要评估这一层表现，必须弄清楚作品面向谁、究竟拿来解决什么问题，这正是 fit 要回答的核心。初次接触的用户能否顺利用起来，在设计领域通常被称为可用性（usability）。可用性横跨了两个标准：操作后是否给出即时反馈、误触后能否便捷撤销，这类通用设计准则对所有人都成立，属于交互上的 craft；而特定用户究竟卡在哪个具体环节，则取决于他们的背景、习惯与认知偏好，这属于 fit。

不仅评判的依据不同，这四种标准能够被转化为自动化检查的时机也大相径庭。针对破面和模型穿模的检查只需编写一次，就能通用于几乎所有三维场景；视觉氛围与光照是否考究，只有少数已被固化为规范的参数能预先校验，其余绝大部分必须依赖有经验的人根据成型作品临场定夺；窗户位置是否准确，必须等拿到具体房源照片后才能比对；而三维漫游到底能不能帮上忙，必须等真实用户带着明确用途进入场景后才能知晓，或者在交互中直接问他们。

一座墙体完整、光影出色的三维房子，卧室窗户依然完全可能开在错误的墙面上，查破面的自动化脚本和关注布光的设计师对此都无能为力。在实际生成的网页应用中，不同评价维度之间的得分同样呈现出明显的弱相关性。WebCraftBench 让模型分别评估应用的外观质量、可用性以及需求满足度。其中外观评测主要依据静态截图，大体对应 craft；需求满足度则逐条核验需求中列出的验收项，八成以上检查的是功能和内容，对应 correctness。具体到单件作品的比对，这两项评分之间的 Pearson 相关系数仅有 0.32（1 代表完全线性正相关） (Liu et al., 2026)。

今天的 UI 评价

在模型接手界面生成之前，设计与工程领域早已建立起长达几十年的评估传统。无论是视觉品味、功能正确性还是可用性，各有一套成熟的验证路径。如今基于 VLM 截图打分或基于 agent 脚本操作的自动化评估，大都能在这些经典方法中找到原型。

设计和工程里原有的评价办法

一个界面是否美观讲究，设计团队通常依赖设计评审（critique）来把关：设计师陈列出方案稿件，同行逐屏审视视觉层级、对齐基准、排版间距与色彩搭配，指出哪些布局未能有效引导视觉焦点，并提出修改建议。这种评估依赖资深专家的审美直觉，并不依赖量化打分。评审之所以有效，核心前提是团队预先对设计目标达成了共识：评审的关键在于分析方案是否达成了既定目标，并以此为基准展开反馈 (Gibbons, 2016)。脱离了这一共识，评审往往会沦为不同个体之间主观偏好的各自表述。

至于功能是否正常、界面是否损坏，工程实践则主要诉诸测试程序。端到端测试会固化一串操作流与预期结果，比如在预约页中选取时段、点击提交，随后断言底表是否新增了该条记录。视觉回归测试则把新渲染的截图与人工验收通过的基线图逐像素比对，它查证的是界面外观是否发生了偏移，而好坏的标准早在最初验收基线图时便已敲定。然而，端到端界面测试本身极易出现偶发失败，软件工程中的测试金字塔因此一贯主张以大量的单元测试为底座，仅保留极少数端到端测试；而界面的直观体验与交互可用性，测试脚本向来难以胜任，仍需依靠人工展开探索式测试 (Vocke, 2018)。

检验可用性成本最低的手段是启发式评估（heuristic evaluation）：数名评估人员对照十来条通用设计准则逐屏排查，例如系统是否即时提供操作反馈、误触后是否提供清晰的撤销途径。映射到预约页中，便是提交后是否弹出“已预约”提示、误点取消后能否一键撤回。Nielsen 将这些准则定位为宽泛的经验法则（broad rules of thumb），如何映射到具体界面完全取决于评估者的现场理解。不同评估者发现的问题往往高度离散：他在六个实际项目中统计发现，单个评估人员平均只能覆盖大约 35% 的可用性缺陷，因此通常需要邀请三到五位专家独立审查后再行汇总 (Nielsen, 1994)。

真正的用户测试则是直接邀请目标用户试用，看别人怎样误解一个设计者自己很熟悉的界面。测试通常招募若干具备代表性的用户执行典型任务，要求他们出声思考，由观察者记录下他们究竟在何处迟疑受阻、误解了哪些控件含义。Nielsen 估算五位同质用户大约能揭示 85% 的可用性痛点，因而主张小步快跑，每轮仅测五人，修复后再开展下一轮迭代 (Nielsen, 2000)。等到系统真正部署上线，还可以开展长达数周乃至数月的线上 A/B 实验，通过真实用户的行为数据来检验新旧版本。许多设计者自信满满的改动，在真实数据面前往往并不尽如人意：Kohavi 在总结微软的在线实验时指出，团队以改善指标为导向设计的改动中，仅有约三分之一带来了显著正向收益，其余多数毫无改观甚至导致指标下滑 (Kohavi, 2015)；Google 在搜索广告领域的实验同样指出，用户对界面变更的适应可能持续几个月，短期指标不一定能预测长期效果 (Hohnhold et al., 2015)。

拿这些传统路径对照当下的自动评估，会发现让 VLM 参照 rubric 给静态截图打分，相当于用同一个评估者同时兼替了设计评审与启发式评估。这位评估者依据一份由外部制定的固定 rubric 逐屏挑刺，未曾与产品团队就设计目标达成过共识。尽管多次采样或引入多模型合议极为廉价，能平抑部分随机打分波动，但人类专家合议之所以有效，是因为不同个体具有不同的观察盲区；倘若主流模型对某一类视觉或几何缺陷存在共同的感知局限，堆叠再多模型也依然视而不见。让 agent 依照预设脚本操作浏览器，也只是相当于执行了几条有限的端到端测试，覆盖的永远只是脚本里写死的路径。至于用户测试与线上实验所捕捉的，恰恰是设计者未曾预料的理解盲区与长期行为变化，这些全都需要真人投入实打实的时间。在公开的 UI 基准里，很少由提需求的普通用户试用作品再做判断，除了在竞技场里让众包用户投票做粗略比对；真人多在出题、审阅测试和检验模型打分时出现。

五类常见的做法

根据观测手段与判定依据的不同，现有的 UI 基准大致可以归纳为五类形态：参考图还原、截图打分、按步骤测试、多轮修改以及竞技场盲测投票。VLM 打分与测试 agent 则是横跨其中的核心工具组件。

从观测窗口来看，参考图还原与截图打分主要审视视觉画面（即便是多状态截图，依然只是离散抽取的几个切片）；按步骤测试审视的是单次交互的连续过程；多轮修改审视的则是在同一次会话里跨轮次的代码演进。除竞技场之外，其余四类基准的判定依据全都由出题人在生成之前便已固定下来，分别对应目标参考图、针对每道题细化的 rubric 项、测试脚本与断言、以及每轮的修改提示词和期望界面。无论是自动化比对脚本还是 VLM，都是在严格遵照这些预设规则执行仲裁。尽管 VLM 偶有泛化表现、能捕捉到 rubric 之外的毛病，但真正具备可复现置信度的，依然局限于那些显式写在规范里的条款。

竞技场模式则放弃了预设评估标准。以 WebDev Arena 以及后来的 Code Arena 为代表，流程通常是由真实用户提出自由需求，随后并排展示两个模型生成的应用供其试用点击，最终由用户盲投选出胜者。在全部五种形态中，唯有竞技场是由实际需求方亲自下场做出裁决，那些未被明文写进 prompt 的隐性偏好（例如特定受众的认知习惯或应用场景）才得以进入评估视野。然而，投票者未必真的用这些应用处理日常业务，试用往往停留在几分钟的摸索，极少会深入核验底层数据的正确性。外观、交互反馈与需求吻合度的直观印象混在一起，票选结果无法还原用户究竟权衡了哪些维度。这类业余投票与专业人员的审视往往存在明显出入：WebDevJudge 曾邀请专家对部署完毕的 WebDev Arena 样本重新盲测仲裁，当把平局纳入选项时，专家结论与众包原投票的一致率仅有 53%，即便只保留分出胜负的样本，一致率也只有 77.4% (Li et al., 2025)。

让 VLM 打分

在基于视觉语言模型的评估流水线中，作为 judge 的模型通常会同时接收网页截图与源码，部分基准还会补充交互前后的多张截图以及操作日志。对比 judge 与人工评估的大量实验表明，两者的吻合程度主要受制于两个核心变量：候选作品之间的质量差距到底有多大，以及这种差距能否在输入的素材中清晰显现。

在 WebCraftBench 中，模型开展的两两成对比较与人工评判的整体一致率为 85.3%，而在两件作品分差悬殊时这一数字可达 90% 以上 (Liu et al., 2026)。然而，Luera 等人探究 VLM 预测众包用户主观感受的研究显示，一旦两个界面在人类受试者眼中水准相近，模型的倾向性判定便几乎退化为随机猜测 (Luera et al., 2025)。WebDevJudge 的测试集直接取自 WebDev Arena，其中的对决样本功能基本可用，表现最好的 judge（GPT-4.1）与专家标注的一致率约为 70%，而论文给出的人工基线约为 85% (Li et al., 2025)。

然而，软件的迭代修改恰恰发生在相近版本之间：系统不仅要在差异微妙的相近版本间决出优劣，更要精准指明下一步该改何处。Duan 等人在 2024 年将 Figma 设计稿的结构化元数据输入 GPT-4，促使其依据设计原则提出修改建议。经设计师逐条核对，第一轮意见的准确率为 52%；而在设计师依循建议完成初版修正后，后续轮次反馈的综合准确率降至 39%，原作者将其归因于方案在多轮修正后本身变得更加完善 (Duan et al., 2024)。随着设计品质提升，残存的缺陷更微观细碎，模型建言的失准与 judge 在高质量相近样本上的一致率滑坡，反映的大概是同一类瓶颈。

WebDevJudge 的研究团队还系统考察了 rubric 扮演的实际角色。当两名人类专家脱离 rubric 自由评估时，计入平局后的判断一致率仅有 65%，分歧主要集中在是否应当判定为势均力敌；而当引入人工编写的严谨 rubric 后，在另一批样本上专家间的一致率达到了 92%。但这一机制在模型端并未复现：无论是依据 rubric 严格比对还是直接判断，模型与专家之间的一致率并未拉开明显差距，rubric 仅在针对单一页面独立打分时略有助益 (Li et al., 2025)。人类专家的审美尺度各不相同，rubric 的价值在于拉平团队认知、构建统一的评估锚点，这与设计评审前先校准目标的逻辑一致；但单个模型内部已具备固化的先验表征，一段文本形式的 rubric 并不能突破它在视觉截图感知层面的真实盲区。

judge 与专家有较好的一致性，相当一部分来自读代码。在 WebDevJudge 中，GPT-4.1 纯看截图时与专家的一致率约为 61%，纯看代码时约为 70%，同时给截图和源码也只和纯看代码差不多 (Li et al., 2025)。ArtifactsBench 截取了操作前、中、后三张图：Gemini-2.5-Pro 纯看截图与前端工程师排名的吻合度约为 75%，纯看代码约为 79%，把代码和三张截图合起来，一致率提高到了约 91% (Zhang et al., 2025)。专家看的是真实跑起来的网页，judge 靠看代码就能达到七八成的一致，这多半是因为多数时候代码里写了什么，页面上就有什么；但在代码写得通、画面出现遮挡或排布走样的场景下，代码就看不出问题了，这类缺陷必须看画面才能暴露。

即便依赖视觉，输入图像在送入视觉编码器前也会经历强烈的降采样，微小的像素级瑕疵往往在此过程中被抹除。根据 Claude 官方技术文档，较新模型的图像长边上限为 2576 像素，早期模型则仅有 1568 像素 (Anthropic, 2026)。面对一张分辨率为 1440×6000 的典型全网页截图，正文中 14 像素的标准字体在缩放重采样后分别只剩下大约 6 像素与 3.7 像素的有效字高。如果为了保真度只截取首屏视口，首屏之外的交互区域又直接被排除在证据链之外。

更为隐蔽的是，即便图像细节足够清晰，模型在解析基础空间拓扑时依然频频失手。BlindTest 针对 2024 年主流模型的实验表明，在清点直线交叉次数等简单几何判定中，四个主流模型的平均准确率仅约 58%；但若在视觉编码器输出的中间隐层上直接训练轻量线性分类器，判定圆交叠或线相交的准确率能达到 99% 以上 (Rahmanzadehgervi et al., 2024)。由此推想，至少这类空间几何关系其实已经被视觉编码器捕捉，失真更可能发生在把视觉特征翻译成自然语言判断的过程中。在实际 UI 中，组件重叠错位、文本超出容器边框等常见缺陷同样属于这类相对几何关系，UI-Lens 的大规模实测印证了这一点：在由设计师标定的近五千个中文界面中，9 个主流通用 VLM 检测文本溢出缺陷的平均 F1 值（兼顾查准率与召回率，满分为 100%）仅有约 22% (Xiang et al., 2026)。针对性微调或能改善这一短板：在针对安卓多任务分屏的一项专项研究中，将截图与控件坐标共同输入微调模型后，识别控件意外遮挡的 F1 值能够提升至 87.2% (Zhang et al., 2026)，但其缺陷定义与界面形态均与通用 Web 场景存在差异。

静态截图只对应特定浏览器和尺寸下的一次渲染。Playwright 等测试框架因此要求回归截图在一致的环境里运行 (Microsoft, 2026)。Guo 等人在跨浏览器、跨设备和多分辨率下的评测显示，68% 的生成网页在至少一种环境里出现兼容问题，多数表现为版式散架。但把多套环境的截图都喂给模型也未必管用：让 GPT-5.5 诊断跨端兼容问题时，只输入 DOM 树时 F1 值为 85.1%，加上截图后 F1 值降到了 77.9% (Guo et al., 2026)。作者认为，多张截图带来了过多视觉干扰，分散了模型的注意力。

让 agent 去操作

当测试用例的操作步骤与预期断言完全由人工编写或逐行复核时，browser agent 能够展现出高度可靠的执行力，精准捕捉静态图像无法反映的动态缺陷。在 WebGen-Bench 中，测试用例先由 GPT-4o 生成草稿，再经由人工逐条审过；agent 依照这些既定脚本驱动浏览器并判定结果，单项测试结论与人工实测结果的一致率达到 86% 至 94%，基于 agent 统计的网站端到端平均合格率与人工实测几乎完全重合（例如 26.4% 对比 26.0%） (Lu et al., 2025)。

但一旦让 browser agent 自主去测试，情况就变了。WebTestBench 只向 agent 输入需求，让它自己想测试点并诊断故障：参测模型的缺陷检测 F1 值都没超过 30%，大多数模型的召回率不足 25%。研究团队把这归因于“默认正确偏见”（default-correctness bias）：只要没看到明确的出错证据，模型倾向于假定页面正常 (Kong et al., 2026)。模型自己列的测试点，覆盖不到人工清单的七成，漏掉的多半是需求里没明说的部分。如果把人工写的测试点直接给 agent 去跑，F1 值会有提升（例如 Claude Sonnet 4.5 从 21.9% 升到 49.2%），但 F1 依然不到一半。失效原因分散在各个环节：没触发交互、读不懂页面状态，或者拿到输出后断言判定错了。

在判定交互结果是否符合预期这一关键卡点上，评估遇到了软件工程中经典的“测试预言机难题”（test oracle problem）：系统需要一套独立于被测代码的机制来断定什么是正确行为 (Barr et al., 2015)。人工编写测试时，预期结果由人写下；换成 agent 临场判断或让大模型自动生成断言，这时得由模型自己提供预言机。Konstantinou 等人的研究表明，模型在逆向生成断言时，倾向于迎合现有代码的实际运行表现，从而把代码中原本潜藏的错误直接固化为断言预期 (Konstantinou et al., 2024)。这种把眼前所见直接默认为合规行为的倾向，大概和没看到明确出错证据就假定页面正常是一样的道理。

更棘手的挑战在于，有些错误只潜伏在内部状态里，在界面外表上毫无表征。WebGrader 记录了一个极具代表性的案例：用户点击新增按钮后，界面正常弹出了成功提示，但底层表格中并未增加任何实际数据。WebGrader 依靠对比交互前后存进去的状态将其判为失败 (Chen et al., 2026)；而若单看那条成功提示，会以为操作成功了。在三维交互场景中，基于内部状态的判定与纯粹外部观测几乎对不上。WorldCoder 要求所有生成的交互式场景遵循规范，将实时运行状态持续同步至内部对象，随后由专家写好的检查逻辑自动读取该对象实施对错断言。研究团队将三种纯外部观测方式（DOM 解析器、多模态 VLM 截图打分、以及支持最多 8 步交互的 browser agent）与这套内部状态检查进行了系统比对：结果显示，三种外部手段给出的排名与内部状态断言几乎没有统计相关性，以等级排序相关系数 Kendall $\tau_b$ 衡量（1 代表完全正相关，0 代表毫无关联），即便表现最佳的 agent 组，其系数也仅有可怜的 +0.111 (Lu et al., 2026)。

两类评估差距这么大，部分原因在于前提不同。WorldCoder 记录的内部状态得零分的案例中，有 42.8% 是因为代码没有按规范暴露状态对象，检查器读不到数据直接判了错，但画面本身不一定坏了。更有警示意义的是另外 40.8% 的案例：画面渲染看似合理自洽，但在用户触发交互后，后台数据根本没有推进。这类问题在静态截图里看不出来；即便让 agent 去操作，如果只看视觉反馈，也容易被看似正常的画面蒙过去，只有直接检查内部数据状态才能发现。

除了状态黑盒，交互测试本身容易出现偶发失败（flakiness）。Romano 等人分析了 235 个出现偶发失败的传统界面测试用例，发现 45.1% 出在异步时序竞争上：在页面响应更新或网络请求尚未落定之际，测试脚本便匆忙执行了断言检查，页面本身没有错，测试报错了 (Romano et al., 2021)。让 agent 来操作，同样的问题还在。WebTestBench 中一部分误报正是源于异步渲染延迟。仅凭一个粗糙的任务通过率，人们根本无法甄别究竟是被测应用存在逻辑缺陷，还是 agent 点击未中或者断言过早。要想弄清原因，得看测试者走了哪些步骤、每步看到了什么。

从一件作品到一个模型

基准测试最终向公众呈现的，通常是浓缩为单一数值的模型总分。然而从单次运行的离散作品汇聚为这一宏观分数的过程中，多个关键环节直接决定了该指标的解释力：候选样本是如何采样的、各项子指标怎样合成一个分、多道测试题的分数如何汇总，以及参测模型产出的作品分布是否高度同质。面对同一模型交付的成果，它可能是一次生成的结果，可能源自 10 个采样候选中的人工最优挑选，也可能是借助 agent 在后台经过了多轮自动化调试与修补，而这些在最终静态交付物上难以察觉。单次生成反映的是终端用户在日常交互中大概率遭遇的真实体验；作者事后挑选的最优解，衡量的是模型在统计长尾上偶尔能触碰的能力上限；若挑选逻辑本身被固化为产品功能（例如设计工作流中一次性生成 4 种版式供用户挑选），则它度量的是“模型生成+重排序”的综合系统效能；而经历多轮调试后的最终产物，衡量的则是模型与复杂自治工作流协同作战的整体产出（租客等待几十分钟才获得的三维漫游便属于此类）。倘若在发布报告时隐去挑选与迭代流程，榜单排名就会被系统性人为放大：针对 Chatbot Arena 的一项计量分析发现，厂商若私下测试多个模型变体并仅选择最优版本上线，会系统性抬高其在天梯榜上的相对名次 (Singh et al., 2025)。发布会演示从多次生成中挑最好的一件做录屏展示，也是同样的道理。

当针对单一作品的多项指标完成测量后，常见的处理方式是将其简单平均为一个综合分。然而这种平权折算常常抹平了关键的结构性冲突：一座视觉渲染惊艳但户型朝向与照片对不上的三维模型，与另一座户型分毫不差但光影平淡的模型，在算术平均后可能得到相同的综合评分。但对于需要据此做出租赁决策的用户而言，真正有价值的显然只有后者。此外，当不同维度的评测指标实际上依赖同一种信息源时，还会引发无意识的双重计分：视觉相似度、DOM 布局相似度与 VLM 静态截图打分表面上是三套独立算法，但其底层所依赖的都是静态画面的瞬时表征，三者并列求和，无形中便让静态视觉在整个评分权重中被单方面放大了三倍。

在大规模基准测试中，跨样本的大数定律确实能够平抑单次评估中偶然发生的评分扰动。在 ArtifactsBench 中，由 VLM 自主打分汇总出的模型梯队排名，与 WebDev Arena 上真实用户众包盲测投票所构建的全局排名呈现出极高的一致性，两者排名的吻合度高达 94.4%（100% 代表完全重合） (Zhang et al., 2025)。然而这一高相关性仅能说明 VLM 在宏观分布上与大众偏好的均值相吻合，至于其在单挑场景下能否贴近专业设计认知，依然取决于微观的成对决断精度。WebGen-Bench 尝试分别调用 GPT-4o、o3、Claude 以及人工 judge 对页面外观打分，尽管不同评测源给出的绝对分值整体平移浮动，但各家生成系统的相对位次几乎纹丝不动 (Lu et al., 2025)。这种一致性只说明了这几个 judge 彼此一致；当它们同时抱有系统性的认知盲区时，排名的稳定性完全可能掩盖共同的偏差。因此，利用自动 judge 对宏观模型梯队实施排位，其可靠性远高于让它为单一样本判定优劣。在以下两种关键场景中，大数平均的平抑效应将彻底失灵：其一是普遍存在的系统性感知盲区，例如当 VLM 看不清文字溢出时，频繁出现溢出缺陷的模型便不会因此在排行榜上遭受应有的惩罚，榜单再稳定也无法刻画该项缺陷的治理水平；其二是在线迭代等单次决策场景，在多轮修改过程中，系统每一步都必须在两版极其微弱的演变间做出单选裁决，一旦判断失准，留下的便是劣质的中间态代码。

现有的五类基准无论采取独立打分还是两两决胜，最后都收敛于逐件割裂评分后的平均，很少考察模型生成的多样性。其直接后果便是，一个只能熟练套用特定单一模版的模型，在每道孤立测试题中都有机会拿到高分。上一篇文章中剖析过的那些常见套路（例如白底配紫色微渐变、搭配 Inter 字体），在现有的逐件评估机制下很难被发现。

归结起来，VLM 在区分质量悬殊的生成物时表现出色，经由大规模样本均值平抑后给出的模型总体排名也足够稳固；然而一旦面对两个功能均无硬伤的相近版本、像素级微观排版瑕疵、以及深藏在运行态内部的数据断层，它便极易误判，此时无论外加多么详尽的文本 rubric，都无法弥补其在原始视觉输入端的感知盲区。同样，测试 agent 在严格遵循人类专家预置的高质量测试用例时，执行准确率堪比专业人工回归；可一旦赋予其自主探索权限，要求其自主推导测试要点并断言结果正误，其在缺乏真实业务预言机支撑的前提下，便会大面积漏检各类隐蔽缺陷。

哪些要求还很少被评到

在当下的 UI 基准中，至少有四类关键要求极少被系统评测，即便偶有涉足，也仅局限于能被自动化脚本执行的边缘环节：缺乏参考录像的开放式动画、第一次来的人和残障用户实际遇到的可用性困难、prompt 之外未曾写明的使用意图，以及跨几周逐步累积的代码修改。动画需要审视一段时序演变，版本修改需要对比多轮历史状态；而真实受众的阻碍与隐性意图，必须紧密锚定在具体的人及其所承载的实际任务上，这正是 fit 标准的核心所在。

动画

在预约页中点击取消操作，如果对应数据行瞬间凭空蒸发，用户很难立刻看清究竟是哪一行被移除了；一段简短自然的折叠动效，能清晰呈现出哪个时间段正在被释放。这种时序连续性存在于相邻画面的过渡缝隙中，然而目前的自动化评估输入给模型的，充其量只是从整段过程中抽取的零散切片。ArtifactsBench 所依赖的操作前、中、后三张截图正是这种离散采样的产物，论文作者明确坦陈，这类静态切片很难捕捉复杂交互中的真实流畅度 (Zhang et al., 2025)。若想提升采样密度，必须依赖屏幕录像。浏览器自动化测试框架 Playwright 的默认视频录制帧率为 25 fps (Feldman, 2026)，但在将视频输入大模型时，通常还会施加二次抽帧：支持原生视频理解的 Gemini 默认按每秒 1 帧进行切分采样 (Google, 2026)；旨在依循录像还原页面的 WebVR 基准，在向模型输入视频时也仅均匀提取数十帧，或者采用每秒 2 帧的采样率 (Dai et al., 2026)。然而在实际界面中，一段典型的 200 毫秒过渡动画在 25 fps 的原生录像中仅占 5 帧，若按每秒 1 帧的粗粒度进行下采样，极有可能整段微动效正好卡在两个采样点之间，导致模型一帧都没看到（图 3）。

t = 0 msplayed at ¼ speed Ⅱ

1 fps2 frames

2 fps3 frames

25 fps31 frames

25 fps,
enlarged

即便关键帧被成功捕捉，模型本身也往往难以分辨细微的时序动态。TimeBlind 曾向多个多模态模型输入成对的对比短视频：同一组视频中的主体、背景与几何关系完全一致，唯一的变量在于动作在时间轴上的展开轨迹（例如一段视频中人物行进速度逐渐加快，另一段则逐渐变缓）。实验统计显示，在随机猜测基线约为 6% 的设置下，参测的二十多个前沿模型中成绩最好者准确率仅约 48%，而人类受试者的识别率高达 98% (Li et al., 2026)。这类物理世界的常规动作测试揭示出，模型在分辨时序非线性变化等通用时间感知能力上仍存在明显缺陷。

在存在确定性参考录像的前提下，动效评测尚能摸索出一部分解法。WebVR 与 Animation2Code 均属于这种还原性任务：系统先向模型输入目标页面的交互视频录像，要求其逆向编写前端代码实现完全相同的动态效果，最后再对比生成录像与参考录像的时序特征。WebVR 促使 VLM 结合生成录像与底层代码，依据细化 rubric 项逐条审查，其中交互与动效构成独立维度。从整站作品综合维度看，最好的 judge 与 UI/UX 专家在方案二选一时的裁决一致率可达 96%，但论文并未单独披露动效维度的一致率；若仅输入动态录像，评估系统难以区分头部强模型之间的细微差异，而若仅输入代码，甚至连完全没有渲染出可视内容的空白页面都可能混得高分 (Dai et al., 2026)。Animation2Code 则尝试从数值算法层面解耦时间维度的一致性：通过在屏幕空间追踪特征点，定量测算生成动效与原版录像在运动矢量与瞬时速率上的偏差。实验表明，当把几项自动化程序指标和 VLM 评分分别拿来预测众包标注者在候选动画间的倾向选择时，在外观、时间动态与整体质量三个考察维度上，均存在至少一项纯程序指标比 VLM 更接近人类选择 (Ji et al., 2026)。

而在纯自然语言驱动的全新界面生成场景中，缺少可供逐帧对齐的真值视频，动效节奏是否协调往往只能由模型凭空定夺，目前尚无经过检验的自动动效 judge。更何况，所谓“得体的动效节奏”本身就不存在标准答案。Material Design 设计规范建议移动端过渡时长控制在约 300 毫秒，桌面端则压缩在 150 至 200 毫秒之间 (Google, 2016)。同一段动画移植到大屏桌面端可能会显得拖泥带水，放在触控小屏上就恰如其分。要对动效体验给出公允评判，必须预先确立其所处的硬件载体与所要表达的状态转换语义。

真实用户的可用性和无障碍

哪怕预约功能都跑通了，初次使用的用户依然可能遇到阻碍：比如取消预约的入口没有任何文字说明，或者点击提交后页面没有反馈，用户不知道预约是否成功。测试脚本照着预设步骤走，新手必须自己摸索。现有的基准里，可用性多数由模型来打分。WebCraftBench 的可用性得分就是让模型自己操作应用并记下操作过程和各个状态，再由评估模型打分：外观排第一的 GPT-5.6-Sol 在可用性上排到第六 (Liu et al., 2026)；但这个分数到底有多接近真人的体验目前尚缺对照，要看了它的 rubric 才知道它到底覆盖了哪部分，它大概也只覆盖了 usability 里 craft 的那一半。Luera 等人研究过更简单的情形：让 VLM 仅凭单张截图预测众包用户的主观感受，在两两判断“哪个界面更好用”时，模型判断与人群选择的一致率只有五成左右，和抛硬币差不多 (Luera et al., 2025)。

让大模型依循经典可用性准则逐屏排查截图，形式上直接继承了启发式评估的衣钵，只是评估者被置换为了自动化算法。Zhong 等人将用户在两款移动应用中执行任务时留存的 3 至 9 张截图输入 GPT-4，促使其检举违背可用性准则之处，并将结论与五位资深专家人工排查的结果交叉比对。在汇总各方发现的缺陷池中，GPT-4 在租房应用上覆盖了 73% 的总体缺陷，而五位人类专家合计覆盖了 57%。然而深入细分结构会发现，在需要跨越多个页面时序才能察觉的连续性缺陷中，模型在 7 处痛点中仅能捕获 3 处，而专家群体合计捕捉到了 6 处；更为致命的是，模型提出的所谓缺陷中有 43 项经复核属于无中生有的虚警，而专家群体的误报仅有 6 条 (Zhong et al., 2025)。大模型查得虽广，但容易遗漏跨页面的交互断层，且输出的清单中掺杂着大量误报，依然需要人工逐条筛过。

启发式评估毕竟只是对着准则查页面，不能代替真实用户的试用。于是有人尝试用多模态模型来模拟用户交互。比如在测试用户第一眼往哪点的“首击测试”（first-click testing）中，Kuric 等人收集了三千多名真实受试者在 45 项任务中的首次点击，和 GPT-4.1 模拟的点击做对比：在 53% 的任务里，模型点击的位置和真人有显著差异；给模型加上角色设定、链式思考或调整采样参数，都没能拉近这种偏差，只是让模拟的结果看上去更可信 (Kuric et al., 2026)。UXAgent 的作者也明确说明，虚拟智能体适合在正式用户研究之前用来调试方案，不能代替真人测试 (Lu et al., 2025)。

无障碍评估关乎有障碍群体能否顺利使用界面。如果预约页只用颜色区分时段是否约满，色觉障碍者无法辨别，读屏软件也读不出颜色含义。无障碍设计有成熟的 WCAG 准则和自动化检测工具，但工具擅长检查的是静态属性有没有漏填、颜色对比度够不够。有的条款必须改变系统设置才能检查：比如 WCAG 2.3.3 要求除必要动效外，交互触发的动画必须允许关闭 (World Wide Web Consortium, 2026)；这需要测试环境去模拟“减少动态效果”（prefers-reduced-motion），检查动画是否停了下来。

只靠自动化工具也无法断定一个页面无障碍做得好不好，W3C 的评估规范强调人工审查必不可少 (World Wide Web Consortium, 2026)。英国政府数字服务局（GDS）建过一个预埋了 143 处无障碍缺陷的测试页面，10 款检测工具联合起来也只查出了 71%，有 42 处缺陷全员漏报，包括只用颜色区分链接这种常见问题 (Duran, 2017)。工具能检查标签在不在，但理解不了内容传达得合不合适。Calò 等人指出了“语义层面的无障碍断层”：如果图片的替代文本写成 alt="image"，语法检查能过，读屏软件给视障用户读出来的就是毫无意义的“image”。他们用模型扫描三款前沿模型生成的 300 个界面，报出了 541 处通过了规则检查但没有实际意义的语义问题，其中含义模糊的按钮和链接占了一半以上；这些问题由模型报出，没有逐条经人核实 (Calò et al., 2026)。

除开规范与工具，终究需要真实受众的亲身参与。W3C 明确倡导引入残障人士与老年群体进行联合测试，以发现仅凭合规审计无法触达的真实可用性问题 (World Wide Web Consortium, 2026)。即便预约系统中的每个时段都有正确的 ARIA 标签、读屏工具能逐个无误朗读，面对一周七天、每天十余个连续排期，依赖语音反馈的用户可能被迫耐着性子聆听几十条报读信息才能摸索到一个空缺席位。这种深重的交互疲劳感从不体现在代码 lint 规则清单里。而在现有的公开研究中，针对 AI 生成界面引入残障用户进行系统性实测的工作还很少见。

用户拿它做什么

“照着房源照片搭一座房子”这句提示词仅仅交代了产物的形态，没说用户到底想拿它做什么。面对完全相同的 prompt，想测量自家沙发能否塞进客厅的租客会这样提，想把空间漫游链接直接发给父母在手机上查验的租客也会这样提，但两者在实现细节上的诉求方向天差地别。默认遵循通用平均标准进行生成，或许能误打误撞契合一部分人群；而对于未被击中的诉求方而言，交付的产物哪怕看上去完整，在解决实际问题时依然形同废纸。荒谬之处在于，当基准测试仅根据原始 prompt 进行逐项验收时，盲猜命中与完全偏航的两个版本在评分体系下将获得完全相同的分数。能够从字面提示词直接逆推的显性边界，一旦被物化为 rubric 条目或自动化测试脚本便容易校验（现有基准中所谓的“满足需求”或自动化断言查证的正是这部分）；但大量隐性约束从未被写进 prompt，甚至看房者本人往往也需要先看到第一版粗胚，才会猛然想起需要测量沙发尺寸这回事。

为了触碰 prompt 之外的暗物质，现有基准只能试图通过人工推演，预先替假想用户拟定未明说的潜台词。InteractWeb-Bench 设定了一个模拟用户智能体，其内部预埋了一套未曾写入提示词的隐藏约束，仅在被模型主动盘问时才会按需释放，以此考察生成模型能否主动识别信息空缺并澄清需求 (Wang et al., 2026)。实验表明，尽管九个主流模型在理解显性需求大意上的得分均超过 3.9 分（5 分制），但能够主动追问出隐藏约束的概率普遍低于 40%，多数时候模型会将残缺的指令直接当成确定性规范全盘付诸实现。X+Slides 则针对同一套原始素材虚构了三类不同诉求的听众画像，调用大模型依循听众背景为信息要素赋权，进而评估生成的演示文稿是否击中了对应群体的核心关切 (Chen et al., 2026)。然而这类评测捕获的终归只是实验室人工预设的画像切片，至于坐在屏幕前的特定个体究竟属于哪类受众、在何种情境下使用，评测基准依然无从得知。

跨几周的修改

现有的多轮代码修改评测几乎都在同一次会话里进行。MT-Web2Code 让模型基于自己前一轮的代码继续改，相比每轮都从正确的上一版出发，Kimi-K2.6 改到第五轮时综合评分低了 23.8 分（百分制） (Li et al., 2026)；FronTalk 同样发现模型在后续轮次里容易改坏之前做好的功能 (Wu et al., 2026)。EvoGenUI-Bench 评测连续五轮修改，表现最好的模型在各轮的平均通过率有 74.9%，但五轮全部做对的会话比例降到了 37.3% (Peng et al., 2026)。单看某一轮的通过率，容易忽视连续修改带来的问题积累。

更为重要的是，这类基准中的修改脉络往往是由出题人预先写好的剧本。在真实的软件生命周期中，实验室预约系统的培训资格限制往往要等几周以后才会被正式提上日程；那时系统里早已存下了大量真实历史数据，穿插着管理员直接改过的说明文字，出题人很难在第一天就凭空设想出这些状态。静态代码分析能够对代码的可维护性给出理论估算，但这种理论指标到底能在多大程度上预测下一次真实业务修改的成败，在 UI 领域依然缺乏实证数据。若想真实评估这种耐磨损度，必须长期跟踪一个 artifact 在数周乃至数月里的演进轨迹，记录每一次业务变更诉求、源码修改差异、以及修改之后暗中遗失的历史资产。在公开的数据集里，记录真实业务需求、跨越数周修改 UI artifact 的评测数据还很少见。

训练用的信号

生成界面的大模型直接输出的是代码，但真正决定体验优劣的质素，必须在代码渲染运行之后才能被感知：布局如何展开、动效如何衔接、交互点击后状态迁移是否精确。海量代码与文档的预训练能够赋予模型实现语法的基本功；而代码渲染后视觉呈现如何、交互体感怎样，则必须依赖一套运行时环境把代码真正跑起来，再将观测到的表征折算为量化反馈。这套反馈机制的思路也差不多：要么依赖 VLM 审看截图打分，要么驱动 agent 执行测试脚本。在学术评测中，针对数百个测试样本跑完这套流程便足以结题；但在强化学习（RL）的训练循环中，系统需要对源源不断采样生成的海量候选持续打分。邀请真人深入试用数周的做法在阶段性实验中尚且可行，直接放入高频训练循环则在工程上难以实现。训练流水线实际能够消费的，多是不依赖人工介入、在单样本上极短时间内便能自动算出的机器信号。

画面的信号又多又便宜

在现有的公开训练工作中，合成语料、清洗示范数据乃至设计奖励函数，大多依赖静态视觉画面。获取成本最低的当属“代码-网页截图”成对数据。WebSight 的庞大语料完全由自动化管线合成：由一个语言模型负责构想网站需求，另一个模型负责写出 HTML，随后在无头浏览器中自动渲染并截屏，由此低成本构建起两百万对跨模态数据 (Laurençon et al., 2024)。在监督微调（SFT）阶段，示范数据的准入清洗同样紧密锚定在静态画面上。WebCode2M 采集了一万个真实网页的人工评分，训练出一个给页面质量打分的模型，并依此从海量原始抓取网页中大刀阔斧地过滤掉了超过半数的劣质样本 (Gui et al., 2025)；UICoder 则促使模型自我迭代生成界面代码，仅保留能够成功编译、且经由跨模态表征模型 CLIP 判定与文本描述高度契合的代码样本，以此作为下一轮训练的语料 (Wu et al., 2024)。

WebGen-R1 在为强化学习设计奖励时，除了基础门槛外，主要打分也集中在画面上：代码要通过语法检查并成功渲染；之后调用 VLM 对多个路由的截图给出 0 到 5 分的外观和功能评分，加上控制台报错情况作为基础功能分；browser agent 只在离线评测时调用，没放进强化学习的奖励里 (Jiang et al., 2026)。在这些实践里，大部分信号关注的是代码能否编译、画面好不好看、图文是否匹配，很少在训练中实际操作界面。

偏好对齐训练借助人工或奖励模型比对候选方案。UIClip 从真实网页出发，通过算法破坏页面的文字对比度、对齐与间距，造出两百多万对“原版更好”的样本 (Wu et al., 2024)。这类合成负例反差很大，相当于训练模型识别明显破损的页面；而在两个挑不出硬伤的方案之间挑选时，往往需要设计师的判断。Wu 等人邀请 21 位设计师对模型生成的界面进行排序、撰写批注、画草图或直接修改，收集了 1,460 份反馈 (Wu et al., 2026)。四种反馈各自转成成对的比较，训练出四个奖励模型。这几个设计师奖励模型都从 UIClip 出发继续训练，新加的反馈数量还不到 UIClip 合成样本的千分之一，再分别用来训练生成器。在人工评价中，用草图训练出的生成器明显胜过用 UIClip 当奖励模型训练出的生成器，基于直接修改微调的生成器略有优势但未达显著差异，而依据排序和批注训练的生成器甚至落后于 UIClip。六位研究人员抽样复核这些标注时发现，仅凭排序推导出的偏好判断与研究者的一致率只有 49.2%，而直接修改得到的样本一致率达到 76.1%。一个可能的原因是：排序时设计师复杂的权衡被压缩成了一个标签，其他人很难稳定复现；而修改后的页面把具体的改法直接落实到了版式上。

依赖这类信号也容易让设计变得雷同。网页设计本身就在趋同，一项追踪 2003 年至 2019 年网站形态的研究发现，2007 年前后起网站布局出现了趋同趋势 (Goree et al., 2021)。Anthropic 在分析为什么模型偏爱 Inter 字体、紫色渐变且很少主动加动效时提到：在预训练数据里，这类不容易出错的安全选项占了多数 (Rajasekaran et al., 2025)。自动打分模型学到的，也可能是多数标注者给高分的稳妥做法。用它来筛选数据或做强化学习，能抬高平均水准，但也可能把作品都推向这几种样子。

运行和修改的信号还很少

在真实浏览器里跑多步操作再给奖励，开销要大得多，实际用来训练的工作很少。WebGen-Agent 尝试把交互评估放进强化学习：每步奖励由截图外观分和 browser agent 执行测试的准确率加权组成，驱动 Qwen2.5-Coder-7B 的功能准确率从基线 12.4% 经过监督微调提升到 38.9%，强化学习后进一步提升到 45.4% (Lu et al., 2025)。WebGrader 让模型根据需求写出操作流程与预期结果，再用测试脚本驱动页面执行，记录画面和内部数据状态，再由判决模型判断流程是否达标。其奖励中流程通过率占七成，外观占三成。从相同的基线模型出发，采用 WebGrader 训练的模型在基准测试中功能准确率达到 52.01%，高出基于 VLM 加 browser agent 训练组的 42.66%。如果直接让 browser agent 当 judge，面对人工注入故障的测试页面，其故障召回率只有约 60% (Chen et al., 2026)。

轻量级的替代方案则退求其次，仅检测交互触发后页面是否存在活性响应。Qwen3-Coder-Next 根据 DOM 树结构自动枚举可交互节点并模拟点击，随后调用 VLM 交叉比对点击前后的瞬时截图，以此剔除交互坏掉、点击后毫无响应的样本 (Qwen Team, 2026)；然而状态响应是否符合业务规范，依然需要严谨的预期断言才能成立。MiMo-V2-Flash 将 Playwright 录制的全周期动态交互视频输入视频大模型进行评分，研发团队认为这比看静态截图更少看错画面 (Xiaomi LLM-Core Team, 2026)。尽管动态视频完整留存了动效证据，但模型在实际判别中究竟能否精准识别不自然的时序卡顿与过渡失真，技术报告中并未披露具体的实验数据。

用于训练修改代码的数据更难构建，需要同时包含初始版本、修改要求和改好的目标版本。现有数据大多在单次会话内：VisRefiner 从七千个页面出发，一部分加规则扰动，另一部分收集模型自己犯的错，按修改推进的程度给奖励 (Deng et al., 2026)。但模型做多轮对话，未必能顺带学会怎样修改代码。在图表代码任务上，MM-ReCoder 发现，让模型自由修改两轮并按第二轮的表现给奖励，接近一半的样本在第二轮只是把第一轮代码原样抄了一遍，正向修复的比例只有 3.4%；让同一组采样共用同一个第一轮、专门训练怎样改，改进的比例升到 14.4%，同时还有 8.4% 的负向改坏风险 (Tang et al., 2026)。像实验室预约页那样跨越几个月、在加新功能的同时还要保护已有数据和手工定制代码的训练数据，在公开资料里目前还没有成规模的。

奖励没看到的地方

奖励函数的漏洞容易被模型利用。UICoder 用 CLIP 评估截图和需求的一致性，发现只要画面里出现包含 prompt 关键词的文字，CLIP 有时就会给出高分，迫使团队追加了和参考图的相似度约束 (Wu et al., 2024)。GLM-5 训练幻灯片排版时引入了几何规则与留白率打分；模型学会了把排不下的长文本直接截断丢弃，或者过度调整间距来凑出合规的版面 (GLM-5 Team, 2026)。版面上没有文字溢出了，但内容也丢了，因为没有哪一项奖励去核对内容是否完整，团队的应对是改进渲染器。在对比前后版本的奖励设计里也有类似情况：ReLook 对修改后的变差引入惩罚，模型的应对策略是尽量不改 (Li et al., 2025)；MM-ReCoder 尝试对第二轮相对第一轮的进步给奖励时，模型学会了故意在第一轮交出较差的代码，以此在第二轮拿分 (Tang et al., 2026)。

在无障碍优化领域，A11yn 将 axe-core 的违规按严重程度加权并按 DOM 规模归一化后作为惩罚：强化学习后，模型在 axe-core 下的违规率下降了 87.5%；但换用没参与训练的 AChecker 验收时，违规率下降幅度只有 58.1% (Yoon & others, 2025)。两个工具相差近 30 个百分点，这可能说明模型学到的一部分做法针对的是 axe-core 的具体规则，也可能只是两款工具覆盖的规则本来就有差异。更重要的是，这类规则检查查的都是属性，像 alt="image" 这种形式合规但在语义上没有意义的占位符，纯规则奖励依然查不出来。

进步的先后

强化学习每一步更新都要汇总一批样本的奖励。偶发的误判主要让信号变嘈杂、拖慢训练；真正平均不掉的是两类系统偏差。一类是奖励模型看不到的盲区，从头到尾不会产生负反馈（图 4）；另一类是奖励系统性高估的东西，模型会在生成中反复钻空子拿分，UICoder 和 GLM-5 遇到的情况都属于这一类。像 GRPO 这样给同组候选按相对高低算奖励的做法，信号质量很可能随着训练深入而下滑。起步时同组作品差距很大，有的渲染失败，有的版面错乱，VLM 容易分清高下；等到模型有了基础形态、候选之间只差细微区别时，VLM 在相近样本上的打分误差就会盖过实际差距，相对胜负里掺进了更多随机猜测，模型的进一步提升也会变慢。

Frame

an instant

Sequence

minutes

Versions

weeks

Integrity

against its medium

renders, no overflow

WebGen-R1 · UICoder · ReLook · UIClip · GLM-5 · A11yn

no crash, no freeze

Qwen3-Coder-Next

nothing newly broken

ReLook

Craft

against a trained eye

hierarchy & balance

WebGen-R1 · WebGen-Agent · WebGrader · WebCode2M · GLM-5 · designer feedback

motion & feedback

MiMo-V2-Flash

emphasis still holds

Correctness

against the facts

right numbers & parts

WebSight · UICoder · Ortho2CAD

right result, every step

WebGen-Agent · WebGrader

edit on target, rest kept

VisRefiner · MM-ReCoder

Fit

against the purpose

the point at a glance

newcomers get it done

meets the real need

none 1 · 2–3 · 4 or more works checked only within one editing session

按照这个逻辑推断，最先取得突破的通常是作品从破损到完整：页面能正常渲染，版式不再大面积散架。这两项都属于 integrity，核对时不需要知道作品本该是什么样。能渲染由程序判定，宏观版式坍塌也容易被轻量脚本或 VLM 抓到，这类信号便宜且源源不断。训练早期的候选样本在这一层表现差异极大，能稳定提供清晰的比较梯度。现有文献里有训练前后对照数据的，也几乎全集中在这类程序化的关卡上：WebGen-R1 把能渲染作为硬性门槛，单靠监督微调时有效渲染比例只有 30.69%，叠加强化学习后升到了 95.89% (Jiang et al., 2026)；ReLook 经过端到端训练，有效渲染率从约四成翻倍到约八成 (Li et al., 2025)；GLM-5 生成的幻灯片符合 16:9 画幅的比例也从 40% 提到 92%，只是报告里没有区分其中有多少是靠截断内容凑出来的 (GLM-5 Team, 2026)。公开研究里很少见到版面散架是否同步减少的训练前后对照，这一步更多属于推断。值得留意的是，integrity 内部也有难以惠及的盲区：文字微小溢出、控件几个像素的重叠，VLM 往往看不出来；即便按 DOM 盒模型写死坐标规则去拦截，模型又可能像 GLM-5 那样用截断内容的办法去机械应付。

第一眼的视觉观感属于 craft。在差距明显的范围里，这项能力很可能是伴随着 integrity 一起提升的：上一篇文章开篇提到的现象，正是前沿模型单次生成时已经能交出排版整齐、间距均匀的界面。这份进步来自哪里，现有材料很难拆开：预训练语料里的安全设计、筛选过的微调示范、以及强化学习阶段 VLM 给的外观奖励，可能都在起作用；加上用来评判训练前后外观分的多模态模型往往和提供奖励的模型属于同类，分数的涨幅不能直接当作审美实质进化的依据。

紧接着是 correctness，包含功能是否做对、内容是否正确两部分。交互功能必须在动态操作中才能展现，如果预期结果能够事先写清，就可以做成自动化测试。在真实环境里按脚本跑一遍，查得到截图看不到的存储状态，给出的反馈远比看画面可靠，WebGrader 正是靠这类信号训练出了交互逻辑更稳的模型。这种做法的代价同样明显：预期结果要事先写对，让模型代写又会掉进预言机难题；而且在浏览器里多步运行的开销远高于单次截图，这类信号在训练中的数量很有限，能覆盖的也只是预先写好的几条测试路径。

对于内容是否正确，只要有明确的参照物，就可以交给程序比对。照着设计稿复原页面时，脚本可以在文字、坐标和颜色上逐一核对，这类任务还能像 WebSight 那样大批量合成；根据工程三视图生成 CAD 参数时，直接运行代码计算三维实体的重合度，Ortho2CAD 就是把体积重合指标当作强化奖励 (Joglekar et al., 2026)。这类比对由确定性算法完成，不受 VLM 看不清的影响，成本也低，在有确定参照的任务上进步可能很快。但大部分真实的 UI 需求只是一句自然语言描述，并没有现成的设计图可供逐块核对；在这些开放场景里，核对内容只能退到让 VLM 判读或者依赖测试，因此就 correctness 整体来说，便宜可信的强化信号依然只覆盖了有限的局部。租客拿到的公寓照片同样是事实参照，但照片和浏览器里的三维场景很难一一对齐，最终还是要交给多模态模型看图比较，这种跨模态核对到底有多少把握，目前还缺乏公开的测量。

当模型越过基础门槛、交出的界面都挑不出大毛病之后，要进一步分清哪种构图更贴合特定内容、哪套细节处理得更讲究，难度就完全不同了。候选方案在这些细节上的差距通常很细微，主流 VLM 在相近对比中给不出稳定的优劣指向，craft 在高阶打磨上的进步就会慢下来。模型生成的设计因此容易收敛到相似的安全状态：乍看挑不出硬伤，彼此之间十分雷同，上一篇文章里讨论过的几种常见生成风格正是这种倾向的体现。专业设计师画的修改草图虽然能提供具体的方向指引，但人工标注成本高昂，在规模化训练面前很难源源不断地供给。

进步最慢的，是那四类很少被系统评测到的领域：没有参考录像的动画、第一次来的人和残障用户实际遇到的困难、prompt 之外的用途，以及跨几周的修改。这些方面目前虽然也有一些自动检查的替代手段，但要么没有和真实体验认真校准过，要么对照下来发现偏差很大，比如模拟智能体的点击坐标在过半任务里和真人不同。拿这些未经校准的工具做奖励，很难说清模型学到的是要求本身，还是只是迎合了检查工具自身的偏见。至于 prompt 之外的用途，在现有的公开训练数据和奖励设计里，目前甚至看不到针对它的信号。

如果某项要求能写成可重复执行的程序，并且这个程序的判断结果与专业人员的评价做过认真比对，训练就能获得一种便宜又可靠的新信号，该维度的进步也就有望提前。为安卓多任务分屏训练的遮挡检测器如果能迁移到通用 Web 页面上，几个像素大小的版式缺陷也可能较早减少；在有真值录像时，Animation2Code 用的时序特征指标可以廉价地核对动效节奏；而在无障碍方面，A11yn 已经把规则检查器引入了奖励计算，只是这个检查器本身还没有和人的判断对照过。

这项推断有两处不确定。第一，功能逻辑的进步未必完全依赖专门的 UI 奖励，通用软件工程任务中训练出来的代码调试和测试推理能力，很可能直接迁移到前端开发中，推动功能成熟得比单纯依靠 UI 信号推断的更快。第二，目前公开的研究大多只单独汇报某一项训练前后的变化，比如有的论文测成功渲染率，有的测任务通过率，尚未有在同一场联合训练中对这几类能力演进速率做严格横向对照的公开实验。

交付时能补上的检查

生成系统是指包裹在模型外面的那一整套工程环境：负责启动 artifact、截图和运行测试的工具链，保存各个历史版本的存储介质，以及决定下一步该做什么的流程编排。有些检查手段成本高昂，训练阶段每个样本跑一遍吃不消，基准测试也很少针对数百件作品挨个执行；但真正交付给用户时，系统只需为眼前这一个需求服务，高成本的检查只要做一次就说得过去。系统可以把渲染出来的截图、真实运行的操作反馈和历史版本重新交还给模型，也可以在对话中直接向用户求证。在一组修改可视化代码的任务中，同样以 GPT-4o 为底座，单轮直接生成的通过率只有 55.75%；而换成一个先规划、生成多套候选方案、渲染检查后再选优细化的 agent，任务通过率提高到了 67.99% (Rahman et al., 2026)。

让模型看到画面和过程

WebGen-Agent 生成网站时，把渲染截图和 browser agent 的操作测试作为两路反馈分别交还给模型。加入视觉截图主要提升了外观得分；加入操作测试则显著改善了功能准确率，但外观分略有回落，研究者的解释是调试功能时偶尔会改坏既有的版面 (Lu et al., 2025)。不仅如此，新增功能同样容易弄坏已有逻辑。TDDev 让 agent 一边开发网页应用一边运行测试，并对比了几种安排测试的时机。其中逐个功能推进的模式专门用来防范这类回退：每完成一个新功能，就把此前所有通过的测试用例重跑一遍；另外两种策略则是整个应用写完后再统一测试，或者全权由 agent 自行决定测试时机 (Wan et al., 2026)。

外部反馈究竟能帮上多大忙，取决于测试者自身的排查能力。在 TDDev 的实验中，以 Claude Sonnet 4.6 为底座且由 agent 自主决定测试时机时，功能准确率（由基准中人工编写的测试集衡量）从不做测试的 67.8% 攀升至 91.5%。然而换成 Qwen3.5 开发并由它自己测试时，无论哪种测试安排都没有带来明显提升。它经常把自身在浏览器里的误操作归咎于被测应用，把原本实现正确的功能误判为失败；若改由 Claude Sonnet 4.6 来执行测试，Qwen3.5 写出的应用功能准确率提升了约 7 到 9 个百分点，但其中只有一种测试时机在统计上显著。模型审视自身生成的画面时也存在相似的盲区。Anthropic 的一份工程实践记录提到，agent 评价自己的作品时往往倾向于大加赞赏，单独设置一个专门挑刺的评判者，往往比让它自我反省有效得多；此外，rubric 中诸如“博物馆水准”这类主观措辞，还会把生成结果推向某种特定的刻板视觉风格 (Rajasekaran, 2026)。

用户在场，可以直接问

真正交付时，用户本人就在交互界面前，系统可以直接求证他们究竟打算拿作品做什么。以生成三维房子的任务为例，租客可能只想先俯瞰弄清户型结构，也可能想推门走进去看。如果是前者，一张平面的空间鸟瞰图就能解决；如果是后者，就必须构建流畅的第一人称室内漫游。在需求尚未完全定型时，先生成几套差异明显的候选方案供人挑选，也能协助用户明确自己的真实意图。不仅如此，用户给出的补充理由还会直接改变后续需要核查的技术指标。如果看房的人压根没提摆放家具，房间尺寸标得准不准，取决于他们拿这座房子做什么；可一旦他们说明想知道沙发能否塞进客厅，系统就必须估算室内尺寸并在场景中标注出来，至于估算得是否准确，也可以拿照片里的门和地砖去核对。

然而系统什么时候该主动提问、问多深，不同编程 agent 之间的策略差异极大。SpecBench 设计了让 agent 专门向模拟用户提问并整理出需求规格书的评测任务，全程不涉及编写代码。其中一项实验要求 agent 通过有限轮次的提问，推断用户对 80 道潜在设计决策的倾向：当允许提问的次数从 0 次放宽到 10 次时，Claude Code 和 Cursor 在约八成的任务实例中推测得更加准确；Gemini CLI 只有 61% 的任务实例分数有提高，甚至在 17% 的测试里提问次数没用完就提前提交了结果 (Wang et al., 2026)。值得说明的是，SpecBench 和 InteractWeb-Bench 中负责应答的都是大模型模拟出来的虚拟角色，SpecBench 的作者也特意强调，模拟出来的用户和真实的人不一样。关于人在这一类判断中所处的核心位置，The Human Is Part of the Agent 做了更深入的探讨。

保存每一版，接着改下去

系统只有完整记录下每一个版本及其对应的检查结果，才能在不同版本间对比优劣，并在恶化时安全回退。在模型反复修改自身代码的过程中，后改的版本往往并不优于早期版本。Xiong 等人测试前沿模型依照设计稿还原页面并自主迭代代码的表现：在以真实网页截图为基准的 Design2Code 测试中，整体相似度（采用百分制衡量）在 GPT-5.4 经历第一轮自我修复后微升了 0.76 分，随后便震荡下滑，在全部 15 轮迭代中有 10 轮的表现甚至不及初始版本。研究者观察到，模型在修复某个局部的同时，经常改坏原本已经正确的另一处区域 (Xiong et al., 2026)。在这次测试中，表现最好的一版恰好出现在第一轮修改之后，如果系统没有完整沉淀历史快照，就无法精准找回这个最优解。WebGen-Agent 采取的策略是在连续出现运行错误时退回上一个稳定状态，并在最后依据操作测试与截图得分综合选出最优版本交付给用户 (Lu et al., 2025)。迭代何时终止，同样取决于手头还能核验什么。当预设的硬性规则全部跑通后，剩余差异若仅关乎配色、间距或特定的业务意图，自动化流程往往无法进一步甄别好坏，此时就需要借助人工经验或让用户亲自裁定。

在实验室预约页的场景里，当系统运行了三个月之后，需要维护的已经是一个存有大量真实数据的界面。库里存着几百条历史预约，管理员直接改过说明文字，这时如果追加“新增一台实验仪器”的需求，生成系统不仅要实现新功能，还必须兼顾既有数据与人工定制的痕迹。说明文字如果写在代码里，而模型单纯依靠上下文里的旧代码重新生成，管理员改过的内容就可能被悄悄覆盖。以 v0 与 Claude Design 这两款代表性工具来看，在这一维度上的支持还很有限。Vercel 的 v0 在设计模式下会先在独立面板中暂存用户的手动调整，待用户应用修改后，再把修改意图打包成提示词让模型生成新版本 (Vercel, 2026)；Claude Design 支持对话、批注和直接编辑，但官方文档提到它尚未支持版本历史追溯 (Anthropic, 2026)。两款产品的文档都没有承诺用户手动调整的内容在下一次全量修改时不受影响。要检验旧资产是否完好，同样必须深入底层数据：例如从按周排布改成按月展示后，所有预约在视觉布局上的位置都发生了变化，比对前后截图根本看不出预约记录有没有丢，只有直接对比底层数据表才能下结论。

引入这套交付流程，代价同样不可忽视。一部分代价体现在机器算力上，能够明确计量：TDDev 在构建单个应用的过程中，平均会额外消耗 100 多万到 700 多万 token (Wan et al., 2026)。另一部分代价则转嫁给了用户的时间。即便系统能把提问收敛得更具体、把候选方案的差异呈现得更清晰，依然需要用户耗费精力甄别并做决定。至于跨几周的修改，自动化工具更难独自承担：哪条旧规则还有人依赖，如果不曾被专门记录，就只有用过这几周的人知道；一旦破坏了什么，也只有他们能发现和补救。

怎样才能说一个 UI 好

评判一个 UI 做得好，总是在某几项具体要求上好，而每一项要求都需要明确的证据来支撑。遇到自称“擅长 UI”的模型或工具，首先要看面对的是哪一类界面。在三维房子这样的任务里，要保证的是画面能渲染、没有大面积穿透和错位，并且大致符合户型，这类要求在生成完成的那一刻就能查验，现有的截图打分和查破面的脚本确实能看出一部分水平；但一旦涉及这个三维模型能否用来核实家具尺寸、甚至辅助租房决策，拿照片核对户型的做法还缺乏经过检验的测量。换到实验室预约页，情况就不同了：真正要紧的逻辑分散在操作过程和版本演进里，比如两个人同时预约时共享表里的记录，或者第三次修改需求后旧预约是否还在。对这类界面，榜单分数几乎碰不到核心；比起看模型在基准里得了多少分，更该看交付系统有没有按人写好的预期执行自动化测试、执行测试的模型自身靠不靠得住、动手改代码前有没有主动问清用途，以及改坏了能否安全退回。

从现有的训练与评测机制推断，各项能力的演进次序主要取决于反馈信号的获取成本：作品从坏掉到完整进步最快；功能逻辑与事实内容的准确性次之；页面普遍整洁之后，区分细节手艺的高下就会放慢；而那四类很少被评测到的领域最为滞后。这种反差在技术指标上往往看不出来，因为眼下的基准评测和模型训练依赖的是同一批容易获取的表层证据。页面能成功渲染、视觉间距均匀，在训练时能稳定拿到奖励，在基准测试中也能拿满基础分；但第一次来的人和残障用户实际遇到的困难、prompt 之外的用途，以及跨几周的修改中出现的问题，在训练中很难受到有效惩罚，在现有榜单里也几乎体现不出来。这就解释了为什么排行榜名次不断攀升、生成的画面愈加精致，与那些深层要求是否真的改善了，彼此其实是脱钩的。

一项检查能不能交给自动化程序，主要取决于评判它的标准在生成前是否已经存在、握在谁的手里。通用的代码语法和布局规则写定一次就能复用；但预约提交后数据库里该记录什么、租客拿三维模型具体做什么，只能由懂业务的人和实际用户提供。只要人类在交付时把这些要求写成具体的预期结果（例如两个人同时预约同一时段，后提交的人应当看到名额已满），系统在后续每次修改代码时都能自动重跑验证；这比在几个候选版本之间打分，或者给出一句抽象的评价，能提供切实得多的约束。

往前看，prompt 之外的用途与跨几周的修改所需的数据，或许正是从这种交付过程中自然留存下来的：用户对追问的澄清、在界面上手动微调的痕迹、自动化测试捕获到的回退，构成了包含真实上下文与修改意图的样本。这项推断只适用于 prompt 之外的用途与跨几周的修改；没有参考录像的动画并不在此列，第一次来的人和残障用户实际遇到的困难同样无法单靠这套交付记录自动补齐：初次到访者的认知障碍、残障用户的交互疲劳，要等这些人亲自用起来才会暴露。要把机制变成现实，工具层面也有待完善：像 Claude Design 尚未支持版本历史追溯，v0 也未承诺全量重新生成时不会冲掉用户手动微调的代码；而直接利用这类交付记录训练模型能否带来实际提升，也尚未见到公开实验的验证。