kimi-frontEndEngineer/gcsa-visual-system

GCSA 視覺體系

建立「同一品牌、不同產品」的視覺結果。品牌識別來自一致的基礎語法；產品識別來自場景、構圖、資訊層級和專屬視覺隱喻。不要把青綠色、深色背景和發光邊框誤當成完整設計。

何時使用

必須使用

• 新建或重構 GCSA 官網、產品落地頁、主控台、行動端介面；
• 選擇或修改 GCSA 色彩、字體、Logo 組合、插畫、圖示、動效和主題；
• 建立 GCSA design tokens、元件庫或跨產品視覺標準；
• 審查頁面是否符合 GCSA 品牌、一致性、差異化、響應式或可及性要求；
• 用戶回饋「太普通」「不像 GCSA」「和其他產品太像」「全是卡片」時。

推薦使用

• 製作產品架構圖、發布海報、簡報封面、社群媒體主視覺；
• 發布前進行視覺品質、互動狀態和主題完整性檢查；
• 將第三方範本或舊產品遷移到 GCSA 視覺體系。

不需要使用

• 純後端、資料庫、DevOps 或與介面無關的效能工作；
• 只改不影響視覺和互動的文案、設定或資料；
• 用戶明確要求保留另一套獨立品牌視覺，且不需要 GCSA 聯合品牌。

判斷標準：任務是否會改變 GCSA 產品的外觀、感受、動作方式或品牌識別。

決策優先級

按優先級解決衝突；低優先級不能破壞高優先級。

優先級	類別	必須滿足	避免
1	可用與可及性	對比度、鍵盤/觸控、焦點、狀態不只靠顏色	為品牌感犧牲可讀性
2	任務清晰	一螢幕一個主要目標、主操作唯一、回饋明確	多個同級 CTA、裝飾搶內容
3	品牌識別	GCSA 主色、字體角色、Logo、克制安全氣質	泛賽博龐克、加密貨幣範本感
4	產品差異	專屬視覺命題、構圖與產品語義	兄弟產品只換文案和主圖
5	響應式與主題	行動/桌面、深/淺主題均完整	事後縮放、簡單顏色反相
6	系統一致	token、元件、圖示、間距、動效節奏統一	局部 hex、隨機圓角與陰影
7	表現增強	插畫、光效、動畫服務敘事	為動而動、滿螢幕 glow

先判斷介面類型

類型	目標	視覺密度	實作重點
官網 / 行銷頁	建立信任、講清產品、推動 CTA	低到中，敘事優先	品牌敘事、公開站點 Chrome、雙主題
主控台 / 管理後台	支援長時間、高頻、準確操作	中到高，資訊優先	穩定 Shell、語義 token、操作效率
行動端產品	單手操作、任務聚焦、平台原生感	中，觸控優先	產品自身規範；借用品牌 token，不照搬桌面佈局
品牌物料 / 圖解	一眼識別 GCSA 並傳達一個主題	低，視覺錨點優先	本 Skill 的品牌骨架與藝術指導

先讀目標專案已有的貢獻指南、品牌規範、設計 token 和元件文件。目標專案有正式設計系統時，以其可執行 token 與元件 API 為準；本 Skill 用於補充 GCSA 品牌決策。不要在主控台混用行銷元件，也不要把 console shell 搬到官網。

使用方式

先生成設計方向

本 Skill 自帶無第三方依賴的推薦腳本：

python3 scripts/recommend.py --surface marketing --task design --product "AI gateway zero trust"

支援的 --surface：marketing、console、mobile、asset。

支援的 --task：design、review、refactor、component。

輸出 JSON 供其他工具使用：

python3 scripts/recommend.py --surface console --task review --product "threat analytics" --format json

腳本提供起點而非替代判斷。若用戶資料或目標專案規範與腳本結果衝突，以用戶要求和專案實際設計系統為準。

再按任務模式執行

模式	輸入	產出
design	產品、受眾、載體、目標、內容	視覺命題、頁面節奏、token 映射、元件與驗收標準
review	頁面、截圖或程式碼	按嚴重度排序的問題、證據、修改方向、驗證條件
refactor	現狀與目標差距	保留項、替換項、分階段改造和回歸範圍
component	元件職責與狀態	anatomy、尺寸、狀態、主題、互動、a11y 與範例

完整輸入/輸出範例見 examples.md。

品牌骨架

氣質

以「可信的安全基礎設施」為核心：專業、克制、精確、現代、有技術深度。視覺應像成熟安全產品，而不是遊戲 HUD、加密貨幣落地頁或泛化賽博龐克範本。

• 深色是主品牌場景，但亮色必須是完整設計，不是反相版本。
• 青色 #00BBCC 是品牌主色，用於主操作、連結、焦點和關鍵資料。
• 綠色強調色表達成功、上線與正向狀態，不代替主色。
• 紅、琥珀、藍嚴格保留給危險、警告、資訊語義。
• 大面積背景依靠明度層級、留白和少量光暈建立空間，不依賴滿螢幕網格、噪點和霓虹。

標識與字體

• GCSA Logo 保持盾牌節點圖形的原比例，不描邊、不加複雜濾鏡、不塞進裝飾卡片。
• 生態產品使用 GCSA 主字標 + 產品名副標題，先表達母品牌，再表達產品。
• Orbitron 僅用於品牌、產品名、短展示標題；正文和控件使用 Plus Jakarta Sans / Inter / 系統中文字體。
• 資料、雜湊、IP、程式碼與指標可使用 Fira Code 等寬字體，並使用 tabular numerals。
• 中文正文避免全大寫式字距與過度緊排；長段正文不要使用展示字體。

形態與空間

• 間距基於 4px 階梯；同一層級保持一致，不用隨機 gap 修補佈局。
• 圓角以 8 / 12 / 16px 為主；pill 只用於狀態、篩選、進度和真正的膠囊控件。
• 優先使用留白、背景深淺和排版分層；邊框與陰影只在需要說明邊界或浮層關係時出現。
• 關鍵互動目標至少 36×36px；公開行動頁面更推薦 44×44px。
• 內容主軸清晰，桌面常用約 1280px 最大寬度；背景效果可以 bleed，正文不要失控擴張。

藝術指導

每個頁面先確定一個「視覺命題」，再選表現手段。例如：全球節點調度、威脅路徑收斂、身份可信鏈、設備指紋譜系。命題必須與產品真實能力有關。

構圖

• 每螢幕只有一個主要視覺錨點；Hero 優先形成清楚的標題、證據、CTA、產品視覺四級關係。
• 官網用節奏變化組織敘事：開闊 Hero、緊湊證據、產品機制、結果/信任、CTA。不要連續堆同尺寸卡片。
• 主控台首先穩定 shell、上下文和任務路徑；資料密度高不等於所有元素都加邊框。
• 行動端減少裝飾層和橫向結構，縮短 section，避免為了「高級感」製造長滾動。

圖形語言

• 優先使用真實產品結構的抽象：節點、路徑、策略、風險層級、時序、關係圖、設備或主控台狀態。
• 插畫採用面性圖形、細線連接、有限深度和少量品牌光暈；不同模組的圖形語義必須不同。
• 產品截圖或 UI mock 必須表達可信狀態與真實資訊層級，禁止無意義假圖表和亂碼資料。
• 圖示使用統一 stroke、端點、視框和視覺尺寸；emoji 不作為系統圖示。
• 外部參考只借鑑結構或節奏，不複製 logo、品牌資產、獨特插畫和受保護內容。

動效

• 動效解釋狀態、層級或因果：進入、連接、掃描、更新、展開；不為裝飾持續漂浮。
• 微互動通常 150–280ms，使用自然 ease-out；大敘事動效也要快速進入穩定狀態。
• 始終尊重 prefers-reduced-motion，關鍵含義不能只靠動畫表達。
• 主控台避免循環閃爍與持續光效；告警態用穩定色、圖示和文字共同表達。

主題與 token

不要在元件中憑感覺寫 hex。先找目標專案現有語義 token；缺失時擴展 token 層，而不是建立局部顏色孤島。

• 官網推薦語義：--background、--card、--foreground、--muted-foreground、--primary、--accent、--border；若目標專案已有命名體系，映射語義而非強行改名。
• 主控台推薦語義：背景、表面、抬升層、正文、次要文字、primary、狀態色、間距、圓角、陰影與 motion token；若目標專案使用 --gcsa-*，應直接復用。
• 深色背景基準：官網 #000205，主控台 #030407；兩者職責不同，不強行抹平。
• 淺色主色需要比深色略深以保持對比；淺色主題減少 glow，以邊界、陰影和排版建立層級。
• 狀態不能只靠顏色區分，必須同時提供文字、圖示或形狀差異。

需要精確 token 基線、交付與審查清單時讀 reference.md。

工作方式

1. 提取 Brief：載體、產品類型、用戶、主任務、主要 CTA、內容密度、主題與技術約束。
2. 生成方向：執行推薦腳本或按同等欄位形成視覺命題；給出選擇理由與明確禁區。
3. 盤點現狀：檢查既有 token、元件、品牌資產和相鄰產品，區分繼承項與差異化項。
4. 定義系統：確定色彩角色、字體角色、空間、圓角、圖示、陰影、動效和響應式規則。
5. 先結構後表現：先建立資訊層級與互動狀態，再加入插畫、光效和敘事動效。
6. 用真實內容驗證：使用真實文案和接近真實的資料密度，不以 lorem ipsum 或空殼卡片驗收。
7. 多狀態驗收：真實瀏覽器檢查桌面/行動、深色/淺色、空/載入/錯誤/成功、長中文/英文、鍵盤焦點和 reduced motion。

用戶僅要求方案或審查時，不修改程式碼。用戶要求實作時，沿用目標專案技術棧與元件庫；只有目標專案缺少設計基礎時才補充最小 token 層，不另造平行設計系統。

視覺禁區

• 泛 cyber 範本：滿螢幕網格、綠色終端雨、六邊形、無意義雷達與持續霓虹。
• 「卡片牆」：每段內容都用同尺寸圓角框、邊框、陰影包裹。
• 只換主色的換皮設計，或多個生態產品共享同一 Hero 插畫語義。
• 過度玻璃態、強模糊、粗發光邊框、淺色主題大面積彩色光斑。
• 行銷頁面使用過高的資訊密度；主控台使用誇張行銷標題和大面積裝飾。
• 用紅綠色彩本身傳達狀態、隱藏焦點環、低對比次要文字、不可操作的小點擊區。
• text-wrap: balance / text-balance；中文長標題在多端容易產生不可控斷行。
• 為追求統一而覆蓋產品特徵，或為追求差異而破壞母品牌語法。

完成標準

最終結果應同時滿足：

• 去掉 Logo 後仍能從色彩語義、字體、空間和互動感知 GCSA；
• 放在兄弟產品旁又能從構圖和視覺隱喻識別當前產品；
• 功能主次、狀態和下一步動作無需解釋即可理解；
• 深淺主題、行動端、鍵盤與 reduced motion 均不是事後修補；
• 實作復用權威 token 和元件，並在真實介面完成視覺驗證。

交付前使用 reference.md 的載體檢查單。涉及新設計、完整重構或正式審查時，同時對照 examples.md 的輸出結構，避免只給抽象審美意見。