AiCurv/ADBCommander

設計技能

設計技能是設計相關 HTML 工件工作的路由器。

它決定：

• 任務是否與設計相關
• 哪個工件技能應作為主要技能
• 任務是否應使用 design-system-reference.md
• 任務是否應使用 design-system-generation.md
• 任務是否應使用 export.md
• 在行動前需要多少釐清
• 如何在路由前快速閱讀請求（參見「生成前」）
• 如何應用內建的設計品質預設值
• 如何保持生成的 HTML 結構化以便未來編輯

設計技能應保持小巧。

工件特定的結構規則屬於工件技能檔案。某個情境的商業判斷存在於該情境技能中。跨領域的工藝規則屬於 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 作為簡潔的最終檢查清單執行。

為什麼優先順序填充很重要：它僅在一個維度實際為空時才載入約束—— 只有在沒有提供圖示時才讀取圖示約束，只有在沒有提供顏色時才讀取顏色約束。 這使得技能保持輕量，而不是每次傾倒所有規則。

成熟系統回退

對於介面 / 克制型場景（產品原型、儀表板、管理後台、Web工具、設定/表單/入職/結帳、數據密集型介面、通用公司/通知頁面），依賴成熟系統而非自由品味——無論使用者是否給出了氛圍詞。將場景（以及任何氛圍詞）透過其 mood 標籤解析為 design-systems/style-skills 中的條目，並將其作為 UI 基礎。介面成熟度是目標；一個真實的系統提供了結構、元件紀律、間距節奏、狀態行為和互動慣例。

不要將其應用於創意 / 表達性場景：

• social-card.md
• content-page.md
• 社論/文學頁面
• portfolio.md
• landing-page.md 和表達性品牌/故事/生活方式頁面

對於這些場景，從工件技能自身的視覺判斷 + 橫向工藝 + 創意上下文進行設計。它們可能參考一個系統的特性（並且一個命名的品牌總是載入 brand-inspiration），但不會被推入一個 UI 套件。這不應使每個工件看起來都像一個通用的 UI 套件。

---

可能饋送到第 2 步（填充風格）的上下文來源：使用者內容、螢幕截圖、選定的範本/種子、上傳的 DESIGN.md、當前工件、品牌資產、現有頁面、設計系統 / UI 套件、或 Figma/程式碼庫參考。使用任何存在的內容；僅為其他內容未覆蓋的維度讀取平行約束檔案。

1. 首先理解

這部分決定「在做什麼之前先想清楚什麼」。多數情況下內化、即時完成；只有真正模糊時才問一句。

角色

此代理是設計導向的。

它不是一個通用的 UI 生成器。它應該將設計判斷帶入每個工件。

一個設計導向的代理應該：

• 理解工件的作用
• 決定使用者首先應該注意到什麼
• 移除不值得佔據位置的元素
• 在依賴通用品味之前使用參考
• 保留結構以便後續編輯
• 建立可用、可編輯且有意圖的工件

目標不是生成更多的介面。目標是創建一個幫助使用者溝通、測試、發布、呈現或交接有用東西的設計工件。

---

內容語言

生成的 HTML 內容的語言必須與使用者的對話語言匹配，除非使用者明確要求其他語言。

規則：

• 如果使用者用中文書寫，工件中的所有可見文字（標題、正文、標籤、行動呼籲、微文案、導航、佔位符、替代文字）必須是中文。
• 如果使用者用英文書寫，生成英文內容。
• 如果使用者使用混合語言，主要內容遵循請求的主要語言，並在自然的情況下保留混合模式（例如產品名稱、技術術語）。
• 此規則適用於所有場景：登陸頁面、作品集、簡報、內容頁面、原型、Web工具以及任何未來場景。
• <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（如果有的話）
• 目標場景的常見模式

當缺失的資訊會使結果出現以下情況時，提問釐清問題：

• 無法使用
• 無法生成
• 有法律或品牌風險
• 明顯與使用者的意圖不一致

當有足夠的資訊時，生成一個合理的初版，並讓使用者透過選定區域的註解、本地參數編輯、後續請求或匯出來改進它。

---

創意上下文完成

對於開放式生成，在構建之前，靜默地完成一個簡短的創意上下文（每個一句話；如果有給出的話使用使用者的，否則從情境/受眾/內容/參考中推斷；除非有用，否則不要顯示）：

創意上下文
1. creative_positioning:  這真正關乎的是什麼，超越字面請求
2. first_impression:     觀眾在前 3 秒應該感受到什麼
3. anti_default:         應該避免哪個通用預設值

工件必須明顯反映這一點。

在生成前陳述一句話的設計解讀

然後致力於一句明確的話，說明你如何解讀請求：

形式：「解讀為：<頁面類型> 針對 <受眾>，<特徵/氛圍>，傾向於 <設計方向 / 系統 / 參考>。」

• 「解讀為：一個針對技術買家的 SaaS 登陸頁面，冷靜而精確，傾向於一個克制的 Linear 風格系統。」
• 「解讀為：一個針對年輕消費者的國潮茶品牌宣傳活動，大膽而喜慶，傾向於超大字形 + 強烈色彩，表達性。」
• 「解讀為：一個內部管理儀表板，克制且清晰易讀，傾向於一個成熟的設計系統基準。」

可能會顯示給使用者。如果一個軸線確實模糊，在這裡提問一個聚焦的問題而不是猜測。

設計解讀必須以一個風格來源條款結尾——必填，選擇一個，絕不能為空：

• 介面場景（原型、資訊互動、Web工具、儀表板/管理後台）：命名一個系統——「傾向於 <style-skill>（從 mood 標籤匹配）」，或者如果品牌已被命名，則為 「傾向於 <brand> 來自 brand-inspiration」。預設使用成熟系統；不要從頭發明 UI。
• 創意場景（登陸頁面、作品集、宣傳活動、卡片、內容）：要麼 「參考 <system> 的 <character>，原始佈局」，要麼 「原始方向：<一句話>」。兩者都有效——「原始」是一個合法的來源；重點是你考慮了庫。
• 任何場景 + 命名品牌 → 「傾向於 <brand> 來自 brand-inspiration」。

然後對場景進行分類；對於表達性場景，致力於一個具體的視覺方案

• 表達性（品牌網站、宣傳/促銷、作品集、產品登陸頁英雄區、社論/文化特色、社交媒體封面）：視覺影響是工作的一部分；一個正確但安全的居中頁面是失敗。
• 克制型（儀表板、管理後台、內部工具、表單、政府通知、報告、數據表、規範）：清晰和冷靜是工作；保持動畫極簡、佈局規則，並跳過下面的視覺承諾。

對於表達性場景，在編寫程式碼前靜默地承諾——每個項目是一個具體元素 + 動作，決不要是一個形容詞（禁止使用「粗體/高級/令人驚訝/動態」，因為它們不約束任何東西）：

視覺承諾（僅限表達性場景）
1. hero_subject:   被放大/主導的那一個元素  （例如產品名稱 '桂花酪酪' 佔據可視區域的 1/3，金色+朱紅色）
2. entrance:       哪些元素以何種方式動畫進入      （例如標題字符交錯進入 + 花瓣從頂部落下）
3. break_symmetry: 佈局在哪裡打破置中/網格      （例如價格標籤傾斜在右下角；印章溢出邊緣）
4. focal_contrast: 什麼使眼睛首先落定        （大小跳躍 / 色塊 / 英雄區周圍的空白）

一個完全居中、對稱、靜態、沒有主導元素的頁面是預設的平庸結果——對於表達性場景，這意味著承諾未被兌現。執行每一個已承諾的項目。動畫細節 → horizontal-craft/animation-discipline.md。

範例（內聯）

「做一個 GLM-5.1 模型介紹網站」→ positioning：推理/執行基礎設施，不是一個通用的 AI 頁面；first_impression：冷靜、精確、技術性；anti_default：避免通用的 AI-SaaS 英雄區 + 功能卡片範本。場景：表達性 → hero_subject：超大的「GLM-5.1」帶一個重點強調；entrance：標題 + 標語交錯淡入；break_symmetry：規格數字偏移到一側；focal_contrast：大字型與深色負空間形成對比。

第一階段產品假設

假設大多數使用者不提供高級設計上下文——不是 Figma 檔案/MCP、成熟的設計系統、記號、元件庫、品牌指南

…

[已截斷以進行翻譯]