screenshot-to-code：从界面图生成可运行原型
放入屏幕截图并将其转换为干净的代码（HTML/Tailwind/React/Vue）。
秒懂
- 它是什么？
- 用截图、Figma 设计或录屏生成 HTML、React、Vue 等代码，真正的门槛在模型密钥和本地服务
- 适合谁用？
- screenshot-to-code 适合需要用截图、Figma 设计或录屏生成 HTML、React、Vue 等代码，真正的门槛在模型密钥和本地服务的团队或个人；不适合把 README 宣传语当成完整验收报告的场景。先按项目实际入口验证：README 明确列出的 screenshot-to-code 运行入口、输入输出和版本限制，再决定是否进入正式工作流。
- 能商用吗？
- 可以。MIT 是宽松许可证：你可以使用、修改并销售基于它的软件，只需保留版权和许可证声明。
- 还在维护吗？
- 在维护。仓库最近一次提交在 6 天前。
- 用什么语言写的？
- 主要是 Python（依据 GitHub 的语言统计）。
以上回答依据项目的 GitHub 数据（最近同步于 2026年9月15日）和我们的分析，不构成法律意见。
开源项目深度解析
screenshot-to-code｜项目作用
该仓库描述了一个将截图、模拟图、Figma 设计和屏幕录制通过 AI 转换为干净、可运行的代码的工具。README 列出了支持的输出栈：HTML + Tailwind、HTML + CSS、React + Tailwind、Vue + Tailwind、Bootstrap 和 Ionic + Tailwind。项目本身使用 Python 编写，前端基于 React/Vite，后端基于 FastAPI。托管版位于 screenshottocode.com，开源代码托管在 GitHub 上。
这一段需要和仓库里的实际对象对应起来。阅读 README 时，先区分项目直接提供的命令、组件或数据格式，以及链接到外部站点的说明；两者都能作为入口，但证据强度并不相同。
screenshot-to-code 的这个环节可以这样核对：读者可以把本节的名词直接映射到一个小实验：准备一个最小输入，执行一条文档命令，保存原始输出，再改变一个明确的开关。这样得到的是本项目行为的记录，不会把别的工具经验误套过来。 Drop in a screenshot and convert it to clean code (HTML/Tailwind/React/Vue). README 将这一定位落在具体的仓库能力上，不能由星标数量替代功能核验。
针对 screenshot-to-code 的“项目作用”，记录中还应注明使用的分支或发布标签、输入样例的位置、执行时间和输出位置。这样回看 abi/screenshot-to-code 的行为时，能把文档描述与一次明确的运行结果对上，而不是只留下主观印象。
screenshot-to-code｜支持的输出栈与默认模型
README 列举了上述六个输出栈。默认 AI 模型包括 Gemini 3 Flash Preview 和 Gemini 3.1 Pro Preview，README 称其为最佳模型，另外还有 GPT-5.5、GPT-5.4 Mini、Claude Opus 4.6 和 Claude Opus 4.8。同时，通过 Replicate 使用 z-image-turbo 进行图像生成。README 还提到，配置更多的 API 密钥后，应用会自动为每个变体选择更强大的模型组合。
从使用角度看，关键不是功能名称的数量，而是输入能否按文档进入、输出能否被下一个步骤消费。把命令、配置键、目录名和版本条件逐项记录，才能发现环境差异造成的问题。
screenshot-to-code 的这个环节可以这样核对：对于开发和运维团队，真正有用的观察点是失败时留下什么。检查退出码、错误文本、生成文件和服务端口，通常比只看成功截图更能说明项目是否适合现有流程。
针对 screenshot-to-code 的“支持的输出栈与默认模型”，记录中还应注明使用的分支或发布标签、输入样例的位置、执行时间和输出位置。这样回看 abi/screenshot-to-code 的行为时，能把文档描述与一次明确的运行结果对上，而不是只留下主观印象。
screenshot-to-code｜本地运行后端与前端
要在本地运行，至少需要一个模型提供商密钥（OpenAI、Anthropic 或 Gemini）。README 强烈建议同时配置 Gemini 和 Replicate，以获得最佳的截图转代码准确率：Gemini 负责从截图中提取真实资源，Replicate 负责图像生成、背景移除和图像编辑。后端配置包括在 .env 文件中写入密钥、使用 Poetry 安装依赖，以及通过 Playwright 安装 Chromium。前端使用 pnpm 管理。README 提供了具体命令，例如 poetry install、poetry run playwright install chromium 和 pnpm dev。应用默认运行在 localhost:5173。
项目的边界也体现在未说明的地方。README 没有列出的默认值、兼容版本、容量上限和运维承诺，不能从社区热度或项目描述推导出来；这些空白应保留为选型风险。
screenshot-to-code 的这个环节可以这样核对：README 中的版本数字只描述材料所对应的时间点。若依赖外部模型、浏览器、数据库、操作系统或云服务，兼容性还受这些边界影响，本文不替项目补写未公布的保证。
针对 screenshot-to-code 的“本地运行后端与前端”，记录中还应注明使用的分支或发布标签、输入样例的位置、执行时间和输出位置。这样回看 abi/screenshot-to-code 的行为时，能把文档描述与一次明确的运行结果对上，而不是只留下主观印象。
screenshot-to-code｜Docker 部署方式
如果安装了 Docker，可以在项目根目录运行 echo "OPENAI_API_KEY=sk-your-key" > .env 和 docker-compose up -d --build。之后应用会在 localhost:5173 运行。README 明确说明这种部署方式不适合开发，因为文件修改不会触发重建。对于只想快速试用而不想配置本地环境的用户，README 推荐使用托管应用。
如果要把它放进团队工作流，先挑一个最小样例，使用仓库给出的名称和路径完成一次闭环，再观察日志、生成物、接口响应或终端界面是否与文档一致。样例应能在失败后删除并重来。
screenshot-to-code 的这个环节可以这样核对：配置应尽量放在可以审阅的位置，并避免把密钥、个人数据或生产凭证混入样例。项目若提供 .env、配置文件、命令行参数或设置页面，应分别验证它们的优先级和生效时机。
针对 screenshot-to-code 的“Docker 部署方式”，记录中还应注明使用的分支或发布标签、输入样例的位置、执行时间和输出位置。这样回看 abi/screenshot-to-code 的行为时，能把文档描述与一次明确的运行结果对上，而不是只留下主观印象。
screenshot-to-code｜可选能力：资源提取、图像编辑与视频模式
README 介绍了一个可选的截图预览功能，它允许代理在无头浏览器中渲染自己生成的页面，并直观检查结果。该功能在安装 Chromium 后自动启用。如果缺少 Replicate 密钥，edit_images 和 remove_backgrounds 功能将不可用。工具还支持将网站操作的屏幕录制转换为可运行的原型。视频模式需要 Gemini 密钥，Gemini 还负责从截图中提取真实图片和素材。
版本变化会改变判断。项目材料记录了默认分支和近期发布信息，但这不等同于长期兼容承诺；升级时应比较 release 页面、README 的迁移说明，以及当前配置对旧行为的依赖。
screenshot-to-code 的这个环节可以这样核对：把验证结果和版本标签放在同一记录里，才能解释后来出现的差异。对于 beta 文档、近期发布或迁移行为尤其如此，旧接口能运行并不表示新版本继续承诺它。
针对 screenshot-to-code 的“可选能力：资源提取、图像编辑与视频模式”，记录中还应注明使用的分支或发布标签、输入样例的位置、执行时间和输出位置。这样回看 abi/screenshot-to-code 的行为时，能把文档描述与一次明确的运行结果对上，而不是只留下主观印象。
screenshot-to-code｜项目数据与文档
根据仓库元数据，该项目拥有 73844 个 star、9071 个 fork 和 126 个未关闭 issue。主页为 https://screenshottocode.com。README 包含 NYTimes、Instagram 和 Hacker News 等示例，以及 FAQ 部分，其中指向 Troubleshooting.md 和一个关于后端设置问题的 GitHub issue。默认分支为 main。
这篇文章只把能够追溯到 screenshot-to-code README 的事实写成判断。许可证、数据处理、凭证、网络访问和第三方服务分别属于不同检查面，不能因为代码开源就合并为安全结论。
screenshot-to-code 的这个环节可以这样核对：采用结论应落在本项目的输入、输出和责任边界上：谁提供数据，谁拥有生成物或监控数据，谁处理升级与故障。README 未作说明的地方，保留问题本身比填入猜测更准确。 采用前应把本项目的实际入口写进试验记录：abi/screenshot-to-code 的 README、版本发布页和许可证页面分别承担功能、变更与分发条件的核对。
针对 screenshot-to-code 的“项目数据与文档”，记录中还应注明使用的分支或发布标签、输入样例的位置、执行时间和输出位置。这样回看 abi/screenshot-to-code 的行为时，能把文档描述与一次明确的运行结果对上，而不是只留下主观印象。
编辑结论
screenshot-to-code 适合需要用截图、Figma 设计或录屏生成 HTML、React、Vue 等代码，真正的门槛在模型密钥和本地服务的团队或个人；不适合把 README 宣传语当成完整验收报告的场景。先按项目实际入口验证：README 明确列出的 screenshot-to-code 运行入口、输入输出和版本限制，再决定是否进入正式工作流。
社区笔记