UI-SCL：HTML 設定契約層——使用者可控介面的前端架構方法論

作者：Neo K. 機構：一言諾科技有限公司（EveMissLab） 版本：v1.0 日期：2026年6月 文件類型：Markdown 技術白皮書 / 方法論論文

摘要

本文提出「UI 設定契約層」（UI Settings Contract Layer, UI-SCL）作為現代 HTML / Web 前端系統中的先行架構方法論。其核心主張是：前端 UI 不應只是賣方展示資訊、引導點擊與堆疊功能的介面，而應是使用者在安全與必要資訊邊界內，能夠調整自身注意力、偏好、密度、排序、主題、語言與互動節奏的可控環境。

在傳統前端開發中，設定通常被視為附屬功能：先完成頁面與功能，再補上深色模式、字體大小、語言切換、通知開關或個人化推薦。然而在 AI 編碼、人機協作、Vibe Coding 與未來意圖語言開發模式下，這種「功能先行、設定後補」的方式會迅速產生結構債。當 AI 或人類開發者先把偏好、顯示規則、互動方式硬編在各個 component 裡，後續若要讓使用者控制介面，就必須到處拆除隱性假設，造成維護困難、設定分裂與協作混亂。

本文主張，凡具備一定規模的 HTML 網頁、Web App、前端平台、AI 工具介面或內容型網站，都應在功能實作前建立 UI-SCL。UI-SCL 定義使用者能控制什麼、不能控制什麼；哪些偏好可以匿名保存，哪些偏好需要登入同步；哪些資訊可隱藏、排序、降噪、聚焦；哪些內容因安全、交易、法規或誠信原因不得關閉；以及 AI 在生成前端程式碼時應遵守哪些設定協議。

本文將 UI-SCL 視為 SCL（Settings Contract Layer, 設定契約層）在前端介面領域的具體化，同時也是 ICL（Intent Collaboration Layer, 意圖協作層）在 AI 前端生成中的操作基礎。它不只是前端工程技巧，而是一種使用者主權、介面倫理、資訊降噪與 AI 協作開發的共同方法論。

關鍵詞：HTML、前端架構、UI 設定層、使用者偏好、個人化介面、Vibe Coding、AI 協作開發、設定契約層、使用者主權、可控 UI

第一章：問題陳述——前端 UI 的賣方中心困境

1.1 UI 原本應為使用者而設計

UI 的字面意義是 User Interface，即使用者介面。這意味著 UI 的正當性並不來自賣方想展示什麼，而是來自使用者如何理解、操作、選擇與控制系統。介面存在的目的，是降低使用者與系統之間的摩擦，使使用者能以更低成本完成自身目標。

然而現代網頁與應用介面長期受到商業邏輯、廣告邏輯、平台留存邏輯與資料蒐集邏輯影響。大量介面實際上不是為使用者服務，而是為供應方服務：推薦欄、熱門榜、彈窗、促銷訊息、強制登入提示、演算法排序、通知誘導、無止盡滑動與注意力捕捉機制，常常凌駕於使用者本身的需求之上。

這導致一個根本矛盾：UI 名義上是 User Interface，實際上卻常常成為 Seller Interface、Platform Interface 或 Attention Extraction Interface。使用者被迫在賣方預設的資訊結構中行動，而不是依照自己的偏好、節奏與目的重新配置介面。

UI-SCL 的出發點正是修正這個矛盾。

1.2 靜態 HTML 與固定 UI 的限制

早期 HTML 主要負責標記文件結構：標題、段落、列表、連結、圖片、表格。其核心任務是呈現內容。隨著 CSS、JavaScript、Web API 與前端框架發展，網頁逐漸從文件頁面演化為互動應用。今天的 HTML 不是單純文件容器，而是複雜應用介面的入口。

然而許多前端系統仍然沿用靜態頁面的思維：設計師與開發者先決定頁面長相，再把所有使用者帶進同一套結構。使用者最多能選擇明暗模式、語言、通知開關或帳號偏好，但很少能深度控制介面本身。

例如，內容型網站通常預設展示推薦文章、熱門文章、廣告區塊、相關連結與社群分享工具；電商網站通常預設展示促銷、加購、倒數、推薦商品；AI 工具網站可能預設展示模板、歷史紀錄、側邊欄、提示詞範例與實驗功能。這些元素未必對每個使用者有用，但大多數介面沒有把「隱藏」、「降噪」、「專注」、「重排」、「密度調整」視為一等功能。

UI-SCL 主張，未來前端不應再把使用者偏好當作附屬設定，而應把可控性納入 HTML / UI 的基礎設計。

1.3 AI 編碼時代使設定層更加必要

在 AI 編碼與 Vibe Coding 模式下，前端生成速度大幅提高。人類可以用自然語言要求 AI 生成頁面、元件、表單、設定面板、儀表板與互動流程。這提高了開發效率，但也放大了隱性結構問題。

如果沒有先定義 UI-SCL，AI 很容易將偏好與顯示邏輯散落在各個 component 中。例如：

Header 自己管理主題
Sidebar 自己管理開合
ArticleList 自己管理排序
Notification 自己管理顯示頻率
RecommendationPanel 自己管理隱藏狀態
LocalStorage key 到處命名
CSS class 與 data attribute 無統一規則

短期看，頁面可能可以運作。長期看，這會形成嚴重的設定分裂。當使用者要求「我不想看到推薦內容」、「我想專注模式」、「我想登入前後偏好一致」、「我想讓 AI 幫我重構 UI」時，開發者或下一個 AI 必須逐一追蹤各元件內部假設。這正是前端領域的「翻腸子」問題。

因此，越是 AI 編碼時代，越需要先建立設定契約層。AI 不應在沒有設定契約的狀態下自由生成 UI；AI 應在明確的 UI-SCL 中生成可控、可讀、可交接的前端結構。

第二章：UI-SCL 的定義

2.1 基本定義

UI-SCL（UI Settings Contract Layer）是 HTML / Web 前端系統中的設定契約層。它定義使用者能如何控制介面，包括視覺主題、版面密度、內容顯示、資訊排序、互動提示、通知頻率、語言偏好、可及性需求、專注模式與匿名或會員偏好保存機制。

簡言之：

HTML 定義頁面有什麼；UI-SCL 定義使用者能如何重組這個頁面。

UI-SCL 不是單一 settings.json，也不是一個設定頁面。它是一組前端架構約定，通常包含：

1. UI 設定 schema
2. 預設設定檔
3. 使用者設定檔
4. 設定載入器
5. 設定提供器
6. UI 元件讀取規範
7. 設定持久化策略
8. 可隱藏內容註冊表
9. 不可隱藏資訊白名單
10. AI 生成前端時的協議文件

2.2 UI-SCL 與一般設定功能的差異

一般設定功能通常是功能完成後才補上的選單，例如「深色模式」、「語言切換」、「通知開關」。這種設定是附屬的、局部的、常常只影響少數 UI 狀態。

UI-SCL 則不同。它是功能開始前就存在的介面契約。它要求開發者先回答：

這個介面有哪些可變項？
哪些資訊對使用者是必要的？
哪些資訊只是平台想推送的？
使用者可以隱藏哪些區塊？
使用者可以調整哪些視覺參數？
偏好要保存在哪裡？
匿名使用者能不能保存偏好？
會員登入後偏好如何同步？
AI 生成新 component 時要如何接入設定層？

這些問題若不在開場先回答，後期就會被各個 component 自行決定。當每個 component 都有自己的偏好邏輯，整個 UI 就失去整體治理。

2.3 UI-SCL 作為使用者主權聲明

UI-SCL 的更深意義是使用者主權聲明。它不只處理「技術上能不能設定」，而是處理「使用者是否有權調整自己的介面」。

使用者主權不是無限制自由。它不是讓使用者任意關閉安全警告、隱藏付款金額、略過法規告知或取消刪除確認。相反，真正成熟的使用者主權，是在必要資訊、安全邊界與系統誠信不受破壞的前提下，最大化使用者對注意力環境的控制。

因此，UI-SCL 需要同時定義兩類邊界：

可控制邊界：使用者可以調整、隱藏、排序、聚焦、保存的內容。
不可控制邊界：基於安全、法律、交易、資料完整性而必須呈現的內容。

這使 UI-SCL 不只是前端架構，而是介面倫理與產品哲學。

第三章：使用者可控 UI 原則

3.1 原則定義

本文提出「使用者可控 UI 原則」（User-Controlled Interface Principle）：

在現代前端設計中，UI 不應只是賣方展示資訊與引導行為的介面，而應是使用者調整注意力、偏好、密度與互動節奏的可控環境。因此，任何具備一定規模的 HTML / Web App，都應在功能實作前建立 UI 設定層，明確聲明哪些內容可隱藏、哪些偏好可保存、哪些介面可調整，以及哪些資訊因安全、交易或法規原因不可關閉。

這條原則的核心不是「所有頁面都要複雜個人化」，而是「所有足夠複雜的 UI 都應先思考可控性」。

3.2 注意力是介面設計的核心資源

UI 不只是一組視覺元件。UI 實際上是在分配使用者注意力。字體大小、色彩、位置、彈窗、通知、推薦、排序、側邊欄、固定導航列、無限滾動，都在決定使用者看到什麼、忽略什麼、先做什麼、停留多久。

如果注意力完全由平台決定，使用者就只是被動接收者。若 UI-SCL 允許使用者調整注意力環境，介面才真正轉向使用者中心。

例如：

使用者可以關閉推薦欄，專注閱讀文章。
使用者可以把工具欄移到左側，符合自己的操作習慣。
使用者可以提高文字大小，降低閱讀負擔。
使用者可以降低動畫，避免分心或不適。
使用者可以選擇只顯示核心功能，隱藏實驗功能。
使用者可以保存偏好，不必每次重新設定。

這些不是瑣碎功能，而是對使用者注意力的尊重。

3.3 UI 應從展示介面變成調適環境

傳統 UI 設計常常把頁面視為一張固定海報：設計師決定布局，使用者接受。現代 Web App 應轉向調適環境：系統提供可變參數，使用者依自己的需求調整。

展示介面關心的是：

我們想讓使用者看到什麼？
我們想讓使用者點什麼？
我們想讓使用者停留在哪裡？

調適環境關心的是：

使用者想完成什麼？
使用者想少看什麼？
使用者想集中注意力在哪裡？
使用者是否需要不同閱讀密度？
使用者是否需要不同互動節奏？
使用者是否需要可及性調整？

UI-SCL 正是從展示介面走向調適環境的架構基礎。

第四章：HTML、CSS、JavaScript 與 UI-SCL 的關係

4.1 HTML：語義骨架

HTML 定義頁面結構與語義。良好的 HTML 應該讓人類、瀏覽器、搜尋引擎、輔助科技與 AI 都能理解頁面內容。例如標題使用 <h1> 至 <h6>，主內容使用 <main>，導航使用 <nav>，文章使用 <article>，側邊區塊使用 <aside>。

在 UI-SCL 中，HTML 還應承擔一個任務：讓可控制區塊具備清楚標記。也就是說，前端不只要寫出看起來能用的 HTML，還要讓設定層知道哪些區塊可被調整。

例如：

<aside data-ui-region="recommendations" data-user-hideable="true">
  ...
</aside>

<section data-ui-region="legal-notice" data-user-hideable="false">
  ...
</section>

這種標記讓 UI 的可控制性不再隱藏於 JavaScript 內部，而是進入 HTML 語義層。

4.2 CSS：設定映射層

CSS 不應只是固定樣式檔，也應是設定層的映射器。UI-SCL 可透過 CSS variables、data attributes、class strategy 或 cascade layers 將設定轉換為視覺效果。

例如：

:root {
  --font-scale: 1;
  --content-width: 960px;
  --motion-level: normal;
}

body[data-density="compact"] {
  --content-width: 1120px;
}

body[data-density="comfortable"] {
  --content-width: 900px;
}

body[data-focus-mode="true"] [data-ui-region="recommendations"],
body[data-focus-mode="true"] [data-ui-region="trending"] {
  display: none;
}

這種方式讓設定與視覺呈現保持明確對應，而不是把所有邏輯寫死在 component 中。

4.3 JavaScript：設定載入與狀態治理

JavaScript 負責載入、驗證、套用、保存與同步 UI 設定。它不應讓每個 component 自行從 localStorage 讀寫偏好，而應建立統一的 Settings Provider 或 Config Registry。

最小流程如下：

default-ui-settings.json
      ↓
ui-settings.schema.json
      ↓
settings-loader.js
      ↓
settings-provider.js
      ↓
component rendering / CSS data attributes
      ↓
localStorage / server profile / session fallback

這個流程確保設定具有預設值、驗證規則、讀取介面與持久化策略。

第五章：UI-SCL 的核心組件

5.1 UI Settings Schema

Schema 是 UI-SCL 的骨架。它定義每個設定項的名稱、類型、預設值、可選範圍、用途、影響層級與安全限制。

例如：

{
  "theme.mode": {
    "type": "enum",
    "options": ["light", "dark", "system"],
    "default": "system",
    "description": "控制介面明暗模式",
    "userEditable": true,
    "scope": "visual"
  },
  "content.hideRecommendations": {
    "type": "boolean",
    "default": false,
    "description": "是否隱藏推薦內容",
    "userEditable": true,
    "scope": "attention"
  },
  "security.showPaymentAmount": {
    "type": "boolean",
    "default": true,
    "description": "付款金額必須顯示，不得由使用者關閉",
    "userEditable": false,
    "scope": "safety"
  }
}

Schema 的價值不只是讓程式驗證設定，也是讓人類與 AI 知道這個 UI 系統允許什麼變動。

5.2 Default Settings

預設設定是系統對一般使用者的初始判斷。它應該保守、清晰、不過度打擾，並保留使用者調整空間。

例如：

{
  "theme": {
    "mode": "system",
    "accentColor": "default"
  },
  "layout": {
    "density": "comfortable",
    "sidebar": "auto",
    "contentWidth": "normal"
  },
  "content": {
    "hideRecommendations": false,
    "hideTrending": false,
    "focusMode": false
  },
  "accessibility": {
    "fontScale": 1,
    "reduceMotion": false,
    "highContrast": false
  }
}

預設值不應只是開發者習慣，而應反映產品對使用者注意力與安全邊界的基本尊重。

5.3 User Settings

User Settings 是使用者實際偏好。它可能保存在 localStorage、sessionStorage、cookie、IndexedDB、server profile 或跨裝置帳號設定中。

UI-SCL 應明確區分：

匿名偏好：不需登入即可保存，例如 theme、density、focusMode。
會員偏好：登入後跨裝置同步，例如 preferredSections、dashboardLayout。
敏感偏好：涉及隱私、通知、資料使用，需要更明確同意。
暫時偏好：只在本次 session 有效，例如臨時隱藏某個提示。

這種分類能避免所有設定混在一起，造成隱私與同步混亂。

5.4 UI Region Registry

UI Region Registry 是可控制區塊註冊表。它記錄每個 UI 區域是否可隱藏、可排序、可調密度、可移動，以及其必要性等級。

範例：

{
  "recommendations": {
    "label": "推薦內容",
    "hideable": true,
    "reorderable": true,
    "required": false,
    "reason": "非必要內容，可依使用者偏好隱藏"
  },
  "payment-summary": {
    "label": "付款摘要",
    "hideable": false,
    "reorderable": false,
    "required": true,
    "reason": "交易必要資訊，不得隱藏"
  },
  "security-warning": {
    "label": "安全警告",
    "hideable": false,
    "reorderable": false,
    "required": true,
    "reason": "涉及帳號安全與風險提示"
  }
}

這使 UI 控制權不再依賴個別開發者判斷，而是進入可檢查的契約層。

5.5 Settings Provider

Settings Provider 是前端系統中的設定存取介面。所有 component 都應透過 Provider 取得設定，不應自行讀寫底層存儲。

偽代碼：

const uiSettings = getUISettings();

if (uiSettings.content.hideRecommendations) {
  hideRegion("recommendations");
}

更成熟的寫法應是 component 只宣告自己受哪些設定影響，由渲染層統一處理：

registerUIRegion({
  id: "recommendations",
  hideable: true,
  controlledBy: "content.hideRecommendations"
});

5.6 Persistence Adapter

Persistence Adapter 負責決定設定保存位置。不同產品可使用不同策略：

localStorage：適合匿名偏好與簡單設定。
sessionStorage：適合短期狀態。
cookie：適合需與伺服器請求一起傳送的小型偏好，但需注意隱私。
IndexedDB：適合複雜本地資料與大型偏好配置。
Server Profile：適合會員跨裝置同步。
Hybrid Strategy：匿名本地保存，登入後合併到帳號設定。

UI-SCL 不強制使用某一種技術，而要求先明確定義策略。

第六章：非會員與會員偏好的雙軌保存

6.1 非會員也應擁有基本偏好權

許多網站把偏好保存綁定會員帳號。這在商業上可理解，但從使用者中心角度看，非會員也應享有基本介面控制權。使用者不登入，也應能選擇深色模式、字體大小、隱藏推薦內容或開啟專注模式。

非會員偏好可以透過本地存儲保存。這能降低使用門檻，也避免把「想讓介面舒服一點」變成強迫註冊的理由。

非會員可保存的偏好通常包括：

theme
fontScale
density
reduceMotion
focusMode
hideRecommendations
preferredLanguage
lastVisitedSection

6.2 會員偏好的跨裝置同步

會員偏好則適合保存更完整的使用者設定，例如 dashboard layout、內容訂閱、常用功能、跨裝置主題、通知規則與 AI 工具偏好。

會員偏好應支援：

跨裝置同步
版本遷移
偏好匯出
偏好重置
與匿名偏好合併
隱私權管理

當使用者從匿名狀態登入時，系統需要決定本地偏好與雲端偏好的合併規則。例如：

本地偏好較新 → 詢問是否覆蓋雲端
雲端偏好較完整 → 合併非衝突項
安全相關偏好 → 不自動覆蓋，需確認

這些規則不應臨時寫在登入流程中，而應屬於 UI-SCL 的 persistence policy。

6.3 偏好保存的倫理邊界

保存偏好不等於追蹤使用者。UI-SCL 必須區分「使用者主動偏好」與「平台暗中蒐集行為」。

使用者主動偏好包括：

我選擇深色模式。
我選擇隱藏推薦。
我選擇字體放大。
我選擇只看某些內容。

平台行為追蹤包括：

系統記錄我停留在哪裡。
系統推測我的興趣。
系統依點擊行為建立個人化模型。
系統跨站追蹤我的偏好。

UI-SCL 處理的是使用者主動控制，不應被包裝成追蹤或操控工具。

第七章：內容可見性控制

7.1 隱藏不是刪除，而是注意力配置

使用者隱藏某個內容區塊，不代表該內容不存在，也不代表系統不提供。隱藏是一種注意力配置：使用者選擇現在不看、不需要、不想被干擾。

因此 UI-SCL 應支援：

hide：隱藏區塊
collapse：收合區塊
mute：降低提示頻率
pin：固定重要區塊
prioritize：優先顯示某類內容
filter：過濾內容類型
sort：排序內容
focus：進入專注模式

這些操作本質上都是使用者對注意力環境的調整。

7.2 可隱藏內容與不可隱藏內容

可隱藏內容包括：

推薦文章
熱門榜單
促銷區塊
非必要廣告
社群分享按鈕
實驗功能入口
提示範例
裝飾性動畫
非必要側邊欄

不可隱藏內容包括：

付款金額
錯誤訊息
帳號安全警告
刪除確認
隱私權重大提示
法規必要揭露
交易條款確認
系統狀態異常
資料遺失警告

中間地帶則需要更細緻的政策。例如通知可以允許降低頻率，但不能讓使用者完全錯過安全警告；推薦可以隱藏，但搜尋結果不能被任意扭曲；促銷可以收合，但訂單費用不能弱化。

7.3 專注模式

專注模式是 UI-SCL 的典型應用。它不是單純把頁面變空，而是根據使用者任務重新配置 UI。

閱讀型專注模式可能隱藏：

推薦欄
熱門欄
廣告
留言區
社群按鈕
非必要導航

寫作型專注模式可能保留：

編輯器
字數統計
保存狀態
必要工具列

AI 工具專注模式可能保留：

輸入框
輸出區
上下文文件
必要設定
執行狀態

同樣是 focusMode，不同產品應有不同映射。因此 focusMode 不應只是 CSS class，而應由 UI-SCL 定義其行為。

第八章：UI-SCL 與可及性

8.1 可及性不是額外功能

可及性常被誤解為只服務少數使用者的特殊功能。然而字體大小、對比度、動畫減少、鍵盤操作、語義標記、螢幕閱讀器支援，實際上都提升所有使用者在不同情境下的體驗。

UI-SCL 應把可及性設定納入核心，而不是放在角落。

基本可及性設定包括：

fontScale
highContrast
reduceMotion
keyboardNavigation
screenReaderMode
lineHeight
contentWidth
colorBlindSafePalette

8.2 可及性與使用者主權

可及性本質上也是使用者主權。當使用者能調整字體、降低動畫、提高對比、改變密度，他就在重新配置介面與自身感知能力之間的關係。

這不是美化，而是讓介面服從人的身體與認知差異。

8.3 AI 生成前端時的可及性約束

AI 在生成前端時常會優先完成視覺樣式與互動效果，卻忽略語義標記、aria 屬性、鍵盤可用性與可及性設定。UI-SCL 應要求 AI 生成時遵守：

不得用 div 取代所有語義元素。
互動元素必須可鍵盤操作。
重要內容不得只靠顏色表達。
動畫必須可被 reduceMotion 設定影響。
字體大小不得完全鎖死。
所有可隱藏區塊必須保留結構語義。

這使 AI 生成的 UI 更容易被人類、工具與輔助科技理解。

第九章：AI 編碼時代的 UI-SCL 協議

9.1 協議先於生成

在 Vibe Coding 中，人類常直接要求 AI：

幫我做一個漂亮的首頁。
幫我做一個 dashboard。
幫我做一個設定頁。
幫我做一個文章列表。

這種提示可以快速得到結果，但往往缺乏架構約束。UI-SCL 要求在生成前先給 AI 一套協議：

所有 UI 偏好必須來自 uiSettings。
不得在 component 內硬編碼偏好。
所有可隱藏區塊必須註冊到 UI Region Registry。
所有設定必須有 default、schema、description、fallback。
所有 localStorage key 必須集中定義。
所有 CSS 狀態必須由 data attributes 或 CSS variables 驅動。
所有安全必要資訊不得被 hideable 設定控制。

這些協議讓 AI 不只是生成畫面，而是在可治理架構中生成前端。

9.2 AI 生成 UI 的常見反模式

AI 生成前端常見問題包括：

1. 硬編碼 theme、language、density。
2. 每個 component 各自讀寫 localStorage。
3. 設定名稱不一致。
4. CSS class 命名無規則。
5. 隱藏內容只用 display:none，沒有語義標記。
6. 重要安全資訊也被納入一般 hideable 設定。
7. 設定頁與實際 UI 狀態不同步。
8. 沒有 schema，導致 AI 後續不知道設定範圍。
9. 沒有 fallback，設定損壞時頁面異常。
10. 亂碼、奇怪命名、不可見字元進入程式碼。

UI-SCL 的任務就是提前阻止這些問題。

9.3 給 AI 的 UI-SCL Prompt 模板

以下是一個可用於 AI 前端生成的提示模板：

你正在為一個 Web App 生成前端 UI。
必須遵守 UI-SCL 協議：

1. 所有使用者可調整的介面偏好，都必須定義在 ui-settings.schema.json。
2. 不得在任何 component 中硬編碼 theme、density、focusMode、language、hideRecommendations。
3. 所有 UI 區塊必須標記 data-ui-region。
4. 可隱藏區塊必須在 ui-region-registry.json 中註冊。
5. 安全、交易、錯誤、法規相關資訊不得設為 hideable。
6. CSS 必須優先使用 CSS variables 與 body data attributes 接收設定。
7. 所有設定讀取必須經過 SettingsProvider。
8. localStorage key 必須集中定義，不得散落在 component 中。
9. 生成程式碼不得包含亂碼、不可見 Unicode、無意義命名。
10. 請同時生成 schema、default settings、provider、範例 component。

這種提示能明顯提升 AI 生成前端的結構品質。

第十章：亂碼、命名與前端可交接性

10.1 前端亂碼的風險

前端系統中的亂碼不只影響顯示，也會影響協作與維護。亂碼可能出現在：

HTML 文字內容
CSS class 名稱
JavaScript 變數名
JSON 設定 key
註解
檔名
data attribute
localStorage key

在 AI 協作開發中，亂碼尤其危險，因為下一個 AI 可能會把亂碼當成有意義的模式延續下去。人類 reviewer 也可能因為看不懂而忽略問題，導致 bug 或設定失效。

10.2 語義命名是協作介面

命名不是小事。命名是人類與 AI 共同理解系統的入口。

例如：

bad:
x1
tmpPanel
newBox
abcSetting
thingVisible

good:
hideRecommendations
focusModeEnabled
contentDensity
uiRegionRegistry
paymentSummaryVisible

好的命名讓下一個人類與 AI 能快速理解意圖。壞的命名則會累積語義債。

10.3 UI-SCL 的命名規則

UI-SCL 應要求設定命名具備一致性：

theme.mode
layout.density
layout.sidebar
content.hideRecommendations
content.focusMode
accessibility.fontScale
accessibility.reduceMotion
notifications.frequency
privacy.analyticsConsent

命名應避免：

無意義縮寫
混合語言亂碼
拼音與英文任意混用
看似英文但語義不清
同一概念多種名稱
不可見字元
全形半形混亂

10.4 可交接性標準

前端程式碼完成不等於可交接。可交接至少應滿足：

1. 新人能理解設定來源。
2. AI 能根據 schema 知道可變項。
3. component 不需要猜測設定含義。
4. UI 區塊是否可隱藏有明確註冊。
5. 不可隱藏資訊有原因說明。
6. 命名一致，沒有亂碼。
7. 設定損壞時有 fallback。
8. 文件能說明如何新增設定項。

不可交接的 UI，不應被視為真正完成。

第十一章：不同規模網頁的 UI-SCL 演化

11.1 小型 HTML 頁面

小型頁面可以保持簡單，不必過度工程化。若只有一頁靜態介紹頁，也許只需要：

index.html
style.css
config.js

最小 config.js：

const uiSettings = {
  theme: "system",
  fontScale: 1,
  reduceMotion: false
};

小型頁面的原則是：不需要複雜 settings platform，但仍應避免把偏好硬編在多處。

11.2 中型內容網站

中型網站可能有文章列表、分類、搜尋、推薦、會員與多頁內容。此時應建立：

settings/
  ui-settings.schema.json
  default-ui-settings.json
  ui-region-registry.json
src/
  settings-provider.js
  persistence-adapter.js
  components/

此階段重點是內容可見性、專注模式、匿名偏好保存與基本可及性。

11.3 大型 Web App

大型 Web App 需要更完整的 UI-SCL：

settings/
  schema/
  defaults/
  user-profile/
  feature-flags/
  region-registry/
  persistence/
  migration/
  audit/

大型系統還需要：

設定版本管理
跨裝置同步
設定遷移
權限控制
團隊責任邊界
UI 設定測試
AI 生成協議

11.4 超大型平台

超大型平台可能需要獨立的 Settings Platform：

settings-service
schema-registry
preference-sync-service
ui-policy-engine
feature-flag-platform
accessibility-profile-service
consent-management-service
audit-log-service

此時 UI-SCL 不再只是前端資料夾，而是跨前端、後端、帳號系統、隱私政策與 AI 代理的基礎設施。

第十二章：UI-SCL 與產品倫理

12.1 從操控介面到尊重介面

許多產品透過暗黑模式設計、預設勾選、彈窗壓迫、無限滾動與難以關閉的推薦來最大化商業指標。這些設計也許能提高短期轉換率，但會削弱使用者信任。

UI-SCL 提倡尊重介面。尊重介面不是放棄商業，而是承認使用者不是被動流量，而是具有偏好、界限與注意力主權的人。

12.2 賣方利益與使用者利益的衝突

賣方可能希望使用者多看推薦、多點廣告、多接受促銷、多開通知。使用者可能希望少被打擾、更快找到核心內容、更容易關閉噪音。

UI-SCL 不能天真地假裝衝突不存在。它應把衝突公開化，並在契約層決定：

哪些內容是平台想推，但使用者可關閉？
哪些內容是交易必要，使用者不可關閉？
哪些內容可以降低頻率？
哪些內容需要明確同意？
哪些內容不可偽裝成必要資訊？

12.3 使用者控制權也是競爭優勢

長期看，提供可控 UI 可能成為產品差異化優勢。當越來越多網站充滿干擾，能讓使用者真正控制介面的產品會更容易建立信任。

尤其在 AI 工具、知識工具、閱讀工具、開發工具、研究工具與專業工作台中，可控 UI 幾乎是必要條件。專業使用者不只需要功能，也需要能配置自己的工作環境。

第十三章：UI-SCL 實作模板

13.1 基礎資料夾結構

project/
  index.html
  src/
    app.js
    settings/
      ui-settings.schema.json
      default-ui-settings.json
      ui-region-registry.json
      settings-provider.js
      persistence-adapter.js
    components/
      Header.js
      Sidebar.js
      ArticleList.js
      RecommendationPanel.js
  styles/
    base.css
    theme.css
    layout.css
    accessibility.css
  docs/
    UI-SCL.md

13.2 預設設定範例

{
  "theme": {
    "mode": "system",
    "accentColor": "default"
  },
  "layout": {
    "density": "comfortable",
    "sidebar": "auto",
    "contentWidth": "normal"
  },
  "content": {
    "focusMode": false,
    "hideRecommendations": false,
    "hideTrending": false
  },
  "accessibility": {
    "fontScale": 1,
    "reduceMotion": false,
    "highContrast": false
  },
  "notifications": {
    "frequency": "normal",
    "marketing": false,
    "security": true
  }
}

13.3 HTML 範例

<body data-theme="system" data-density="comfortable" data-focus-mode="false">
  <header data-ui-region="header" data-user-hideable="false">
    ...
  </header>

  <main data-ui-region="main-content" data-user-hideable="false">
    ...
  </main>

  <aside data-ui-region="recommendations" data-user-hideable="true">
    ...
  </aside>

  <section data-ui-region="security-warning" data-user-hideable="false">
    ...
  </section>
</body>

13.4 Settings Provider 範例

const DEFAULT_SETTINGS = {
  theme: { mode: "system", accentColor: "default" },
  layout: { density: "comfortable", sidebar: "auto" },
  content: { focusMode: false, hideRecommendations: false },
  accessibility: { fontScale: 1, reduceMotion: false }
};

const STORAGE_KEY = "ui-scl-settings-v1";

export function loadSettings() {
  try {
    const raw = localStorage.getItem(STORAGE_KEY);
    if (!raw) return DEFAULT_SETTINGS;
    const userSettings = JSON.parse(raw);
    return mergeSettings(DEFAULT_SETTINGS, userSettings);
  } catch {
    return DEFAULT_SETTINGS;
  }
}

export function saveSettings(settings) {
  localStorage.setItem(STORAGE_KEY, JSON.stringify(settings));
}

export function applySettings(settings) {
  document.body.dataset.theme = settings.theme.mode;
  document.body.dataset.density = settings.layout.density;
  document.body.dataset.focusMode = String(settings.content.focusMode);
  document.documentElement.style.setProperty(
    "--font-scale",
    settings.accessibility.fontScale
  );
}

function mergeSettings(defaults, userSettings) {
  return {
    ...defaults,
    ...userSettings,
    theme: { ...defaults.theme, ...userSettings.theme },
    layout: { ...defaults.layout, ...userSettings.layout },
    content: { ...defaults.content, ...userSettings.content },
    accessibility: { ...defaults.accessibility, ...userSettings.accessibility }
  };
}

第十四章：反模式與風險

14.1 設定散落

設定散落是最常見問題。每個 component 自己保存偏好，會造成命名不一致、狀態不同步、同步困難與 AI 難以理解。

14.2 過度設定

不是所有東西都要開放設定。過度設定會造成使用者負擔。UI-SCL 應避免把產品責任推給使用者。好的設定層應提供少量高價值控制點，而不是讓使用者面對幾百個開關。

14.3 偽使用者控制

有些產品表面上提供設定，實際上只是象徵性開關。例如使用者關閉推薦後，系統仍以其他形式插入推薦；使用者關閉通知後，平台仍透過彈窗提醒。這會破壞信任。

14.4 安全資訊被錯誤隱藏

若安全警告、付款金額、錯誤訊息被納入一般可隱藏區塊，將造成嚴重風險。因此 UI-SCL 必須有不可隱藏白名單。

14.5 AI 生成設定債

當 AI 快速生成大量 UI 而缺乏設定契約，會形成難以追蹤的前端設定債。這種債比一般 CSS 混亂更麻煩，因為它牽涉使用者偏好、持久化、介面倫理與產品行為。

第十五章：UI-SCL 與未來意圖語言

15.1 意圖語言需要可控介面

未來若人類能直接用自然語言命令 AI 修改介面，例如：

把這個網站改成專注閱讀模式。
隱藏所有推薦與社群元素。
幫我把工具欄改成左側。
只保留研究相關內容。
把動畫全部關掉。

那麼 AI 必須知道哪些 UI 區塊可控制、如何控制、控制後是否違反安全或必要資訊邊界。這正是 UI-SCL 的作用。

沒有 UI-SCL，AI 只能猜。 有 UI-SCL，AI 可以依契約執行。

15.2 言出法隨之前，需要設定契約

真正的「言出法隨」不是一句話讓系統神奇改變，而是系統已經具備清楚的可變結構。人類說出意圖，AI 根據設定契約、架構邊界與安全規則轉換為可靠操作。

因此，UI-SCL 是意圖語言前端化的基礎之一。

15.3 從頁面到個人化工作環境

未來的前端 UI 會越來越不像固定頁面，而像個人化工作環境。使用者不只是瀏覽網站，而是在配置自己的資訊空間。AI 則成為協助使用者重新排列、篩選、降噪與擴展介面的代理。

在這個時代，UI-SCL 不只是工程文件，而是人類與 AI 共同操作介面的語法前提。

第十六章：結論

本文提出 UI-SCL 作為 HTML / Web 前端系統中的設定契約層方法論。其核心命題是：前端 UI 不應只是賣方展示與平台引導的介面，而應是使用者在安全邊界內可調整、可保存、可聚焦、可降噪的注意力環境。

UI-SCL 要求前端開發在功能實作前先定義設定層，明確聲明使用者能控制什麼、不能控制什麼；哪些偏好可匿名保存，哪些需要會員同步；哪些內容可隱藏，哪些資訊不可關閉；AI 生成前端時必須遵守哪些設定協議。

在 AI 編碼與 Vibe Coding 時代，UI-SCL 的重要性更高。因為 AI 能快速生成 UI，也能快速生成混亂。若缺乏設定契約，偏好、顯示、控制與持久化邏輯會散落在元件中，造成後續人類與 AI 都難以維護。反之，若先建立 UI-SCL，AI 就能在明確結構中生成可控、可讀、可交接的前端。

本文最後主張：

未來的好 UI，不是讓使用者被動接受設計，而是讓使用者在安全與必要資訊邊界內，重新配置自己的注意力環境。

HTML 定義頁面有什麼。 UI-SCL 定義使用者能如何重組這個頁面。 AI 可以生成介面，但使用者主權與設定契約必須先被聲明。

附錄 A：UI-SCL 檢查清單

[ ] 是否有 ui-settings.schema.json？
[ ] 是否有 default-ui-settings.json？
[ ] 是否有 UI Region Registry？
[ ] 是否明確區分可隱藏與不可隱藏內容？
[ ] 是否支援匿名偏好保存？
[ ] 是否定義會員偏好同步策略？
[ ] 是否有 Settings Provider？
[ ] 是否禁止 component 直接硬編碼偏好？
[ ] 是否集中管理 localStorage key？
[ ] 是否支援 focusMode？
[ ] 是否支援基本可及性設定？
[ ] 是否有設定 fallback？
[ ] 是否定義 AI 生成前端協議？
[ ] 是否禁止亂碼、不可見字元與無意義命名？

附錄 B：UI-SCL 最小可行模板

settings/
  default-ui-settings.json
  ui-settings.schema.json
  ui-region-registry.json
  settings-provider.js
docs/
  UI-SCL.md

附錄 C：核心命題

HTML 定義頁面有什麼；UI-SCL 定義使用者能如何重組這個頁面。

UI 不應只是賣方展示資訊的介面，而應是使用者配置注意力的環境。

設定不是功能完成後的附屬選單，而是前端可控性的先行契約。

在 AI 編碼時代，沒有 UI-SCL 的前端生成會迅速累積設定債。

不可讀、不可控、不可交接的 UI，不應被視為真正完成。

使用者主權不是任意關閉一切，而是在安全與必要資訊邊界內最大化介面控制權。

附錄 D：與既有方法論的關係

UI-SCL 可被視為以下方法論的前端延伸：

三層認知架構：
  UI-SCL 位於宏觀決策與中觀架構之間，回答使用者可控制什麼。

MSSP：
  UI-SCL 可作為 FMS 與前端 SMS/TMS 之間的可變性契約。

規模感知架構：
  UI-SCL 會隨網頁規模從 config.js 演化為 settings platform。

SCL：
  UI-SCL 是設定契約層在前端 UI 領域的具體分支。

ICL：
  UI-SCL 是 AI 與人類協作生成 UI 時的前端協議基礎。

附錄 E：給 AI 的簡短指令

請依 UI-SCL 架構生成前端。
所有 UI 偏好集中於 settings 層。
不得硬編碼使用者偏好。
所有可隱藏區塊需註冊。
所有不可隱藏資訊需標示原因。
支援匿名偏好保存與未來會員同步。
輸出不得包含亂碼、無意義命名或不可見字元。