Pokémon SVG Bench

About

总体规划

选择一些宝可梦测试集，交给 AI 生成 SVG 代码。

  • 尽可能仅使用 API 生成，不依赖任何额外的 tool、agent、harness
  • 统一 Prompt，每个宝可梦有 2 次生成机会
  • 每组选择不同评估维度的宝可梦测试集
  • 人工评估每一个生成数据，并对齐评分刻度

如何选择宝可梦

目前选用的测试集将宝可梦分为三组：

  • S1 第一阶段：专注于测试宝可梦几何形状和颜色的还原度
  • S2 第二阶段：专注于测试宝可梦显著特征和空间比例的还原度
  • S3 第三阶段：专注于测试大型复杂宝可梦的结构和细节还原度

每组选择了 5 只宝可梦，每只宝可梦有 2 次生成机会，每组模型共会生成 30 个 SVG 数据。最开始是测试 4 次生成机会，但是其实对最终成绩影响并不大，也能减少人工评估的成本。

如果不熟悉宝可梦，可以在这里看到对宝可梦作为测试对象的简单描述。

生成

统一使用最为简单的 Prompt 生成：

Generate the SVG code for the Pokémon {{pokemon_name}}

大多数模型可以顺利拦截到 SVG 信息。但是某些过于热爱前端样式的模型会有几率生成 HTML，所以针对这些模型会额外加一些约束 Prompt：

Output only the SVG tag code. No additional text and tool call.

涉及到约束 Prompt 的模型： Kimi-K2.6, GLM 5.1

还有一些模型没有公开 API，例如 Cursor 的 Composer 2。那么在合规的形式下，会在 Cursor 中使用 subagents 并禁用 tool 批量生成。以下相应的 rules：

---
name: pokemon-svg-generator
description: One Pokémon per run only; English filename; do not read other SVGs. This subagent must never batch all 15 in one invocation. Parent agent—when the user gives an output dir plus explicit full-batch intent (e.g. all 15, full whitelist, generate every name in this agent file), launch 15 parallel pokemon-svg-generator subagents. Whitelist and templates in this doc are not user chat input unless the user quotes them in the same turn. /pokemon-svg-generator
model: inherit
---

涉及到使用 subagents 的模型： Composer 2

还有一些模型 API 在大陆地区无法访问，所以只能借用第三方代理。关于模型的请求参数，也尽量贴合实际用途的参数。毕竟谁也不想使用昂贵的思考 token 去生成质量不佳的 SVG。

以上相关信息在排行榜上有标明。

计分规则

虽然每组评估方向不同，但基本采取了 4-2-4 的权重。所有维度的评分范围均为 0 - 10 分。

  • S1 几何精准度 40%，色彩还原 20%，整体观感 40%
  • S2 特征识别 40%，空间比例 20%，整体观感 40%
  • S3 结构解构 40%，细节打磨 20%，整体观感 40%
S_i = 0.4 · d_1 + 0.2 · d_2 + 0.4 · d_3

计算出单个生成数据的分数后，同组内计算算术平均数，得出组平均数。由于每组本身难度也不同，计算总分时会再次按照 W_1 : W_2 : W_3 = 1.0 : 1.8 : 3.2 来加权。设每组数据个数为 N（目前为 10），组内平均分数值范围仍为 0–10，则加权总分的理论上限为 N × 10 × (W_1 + W_2 + W_3) = 600，最终分数化为百分制：

S_total = (S_1 · N · W_1 + S_2 · N · W_2 + S_3 · N · W_3) · 100 / 600

SVG 参数统计

额外统计了 SVG 的一些参数作为参考。包括：

Size

SVG 的字节长度（UTF-8），与首页榜单「SVG 结构」表中的 Size 列一致。

标签总数

解析得到的标签开启数量，与「标签总数」列一致。

高级标签

落在预定义高级标签集合内的节点数量占标签总数的比例（百分比），与「高级标签」列一致。高级标签包括 <defs>、<use>、<clipPath>、<mask>、<linearGradient>、<radialGradient>、<filter>、<pattern>、<symbol>、<marker>、<foreignObject>、<textPath>、<switch>。

与首页榜单「SVG 结构」·「视图」中的散点图一致：横轴为锚点数量，纵轴为视觉分（加权分 ×10 后的百分制，与「视觉分」表头及散点纵轴一致）。四象限含义与图角标注一致：

  • 视觉分高、锚点少：简洁
  • 视觉分高、锚点多：精致
  • 视觉分低、锚点少：简陋
  • 视觉分低、锚点多：冗杂

常见问题

Q：人工评估会不会带有主观色彩？

A：会的。通常评估完一组模型分数后，会再次在整体的视野中去微调分数。但我个人本身对模型没有额外偏好，我也想看看哪个模型 SVG 生成效果最好。评估员目前仅我一人，我尽量把自己控制为非变量！所以，仅供参考。

Q：Claude Opus 4.7 为什么排名靠后？

A：目前除了 Gemini 3.1 Pro 有在发布时营销自己的 SVG 生成能力，以及 Arrow 1.1 这种专门生成矢量图形之外，其他模型都没有将重点放在这个能力上。这也是目前有趣的点之一。Opus 4.7 由于有 thinking type: adaptive 的参数，可能默认会将 SVG 生成视为轻量级任务而没专注于生成质量。如果加上额外的 Prompt 又会对其他模型不太公平。如下图所示，左侧是 "effort": "medium"，右侧是 "effort": "max"，其实并无太大差别。

Claude Opus 4.7 Jigglypuff SVG：effort medium 与 effort max 对比

Q：为什么有些 API 不是官方源？

A：Anthropic 和 OpenAI 禁止大陆地区用户使用他们的产品，包括 API，我不想费心去硬碰硬。最近发现 OpenRouter 也因账单地址禁用了这两模型，所以选择了 Cloudflare。嘘，小点声。

Q：Benchmark 和任天堂有关系吗？

A：完全没有，只是我个人的兴趣。希望任天堂手下留情。

Q：你玩宝可梦游戏吗？

A：虽然童年时看过一些宝可梦动画，但其实并非游戏死忠粉。近几年我玩了《宝可梦传说 阿尔宙斯》和《宝可梦传说 Z-A》感觉又找到了乐趣！下次一定试试《宝可梦风与波》。

反馈

我的邮箱：

hi@fenx.work

幕后

本网站开发时使用了如下产品：

  • Cloudflare 全家桶：Workers、KV、D1、R2、AI，线上衔接非常流畅；
  • 本网站使用 Cursor 开发，使用了 GPT 5.5，Codex 5.3 和 Composer 2 模型；
  • 纯人工设计。因为我是一名 UI 设计师；
  • SvelteKit：不太懂。之前一直在用 Astro，这次后台比重大了些就换为这个了；
  • 宝可梦 wiki：在挑选测试对象时帮了很多忙；
  • Simon Willison's Weblog：鹈鹕骑自行车是灵感来源之一；

关于我

我的其他一些链接：