anti-ai-design
自動編排UI設計技能，附帶強制性的反AI規則。產出令人驚豔、視覺獨特的畫面——絕非千篇一律的AI生成外觀。
使用時機
當使用者要求以下內容時，啟動此技能：
- 登陸頁面、英雄區塊或行銷畫面
- 儀表板、管理後台或數據密集的介面
- 行動應用程式畫面（iOS、Android）或響應式網頁UI
- 引導流程、註冊表單或產品導覽
- 任何元件庫或設計系統畫面
- 「讓它更好看」、「重新設計這個」、「為……建立UI」
不可協商的互動合約
在產生任何設計輸出之前，你必須按順序解決以下三個決策：
- 平台範圍 — 詢問使用者要為哪些平台產生：
mobile、tablet、desktop。- 允許多選。
- 如果使用者只選擇
mobile和desktop，請勿產生tablet。 - 如果平台已經明確陳述且無歧義，則複述確認後繼續。
- 色彩方向 — 按以下順序解決品牌色彩方向：
- 如果使用者提供了確切顏色，則直接使用。
- 否則，如果使用者提供了品牌/主題氛圍，提供2–3個合適的色板方向並請他們選擇。
- 否則，自動選擇適合產品類別的色板，並清楚陳述已自動選擇。
- 風格方向 — 提供2–3個風格選項，讓使用者選擇其中一個。
除非對話中已包含明確答案，否則不可跳過這些決策。
執行模式
互動模式（預設）
- 按順序詢問使用者缺少的每個選擇：平台 → 色彩 → 風格。
- 等待他們回應後再進入下一階段。
- 針對風格方向提供選項卡片，並標記為「RECOMMENDED」。
非互動模式
當使用者有以下情況時啟動：
- 使用
mode: non_interactive或等效標誌呼叫技能， - 正在執行一次性CLI命令、背景Codex任務或腳本化管道，或
- 提供提示但沒有先前的對話上下文（請求前沒有任何對話輪次）。
自動選擇規則（按順序套用）：
- 平台 — 如果未指定，預設為
desktop。如果存在行動優先信號（行動應用描述、React Native提及、「手機」上下文），預設為mobile。 - 色彩方向 — 為偵測到的專案類型選擇最合適的色板，不提供替代方案。
- 風格方向 — 從該專案上下文的2–3個候選風格中，選擇會被標記為「RECOMMENDED」的那一個。不提供選項卡片。
產生前的必要輸出標題（僅限非互動模式）：
自動選擇：
- 平台：[選定平台]
- 色板：[色板名稱] — 主要色彩 [十六進位值]
- 風格：[風格名稱] — [一句話氛圍]
繼續進行套裝產生。
不要提出澄清問題。不要提供選項卡片。在標題後直接進入第三階段。
輸出合約 — CJX套裝，而非單一獨立的HTML
預設輸出是專案的套裝目錄，而非單一獨立的HTML檔案。
<app-slug>-design/
html/
landing-page.html
mobile-<screen>.html
tablet-<screen>.html
desktop-<screen>.html
css/
foundation.css
shared.css
landing-page.css
mobile-<screen>.css
tablet-<screen>.css
desktop-<screen>.css
js/
app.js
landing-page.js
mobile-<screen>.js
tablet-<screen>.js
desktop-<screen>.js
套裝規則
html/包含每個產生的畫面/平台組合一個HTML檔案。css/foundation.css僅包含凍結的設計權杖。css/shared.css包含共享的基本元素、工具類、動態效果、玻璃效果配方、焦點狀態和常見佈局模式。- 畫面專用的CSS放在專用的畫面檔案中。
js/app.js包含共享的UI輔助函式、狀態切換、模擬資料處理和無障礙安全的互動。- 畫面專用的JS只在需要時放在專用的畫面檔案中。
- 如果使用者稍後要求單一檔案匯出，你可以另外提供一個自包含的HTML匯出，但預設合約是CJX套裝。
平台檔案命名規則
- 登陸頁面保持語義：
landing-page.html、landing-page.css、landing-page.js - 應用程式畫面使用平台前綴：
mobile-<screen>.htmltablet-<screen>.htmldesktop-<screen>.html
- 僅為選定的平台產生檔案。
- 如果使用者選擇了
mobile和desktop，則輸出套裝不得包含任何tablet-*檔案。
為何使用獨立檔案而非單一響應式HTML
預設使用獨立平台檔案，因為：
- 每個平台在資訊架構、導航、密度和CTA放置上可能有實質差異，
- 當每個目標獨立時，審查和交接更容易，
- 當畫面意圖明確時，CJX驗證更清晰，
- 桌面/平板/行動通常需要不同的層級結構，而不僅僅是不同的斷點。
只有當使用者明確要求單一檔案交付時，才可接受單一響應式HTML。
子技能路由
僅載入當前步驟所需的參考檔案。不要一次載入所有檔案。
| 任務 | 載入 | 詳細資訊 |
|---|---|---|
| 選擇設計風格/藝術方向 | references/design-styles-catalog.md | 36種風格，橫跨11個類別 |
| 選擇趨勢/藝術包 | references/design-trends.md | 6個趨勢，3個藝術方向包 |
| 套用設計配方 | references/design-recipes-catalog.md | 15個完整設計配方 |
| 套用平台佈局規則 | references/platform-rules.md | 行動/iOS 26/桌面/平板規則 |
| 凍結並注入基礎權杖 | references/foundation-tokens.md | 權杖凍結說明和格式 |
| 強制圓角語法和巢狀層級 | references/radius-choreography.md | 語義圓角角色、巢狀表面規則、風格系列圓角語法 |
| 套用UX/客戶旅程規則 | references/ux-guidelines.md | UX強制、CJX模式 |
| 強制動態編排和互動意圖 | references/motion-choreography.md | 動態目的、懸停策略、狀態轉換、平台動態規則 |
| 強制套裝資產所有權和清單審計 | references/output-bundle-rules.md | 共享vs畫面資產規則、清單、自我審計 |
| 產生輸出套裝 | references/output-template.md | 套裝結構、HTML模板、檔案合約 |
自動編排流程
按順序執行這些階段。每個階段都有條件邏輯——請精確遵循。
第一階段 — 上下文偵測
-
掃描對話和任何附加檔案，尋找：專案名稱、現有品牌色彩、字體、技術棧、目標平台和畫面用途。
-
將專案類型分類為以下之一：SaaS產品 · 電子商務 · 行動應用 · 作品集 · 儀表板 · 行銷網站 · 其他。
-
提取要求的畫面並計算數量。
-
將平台範圍解析為一個或多個：
mobile、tablet、desktop。 -
如果平台範圍缺失或模糊： 確切詢問一個平台選擇問題，提供多選選項：
- Mobile
- Tablet
- Desktop
-
如果使用者已指定平台，不要再次詢問——原樣沿用這些平台。
-
記錄專案中發現的任何現有品牌權杖（色彩、字體、間距比例）——你將在後續的權杖凍結中使用它們。
-
根據專案類型解析色彩方案優先順序：
深色模式優先（深色是主要畫布；淺色是可選的覆蓋）：
- 儀表板 · 管理後台 · 數據密集的SaaS · 金融科技 · 開發者工具 · 分析 · 監控 · 加密/Web3 · 媒體/串流 · 遊戲
淺色模式優先（淺色是主要畫布；深色是可選的覆蓋）：
- 電子商務 · 行銷網站 · 作品集 · 醫療保健 · 教育 · 餐飲 · 生活方式
如果專案類型模糊或不符合任何一個清單，預設為淺色模式優先，並提供深色模式作為附加選項。
將此決策作為
color_scheme_priority: dark_first | light_first向前傳遞。第二階段的色板選項和第四階段的權杖凍結必須反映此優先順序。
第二階段 — 色彩 + 設計方向
-
在選擇風格之前先解決色彩方向。
-
如果使用者沒有提供明確的色板，則提供2–3個適合產品類別的色板方向，並反映第一階段的
color_scheme_priority：- 對於
dark_first專案：以深色色板選項為主（例如：OLED深色奢華、電氣石板灰、深海軍藍），僅在最後一個選項包含淺色選項。 - 對於
light_first專案：以淺色色板選項為主（例如：商業暖色能量、信任冷色中性），僅在符合品牌時才包含深色選項。 - 請使用者選擇一個。
- 對於
-
如果使用者拒絕選擇，則自動選擇最合適的色板，並用一句話說明原因。
-
載入
references/design-styles-catalog.md。 -
從目錄中選擇2–3種風格，這些風格最符合專案類型、所選色板和上下文。
-
對於每種選定的風格，以以下格式產生一個選項卡片：
[N]. **風格名稱** — RECOMMENDED（如適用） 氛圍：[一句話氛圍/情緒] 關鍵美學：[3個定義性的視覺特徵] -
根據最合適的程度，將恰好一個選項標記為RECOMMENDED。
-
將編號清單呈現給使用者，並請他們選擇。等待他們回應後再繼續。
-
如果使用者要求清單中沒有的不同風格，則接受該要求並繼續。
第三階段 — 套裝產生
- 載入
references/platform-rules.md，針對選定的平台。 - 載入
references/output-template.md，用於CJX套裝格式。 - 載入
references/output-bundle-rules.md，用於資產所有權、共享類別放置、清單和套裝自我審計。 - 載入
references/radius-choreography.md，以在撰寫任何CSS之前解析圓角語法、巢狀表面層級和基於角色的曲率。 - 載入
references/ux-guidelines.md，因為狀態完整性是強制性的。 - 套用所有下方的反AI設計規則。
- 分別為每個選定的平台套用平台規則。
- 在撰寫元件CSS之前，為選擇的風格方向解析一個圓角語法：
- 選擇2–4個主要圓角層級，如有需要再加上藥丸形，
- 將它們映射到語義角色：殼層、表面、內嵌、控制、緊湊、藥丸形，
- 在整個套裝中保持語法一致，
- 確保巢狀的同材質表面在曲率上遞減。
- 產生一個套裝目錄，包含：
html/css/js/manifest.json
- 為每個所需的畫面/平台組合產生一個HTML/CSS/JS三件組。
- 僅產生要求的畫面，且僅針對選定的平台。
- 如果同一個檔案夠用，登陸頁面可以保持跨平台語義，但如果佈局因平台而有實質變化，也請為平台產生專屬的登陸變體。
- 每個HTML檔案必須：
- 引用
../css/foundation.css - 引用
../css/shared.css - 引用其畫面CSS檔案
- 引用共享的
../js/app.js - 在需要時引用其畫面JS檔案
- 在所有主要結構元素上使用
data-ai-id - 使用上下文相關、逼真的文案——絕不使用Lorem Ipsum
- 引用
- 每個產生的應用程式畫面必須包含或明確處理來自
ux-guidelines.md的四種UX狀態：- 載入中
- 空白
- 錯誤
- 成功
- 這些狀態可以在主要畫布中可見，或透過JS控制實現為可切換的模擬狀態，但它們必須存在於已發佈的套裝中。
- 有意識地解析預設可見狀態：
- 產出器畫面應預設為
空白，除非使用者明確要求了預載入/示範就緒的成功畫布， - 結果/檢閱畫面應預設為
成功，除非敘述明確要求先顯示其他狀態， - 永遠不要讓產出器畫面在使用者提供或載入輸入之前暗示已完成的輸出。
- 產出器畫面應預設為
- 將工具畫面真實性規則套用於產出器、結果、儀表板和表單密集的畫面：
- 在追求視覺效果之前，優先考慮信任、可掃描性和對齊，
- 將主要表單、狀態畫布、結果板和CTA組保持在穩定的正常流佈局中，
- 不要使用重疊或絕對定位的內容承載卡片作為工具螢幕的主要結構，
- 將裝飾性的不對稱保持次要，以免削弱任務清晰度或CTA的可發現性，
- 確保工具螢幕上的Hero字體排版在目標視口下看起來可信，而非依賴戲劇性的換行。
- 在宣告輸出完成之前，從
references/output-bundle-rules.md執行套裝自我審計：- 將所有在2個以上HTML檔案中重複使用的選擇器移至
shared.css - 確保沒有頁面依賴於同級頁面的CSS檔案才能正確渲染
- 確保每個被引用的資產都存在
- 確保
manifest.json與產生的檔案完全匹配 - 確保沒有為未選定的平台產生檔案
- 確保圓角層級遵循所選的語義語法，並且巢狀表面不會扁平化為相等半徑的圖層
- 確保工具畫面通過在其目標視口下的佈局真實性審計
- 將所有在2個以上HTML檔案中重複使用的選擇器移至
第四階段 — 基礎權杖凍結
- 在產生第一個批准的畫面後，將確切的權杖值提取到
css/foundation.css中。 - 不僅凍結顏色/字體/動態，還要凍結套裝的語義圓角語法。
- 使用這個確切格式：
/* 凍結基礎權杖 — 請勿修改 */
:root {
--color-primary: <確切值>;
--color-secondary: <確切值>;
--color-accent: <確切值>;
--color-bg: <確切值>;
--color-surface: <確切值>;
--color-text: <確切值>;
--color-text-muted: <確切值>;
--font-heading: <確切字體堆疊>;
--font-body: <確切字體堆疊>;
--space-base: <確切值>;
--radius-1: <確切值>;
--radius-2: <確切值>;
--radius-3: <確切值>;
--radius-4: <確切值>;
--radi
…
（為翻譯而截斷）