# 影片筆記：一張截圖變成可跑原型？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）。
    *   若需處理敏感資料，先遮擋截圖中的內部後台、客戶資料或未公開設計。
2.  **輸入階段**：
    *   提供截圖、Mockup 或螢幕錄影（支援動態畫面如按鈕點擊、Tab 切換、Modal 彈出）。
3.  **處理階段**：
    *   後端呼叫 AI 模型（建議 Gemini 以增強截圖理解與素材擷取）。
    *   使用 Replicate 進行圖片編輯、去背與生成。
    *   保留截圖中的真實素材（Logo、照片、Icon）。
4.  **輸出與檢查階段**：
    *   生成前端程式碼（HTML/Tailwind/React/Vue 等）。
    *   工具將產出頁面丟入 Chromium 截圖。
    *   Agent 回頭檢視結果是否像截圖（自我檢查機制）。
5.  **人工介入階段**：
    *   檢查畫面相似度、互動正確性。
    *   進行程式碼的長期維護性評估、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 在該工具中的具體角色與成本結構為何？