背景
当前 Web UI 已经具备主题预设、运行时 CSS 变量注入、组件库 token 和 generated widget theme payload 等多条主题链路,但颜色定义分散在多个层级。组件样式、运行时主题服务、静态 token、widget iframe、编辑器/终端/语法高亮等专用区域之间缺少统一的治理边界,导致主题调整、视觉一致性验证和后续维护成本持续上升。
这个 issue 是主题与颜色 token 治理的顶层规划入口,用于描述背景、问题、核心方案、风险和关键里程碑。它不用于维护逐项进度,也不用于记录具体 PR 列表。后续 PR 可以引用此 issue 作为背景,但不应使用自动关闭关键字关闭它。
核心问题
- 颜色字面量和 fallback 分散在大量组件文件中,同一语义角色存在多种写法,容易形成隐性的第二套色板。
- 静态 token、运行时
ThemeService 注入变量、generated widget payload 暴露变量之间没有完全统一的注册契约,某些 UI 形态可能依赖局部 fallback 或运行时偶然存在的变量。
- 近似色、重复色和历史命名 alias 混在一起,缺少判断标准。直接合并可能削弱区域边界、交互状态、状态语义、diff/git 语义或主题个性。
- editor、terminal、Mermaid、syntax、diff、generated widget 等专用视觉域与通用 app token 的边界不够清晰,容易在“减少色值数量”时被错误归一。
- 当前缺少可重复的审计工具和颜色预算约束,新增组件仍可能继续引入 raw color、局部 fallback 或未登记的 token 名称。
核心解决方案
采用分层 token 治理模型:
- Primitive palette:承载基础 hue、neutral、alpha ramp,不直接作为普通组件的业务语义色使用。
- App semantic token:承载背景、文本、边框、状态、交互、intent 等产品级语义,是普通 UI 的默认使用层。
- Component token:只在通用 semantic token 无法表达组件契约时使用,例如 Flow Chat、tool card、diff/git、widget frame、editor/terminal 等。
- Compatibility alias:保留历史命名和迁移期别名,先补齐契约再逐步迁移调用点,避免删除 fallback 后造成早期渲染、嵌入式渲染或隔离 iframe 样式丢失。
- Exception namespace:为 editor、terminal、syntax、diff、Mermaid、theme personality 等专用色板建立明确例外空间,避免它们被错误压缩到普通 app token。
治理原则:
- 极其相似、肉眼难以区分且语义一致的颜色可以直接合并。
- 其他近似颜色必须有明确依据,包括语义角色、相邻显示风险、状态区分、数据含义、主题覆盖和可访问性影响。
- 目标是减少色值数量,但不是抹平有用户理解价值的视觉差异。
- 一个应用的色值数量应有明确上限,新增 raw color 或 component token 必须能说明语义和边界。
相关风险
- 相邻 surface 的近似背景色被错误合并,可能导致 panel、card、input、canvas、floating overlay 等区域边界变弱。
- hover、active、selected、focus、disabled、loading、drag-over 等状态色被合并,可能削弱交互 affordance。
- success、warning、error、info、destructive、git/diff 等 intent 或数据语义被过度归一,可能影响用户判断。
- 静态 token、运行时注入和 widget payload 不一致,可能在 iframe、静态渲染、早期渲染或主题切换场景下出现 UI 差异。
- 大规模迁移 PR 容易产生 review 疲劳,导致视觉回归、contrast 回归或专用色板误迁移漏审。
- 过早启用严格 CI 约束可能被历史债务阻塞;过晚启用约束则可能继续新增同类问题。
关键里程碑
- 建立颜色审计基线:统计 raw color、fallback literal、token 使用、未定义 token、重复色、近似色和高风险 surface。
- 明确 canonical token 契约:对齐静态 token、运行时主题注入和 generated widget payload,补齐兼容 alias。
- 迁移精确重复项:优先处理完全重复、格式差异、历史 alias 和明确等价 fallback,不改变用户可见视觉语义。
- 收敛组件 fallback:按 component-library、Flow Chat、tool card、review panel、git/diff、widget 等 surface 分批迁移。
- 抽取必要 component token:为高密度或专用 UI surface 建立清晰的组件级 token,而不是让组件继续携带 raw color。
- 审慎合并近似色:每个非完全等价合并都需要调用点、相邻关系、状态语义和视觉证据支持。
- 建立防回退约束:在迁移期使用 baseline-aware audit,逐步阻止新增普通组件 raw color、未登记 token 和无依据的 fallback。
背景
当前 Web UI 已经具备主题预设、运行时 CSS 变量注入、组件库 token 和 generated widget theme payload 等多条主题链路,但颜色定义分散在多个层级。组件样式、运行时主题服务、静态 token、widget iframe、编辑器/终端/语法高亮等专用区域之间缺少统一的治理边界,导致主题调整、视觉一致性验证和后续维护成本持续上升。
这个 issue 是主题与颜色 token 治理的顶层规划入口,用于描述背景、问题、核心方案、风险和关键里程碑。它不用于维护逐项进度,也不用于记录具体 PR 列表。后续 PR 可以引用此 issue 作为背景,但不应使用自动关闭关键字关闭它。
核心问题
ThemeService注入变量、generated widget payload 暴露变量之间没有完全统一的注册契约,某些 UI 形态可能依赖局部 fallback 或运行时偶然存在的变量。核心解决方案
采用分层 token 治理模型:
治理原则:
相关风险
关键里程碑