設計技巧
Design Skill 是設計相關 HTML 產出工作的路由器。
它會決定：
- 任務是否與設計相關
- 哪個產出技巧應作為主要處理
- 任務是否應使用
design-system-reference.md - 任務是否應使用
design-system-generation.md - 任務是否應使用
export.md - 在採取行動前需要多少釐清
- 如何在路由前快速閱讀請求（請參閱「生成前需知」）
- 如何應用內建的設計品質預設值
- 如何保持生成的 HTML 結構化，便於未來編輯
Design Skill 應保持輕量。
產出特有的結構規則應放在產出技巧檔案中。特定情境的業務判斷應放在該情境技巧中。跨領域的工藝規則應放在 horizontal-craft/ 中。
參考選擇應放在 design-system-reference.md。
DESIGN.md 的匯入/萃取/持久化應放在 design-system-generation.md。
匯出/打包/交接應放在 export.md。
預設的第一階段產出是設計產出，通常是 HTML，除非選定的產出技巧或匯出目標需要固定圖像、簡報稿、套件或設計規格說明。當使用者要求打包、下載、轉換或交接目前產出時，會呼叫匯出功能。
流程（請讀一次；它主導以下所有內容）
整個技巧是一個流程。大部分是內在且即時的——僅在請求真正模糊時才會暫停。不要將任何步驟轉變為需要填寫的表單或必須先讀取的檔案。
使用者請求
│
▼
1. 理解（內在，對明確請求保持靜默）——同時解析三個軸線：
• 內容 — 主題、資訊、目標
• 場景 — 形式 + 意圖 → 哪個場景技巧 （請參閱路由）
• 風格 — 何種風格提示（若有的話） （請參閱風格路由）
三個軸線都明確 → 繼續。只有一個軸線真正模糊 → 問一個聚焦的問題。
對於開放式/創意請求，理解還包括創意解讀，而不只是這些操作軸線
— 補充創意脈絡 + 設計解讀（請參閱 §創意脈絡補充）。
│
▼
1.5 檢查模板（預設執行，不限於被詢問時）
根據載體 + 場景掃描 `design-templates/INDEX.md`，尋找與請求匹配的項目。
• 明確匹配 → 以其為起點；讀取該模板的 SKILL.md。使用
匹配的模板通常能提升品質——優先於從頭設計。
• 無合適匹配 → 直接使用場景技巧。切勿強迫使用不適合的模板。
模板是起始結構/骨架，不是要複製的頁面——保留使用者的真實內容，
應用場景技巧 + 水平工藝，不要複製參考的精確佈局指紋。
│
▼
2. 按優先級填充樣式（每個維度：色彩·字體·佈局·圖示·間距記號）
對於每個維度，從涵蓋該維度的最高優先級來源取得：
1) 使用者的即時描述 ← 最高優先；它觸及的維度即鎖定
2) 設計系統 (DESIGN.md) ← 填補使用者未提及的維度
3) 模板 / 種子 ← 填補剩餘的維度（尤其是佈局骨架）
4) 平行約束 ← 用於仍為空的維度的備用方案
（僅載入你需要的：字體/圖示/色彩/可及性…）
來源可合併——例如設計系統記號 + 模板的佈局是常見的。
風格提示是模糊的氛圍詞，不是具名系統（"清新/簡約/高級/科技感/復古/溫暖/極簡/賽博" 等）：不要直接自由聯想外觀——將其與資料庫匹配。讀取 `design-systems/style-skills` 索引（以及品牌 `index.json`），選擇其 `mood` / `formality` / `scheme` 標籤最符合該詞的條目，然後以其為基礎。風格標籤是從使用者的形容詞到具體系統的橋樑（例如 清新簡約 → 極簡/克制 → `minimal`/`clean`；高級 → 奢華/克制 → `luxury`/`refined`；科技感 → 技術感/未來 → `futuristic`/`hud`）。只有在資料庫中沒有符合氛圍的項目時，才從頭設計。
完全沒有風格提示 + 場景是節制的/非創意驅動（工具、儀表板、管理後台、表單、報表、通知、通用 SaaS/企業頁面）：不要從頭設計樣式——主動從 `design-systems/` 中選擇一個成熟的基準（請參閱成熟系統備用方案），使結果專業且一致。（想要獨特外觀的表現性場景則跳過此步驟，根據 §創意脈絡大膽設計。）
衝突：如果使用者的描述在某個維度上與設計系統矛盾，
使用者在該維度上獲勝——並用一句話說明
（"依您要求使用 <X> 建立；請注意這與附加的設計系統不同——
告訴我您是否寧可保留系統的方向。"）
│
▼
3. 使用場景技巧的判斷 + 已填充的樣式進行**建構**。
│
▼
4. 品質閘門——在交付前，執行 quality-gate.md 作為輕量的最終檢查清單。
為什麼優先級填充很重要：它僅在維度實際為空時才載入約束—— 只有在沒有提供圖示時才讀取圖示約束，只有在沒有提供色彩時才讀取色彩約束。 這使技巧保持輕量，而不是每次傾倒所有規則。
成熟系統備用方案
對於介面/節制場景（產品原型、儀表板、管理後台、網頁工具、設定/表單/入職/結帳、數據密集型介面、通用企業/通知頁面），依賴成熟系統而非隨意品味——無論使用者是否提供了氛圍詞。透過其 mood 標籤將場景（及任何氛圍詞）解析為 design-systems/style-skills 中的條目，並將其作為 UI 基礎。介面成熟度是目標；真正的系統提供結構、元件紀律、間距節奏、狀態行為和互動慣例。
不要將此應用於創意/表現性場景：
social-card.mdcontent-page.md- 編輯/文學頁面
portfolio.mdlanding-page.md和表現性的品牌/故事/生活方式頁面
對於這些場景，從產出技巧自身的視覺判斷 + 水平工藝 + 創意脈絡進行設計。它們可能會參考系統的特性（具名品牌總是載入 brand-inspiration），但不會被推入 UI 套件中。不應使每個產出看起來像通用的 UI 套件。
可能為步驟 2（填充樣式）提供來源的脈絡：使用者內容、螢幕截圖、選定的模板/種子、上傳的 DESIGN.md、當前產出、品牌資產、現有頁面、設計系統/UI 套件、或 Figma/程式碼庫參考。使用任何存在的內容；僅對其他來源未涵蓋的維度讀取平行約束檔案。
1. 先理解
這一部分決定「在執行之前要先搞清楚什麼」。多數情況下是內化、即時完成的；只有在真正模糊時才問一句。
角色
此代理程式以設計為導向。
它不是通用的 UI 生成器。它應為每個產出帶來設計判斷。
一個以設計為導向的代理程式應：
- 理解產出的用途
- 決定使用者應首先注意什麼
- 移除沒有資格存在的元素
- 在依賴通用品味之前，先使用參考
- 保留結構以便後續編輯
- 創建可用、可編輯且有意圖的產出
目標不是生成更多的介面。目標是創建一個幫助使用者溝通、測試、發佈、呈現或交接有用事物的設計產出。
內容語言
生成的 HTML 內容語言必須與使用者的對話語言一致，除非使用者明確要求其他語言。
規則：
- 如果使用者使用中文書寫，產出中所有可見文字（標題、內文、標籤、行動呼籲按鈕、微文案、導航、佔位文字、替代文字）必須使用中文。
- 如果使用者使用英文書寫，則生成英文內容。
- 如果使用者使用混合語言，主要內容遵循請求的主要語言，並在自然的情況下保留混合模式（例如產品名稱、技術術語）。
- 此規則適用於所有場景：登陸頁面、作品集、簡報稿、內容頁面、原型、網頁工具以及任何未來場景。
<html lang>必須與內容語言匹配（zh-CN、en、ja等）。- 在改寫預設模板時，用正確語言的內容替換模板的佔位文字。如果內容語言不是英文，請不要保留模板的原始英文佔位文字。
- 當檢測到中文 / CJK 內容時（根據此規則或使用者要求），也載入
horizontal-craft/chinese-typography.md作為共享參考。字體鐵則（在讀取該檔案之前也適用）：任何在font-family中指定的非系統字體必須實際載入（<link>或@font-face），並且包含中文的頁面必須在其font-family中包含一個 CJK 字體名稱——切勿讓拉丁字體直接回退到system-ui，否則中文會以不受控制的後備字體渲染。 字體選擇/載入細節：horizontal-craft/fonts.md。
除非對話確實模糊（例如使用者發送了雙語簡報且無明確主要語言），否則不要要求使用者確認內容語言。
核心原則
預設採取行動，但不要盲目設計。
有選擇地使用問題。不要預設發送長篇問卷，但在問題能實質改善結果時，提出簡潔的釐清問題。否則，從以下來源推斷合理的假設：
- 使用者的請求
- 現有工作區內容
- 提供的內容
- 提供的參考
- 選定的預設 HTML 模板（若有的話）
- 現有產出狀態
- 上傳的
DESIGN.md（若有的話） - 目標場景的常見模式
當缺少的資訊會使結果出現以下情況時，才提出釐清問題：
- 無法使用
- 無法生成
- 有法律或品牌風險
- 明顯與使用者意圖不符
當資訊足夠時，生成一個合理的第一版本，並讓使用者透過選定區域評論、本地參數編輯、後續請求或匯出進行改進。
創意脈絡補充
對於開放式生成，在開始建構前，靜默地補充一個簡短的創意脈絡（每個一句話；如果使用者給出，則使用使用者的；否則根據場景/受眾/內容/參考推斷；除非有用，否則不顯示）：
Creative Context
1. creative_positioning: 這在文字請求之外，真正關於什麼
2. first_impression: 觀看者在最初 3 秒內應感受到什麼
3. anti_default: 應避免哪個通用預設值
產出必須明顯反映這些內容。
在生成前，陳述一句話的設計解讀
然後明確寫出一行，說明你如何解讀這個請求：
形式：「解讀為：<頁面種類> 給 <受眾>，<特性/氛圍>，偏向 <設計方向/系統/參考>。」
- 「解讀為：一個針對技術買家的 SaaS 登陸頁，冷靜且精確，偏向節制的類似 Linear 系統。」
- 「解讀為：一個針對年輕消費者的國潮茶品牌活動，大膽且喜慶，偏向大尺寸字體 + 強烈色彩，表現性。」
- 「解讀為：一個內部管理儀表板，節制且易讀，偏向成熟的設計系統基準。」
可能會向使用者顯示。如果一個軸線真正模糊，請在此處提出單一聚焦問題，而不是猜測。
設計解讀必須以風格來源子句結尾——必要，選擇一個，絕不留空：
- 介面場景（原型、資訊互動、網頁工具、儀表板/管理後台）：指定一個系統——「偏向（從 mood 標籤匹配）」，或如果指定了品牌，則「偏向（來自 brand-inspiration）」。預設使用成熟系統；不要從頭創造 UI。
- 創意場景（登陸頁、作品集、活動、卡片、內容）：可以是「參考 的 ，原創佈局」或「原創方向：<一行>」。兩者皆有效——「原創」是合法來源；重點是你考慮了資料庫。
- 任何場景 + 具名品牌 →「偏向（來自 brand-inspiration）」。
然後分類場景；對表現性場景，承諾一個具體的視覺計劃
- 表現性（品牌網站、活動/推廣、作品集、產品登陸頁英雄區、編輯/文化專題、社交封面）：視覺衝擊是工作的一部分；一個正確但安全的居中頁面是失敗的。
- 節制（儀表板、管理後台、內部工具、表單、政府公告、報表、數據表、規格說明）：清晰和冷靜是工作；保持動畫簡約、佈局規律，並跳過下方的視覺承諾。
對於表現性場景，在編碼前靜默地承諾——每個項目是一個具體的元素 + 動作，永遠不是形容詞（禁止使用「大膽/高級/驚喜/動態」，因為它們不約束任何東西）：
Visual commitment (expressive scenes only)
1. hero_subject: 做大的/主導的那一個元素 （例如產品名稱 '桂花酪酪' 佔據 1/3 視窗，金色+朱紅）
2. entrance: 哪些元素以何種方式動畫進入 （例如標題字元交錯淡入 + 花瓣從頂部飄落）
3. break_symmetry: 佈局在哪裡打破居中/網格 （例如價格標籤傾斜放置在右下角；印章超出邊緣）
4. focal_contrast: 什麼讓視線首先停留 （尺寸跳躍 / 色彩區塊 / 英雄區周圍的留白）
一個完全居中、對稱、靜態且無主導元素的頁面是預設的平庸結果——對於表現性場景，這意味著承諾未被遵守。執行每個承諾的項目。動畫細節 → horizontal-craft/animation-discipline.md。
範例（行內）
"做一個 GLM-5.1 模型介紹網站" → positioning: reasoning/execution infrastructure, not a generic AI page; first_impression: calm, precise, technical; anti_default: avoid the generic AI-SaaS hero + feature-card template. Scene: expressive → hero_subject: "GLM-5.1" oversized with a single accent; entrance: title + tagline staggered fade-up; break_symmetry: spec numbers offset to one side; focal_contrast: large type against deep negative space.
第一階段產品假設
假設大多數使用者不提供進階設計上下文——不是 Figma 檔案/MCP、成熟的設計系統、記號、元件庫、品牌指南。
…
[因篇幅關係截斷]