screenshot-to-code 中的 Claude 3 视觉能力评测一套可复现的截图转代码模型评估体系【免费下载链接】screenshot-to-codeDrop in a screenshot and convert it to clean code (HTML/Tailwind/React/Vue)项目地址: https://gitcode.com/GitHub_Trending/sc/screenshot-to-code本文围绕 screenshot-to-code 项目的评测博文 evaluating-claude.md 展开完整还原作者评估 Claude 3Sonnet / Opus与 GPT-4 Vision 在截图转代码任务上表现的方法论16 张截图数据集、0–4 分人工复现度打分、并行评测脚本与前后对照 UI并给出三个模型的实际得分对比。读完本文你既能理解这套评测如何设计也能基于仓库中的 run_evals.py 与 Evaluation.md 在自己的环境里复现模型对比实验。评测背景与总体结论screenshot-to-code 是一个利用 GPT-4 vision 将截图/设计稿转换为干净代码HTML/Tailwind/React/Vue 等的开源项目。Claude 3 发布时宣称在大量任务上可与 GPT-4 比肩作者随即针对自己项目最核心的任务——截图转代码——做了一次直接对比。原文给出的 TLDR 结论是Claude 3 在截图转代码上达到 GPT-4 vision 的水平某些方面更好某些方面更差。这个结论不是拍脑袋得出的而是基于一套完整的评测流程下面逐层拆解。评测设置数据集、指标与打分机制由于当时没有公开的截图转代码基准测试作者自建了一个简单的评测体系包含三个要素评测数据集16 张截图混合了 UI 组件、落地页、仪表盘和知名网站如 Hacker News页面覆盖面兼顾了从局部组件到完整页面的不同复杂度。评测指标复现准确度Replication accuracy即生成的代码渲染后与原截图有多接近。作者明确指出虽然代码质量、速度等指标同样重要但复现度是该项目用户最关心的第一指标。评测机制由人工对每个输出按 0–4 分打分——4 分表示几乎完全复刻0 分表示与原截图毫无相似之处。16 张截图意味着单轮跑分的理论最高分为 64 分。需要说明的是仓库中的 Evaluation.md 在描述前端打分界面时写的是按 1–4 分打分与博文中的 0–4 分略有出入两者都是作者对同一个人工评分环节的表述本文以博文原述的 0–4 分制为准。为了降低评测操作成本作者编写了一个 Python 脚本对所有输入并行执行代码生成并配套一个简单的 UI 用于输入/输出的前后对照比较。这一套工具链在后文结合源码展开。评测工具链的源码实现入口脚本backend/run_evals.py博文链接到的 run_evals.py 入口极其精简from dotenv import load_dotenv load_dotenv() import asyncio from evals.runner import run_image_evals async def main(): await run_image_evals() if __name__ __main__: asyncio.run(main())它先加载环境变量API Key 等然后调用 evals/runner.py 中的run_image_evals。按 Evaluation.md 的说明运行前需要在脚本中设置STACK技术栈与MODEL模型两个变量并以OPENAI_API_KEYsk-... python run_evals.py的形式执行——脚本会对输入数据集并行跑代码生成仍需几分钟才能完成。并行执行与重试机制从 runner.py 的源码结构看评测执行器的核心设计包括并行调度所有输入 × 尝试次数的任务被封装为协程列表通过asyncio.as_completed按完成顺序消费结果见 runner.py这是博文所说runs code for all the inputs in parallel的底层实现。失败重试单张截图的生成失败会重试上限由MAX_EVAL_RETRIES 2控制runner.py但预算超限BudgetExceededError这类错误不做重试因为每次重试都会重新花掉整个预算上限。输出组织结果写入以日期、模型、技术栈命名的子目录即{EVALS_DIR}/results/{今天日期}_{model}_{stack}/每张截图输出为{输入文件名}_{尝试序号}.html见 runner.py。EVALS_DIR可通过环境变量配置默认指向backend/evals_data见 config.py。可观测产物除 HTML 输出外还会追加写入generation_times.txt每个输出的耗时用于评测中速度这一维度的观察和failed_tasks.txt失败日志。单图生成链路真正调用模型的是 evals/core.py 中的generate_code_for_image它用build_image_prompt_messages组装图像提示词消息按模型所属厂商校验对应的 API KeyANTHROPIC_API_KEY/GEMINI_API_KEY/OPENAI_API_KEY见 core.py再通过Agent运行器执行生成。也就是说评测流程与正式产品生成共用同一套 prompt 与模型调用链路——这保证了博文结果反映的是项目真实使用场景下的模型表现而非脱离上下文的裸模型测试。一个值得注意的细节Claude 3 在发布初期由 OpenAI 兼容网关间接访问如今仓库已内置完整的 Anthropic 原生 Provideragent/providers/anthropic/provider.py负责 OpenAI 消息格式到 Claude 消息格式含图片 base64 块、20 图以上时的尺寸压缩的转换并支持工具调用、流式 thinking 与 token 用量/成本统计。模型清单在 llm.py 的Llm枚举中维护——可以看到当时的 Claude 3 Sonnet/Opus 已随时间演进为claude-sonnet-4-6、claude-opus-4-8等更新型号但按 provider 分组 显式映射MODEL_PROVIDERllm.py的多模型架构与博文评测时期一脉相承。人工打分 UI博文提到一个简单的 UI 用于输入/输出前后对照。在仓库中评分入口是前端/evals路由下的评测页面族EvalNavigation.tsx包括AllEvalsPage全部评测对照、RunEvalsPage运行评测、BestOfNEvalsPage等。后端对应路由在 routes/evals.pyGET /evals?folder...会列出指定输出目录下的 HTML 文件并按输入文件名把同一截图的多次尝试归组返回前端据此渲染原图 vs 生成结果的对照卡片供人工打分。Evaluation.md 补充了使用方式打分完成后可将页面打印为 PDF 分享给他人。评测结果三个模型的复现度对比先交代被测代码类型screenshot-to-code 支持 HTML Tailwind、React、Vue 等多个技术栈stack技术栈会显著影响复现度——例如 Bootstrap 可用元素集相对受限用 Bootstrap 生成的页面往往带明显的Bootstrap 味。本次评测只跑 HTML/Tailwind因为这是 GPT-4 vision 表现最好的技术栈可排除技术栈差异对模型的干扰。以下为每个模型 3 次独立运行取平均的得分原始为 64 分满分制的百分比化结果模型得分备注GPT-4 Vision65.10%基准线我们要超越的对象Claude 3 Sonnet70.31%略胜一筹Claude 3 Opus61.46%意外垫底低于前两者两个值得注意的发现Sonnet 超过 GPT-4 Vision70.31% 对 65.10%且差距并非噪声级别的。Opus 反向落榜按产品定位Opus 应该是更聪明但更慢的模型却在复现度上同时输给了 GPT-4 Vision 和 Sonnet。作者当时的猜测是Opus 的差距可以通过更好的 prompting 弥补到与其他模型相当的水平。作者同时诚实地标注了评测局限打分是主观的subjective但综合来看Claude 3 毫无疑问与 GPT-4 Vision 处于同一水平甚至更好。原文还附了 Claude 3 Sonnet 与 GPT-4 Vision 各一轮跑分的整页前后对照截图托管在项目配套文件仓库中本文不转载外部图片。评测中的定性观察除了分数博文记录了几条对使用者有直接参考价值的行为差异提示词适应性所用 prompt 是为 GPT-4 vision 优化的为 Claude 做少量调整后确有小幅提升但并非改变格局且要权衡维护两套 prompt 的成本。代码质量整体出色所有模型的代码质量都接近甚至超过人类水平。偷懒行为差异显著以复刻 Hacker News 为例GPT-4 Vision 只会生成列表中的两条新闻并在代码里留下!-- Repeat for each news item --、!-- ... other news items ... --这类占位注释Claude 3 Sonnet 虽然偶尔也会偷懒但大多数时候会完整执行你的要求。flex 横向布局是共同短板所有模型在并排 flex 布局上都有困难这说明视觉到布局结构的映射是该任务的固有难点而非某一家模型的缺陷。速度Claude 3 Sonnet 明显更快。颜色准确性Claude 3 经常弄错背景色与文字色Hacker News 案例中即有体现。最终结论作者对 Claude 3 Sonnet 在该用例上的表现印象深刻并将其作为 GPT-4 Vision 的替代选项加入开源仓库。从当前仓库源码看这一集成确实长期存续并持续演进llm.py 中 Anthropic 模型族已扩展到 Sonnet/Opus/Fable 多个型号与多种 effort 档位Anthropic Provider 实现了完整的流式会话、工具调用循环与用量计费ANTHROPIC_MODELS成员集合llm.py则被 evals/core.py 用于评测时的 API Key 校验——博文评测所引入的多模型可比性架构一直保留至今。如何自己复现这套评测按 Evaluation.md 的步骤可以在本地完整复现该评测流程准备输入输入截图放在backend/evals_data/inputs输出会落到backend/evals_data/outputs或results见 runner 实现如需修改位置改 evals/config.py 中的EVALS_DIR环境变量。选择技术栈与模型在 run_evals.py 中设置STACK与MODEL变量。并行执行OPENAI_API_KEYsk-... python run_evals.py——对数据集并行生成代码耗时数分钟。人工打分访问前端/evals页面对每个输出打分并可将结果页打印为 PDF 分享。统计口径作者的做法是对每个模型/prompt 技术栈组合跑 3 次测试取平均分——本文的结果表即遵循该口径。此外当前仓库的评测体系已比博文时期更完整支持命名的评测集PNG 放入sets/{名称}/inputs/由 evals/sets.py 管理清单与图片哈希、评测会话与 agent 运行记录evals/sessions.py、fs_logging/agent_runs.py、OpenAI 输入格式对比页routes/evals.py、OpenAIInputComparePage.tsx等。作者也在博文中提到当时正着手用 Elo 评分机制替代纯人工打分欢迎社区参与改进。小结这篇评测的价值不在于某一轮的胜负数字而在于展示了一个视觉代码生成项目如何诚实地评估新模型的完整范式明确的单一核心指标复现度、可控的变量固定 HTML/Tailwind 技术栈、多次运行取均值3 runs、保留定性观察偷懒、flex 布局、颜色错误以及全部工具开源可复现。Claude 3 Sonnet 以 70.31% 超越 GPT-4 Vision 的 65.10%而 Opus 以 61.46% 意外垫底——这个更大模型未必更好的反直觉结果至今仍是评估 LLM 能力时值得记住的教训。【免费下载链接】screenshot-to-codeDrop in a screenshot and convert it to clean code (HTML/Tailwind/React/Vue)项目地址: https://gitcode.com/GitHub_Trending/sc/screenshot-to-code创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 screenshot-to-code 中的 Claude 3 视觉能力评测：一套可复现的“截图转代码“模型评估体系
screenshot-to-code 中的 Claude 3 视觉能力评测一套可复现的截图转代码模型评估体系【免费下载链接】screenshot-to-codeDrop in a screenshot and convert it to clean code (HTML/Tailwind/React/Vue)项目地址: https://gitcode.com/GitHub_Trending/sc/screenshot-to-code本文围绕 screenshot-to-code 项目的评测博文 evaluating-claude.md 展开完整还原作者评估 Claude 3Sonnet / Opus与 GPT-4 Vision 在截图转代码任务上表现的方法论16 张截图数据集、0–4 分人工复现度打分、并行评测脚本与前后对照 UI并给出三个模型的实际得分对比。读完本文你既能理解这套评测如何设计也能基于仓库中的 run_evals.py 与 Evaluation.md 在自己的环境里复现模型对比实验。评测背景与总体结论screenshot-to-code 是一个利用 GPT-4 vision 将截图/设计稿转换为干净代码HTML/Tailwind/React/Vue 等的开源项目。Claude 3 发布时宣称在大量任务上可与 GPT-4 比肩作者随即针对自己项目最核心的任务——截图转代码——做了一次直接对比。原文给出的 TLDR 结论是Claude 3 在截图转代码上达到 GPT-4 vision 的水平某些方面更好某些方面更差。这个结论不是拍脑袋得出的而是基于一套完整的评测流程下面逐层拆解。评测设置数据集、指标与打分机制由于当时没有公开的截图转代码基准测试作者自建了一个简单的评测体系包含三个要素评测数据集16 张截图混合了 UI 组件、落地页、仪表盘和知名网站如 Hacker News页面覆盖面兼顾了从局部组件到完整页面的不同复杂度。评测指标复现准确度Replication accuracy即生成的代码渲染后与原截图有多接近。作者明确指出虽然代码质量、速度等指标同样重要但复现度是该项目用户最关心的第一指标。评测机制由人工对每个输出按 0–4 分打分——4 分表示几乎完全复刻0 分表示与原截图毫无相似之处。16 张截图意味着单轮跑分的理论最高分为 64 分。需要说明的是仓库中的 Evaluation.md 在描述前端打分界面时写的是按 1–4 分打分与博文中的 0–4 分略有出入两者都是作者对同一个人工评分环节的表述本文以博文原述的 0–4 分制为准。为了降低评测操作成本作者编写了一个 Python 脚本对所有输入并行执行代码生成并配套一个简单的 UI 用于输入/输出的前后对照比较。这一套工具链在后文结合源码展开。评测工具链的源码实现入口脚本backend/run_evals.py博文链接到的 run_evals.py 入口极其精简from dotenv import load_dotenv load_dotenv() import asyncio from evals.runner import run_image_evals async def main(): await run_image_evals() if __name__ __main__: asyncio.run(main())它先加载环境变量API Key 等然后调用 evals/runner.py 中的run_image_evals。按 Evaluation.md 的说明运行前需要在脚本中设置STACK技术栈与MODEL模型两个变量并以OPENAI_API_KEYsk-... python run_evals.py的形式执行——脚本会对输入数据集并行跑代码生成仍需几分钟才能完成。并行执行与重试机制从 runner.py 的源码结构看评测执行器的核心设计包括并行调度所有输入 × 尝试次数的任务被封装为协程列表通过asyncio.as_completed按完成顺序消费结果见 runner.py这是博文所说runs code for all the inputs in parallel的底层实现。失败重试单张截图的生成失败会重试上限由MAX_EVAL_RETRIES 2控制runner.py但预算超限BudgetExceededError这类错误不做重试因为每次重试都会重新花掉整个预算上限。输出组织结果写入以日期、模型、技术栈命名的子目录即{EVALS_DIR}/results/{今天日期}_{model}_{stack}/每张截图输出为{输入文件名}_{尝试序号}.html见 runner.py。EVALS_DIR可通过环境变量配置默认指向backend/evals_data见 config.py。可观测产物除 HTML 输出外还会追加写入generation_times.txt每个输出的耗时用于评测中速度这一维度的观察和failed_tasks.txt失败日志。单图生成链路真正调用模型的是 evals/core.py 中的generate_code_for_image它用build_image_prompt_messages组装图像提示词消息按模型所属厂商校验对应的 API KeyANTHROPIC_API_KEY/GEMINI_API_KEY/OPENAI_API_KEY见 core.py再通过Agent运行器执行生成。也就是说评测流程与正式产品生成共用同一套 prompt 与模型调用链路——这保证了博文结果反映的是项目真实使用场景下的模型表现而非脱离上下文的裸模型测试。一个值得注意的细节Claude 3 在发布初期由 OpenAI 兼容网关间接访问如今仓库已内置完整的 Anthropic 原生 Provideragent/providers/anthropic/provider.py负责 OpenAI 消息格式到 Claude 消息格式含图片 base64 块、20 图以上时的尺寸压缩的转换并支持工具调用、流式 thinking 与 token 用量/成本统计。模型清单在 llm.py 的Llm枚举中维护——可以看到当时的 Claude 3 Sonnet/Opus 已随时间演进为claude-sonnet-4-6、claude-opus-4-8等更新型号但按 provider 分组 显式映射MODEL_PROVIDERllm.py的多模型架构与博文评测时期一脉相承。人工打分 UI博文提到一个简单的 UI 用于输入/输出前后对照。在仓库中评分入口是前端/evals路由下的评测页面族EvalNavigation.tsx包括AllEvalsPage全部评测对照、RunEvalsPage运行评测、BestOfNEvalsPage等。后端对应路由在 routes/evals.pyGET /evals?folder...会列出指定输出目录下的 HTML 文件并按输入文件名把同一截图的多次尝试归组返回前端据此渲染原图 vs 生成结果的对照卡片供人工打分。Evaluation.md 补充了使用方式打分完成后可将页面打印为 PDF 分享给他人。评测结果三个模型的复现度对比先交代被测代码类型screenshot-to-code 支持 HTML Tailwind、React、Vue 等多个技术栈stack技术栈会显著影响复现度——例如 Bootstrap 可用元素集相对受限用 Bootstrap 生成的页面往往带明显的Bootstrap 味。本次评测只跑 HTML/Tailwind因为这是 GPT-4 vision 表现最好的技术栈可排除技术栈差异对模型的干扰。以下为每个模型 3 次独立运行取平均的得分原始为 64 分满分制的百分比化结果模型得分备注GPT-4 Vision65.10%基准线我们要超越的对象Claude 3 Sonnet70.31%略胜一筹Claude 3 Opus61.46%意外垫底低于前两者两个值得注意的发现Sonnet 超过 GPT-4 Vision70.31% 对 65.10%且差距并非噪声级别的。Opus 反向落榜按产品定位Opus 应该是更聪明但更慢的模型却在复现度上同时输给了 GPT-4 Vision 和 Sonnet。作者当时的猜测是Opus 的差距可以通过更好的 prompting 弥补到与其他模型相当的水平。作者同时诚实地标注了评测局限打分是主观的subjective但综合来看Claude 3 毫无疑问与 GPT-4 Vision 处于同一水平甚至更好。原文还附了 Claude 3 Sonnet 与 GPT-4 Vision 各一轮跑分的整页前后对照截图托管在项目配套文件仓库中本文不转载外部图片。评测中的定性观察除了分数博文记录了几条对使用者有直接参考价值的行为差异提示词适应性所用 prompt 是为 GPT-4 vision 优化的为 Claude 做少量调整后确有小幅提升但并非改变格局且要权衡维护两套 prompt 的成本。代码质量整体出色所有模型的代码质量都接近甚至超过人类水平。偷懒行为差异显著以复刻 Hacker News 为例GPT-4 Vision 只会生成列表中的两条新闻并在代码里留下!-- Repeat for each news item --、!-- ... other news items ... --这类占位注释Claude 3 Sonnet 虽然偶尔也会偷懒但大多数时候会完整执行你的要求。flex 横向布局是共同短板所有模型在并排 flex 布局上都有困难这说明视觉到布局结构的映射是该任务的固有难点而非某一家模型的缺陷。速度Claude 3 Sonnet 明显更快。颜色准确性Claude 3 经常弄错背景色与文字色Hacker News 案例中即有体现。最终结论作者对 Claude 3 Sonnet 在该用例上的表现印象深刻并将其作为 GPT-4 Vision 的替代选项加入开源仓库。从当前仓库源码看这一集成确实长期存续并持续演进llm.py 中 Anthropic 模型族已扩展到 Sonnet/Opus/Fable 多个型号与多种 effort 档位Anthropic Provider 实现了完整的流式会话、工具调用循环与用量计费ANTHROPIC_MODELS成员集合llm.py则被 evals/core.py 用于评测时的 API Key 校验——博文评测所引入的多模型可比性架构一直保留至今。如何自己复现这套评测按 Evaluation.md 的步骤可以在本地完整复现该评测流程准备输入输入截图放在backend/evals_data/inputs输出会落到backend/evals_data/outputs或results见 runner 实现如需修改位置改 evals/config.py 中的EVALS_DIR环境变量。选择技术栈与模型在 run_evals.py 中设置STACK与MODEL变量。并行执行OPENAI_API_KEYsk-... python run_evals.py——对数据集并行生成代码耗时数分钟。人工打分访问前端/evals页面对每个输出打分并可将结果页打印为 PDF 分享。统计口径作者的做法是对每个模型/prompt 技术栈组合跑 3 次测试取平均分——本文的结果表即遵循该口径。此外当前仓库的评测体系已比博文时期更完整支持命名的评测集PNG 放入sets/{名称}/inputs/由 evals/sets.py 管理清单与图片哈希、评测会话与 agent 运行记录evals/sessions.py、fs_logging/agent_runs.py、OpenAI 输入格式对比页routes/evals.py、OpenAIInputComparePage.tsx等。作者也在博文中提到当时正着手用 Elo 评分机制替代纯人工打分欢迎社区参与改进。小结这篇评测的价值不在于某一轮的胜负数字而在于展示了一个视觉代码生成项目如何诚实地评估新模型的完整范式明确的单一核心指标复现度、可控的变量固定 HTML/Tailwind 技术栈、多次运行取均值3 runs、保留定性观察偷懒、flex 布局、颜色错误以及全部工具开源可复现。Claude 3 Sonnet 以 70.31% 超越 GPT-4 Vision 的 65.10%而 Opus 以 61.46% 意外垫底——这个更大模型未必更好的反直觉结果至今仍是评估 LLM 能力时值得记住的教训。【免费下载链接】screenshot-to-codeDrop in a screenshot and convert it to clean code (HTML/Tailwind/React/Vue)项目地址: https://gitcode.com/GitHub_Trending/sc/screenshot-to-code创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考