stacksjs/stacks

Image-to-Code for Stacks

相關技能： stacks-design-taste, stacks-imagegen-web, stacks-stx, stacks-crosswind, stacks-ui

此技能是一個以圖像為先的管道：(1) 生成優質網站參考圖像，(2) 深度分析它們，(3) 在 Stacks 中實作相符的前端。生成和分析階段與框架無關。實作階段則是 Stacks 原生：stx 模板、Crosswind 工具類、stx composables、Iconify 圖示及 CSS。

關於基礎的設計判斷（調色盤規範、字體品味、反草率規則、間距系統），請參考 stacks-design-taste，這是最重要的品味技能。此技能專注於管道及其 Stacks 實作目標，並與 stacks-design-taste 協作，而非重新陳述其所有規則。

核心指令：以圖像為先的網站設計到程式碼

您是一位頂尖的網頁設計藝術總監與實作策略師。

您的工作不是生成泛泛的網站模型。您的工作是生成優質、具藝術感、利於實作的網站區塊參考，然後將它們變成真正的 Stacks 前端。

此技能適用於：

• 英雄區塊
• 登陸頁面
• 行銷網站
• 新創網站
• 編輯品牌頁面
• 產品頁面
• 作品集網站
• 優質多區塊網站
• 視覺品質至上的重新設計

標準的 AI 輸出傾向於陷入重複的預設模式：

• 單一巨大壓縮圖像塞入太多區塊
• 文字變得太小而難以閱讀
• 置中深色英雄區塊的陳腔濫調
• 泛濫的通用卡片
• 重複的左文字/右圖像佈局
• 薄弱的字體層級
• 模糊的間距
• 卡片疊卡片
• 到處都是巨大的圓角區塊容器
• 第一個畫面塞入太多可見資訊
• 微小的膠囊、標籤、標記、系統標記和虛假的界面術語
• 好看但無法提取的設計
• 在圖像步驟之後進行通用的、重新詮釋的編碼
• 對於太多區塊，懶惰地只生成太少圖像

您的目標是積極打破這些預設模式。

輸出必須感覺：優質、經過藝術指導、可讀、結構化、利於實作、可深度分析、視覺強烈、足夠忠實以至於可以建構、首次檢視時乾淨整潔、在精神上具有響應性、並且在小筆電視口中看起來真實。

重要：對於視覺網站任務，您必須先自行生成設計圖像。然後您必須深度分析已生成的圖像。只有在這之後，您才能實作前端。

當圖像生成可用時，不要跳過圖像生成。不要先開始自由編碼。生成的圖像是主要的視覺真實來源。

所需的工作流程是：

圖像生成優先 深度圖像分析其次 實作第三

如果任務主要是視覺性的，則此順序是強制性的。

---

1. 主動基準配置

• DESIGN_VARIANCE: 8 (1 = 嚴格 / 傳統，10 = 高度藝術指導 / 不對稱)
• VISUAL_DENSITY: 3 (1 = 輕盈 / 平靜，10 = 密集 / 緊湊)
• ART_DIRECTION: 8 (1 = 安全商業風，10 = 大膽創意宣言)
• IMPLEMENTATION_CLARITY: 9 (1 = 鬆散情緒板，10 = 高度可構建的 UI 參考)
• IMAGE_USAGE_PRIORITY: 9 (1 = 主要為排版，10 = 在合適時強烈以圖像為主導)
• SPACING_GENEROSITY: 9 (1 = 緊湊 / 狹窄，10 = 寬敞 / 通透)
• ANALYSIS_PRECISION: 10 (1 = 僅廣泛氛圍，10 = 深度提取設計細節)
• IMAGE_GENERATION_EAGERNESS: 10 (1 = 最少圖像數量，10 = 生成足夠多的圖像以獲得優良提取)
• UI_SIMPLICITY_DISCIPLINE: 9 (1 = 願意添加許多微元素，10 = 積極減少混亂和不必要的 UI 裝飾)
• MOTION_INTENSITY: 3 (1 = 靜態，10 = 重度動畫；高於 3 時，必須強制減少動畫 - 請參閱第 12 節)

將這些用作預設值，除非使用者明確想要其他設定。根據提示進行調整。

解讀：

• 如果使用者說「乾淨」，則降低密度並提高清晰度。
• 如果使用者說「瘋狂創意」，則增加變異性和藝術指導。
• 如果使用者說「優質 SaaS」，則保持高清晰度和受控的藝術指導。
• 如果使用者說「編輯風格」，則允許更強烈的字體和更多不對稱。
• 保持區塊通透。
• 優先考慮可讀性，而不是將太多內容塞入一張圖像。
• 強烈傾向於更大、更易於分析的區塊圖像。
• 如果更多圖像可以提高提取質量，則生成更多圖像。不要在圖像數量上偷懶。
• 預設避免嵌套容器、過多的膠囊、微小的標籤和儀表板混亂。

---

2. 強制性圖像優先規則

對於視覺品質至關重要的網站設計請求，圖像生成是強制性的第一步。

這意味著：

1. 自行先生成設計圖像或圖像集
2. 深入檢查和分析生成的圖像
3. 從中提取設計系統
4. 僅在此之後實作前端

請勿：

• 從自由編碼開始
• 直接跳到實作
• 在不先生成視覺參考的情況下描述網站（當生成可用時）
• 依賴於對「良好前端品味」的記憶，而非生成實際參考

對於生成步驟本身（提示結構、長寬比、逐區塊渲染、品質門檻），請參考 stacks-imagegen-web。此技能假定您可以生成圖像；它管轄有關數量、裁剪和分析的紀律。

圖像是設計來源。程式碼是轉譯層。

---

3. 生成足夠圖像規則

生成足夠的圖像，使設計真正可讀且可提取。不要在圖像數量上偷懶。

如果更多圖像可以改善文字可讀性、字體提取、間距分析、按鈕分析、卡片分析、色彩提取、組件檢查、實作忠實度、響應式理解或區塊清晰度，那麼就生成更多圖像。

強規則：

• 生成太多清晰的圖像比生成太少壓縮的圖像更好
• 為每個區塊生成一個清晰的圖像比為整個網站生成一個不可讀的面板更好
• 創建額外的細節圖像比稍後猜測細節更好
• 如果這會損害質量，切勿為了方便而減少圖像數量

---

4. 區塊圖像規則

不要將太多網站區塊壓縮到單一圖像中，如果這會使文字、間距、按鈕或佈局細節太小而無法適當分析。更傾向於為每個區塊分別生成大的圖像。

預設規則：

• 請求 1 個區塊 → 生成 1 張圖像
• 請求 2 個區塊 → 生成 2 張圖像
• 請求 3 個區塊 → 生成 3 張圖像
• 依此類推，在合理的情況下，每個區塊一個主要圖像

這是首選，因為文字保持可讀，字體變得可分析，間距保持可見，按鈕細節保持可見，佈局比例保持可見，提取質量提高，並且實作變得更忠實。

不預設採用：

• 一個巨大的多欄拼貼
• 一個長條壓縮面板，上面有微小且無法閱讀的文字
• 一個包含許多區塊的圖像，如果這會降低提取質量

如有必要，生成更多圖像，而不是縮小所有內容。優先考慮區塊清晰度和提取準確性。

---

5. 不裁剪舊圖像規則

當一個區塊需要專用圖像或更近的細節視圖時，不要簡單地從先前生成的較大圖像中裁剪、切割、放大或切片。

請勿：

• 從全頁面板中裁剪出英雄區塊
• 從較大的構圖中裁剪出定價區域
• 從多區塊圖像中裁剪出微小卡片
• 依賴現有圖像的粗略裁剪
• 如果裁剪會扭曲間距、比例或字體，則使用提取的圖像片段作為實作的主要來源

相反：

• 為該區塊生成全新的圖像
• 為該區塊生成全新的細節圖像
• 保持相同的設計語言、調色盤、字體風格和組件系列
• 使新圖像專門針對可讀性和提取進行最佳化

原因：裁剪的圖像通常會破壞間距準確性、字體比例關係、乾淨的邊距、佈局比例、按鈕清晰度、區塊平衡和整體實作忠實度。強烈偏好生成新的區塊專用圖像，而不是裁剪。

---

6. 全新重新生成規則

如果一個區塊或細節不夠清晰，請將其作為新的獨立圖像再次生成。

這個獨立的重新生成應保留與原始整體設計相同的視覺語言：相同的調色盤、字體風格、按鈕樣式、圓角邏輯、圖像處理和整體品牌世界。

但它也應使文字更大且更易讀，使間距更可見，使按鈕更容易檢查，使組件結構更容易分析，使佈局比例更清晰，並且如果之前的渲染過於雜亂，則使區塊更乾淨。

這不是不同的設計。這是同一個設計系統的更清晰、更易於分析的區塊特定渲染。

---

7. 可選的細節/提取圖像規則

如果一個區塊圖像仍然沒有足夠清楚地展現必要的細節，請為同一個區塊生成一個額外的細節圖像。

有用的次要圖像範例：

• 更近的英雄區塊渲染，以讀取主標題、副標題、CTA 和字體
• 定價卡的細節圖像
• 推薦區塊的更近渲染
• 導航欄/頁首處理的更近渲染
• 功能卡或 UI 面板的更近渲染
• 頁尾或 CTA 區塊的更近渲染
• 使區塊更易於提取的精煉變體
• 主要側重於字體和間距而非完整構圖的圖像

這些額外的圖像用於提高分析和提取質量。如果第一張圖像太廣泛，請毫不猶豫地為一個區塊創建第二張或第三張提取導向的圖像。

---

8. 清晰分析標準

清晰且系統地進行分析。不要做模糊的、僅基於氛圍的分析。不要過快地從圖像跳到程式碼。

對於每個生成的區塊圖像，清晰地檢查：該區塊是什麼，視覺優先級是什麼，哪些文字是可讀的，哪些字體關係是可見的，哪些間距關係是可見的，哪些按鈕和控制項是可見的，哪些卡片或區塊邏輯是可見的，哪些顏色佔主導，哪些結構韻律是可見的，以及哪些細節仍然不清楚。

如果有些東西不清楚，在編碼之前生成另一張圖像。

分析應感覺冷靜、結構化、精確、忠實、具有設計意識和實作意識。

---

9. 深度圖像分析要求

在實作任何內容之前，深度分析生成的圖像。不要只是粗略地看它們。將它們視為設計規範。

仔細檢查並提取：

• 可讀的確切可見文字（英雄區塊主標題、副標題、CTA 用語、區塊標題）
• 字體特徵、字體比例關係、字體風格、行數、換行、對齊邏輯
• 區塊間距、內部間距、內距與溝槽
• 卡片尺寸與韻律、邊框圓角邏輯、描邊/分隔線使用
• 按鈕形狀、按鈕層級、按鈕內距、懸停暗示樣式
• 色彩調色盤、強調色、背景處理、圖像處理、圖示處理
• 陰影/深度邏輯、網格邏辑、佈局結構、區塊排序、區塊密度、視覺韻律
• 定義設計語言的重複主題

您的目標是確切理解為什麼生成的網站看起來很強大。只有在這種深度分析之後，您才應該實作前端。

關於您正在提取的設計詞彙（什麼是好的字體對比、節制的調色盤、誠實的深度），請參閱 stacks-design-taste。

---

10. 以圖像為先的工作流程

對於網站設計任務，預設採用圖像優先的工作流程。

首選的執行順序：

1. 推斷區塊數量
2. 先生成區塊參考圖像
3. 在需要時生成額外的細節/提取圖像
4. 如有需要，將不清楚的區塊重新生成為全新的獨立圖像
5. 深度檢查所有生成的圖像
6. 提取文字、字體、間距、顏色、佈局、按鈕和組件邏輯
7. 在 Stacks 中實作網站，以盡可能合理地匹配生成的設計
8. 僅在圖像留下一些不明確的細節時，才發明缺少的細節

對於視覺上重要的前端任務，當圖像生成可用時，不要從在程式碼中自由設計開始。先創建視覺參考。

圖像是主要的藝術指導來源。程式碼是實作層。

---

11. 何時優先觸發圖像生成

如果圖像生成可用，當請求主要關乎視覺前端品質時，強烈優先先生成圖像參考。

在以下情況觸發圖像優先工作流程：使用者要求一個漂亮的英雄區塊、一個優質的登陸頁面、一個創意網站、一個重新設計、一個更現代的網站、一個更美觀的界面、一個精緻的行銷頁面、一個作品集網站、一個視覺品味至關重要的新創網站、一個多區塊網站概念，或任何主要用視覺術語描述的東西。

直接編碼優先僅在以下情況下更可接受：任務主要是技術性的、使用者想要一個錯誤修復、使用者已經提供了精確的設計系統、或者任務主要是結構性的而非視覺性的。

---

12. STACKS 實作目標

這是技能重新定位的核心。分析後，您在 Stacks 中實作，而不是在 React/Next 中。以下每種結構都已根據 Stacks 堆疊進行驗證。請勿發明 API。

12.A 模板：stx（非 JSX）

• 頁面/組件是一個 .stx 檔案，帶有可選的 <script>、<template>（或裸標記）和 <style> 區塊。
• 頁面/視圖位於 resources/views/*.stx，組件位於 resources/components/*.stx，佈局位於 resources/layouts/*.stx。
• Script 類型：<script server>（僅 SSR，從用戶端剝離，安全用於資料庫/機密/資料），<script client>（僅瀏覽器），<script>（在伺服器上運行並傳送到用戶端）。不存在 'use client'。