200 位導演、80 種構圖、1,486 個網站 DNA、2.9MB 的設計資料庫——這是一個 npm 套件會塞的東西嗎?不是,它根本不是套件。

大部分 AI 設計工具的問題,不是 AI 不夠聰明,是我們讓它做錯的事。你給它一個色板、一組元件、一套排版模板,叫它「挑一個」。結果就是你看到的 AI 首頁千篇一律——Hero 配大標題、三欄 Features、CTA 按鈕、footer 放社群 icon。Cinematic UI 這個專案的切入角度很反直覺:問題不在素材不夠多,是 AI 根本不該在「挑選」這一層做事

你以為的 AI 設計 vs 它想做的事

想像一下這個對比。一個設計師接到「幫我做一個有電影感的網站」,他會怎麼開始?如果他是個懂設計的人,大概會先問你——「你說的電影感是王家衛那種、還是 Fincher 那種?」然後打開 Mubi 看半天,把某部片的色調、節奏、構圖邏輯拆解出來,再開始畫 wireframe。

換成 AI 呢?它直接打開元件庫,挑一個叫做「cinematic」的預設主題,套上去給你。成品當然有模有樣,但不會有靈魂——因為它根本沒做過「拆解一位導演的視覺語言」這件事。它做的是選擇題,不是推理題。

Cinematic UI 的設計就是硬生生把 AI 從選擇題的軌道上拉下來。你啟動它,第一件事不是挑模板,是被問「你要用哪位導演的視覺語言?」你選了 Wong Kar-wai,AI 就得先研究——為什麼他的畫面偏暖色?為什麼時間感是慢的?手持鏡頭在敘事上做了什麼?然後才把這些答案轉譯成 CSS gradient、scroll-driven animation、typography 的節奏。

知道一個東西叫什麼,跟懂這個東西是兩件事。AI 認得「cinematic」這個標籤,但不代表它懂一部電影為什麼讓你覺得 cinematic。Cinematic UI 逼它從標籤退到原理。

它到底是什麼——不是套件,是一組 Markdown

一開始你可能會想,這個專案應該是個 npm install cinematic-ui 就能用的東西吧?不是。它是一組 Markdown 文件,裝到 AI agent 的 skill 目錄裡面,agent 讀了才知道該怎麼推理

架構大概長這樣:

  • SKILL.md(271 行)—— AI 的指令書,定義一套四階段工作流
  • references/(7 檔)—— 品質控管規則,包含 Anti-Garbage、Anti-Convergence、Premium Calibration
  • references/data/(19 檔,約 2.9MB)—— 真正的設計資料庫,有 200+ 導演、80 種構圖、1,486 個網站 DNA、55+ 動畫效果、40+ 電影色彩

安裝方式一行 git clone

1
2
3
4
5
# Claude Code
git clone https://github.com/akseolabs-seo/cinematic-ui ~/.claude/skills/cinematic-ui

# Cursor / Windsurf / Copilot / Gemini
git clone https://github.com/akseolabs-seo/cinematic-ui

進到 Claude Code 下 /cinematic-ui 觸發,其他平台有對應的進入點檔案(CODEX.mdGEMINI.md.cursor/rules/...mdc.windsurf/rules/...md.github/copilot-instructions.md),各家 agent 自己會讀。

這個形式本身就是個很聰明的決策——不做成套件,因為套件會強迫 AI 在編譯時學會用它;做成 Markdown,AI 在推理時讀進去就能用,適配任何平台。簡潔不是少寫代碼,是少做承諾。

四階段工作流:把拍片流程搬進瀏覽器

觸發後 AI 不會直接寫 code,會先跑一個互動問卷——啟動模式是什麼、網站利基是什麼。問完才開始跑四階段:

Decisions —— 先選一部片

選導演、選電影,研究那部片的視覺語言。色彩、構圖、節奏、敘事節拍,全部拆出來變成設計基因。如果 agent 有網路,這階段會真的上網查資料(Wikipedia、IMDb、導演訪談);沒網路就退回 best-effort 推理,品質會掉。

這一階段的輸出是一份 Markdown 檔,裡面寫滿「為什麼」——為什麼選這個色調、為什麼是這個節奏。

Storyboard —— 把網頁當成鏡頭規劃

每個 section 當成一個鏡頭。Hero section 是開場鏡頭,用什麼構圖、什麼入場、什麼敘事鉤子;About 區段是文戲還是動作戲;CTA 是情緒的高潮還是句號。

這是整個框架裡最「導演化」的一步。寫網頁的人很少這樣想事情,但拍片的人就是這樣工作。

Compiled Spec —— 把決策編譯成 CSS

把前兩階段的抽象決策具體化成程式碼規格。每個動畫、每個顏色、每個字體層級都有對應的 CSS/JS 片段。這一階段看起來像把劇本轉成分鏡表,下一階段才真的開拍。

Build & Verify —— 拍出來之後自檢

實際產出 HTML/CSS/JS,然後跑 Premium Calibration 自檢清單。最關鍵的自檢問題是這句:

如果移除 30% 的效果,這個頁面會不會反而更強?

這是在逼 AI 主動刪東西——能拿掉一層還站得住的設計,才是真的有結構。克制比堆疊更高端。

每個階段都產出獨立的 Markdown 檔,而且用 Progressive Loading——該階段需要哪批資料才載入,避免一次塞爆 context window。這個設計很重要,因為完整的設計資料庫是 49,741 行。

最硬的部分:那個 2.9MB 的設計資料庫

資料庫是整個專案的靈魂。不是概念描述,而是每一條資料都附完整可用的 CSS/JS

資料庫 內容 特色
directors-200.md 200+ 位導演 涵蓋 11 個類型、20+ 國家
hero-archetypes.md 30 種 Hero 骨架 每種附完整 CSS Grid/Flex 佈局
compositions.md 80 種版面構圖 從黃金比例到碎片拼貼
camera-shots-50.md 55 種入場動畫 虹膜開閉、簾幕揭示、dolly zoom
interaction-effects-50.md 55+ 互動效果 15 種需 JS,其他純 CSS
dna-index.tsv 1,486 個網站 DNA 真實網站的設計基因索引
color-grades.md 40+ 電影色彩 從調色盤轉譯為 UI color token
typography-cinema.md 40+ 文字表演 字體層級、排版節奏

入場動畫那一頁,每個效果都是寫死的 clip-path + transform + transition 組合,不是概念描述。色彩那一頁,每個電影色調都對應到一組 CSS 變數。這不是給人看的字典,是給 AI 編譯用的硬體。

動畫技術上,這套框架偏執地選擇純 CSS 優先——clip-path 做虹膜開閉、transform 做 3D 透視、filter 做 blur/saturate、@keyframes 做閃爍和顆粒、scroll-driven 做視差。JS 只在滑鼠追蹤 spotlight、perspective tilt、magnetic snap 這些非 JS 做不到的效果上出現,而且明確標記。

三重防線:防止 AI 退化回模板

這個專案真正有趣的地方,是它承認 AI 會作弊。給 AI 多少素材都沒用,它只要有偷懶的機會就會偷懶。所以 Cinematic UI 內建三層防線:

Anti-Garbage Rules(34 條反退化規則) 明確禁止常見的偷懶行為——每個 section 都 fadeUp、到處放泛用卡片矩陣、Hero 永遠是「大標題 + 副標 + CTA 按鈕」。違反規則的產出會被回送重做。

Anti-Convergence(反收斂演算法) 用 hash-based 方式保證跨頁面、跨專案不會選到相同骨架。你連做五個網站,每個的 wireframe 結構都會不同。這對接案設計師是核彈級的——客戶不會再問「怎麼跟上個案子長得一樣」。

Premium Calibration(高端感校正) 12 項自檢清單,核心就是那句「移除 30% 會不會更強」。它是用來對抗 AI 的另一個壞習慣——把所有炫技都塞進去。

這三層加起來的意義是:Cinematic UI 不只提供資料,它在 AI 的產出流程上加了品管閘門。

限制要講清楚

這不是萬能藥,幾個現實的坑:

  • Context window 吃很兇。完整資料庫 2.9MB、49,741 行。Progressive Loading 有幫助,但複雜專案仍會吃掉不少 token。
  • 需要網路。Phase 1 要查導演和電影資料,沒網路的話推理品質會掉一截。
  • 風格偏向明確。天然偏向「電影感 / 高端感 / 敘事驅動」美學,不適合後台管理系統、SaaS dashboard、資料視覺化介面。你叫它做 Datadog 的頁面它會做得很痛苦。
  • 版本還很早。2026-04-02 發布 v1.0.0,目前只有 1 個 commit,生態很新。踩到 bug 的機率存在。
  • 學習曲線。四階段工作流 + 互動問卷,第一次用需要一點時間理解它在問什麼。

什麼時候用、什麼時候不用

選擇指引清楚一點:

適合用——品牌官網、產品 Landing Page、作品集 Portfolio、活動網站、設計實驗專案。凡是「視覺辨識度」比「功能密度」重要的場景,它會很香。

不適合用——後台 CRUD、Admin dashboard、報表系統、電商商品頁(除非是奢侈品牌)、SaaS 設定頁。這些場景的好設計是透明化、不擋路,而 Cinematic UI 的美學是要你記住它。

把這個專案放到更大的脈絡

Cinematic UI 出現的時機不是巧合。過去半年 AI coding 工具的爭議一直繞在一件事上——AI 產出的東西缺乏辨識度、缺乏主張。GitHub Copilot 產出的 code 看起來像平均值,v0、Lovable、Bolt 產出的網頁也長得像平均值。平均值是 AI 訓練資料的必然結果,不是 bug。

要對抗平均值,你有兩個方向。第一個是靠人的品味去 prompt——但這門檻很高,而且不穩定。第二個就是 Cinematic UI 在做的事——把品味編碼成可推理的資料庫,讓 AI 在推理階段就被迫進入一個有立場的框架

這個思路可以套到很多領域。寫作風格、產品策略、程式碼架構——任何你不想要 AI 產出「平均值」的場景,都可以做一個自己的「Cinematic X」。這大概是這個專案最有啟發性的地方:它不只是個 AI 網頁設計工具,它是一個「怎麼讓 AI 避開平均值」的範例。

背後就兩條線——AI 的問題從來不是能力不夠,是我們問它的問題太懶。給它一張選單,它給你平均值;給它一個推理框架,它可能給你一部片。這個邏輯可以複製。


原文來源:Cinematic UI on GitHub
授權:MIT|版本:v1.0.0(2026-04-02)