影片筆記：一張截圖變成可跑原型？screenshot-to-code 開源工具拆解｜Github雷達

<!-- VIDEONOTE_PUBLICATION_WARNINGS_BEGIN -->

⚠️ 可先使用，仍有待修正項目

本筆記已完成可閱讀的逐字稿與時間跳轉；下列為待處理問題，建議播放原片確認。

• 待修正：逐字稿全文快速校讀未完成（已保留自動字幕/原始逐字稿並繼續生成筆記。；未完成的全文速讀項目可在精進模式回聽確認。）

<!-- VIDEONOTE_PUBLICATION_WARNINGS_END -->

一句話總結

screenshot-to-code 是一個開源工具，透過結合多個 AI 模型（如 Gemini、GPT、Claude）與工作流，將截圖、Mockup 或螢幕錄影轉換為可運行的前端程式碼原型，旨在縮短設計稿到互動原型的時間，但最終仍需人工進行 QA 與維護。

核心重點

1. 解決痛點：針對設計稿清晰但切版困難、緊急補頁面、舊系統 UI 重做，以及設計師與工程師溝通互動原型的需求，提供比從空白檔案開始更有效率的解決方案。
2. 技術架構：並非單一模型，而是結合多個 AI 模型的工作流。後端可接 Gemini、GPT 或 Claude（建議使用 Gemini 以增強對截圖理解與素材擷取的能力）；圖片處理透過 Replicate 進行去背與生成。
3. 核心功能：輸入截圖、Mockup 或螢幕錄影，輸出 HTML、Tailwind、React、Vue 等前端程式碼。
4. 自我檢查機制：工具具備「Screenshot Preview」功能，將產出頁面丟入 Chromium 截圖，讓 Agent 回頭比對結果是否像截圖，比只相信文字輸出更可靠。
5. 適用場景：製作 Landing Page 草稿、舊畫面快速翻新、讓設計與工程團隊在會議前先看到互動原型。
6. 限制與建議：僅能節省第一版草稿時間，最終仍需人工進行 QA（畫面相似度、互動正確性、程式維護性）、可及性檢查與重構。需注意資料隱私，敏感資訊需遮擋。

詳細大綱

一、 痛點與定位

• 常見痛點：
• 設計稿清晰但切版困難。
• Demo 前緊急補頁面。
• 舊系統 UI 重做。
• 設計師想看互動版本，但工程師卡在切版。
• 解決方案：提供可修改的原型，比從空白檔案開始更有效率。
• 核心功能：輸入截圖、Mockup 或螢幕錄影，輸出前端程式碼。

二、 技術架構與支援技術

• 支援的前端框架與樣式：
• HTML
• Tailwind
• React
• Vue
• Bootstrap
• Ionic
• 本機運行環境：
• 前端：React + Vite
• 後端：FastAPI
• 需求：需準備一組模型金鑰（OpenAI、Anthropic 或 Gemini 其中之一）。
• 模型與服務整合：
• 後端可接：Gemini、GPT、Claude。
• 建議：README 特別建議使用 Gemini，因其對截圖理解與素材擷取較關鍵。
• 圖片處理：Replicate（負責圖片編輯、去背、生成）。
• 定位：非單一模型秀肌肉，而是將多個能力接起來的工作流。

三、 功能特色與流程

• 真素材保留：新版本重視真實素材（Logo、照片、Icon），若截圖中有則盡量保留，而非重畫成假素材。
• 螢幕錄影支援：支援動態畫面（按鈕點擊、Tab 切換、Modal 彈出），捕捉使用者真正感受到的 UI。
• 自我檢查機制 (Screenshot Preview)：
• 工具將產出頁面丟入 Chromium 截圖。
• Agent 回頭檢視結果是否像截圖。
• 目的：比只相信文字輸出更可靠，但不保證完美。

四、 適用場景

1. 製作 Landing Page 草稿。
2. 將舊畫面快速翻新版。
3. 讓設計與工程團隊在會議前先看到互動原型。

五、 使用建議與限制

• QA 檢查三要素：

1. 畫面是否像？
2. 互動是否正確？
3. 程式是否具備長期維護性？

• 開源優勢：可自架、修改提示詞、更換模型、加入自有設計系統。
• 成本考量：模型越強，畫面越接近，但速度與費用通常越高。
• 資料隱私：內部後台、客戶資料、未公開設計等敏感畫面需先遮擋，不可直接丟入。
• 團隊流程建議：
• 工程師：省掉第一版草稿時間。
• 設計師：將「看起來像」更快推到「點起來像」。
• 流程位置：放在團隊流程前段（截圖進 -> 原型出 -> 人工整理/測試/重構 -> 交付前跑起來看錯誤/補可及性）。
• 結論：快但要有 QA，省時間但不要省檢查。

工具 / 模型 / 名詞整理

• 專案/工具名稱：
• screenshot-to-code
• Replicate
• Chromium
• AI 模型：
• Gemini
• GPT
• Claude
• 開發框架與技術：
• HTML
• Tailwind
• React
• Vue
• Bootstrap
• Ionic
• Vite
• FastAPI
• 服務/平台：
• OpenAI
• Anthropic
• Figma
• Github

操作流程整理

1. 準備階段：

• 準備模型金鑰（OpenAI、Anthropic 或 Gemini）。
• 若需處理敏感資料，先遮擋截圖中的內部後台、客戶資料或未公開設計。

1. 輸入階段：

• 提供截圖、Mockup 或螢幕錄影（支援動態畫面如按鈕點擊、Tab 切換、Modal 彈出）。

1. 處理階段：

• 後端呼叫 AI 模型（建議 Gemini 以增強截圖理解與素材擷取）。
• 使用 Replicate 進行圖片編輯、去背與生成。
• 保留截圖中的真實素材（Logo、照片、Icon）。

1. 輸出與檢查階段：

• 生成前端程式碼（HTML/Tailwind/React/Vue 等）。
• 工具將產出頁面丟入 Chromium 截圖。
• Agent 回頭檢視結果是否像截圖（自我檢查機制）。

1. 人工介入階段：

• 檢查畫面相似度、互動正確性。
• 進行程式碼的長期維護性評估、QA、可及性檢查與重構。
• 交付前跑起來看錯誤並補可及性。

值得注意的限制或風險

1. 非完美解決方案：工具僅能節省第一版草稿時間，不保證完美，最終仍需人工進行 QA、可及性檢查與重構。
2. 資料隱私風險：內部後台、客戶資料、未公開設計等敏感畫面若直接丟入可能洩露，需先遮擋。
3. 成本與速度取捨：模型越強，畫面越接近，但速度與費用通常越高。
4. 依賴外部服務：需依賴後端模型（Gemini/GPT/Claude）與圖片處理服務（Replicate）。
5. 自我檢查非絕對可靠：雖有比對機制，但不保證結果完美。

逐字稿辨識疑點

• 素材擷取比較關：原文為「關」，語意不通，疑為「關鍵」之聽寫錯誤或漏字。
• 圖片編：原文為「編」，疑為「編輯」之聽寫錯誤或漏字。
• Github雷達：疑為頻道名稱或特定專案名稱，保留原樣。

可延伸追問

1. 如何具體設定 screenshot-to-code 的本機環境（React + Vite + FastAPI）？
2. 在什麼情況下應該選擇 Gemini 而非 GPT 或 Claude 作為後端模型？
3. 如何將自有的設計系統（Design System）整合進 screenshot-to-code 的提示詞中？
4. 對於複雜的動態互動（如複雜的表單驗證邏輯），該工具生成的程式碼維護難度如何？
5. Replicate 在該工具中的具體角色與成本結構為何？