Screenshot to Code：將截圖轉換為前端程式碼的開源工具
放入螢幕截圖並將其轉換為乾淨的程式碼（HTML/Tailwind/React/Vue）。
秒懂
- 它是什麼？
- 一個基於 Python 的工具，可將截圖、設計稿和螢幕錄製轉換為 HTML、React、Vue 等前端程式碼。
- 適合誰用？
- 該開源專案支援本地和 Docker 部署，需要設定 AI 服務商 API 金鑰，以 MIT 授權發布且不提供任何擔保。 對 screenshot-to-code 而言，適合先依 README 的專案入口驗證主要流程，再依實際權限、輸入與部署環境決定是否採用；不適合把素材未說明的能力視為保證。
- 可以商用嗎？
- 可以。MIT 是寬鬆授權：你可以使用、修改並販售以它為基礎的軟體，只需保留著作權與授權聲明。
- 還在維護嗎？
- 有在維護。儲存庫最近一次提交在 6 天前。
- 用什麼語言寫的？
- 主要是 Python（依據 GitHub 的語言統計）。
以上回答依據專案的 GitHub 資料（最近同步於 2026年9月15日）與我們的分析，不構成法律意見。
開源專案深度解析
專案作用
該倉庫描述了一個將截圖、模擬圖、Figma 設計和螢幕錄製透過 AI 轉換為乾淨、可執行的程式碼的工具。README 列出了支援的輸出棧：HTML + Tailwind、HTML + CSS、React + Tailwind、Vue + Tailwind、Bootstrap 和 Ionic + Tailwind。專案本身使用 Python 編寫，前端基於 React/Vite，後端基於 FastAPI。託管版位於 screenshottocode.com，開源程式碼託管在 GitHub 上。
支援的輸出棧與預設模型
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 金鑰後，應用會自動為每個變體選擇更強大的模型組合。
本機執行後端與前端
要在本機執行，至少需要一個模型提供商金鑰（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。
Docker 部署方式
如果安裝了 Docker，可以在專案根目錄執行 echo "OPENAI_API_KEY=sk-your-key" > .env 和 docker-compose up -d --build。之後應用會在 localhost:5173 執行。README 明確說明這種部署方式不適合開發，因為檔案修改不會觸發重建。對於只想快速試用而不想設定本機環境的使用者，README 推薦使用託管應用。
可選能力：資源提取、影像編輯與影片模式
README 介紹了一個可選的截圖預覽功能，它允許代理在無頭瀏覽器中渲染自己生成的頁面，並直觀檢查結果。該功能在安裝 Chromium 後自動啟用。如果缺少 Replicate 金鑰，edit_images 和 remove_backgrounds 功能將不可用。工具還支援將網站操作的螢幕錄製轉換為可執行的原型。影片模式需要 Gemini 金鑰，Gemini 還負責從截圖中提取真實圖片和素材。
專案資料與文件
根據倉庫元資料，該專案擁有 73844 個 star、9071 個 fork 和 126 個未關閉 issue。主頁為 https://screenshottocode.com。README 包含 NYTimes、Instagram 和 Hacker News 等範例，以及 FAQ 部分，其中指向 Troubleshooting.md 和一個關於後端設定問題的 GitHub issue。預設分支為 main。
授權與擔保
該專案採用 MIT 授權，版權歸 Abi Raja（2023）所有。授權授予使用、複製、修改、合併、發布、分發、再授權和出售軟體副本的權利，前提是包含上述版權聲明和許可聲明。軟體按「原樣」提供，不附帶任何明示或默示的擔保，作者不對任何損害承擔責任。授權未提及安全保證、技術支援或生產環境適用性。
screenshot-to-code 的驗證邊界
實際試用時，先用 README 指定的入口載入一張介面截圖，再逐項核對產生的元件結構、樣式與資產引用。需要留意的是，截圖到程式碼的結果受輸入畫面、框架選項與模型服務影響；素材未提供固定的像素準確率或跨頁面一致性數據。若要納入既有前端專案，應把生成結果視為可編輯的初稿，檢查路由、響應式斷點和無障礙語意是否真的存在。
screenshot-to-code 的使用邊界需要從專案本身的檔案與命令來理解。README 所描述的功能，必須放回它指定的執行環境、輸入格式和輸出結果中閱讀。對 abi/screenshot-to-code 而言，不能只因為它在 GitHub 上公開，就推論所有作業系統、版本或資料形狀都已被涵蓋。素材沒有提供的相容性、效能或穩定性，本文保留為未說明，避免把推測寫成承諾。
採用前可建立一個只包含核心路徑的測試案例，使用 README 出現的專案名稱、命令或設定檔，逐項記錄成功輸出、錯誤訊息和資源使用。若專案涉及權限、網路、檔案或 Android 系統服務，測試時還要確認這些外部條件是否存在，因為它們會直接改變結果。對 screenshot-to-code 的判斷，重點是團隊能否接受它明確列出的限制，以及是否能在自己的工作流中保留可追蹤的版本。
這也說明了它適合的讀者：需要 README 所列功能、願意理解配置細節並能處理例外的人。若需求依賴未在素材中出現的整合、正式服務等級或完整準確率，現有資料不足以支持承諾。最小測試應優先檢查 screenshot-to-code 的主要入口、關鍵輸出和失敗路徑，再決定是否擴大使用範圍。
screenshot-to-code 的部署邊界需要從專案本身的檔案與命令來理解。README 所描述的功能，必須放回它指定的執行環境、輸入格式和輸出結果中閱讀。對 abi/screenshot-to-code 而言，不能只因為它在 GitHub 上公開，就推論所有作業系統、版本或資料形狀都已被涵蓋。素材沒有提供的相容性、效能或穩定性，本文保留為未說明，避免把推測寫成承諾。
部署前可建立一個只包含核心路徑的測試案例，使用 README 出現的專案名稱、命令或設定檔，逐項記錄成功輸出、錯誤訊息和資源使用。若專案涉及權限、網路、檔案或 Android 系統服務，測試時還要確認這些外部條件是否存在，因為它們會直接改變結果。對 screenshot-to-code 的判斷，重點是團隊能否接受它明確列出的限制，以及是否能在自己的工作流中保留可追蹤的版本。
這也說明了它適合的讀者：需要 README 所列功能、願意理解配置細節並能處理例外的人。若需求依賴未在素材中出現的整合、正式服務等級或完整準確率，現有資料不足以支持承諾。部署測試應優先檢查 screenshot-to-code 的主要入口、關鍵輸出和失敗路徑，再決定是否擴大使用範圍。
screenshot-to-code 的維運邊界需要從專案本身的檔案與命令來理解。README 所描述的功能，必須放回它指定的執行環境、輸入格式和輸出結果中閱讀。對 abi/screenshot-to-code 而言，不能只因為它在 GitHub 上公開，就推論所有作業系統、版本或資料形狀都已被涵蓋。素材沒有提供的相容性、效能或穩定性，本文保留為未說明，避免把推測寫成承諾。
維運前可建立一個只包含核心路徑的測試案例，使用 README 出現的專案名稱、命令或設定檔，逐項記錄成功輸出、錯誤訊息和資源使用。若專案涉及權限、網路、檔案或 Android 系統服務，測試時還要確認這些外部條件是否存在，因為它們會直接改變結果。對 screenshot-to-code 的判斷，重點是團隊能否接受它明確列出的限制，以及是否能在自己的工作流中保留可追蹤的版本。
這也說明了它適合的讀者：需要 README 所列功能、願意理解配置細節並能處理例外的人。若需求依賴未在素材中出現的整合、正式服務等級或完整準確率，現有資料不足以支持承諾。維運測試應優先檢查 screenshot-to-code 的主要入口、關鍵輸出和失敗路徑，再決定是否擴大使用範圍。
screenshot-to-code 的檢查邊界需要從專案本身的檔案與命令來理解。README 所描述的功能，必須放回它指定的執行環境、輸入格式和輸出結果中閱讀。對 abi/screenshot-to-code 而言，不能只因為它在 GitHub 上公開，就推論所有作業系統、版本或資料形狀都已被涵蓋。素材沒有提供的相容性、效能或穩定性，本文保留為未說明，避免把推測寫成承諾。
檢查前可建立一個只包含核心路徑的測試案例，使用 README 出現的專案名稱、命令或設定檔，逐項記錄成功輸出、錯誤訊息和資源使用。若專案涉及權限、網路、檔案或 Android 系統服務，測試時還要確認這些外部條件是否存在，因為它們會直接改變結果。對 screenshot-to-code 的判斷，重點是團隊能否接受它明確列出的限制，以及是否能在自己的工作流中保留可追蹤的版本。
這也說明了它適合的讀者：需要 README 所列功能、願意理解配置細節並能處理例外的人。若需求依賴未在素材中出現的整合、正式服務等級或完整準確率，現有資料不足以支持承諾。檢查測試應優先檢查 screenshot-to-code 的主要入口、關鍵輸出和失敗路徑，再決定是否擴大使用範圍。
編輯結論
該開源專案支援本地和 Docker 部署，需要設定 AI 服務商 API 金鑰，以 MIT 授權發布且不提供任何擔保。 對 screenshot-to-code 而言，適合先依 README 的專案入口驗證主要流程，再依實際權限、輸入與部署環境決定是否採用；不適合把素材未說明的能力視為保證。
社群筆記