Marico's space
最近折腾 AI 应用构建工具，发现大多数评测基准都停留在"这道算法题能不能做出来"这个层面。说实话，这跟真实场景差距挺大的。
真实用户的需求往往是混乱的：截图、视频、PDF、半个写好的项目、互相矛盾的后续需求、或者用户已经拍板的设计方案全混在一起。AI 代理得自己判断是应该先讨论、规划、原型还是直接开干，然后还要保持之前决策的一致性、产出能跑的结果、做测试、用户改方向时还得能兜住。
Eazo 最近发了一套基准测试，就是围绕这个完整创作链条来设计的，而不是一堆孤零零的代码生成题目。
这套基准测试包含 103 个真实用户的创意任务，分为七个能力板块：
任务涉及多轮交互，包括图片、视频、CAD/STEP 文件、文档、现有项目、设计反馈、回滚请求、浏览器 QA、导出和发布等场景。
用户的原始表述直接提交给系统。当 AI 代理提问时，模拟用户只回答任务中已有的事实，不会透露评分标准。
这个细节很关键。如果评测者悄悄引导 AI 走向"正确答案"，基准测试的难度会大幅降低。
每个任务从两个维度来评判。
首先是八个维度的加权质量分：
其次是逐项验收。每个任务都有明确的交付物和过程要求。只有当固定下来的证据支持某项时，该项才算通过。
这个区分防止了一种常见的问题：应用、文件或运行时根本不支持某个说法，但最终回复写得漂亮，让外行以为成功了。
运行结束时，对话、文件、截图和运行时状态全部冻结。评审者根据这些证据做判断，不会追问 AI 代理后续问题，也不会修改结果。
对于可运行的应用，单独的测试人员会在真实浏览器中打开产品，操作各种交互，采集桌面端和移动端的证据。然后评审者判断每个需求是否通过。
一个有用的规则：
"AI 代理说能用"不是它能用的证据。
这听起来是废话，但会改变基准测试的设计思路。构建命令成功退出不能证明主要交互没问题。截图不能证明状态变更正确。部署 URL 不能证明部署的是要求的版本。
AI 代理可能写出了合格的代码，但因为走得太远而没满足用户需求。
如果用户只是要求对比几个选项，直接做个 App 不是什么加分项。如果用户说"先看看现有项目，等我消息"，去改文件就是失败。如果用户只要一个轻量原型，做成完整产品反而会让迭代变得更难。
这套基准测试把正确的阶段——讨论、规划、产出、原型、还是可运行应用——作为独立的质量维度。
很多真实失败不是语法错误，而是悄悄推翻了之前的决定：
单轮基准测试很少暴露这些问题。多轮任务会。
"支持图片"可以是从接受上传到真正把图片里的本地细节用到产品里，中间差了十万八千里。
PDF、CAD 装配体、视频、现有代码仓库都是如此。有意义的评测要检查 AI 代理是否解析了内容、理解了相关部分、把这些事实带入了交付物——而不是仅仅"收到了附件"。
用户会改主意。工具会失败。生成的素材可能不可用。设计方向可能在实现开始后被否定。
回滚、任务中途转向、素材锁定、故障恢复都需要显式的任务设计。否则基准测试会过度奖励那些"每一步都顺利才能工作"的 AI 代理。
整个基准测试跑下来，Eazo 的平均综合质量分是 88.5，Codex 是 84.2。平均任务时间是 11.1 分钟 对比 11.7 分钟，token 总用量是 1.58 亿 对比 1.79 亿。
但交付物通过率两边都是 60%。过程通过率 Eazo 是 52%，Codex 是 47%。
这些数字提醒我们：平均质量分更高不意味着每个必选项都过了。详细的逐任务证据比单薄的排行榜数字更有信息量。
完整的方法论、逐任务案例、评分维度和当前的聚合结果可以在 Eazo 基准测试页面查看。
评估一个应用构建代理时，检查基准测试是否包含：
目标不是为了把基准测试搞得复杂而复杂。而是让一个系统很难因为"用户根本用不了的工作"而拿到 credit。
任何基准测试都反映了它的任务选择、评分权重、产品版本和评审流程。两个系统的对比不等于对所有编码代理的通用排名，聚合分也会掩盖个体失败。
所以最有用的基准测试不只是个排行榜。它是一套可审查的任务、产出物、运行时证据和评审决策，别人可以质疑。