🎯 成绩单速览#

测试模型：14 个
完美完成：9 个 部分问题：3 个 翻车：2 个 不支持多模态：1 个 - MiniMax

⚠️ 部分问题（3/14）#

以下模型完成了任务，但存在明显缺陷：

DeepSeek — 标签上面的文字只是加了空格，并不是和标签完整对齐，用不了。没用 CSS 做定位，纯靠空格凑，不够精确。

Gemini 3.1 Pro — 把标签上面的文字位置放错了，正好被标签挡住，完全用不了。视觉理解有问题，没考虑 z-index 或布局顺序。

Grok Fast — 完全没按要求来，虽然写的效果还行，但大小写自己瞎编，该是标签的内容写到标签里去了。理解偏差严重，自由发挥过度。

这三个模型都”看懂”了图片要表达什么，但在实现细节上出了问题：

• DeepSeek 用原始方法（空格）而非现代 CSS 布局
• Gemini 的层级错误导致文字被遮挡
• Grok Fast 理解了意图但没遵守原图的具体要求

❌ 翻车（2/14）#

GLM (初次) — 生成了图片而不是 HTML，理解错任务目标。

GLM (提醒后) — 生成的是白屏，根本用不了，实现失败，无可用输出。

Kimi K2.6 Fast — 直接用 Python 把图片里的元素抠出来了，但是抠歪了，非常难看。这个操作很难评价——有创意但实用性存疑，一般都要自己重新调图片。

Kimi K2.6 Fast 是唯一一个试图”抠图”的模型，虽然方向有意思，但实际效果不佳且不符合常规需求（开发者通常需要可编辑的 HTML/CSS，而不是处理过的图片）。

GLM 的表现则是完全偏离任务要求。

✅ 完美完成（9/14）#

以下模型准确理解了图片内容，生成的 HTML 可直接使用且美观程度合格：

这些模型都老老实实地分析图片内容，编写了结构化的 HTML + CSS，没有偷懒也没有过度发挥。

几点观察#

结论#

这次测试的 prompt 极其简单——“给我按照图片写一个一样的 HTML”——但结果分化明显：

• 9/15 的模型能完美完成任务，生成可直接使用的代码
• 3/15 的模型理解正确但实现有缺陷，需要手动修复
• 2/15 的模型完全翻车，要么理解错误要么方法不当
• 1/15 的模型不支持多模态输入，无法参与

最大的启示：

1. 多模态理解能力已经很强，但视觉到代码的转换仍是难点
2. Thinking 模式的创造性可能带来意外的”非标准解法”
3. 简单任务的失败往往源于层级关系、定位方式等细节理解
4. 即使模型”看懂了”图片，也可能在实现细节上翻车

对开发者的建议：

• 视觉转代码任务需要验证输出，不能盲目信任
• 对于需要精确复现的场景，应该提供更详细的要求（如”使用 flexbox 布局”、“确保所有文字可见”）
• Thinking 模式的”抠图”行为提醒我们：创新方法需要结合实际需求场景

TL;DR：给 14 个大模型同一张图让它们写 HTML，9 个完美，3 个有瑕疵（文字遮挡/空格对齐/自由发挥），1 个抠图抠歪，GLM 干脆生成了白屏，MiniMax 不支持多模态直接出局。Kimi K2.6 Fast 独树一帜用 Python 抠图但效果不佳，Gemini 3.1 Pro 把文字挡住了，DeepSeek 还在用空格凑对齐。多模态理解很强，但视觉到代码的转换仍是难点，尤其在层级关系、定位方式等细节上容易翻车。