n0ctx/tavern-aesthetic

酒館美學 — 沉浸式敘事前端設計

此技能產出的成果

一個運作中的使用者介面，它讀起來就像是故事世界中的一件文物 —— 既不是重新換皮的儀表板，也不是一堆通用的遊戲 HUD 道具。檢驗標準是精緻的前端卡片：一眼就能辨識出是哪部作品，每個表面都遵循統一的藝術方向，細節處理完善，互動感覺自然。

精緻 ≠ 複雜。精緻意味著每一個可見的選擇都是刻意的，每一個可見的區域都符合相同的品質標準。

此技能涵蓋視覺設計與實作方法。它不依賴 SillyTavern、任何輔助外掛、MVU 或任何框架。請重用專案現有的技術棧、元件、素材與互動模式。如果使用者只要求設計，請勿修改程式碼。

參考資料（按需閱讀，切勿一次全部讀完）

• references/design-knowledge.md — 按維度（敘事認同感、色彩、字體、形狀、光線/材質、圖像、佈局、元件、動態、適配）劃分的決策指南，並附有失敗模式表。請針對當下決策查閱對應章節。
• references/workflow.md — 階段式流程、通過/失敗關卡、審查方法、回滾規則、設計記錄範本。在進行中等或複雜任務前請先閱讀。
• references/asset-sources.md — 插圖、紋理、圖示、字體的來源與授權檢查。在從網路收集素材時閱讀。
• references/research.md — 此技能背後的證據與限制。執行時不需閱讀。

任務層級

依據設計難度而非程式碼量來判斷：

• 簡單：單一元件、細節修正、在現有視覺語言內的小功能。沿用既有語言；實作後截圖檢查一次即可。
• 中等：單一頁面/面板，或現有畫面的重新設計。先進行簡短的定調，建立焦點區域，再完成頁面；進行 1-2 輪審查。
• 複雜：多畫面流程、遊戲化系統、從頭建置、需要客製的主視覺，或使用者要求成品級品質。請執行 workflow.md 中的六個階段，並保留設計紀錄。

反漂移規則（具有約束力）

這些規則的存在是因為多輪執行會產生漂移。請嚴格遵守：

1. 設計紀錄是唯一的真相來源。 對於中等和複雜任務，請在定調階段建立它（範本在 workflow.md 中），並在隨後每一輪/模組開始時重新閱讀。任何新的顏色、圓角、字體或動態值在使用前必須先加入紀錄的權杖註冊表。如果一個值不在註冊表中，就不允許出現在程式碼中。
2. 核心範例通過後，凍結權杖註冊表。 後續的模組只能重複使用已註冊的權杖。新權杖需要在紀錄中加入明確的註釋，說明為何現有集合無法滿足需求。
3. 每個模組在繼續前，都必須與核心範例進行螢幕截圖比對。 沒有例外；口頭比較是不夠的。
4. 每個階段最多兩輪修正。 如果仍然失敗，請回滾並根據 workflow.md 中的回滾表進行診斷，而不是堆疊更多修正。
5. 一次只專注於一個方向。 不要在不同輪次中保留備選方向。選定一個，記錄下來，然後放棄其餘的。

核心原則

1. 為作品設計，而非為類型設計。
   • 首先回答：這個 UI 在故事中是怎樣的物件或系統？由誰製作？誰閱讀它？何時？
   • 然後選擇一個屬於這個特定作品的記憶點。
   • 視覺認同來自具體的角色、地點、時代、陣營、事件、道具。類型公式（例如：末日廢土 = 黑/黃色雷達；修仙 = 墨綠 + 金色）只是起點，必須讓它們變得具體。
   • 自我檢驗：將相同類型的通用需求交給另一個 AI —— 如果它產生的 UI 幾乎一模一樣，表示你的方向還不夠具體。
   • 在內部比較幾個方向，但只交付一個。對於例行任務，不要向使用者列出選項。
2. 一個核心概念主導所有設計決策。
   • 色彩來自材質與光源；字體來自書寫/印刷方法；形狀來自工藝；動態來自物體的物理動作。
   • 相關維度應同時決定，而非依序進行（「先決定所有顏色，再決定所有字體」是錯誤的）。
   • 對於任何元素，你必須能夠說出它表達了概念的哪一部分。
3. 具體的藝術作品使用插圖素材；程式碼繪製的藝術僅作為佔位符。
   • 人物、場景、物體：最終版本使用插圖素材。來源優先順序：現有專案素材 → AI 生成 → 授權網路素材。
   • 使用 CSS/SVG 繪製的場景、人物、物體僅允許用於構圖/概念驗證，並且必須在交付前（複雜任務不得晚於核心範例階段）被替換。它們看起來像是程式設計師的藝術，會拖累整個 UI。
   • 程式碼負責介面本身：佈局、字體排印、邊框、紋理、裝飾圖案、圖示、抽象圖形和數據圖形。
4. 插圖主導構圖。
   • 插圖設定佈局的重心；文字和元件圍繞它排列。切勿將它縮小成頂部橫幅或卡片縮圖。
   • 每個主畫面都必須像一幅畫：瞇起眼睛看，畫面大部分應該是插圖，而不是深色面板加細線加文字。
   • 藝術的存在感應延伸到功能性頁面（在面板下以低對比度圖層呈現、角色跨越面板邊緣、場景隨時間/地點變化）。「華麗的開場，然後是平淡無奇的深色表單頁面」是最常見的品質崩潰。
   • 每個畫面使用一張主圖。次要圖像融入同一張圖中，或形成統一處理的集合；切勿將不同來源的圖像並排排列在方框裡。
5. 資訊採用世界內的格式，並節制使用道具。
   • 資訊使用世界內的本地格式與詞彙（分類帳欄位、名冊佈局、世界內的動詞/名詞），並以敘事節奏呈現。
   • 為整個 UI 選擇一個主要載體。不要讓每個模組都有不同的 CSS 模擬道具（貼紙便條、歪斜的郵戳、標籤、算盤珠子）—— 堆疊的道具看起來廉價。
   • 節制道具和裝飾，而非圖畫和色彩。從道具中釋放出的空間應用於插圖和字體排印，而不是深色的文字表單。
   • 並非所有東西都是「標籤：值」加進度條。流程頁面（如入門、設定）不應是表單；關鍵選項可以帶有插圖。
6. 統一的品質標準。
   • 投入程度可以不均：焦點區域獲得最好的素材和最多細節。
   • 沒有任何可見區域可以低於標準。任何繪製的東西都必須符合整體精確度；如果無法做到，就用插圖取而代之，或透過字體排印/抽象圖形來表達。
   • 為了節省成本，請在相同的語言內簡化 —— 永遠不要退回到預設元件、瀏覽器原生樣式或預留位置的圖像。
7. 閱讀與操作為首要考量。
   • 中文內文：≥14px（15-17px 為典型），行高 1.6-1.9，行長 ~20-40 字元，內文對比度 ≥4.5:1。
   • 情緒由色溫、光線、材質、動態來承載；文字和數字保持清晰。
   • 不使用過小的文字、低對比度，或使用無意義的英文作為「高級」的簡寫。
   • 圖像和紋理絕不能覆蓋在內文或點擊目標之上。
   • 完整的互動狀態、鍵盤可操作、適配目標寬度。
8. 預設值必須經過選擇，而不是繼承。 僅在經過刻意選擇的情況下，才保留預設字體、調色板、元件庫樣式或瀏覽器滾動條/焦點環。常見的 AI 遊戲 UI 套件（米色紙張 + 深石板色、紅色歪斜郵戳、小標籤、十六進制步驟節點、雷達圖）本身也是一種預設。用一個新的流行預設替換另一個，仍然是使用預設。
9. 工程上的克制。 重複使用現有程式碼、依賴項和素材。僅根據素材計劃生成/收集素材。不要引入新的重量級依賴項、素材管線或後端重構。

執行流程

1. 理解場景

確認：類型；角色/世界的具體細節；目標情緒；頁面目的；核心資訊與操作；目標裝置；主機環境（例如嵌入在聊天中）。 審查現有程式碼和素材。使用者提供的參考：提取的是藝術技法，而非圖像本身。當沒有重大歧義時，直接進行，無需提問。

2. 設定方向（所有中等+任務）

在設計紀錄中撰寫：

• 介面認同：什麼物件/系統？由誰製作？誰閱讀？
• 記憶點：一句話；必須來自這部作品的具體細節。
• 藝術方向：媒材、筆觸、光線方向、調色板、清晰度 —— 一個共用的風格描述，在後續每個生成請求中逐字使用。
• 排除清單：此作品必須避免的類型公式與預設值。
• 素材計劃：每個具體藝術項目都需說明用途、比例、裁切、透明度、來源（現有 → AI → 網路）。在承諾前先確認來源確實存在；如果 AI 和授權網路素材都無法支援該方向，請立即說明。

3. 建置

根據任務層級：

• 簡單：實作、截圖、修正最嚴重的 1-3 個問題，完成。
• 中等：將焦點區域做到完全品質 → 完成頁面 → 一次綜合審查。
• 複雜：按照 workflow.md 的六個階段進行（方向 → 構圖 → 核心範例 → 逐模組擴展 → 打磨 → 驗收）。這些階段是品質關卡，而非報告檢查點；應持續進行。遇到系統性問題時，回到相關階段，只重做受影響的部分。

在建置期間：

• 重用專案程式碼與互動模式。
• 裝飾性字體僅用於標題；確認中日韓 (CJK) 字型涵蓋率並設定後備字型堆疊。
• 所有狀態：懸停、焦點、啟用、選中、禁用、載入、空、錯誤 —— 視覺上保持一致。
• 動態服務於互動與情緒；整個作品使用相同的持續時間/緩動函式家族；尊重 prefers-reduced-motion。

4. 整合素材

• 先放置主圖，然後安排輔助資訊。
• 透過裁切、遮罩、調色、增加顆粒感、邊緣混合、統一光線方向來整合素材；為文字保留寧靜區域。
• 來源風格衝突 → 進行調色使其一致；仍然衝突 → 替換，不要強行使用。
• 素材是本地專案檔案，而非熱連結 URL。遵守授權/歸屬要求。

視覺審查（基於截圖，優先處理最大問題）

1. 第一眼（縮圖，約 1 秒）：視線落在何處？是否是預期的焦點？是否有值得記住的東西？
2. 瞇眼看：明度結構閱讀為 2-3 個色塊；畫面大部分是插圖還是深色面板？
3. 遮住標題：是否仍能被辨識為此作品，而非任何同類型的樣板？
4. 並排比較：所有區域看起來是否遵循統一的藝術方向（光線、線條、材質、調色板、字體）？
5. 實際尺寸：中文內文閱讀是否舒適？
6. 邊緣：對齊、溢出、瀏覽器原生 chrome、空狀態、沒有遺留的程式繪製藝術或預留位置。
7. 互動：檢查狀態與動態。
8. 目標寬度：檢查窄版面/嵌入式佈局。

修正優先順序：方向 > 構圖 > 核心藝術 > 一致性 > 可讀性 > 細節。每輪只修正最頂端的 1-3 個問題；每輪修正後重新截圖。每個階段最多兩輪；在每次修正前保留一個回滾點。

在修正前診斷原因類別：缺少核心藝術 / 概念認同薄弱 / 構圖層次薄弱 / 風格衝突 / 可讀性或佈局錯誤。每種原因有不同的修正方法。

如果主模型無法看到圖像，請重複使用現有的視覺工具或將審查委派給具有視覺能力的子代理。僅報告實際驗證過的內容。

驗收清單（必須全部為「是」）

1. 是否有一個令人難忘的第一眼元素，且來自於此作品自身的內容？
2. 遮住標題後，這個 UI 是否仍然不會與同類型的樣板混淆？
3. 最重要的視覺區域是否使用與其地位相匹配的精度的插圖素材 —— 沒有程式碼繪製的人物，畫面中沒有明顯更粗糙的元素？
4. 素材、字體、元件和背景是否讀起來像一個整體作品？最樸素的區域是否仍然具有圖像性，且處於相同的品質標準？
5. 頁面是否清晰、可操作、適配目標寬度，且功能從未為了視覺而犧牲？

交付

• 首先交付可運行的結果。
• 複雜任務：簡要說明核心藝術概念、實際使用的素材（附帶授權說明）、審查期間進行的主要修正、驗證結果，以及任何仍為預留位置的東西。
• 簡單任務：僅說明關鍵變更。
• 不要向使用者提供冗長的設計文件。設計紀錄是為了跨階段/跨工作階段的連續性而存在，而非作為使用者報告。