设计系统、Design Tokens 与组件库体系

• 设计系统分层中各层的抽象程度与职责边界
• 层与层之间的依赖方向与演进闭环
• 分层如何指导团队分工与变更隔离

成熟设计系统通常按抽象程度自下而上分为五层。最底层是设计原则（Principles），如"清晰优先""一致优于新颖"，它们不产出代码，只提供方向性约束，是其他所有层的价值源头。第二层是 Design Tokens，把颜色、间距、字号、圆角、阴影等视觉决策原子化为跨平台可共享的变量，将"设计决策"与"组件实现"解耦。第三层是组件（Components），由 Tokens 组装而成，暴露受控的 API，是业务可复用的最小 UI 单元。第四层是模式（Patterns），即组件组合出的高阶解决方案，如表单校验流程、空状态、数据加载骨架屏，回答"如何用组件解决一类业务问题"。最顶层是文档（Documentation），把原则、Tokens、组件与模式沉淀为可检索、可演示、可消费的知识资产。

层级之间是"自下而上约束、自上而下消费"的关系：原则约束 Tokens 的取值，Tokens 约束组件的实现，组件组合为模式，模式沉淀为文档；同时文档与业务反馈又驱动新原则与新组件的产生，形成闭环。责任分工也随之清晰：设计团队负责原则与 Tokens，组件库团队负责组件与模式，内容与文档团队负责文档沉淀。工程落地的核心价值是隔离变化：品牌换色只触及 Tokens 层，组件内部结构重构不触碰上层 API，业务侧永远只依赖稳定接口，从而把跨端、跨业务的返工成本降到最低。

本题考察对设计系统本质的理解：分层不是为了架构好看，而是为了隔离变化与明确协作边界。回答时先按抽象度排序列出五层并给出各自职责，再说明层间依赖方向（约束与消费），最后落到团队分工与变更隔离，体现从"抽象模型"到"工程治理"的完整性。常见失分点是只罗列名词而不讲层间关系，或者漏掉"文档反馈驱动迭代"这一闭环。

• W3C Design Tokens 规范的结构：$type / $value、分组与别名引用
• 构建管线分发：Style Dictionary / Tokens Studio 的多平台输出
• CSS Variables 的边界：运行时切换能力与静态消费场景的分野

W3C Design Tokens 规范用 JSON 描述 token：每个 token 由 name、$value、$type（color、dimension、fontFamily 等）构成，可用 $description 注释、以分组表达层级，并支持别名引用（$value 指向另一个 token），实现"一次定义、多处复用"的引用关系。规范本身与平台无关，分发必须借助构建管线：Style Dictionary、Tokens Studio Export 或自研脚本读取 token JSON，通过 transform / format 输出各平台产物——Web 端生成 CSS Variables 或 SCSS 变量，iOS 生成 Swift / SwiftUI 的 Color 常量，Android 生成 resources XML 或 Kotlin 常量，Server 端生成 JSON / 配置供模板渲染或邮件样式消费。别名引用在管线中被解析为最终值或保留为变量引用，确保各平台语义一致。

CSS Variables 的优势是运行时切换（暗色模式、品牌换肤无需重新构建），边界也很明确：其一，Server 端与原生端不消费 CSS，必须用静态产物；其二，CSS Variables 无法直接在原生代码、模板引擎中消费，涉及颜色空间换算（oklch 到 sRGB）、透明度计算等场景需要辅助函数或构建期预计算；其三，海量 token 全量挂在 :root 会增加样式体积与解析开销，旧浏览器不支持；其四，token 被 JS 逻辑消费（如图表库取色）时 CSS 变量无法直接 import，需保留 JSON 或 TS 产物。工程结论：CSS Variables 适合"浏览器内运行时主题切换"场景，静态平台与高频计算场景应使用管线生成的编译产物，二者共用同一 token 源保证一致性。

本题考察"单一事实源（Single Source of Truth）"工程链路的理解。先答规范本身的建模能力（$type / $value / 别名引用），再答构建管线如何做多平台分发，最后针对 Web 端深入 CSS Variables 的能力边界，指出"运行时切换能力"与"静态消费需求"的分野。答题要有取舍判断：不是"哪个方案更好"，而是"哪个场景用哪个方案"。

• API 契约：props / events / slots 的类型化与语义稳定性
• SemVer 语义化版本在组件库中的严格执行
• Breaking Change 的弃用（deprecation）、迁移与发布治理

组件库的 API 就是对外契约，一旦发布便很难收回，因此契约设计必须前置。核心实践：所有 props / events / slots 全部 TypeScript 类型化并导出类型定义；props 命名遵循稳定语义（如 value / onChange 对齐原生约定），事件支持受控 / 非受控双模式；API 变更必须过 RFC 评审，记录"为什么这样设计"，并维护 changelog 与迁移指南。契约还包括 DOM 结构、className 注入方式（slot / part 机制）与样式覆盖协议，这些同样属于不可破坏的承诺。

版本化采用严格 SemVer：Major 允许破坏性变更，Minor 新增向后兼容特性，Patch 只修缺陷。Breaking Change 治理的关键是"预沟通、双版本、可迁移"：先在 Minor 版本中 deprecate 旧 API 并给出运行时警告与替换建议，给予至少一个大版本周期的迁移窗口；发布 Major 前公布升级计划（升级指南 + codemod 自动迁移脚本），统计消费方使用率，必要时提供兼容层过渡。同时用自动化手段守卫契约：API 快照测试、类型级测试（tsd）、消费方项目的 CI 冒烟验证，确保任何破坏性变更在合并前就被发现。

组件库 API 面向整个组织开放，错误设计的修复成本极高，因此答题重点是"契约前置 + 变更受控"。先讲契约如何被类型化与语义化固化，再讲 SemVer 的严格执行，最后落到 Breaking Change 的"弃用窗口 + 迁移工具 + 自动校验"完整治理闭环。能补充 RFC 评审与消费方 CI 冒烟是加分项，体现组织级工程视角。

• 全局 Token（原始值）与语义 Token 的职责划分
• 组件级 Token 的本地化覆盖策略
• 多主题实现：CSS Variables 覆盖、data-theme 作用域与 CSS @layer 治理

分层原则是"原始值不直接消费，组件只认语义"。全局层（原始值）存放品牌基元，如 --color-brand-500: #1677ff、--space-4: 16px，它们表达"值是什么"；语义层把用途固化，如 --color-bg-primary、--color-text-link，表达"这个值用于什么场景"，是组件与业务唯一可消费的层；组件层是语义 token 的本地化别名，如 --button-bg-primary 指向语义 token，允许单个组件在不影响全局的前提下定制。三层依赖方向固定：组件层 → 语义层 → 全局层，保证主题切换时只需替换底层取值，上层全部自动跟随。

多主题切换的主流机制是基于 CSS Variables 的级联覆盖：在 :root 定义默认主题，用 [data-theme="dark"]、[data-theme="brand"] 等选择器在根节点覆盖同名变量，切换只需改根元素属性，运行时零重构建。进阶做法：主题作用域收窄到组件子树时用局部 class 容器隔离；为防止第三方样式干扰与特异性战争，可配合 CSS @layer 划分优先级；原生端与 SSR 场景则回到管线生成的静态产物，与浏览器端运行时切换各司其职。所有方案的前提是组件只消费语义 token，否则任何覆盖都会被组件内联样式破坏。

本题把"分层建模"与"运行机制"串成一条线。先讲清三层 token 各管什么、依赖方向如何保证"底层换值、上层自动跟随"，再展开 Web 端主题切换的具体机制（data-theme + CSS Variables 覆盖、作用域隔离、@layer 治理）与原生端 / SSR 的静态产物方案。能点出"组件内联样式是主题切换的头号破坏者"是理解深度的体现。

• 原始值（Primitive）层：物理取值与刻度组织
• 语义值（Semantic）层：按用途抽象与别名引用
• 组件值（Component）层：组件本地化别名与引用关系追溯

原始值是物理层面的最小设计基元，例如 --blue-500: #1677ff、--spacing-4: 16px，它们只回答"是什么"、不表达用途，通常按色阶、字号梯度、间距刻度组织。语义值把用途语义化：--color-primary、--color-text-default、--spacing-section 分别表达"主色""默认文本色""区块间距"，它们通过别名引用原始值（$value 指向原始 token），是组件与业务代码中唯一可被消费的层。组件值是进一步本地化的别名，如 --button-primary-bg、--card-radius，绑定到具体组件上下文，允许组件在语义层基础上做局部定制而不污染全局。

三层转换的价值有三点：一是隔离变化——品牌换色只改原始值，语义值与组件值不用动；二是语义稳定——组件与业务依赖的是"用途"而非"数值"，换主题、换品牌时无需改代码；三是可治理——通过别名引用关系可以追溯"哪个组件用了哪个原始值"，审计与一致性检查都建立在引用图上。实践中用 Style Dictionary / Tokens Studio 维护这套层级，构建时解析别名生成各平台产物。

本题是分层模型的进阶版，核心是讲清"值 — 用途 — 组件上下文"三个抽象级别及别名引用机制。回答要突出"组件只消费语义值、原始值可自由替换"这一主线，并说明三层带来的隔离变化与可审计性收益。本题侧重分层本身的意义，而非多主题切换的具体实现机制。

• token JSON 的建模（name / type / value、别名引用）
• Style Dictionary 的 transform / transformGroup / format 管线
• 引用关系在输出端的两种处理：保留变量引用 vs 解析为字面值

Style Dictionary 的输入是结构化 token 文件（支持嵌套分组或 W3C 规范的 $type / $value 形式），核心管线分三步：transform（逐 token 转换，如把 px 转 rem、把 hex 转 Swift 的 UIColor、把 camelCase 转 Android 的 snake_case 资源名）、transformGroup（组合常用转换集，css、scss、ios-swift、android 各有预置组）、format（按平台输出文件，如 variables.css、tokens.scss、Colors.swift、colors.xml 或 Kotlin 常量）。输出由配置的 platforms 段声明，一份 JSON 一次构建即可产出全平台产物。

引用关系的保持有两种策略。其一保留引用：Web 端输出为 CSS 变量并用 var(--x) 相互引用、SCSS 输出变量引用，运行时仍是一张引用网，主题切换只换源头；其二解析引用：原生端（Swift / Android）与静态场景在构建期把别名解析为最终字面值（或保留命名常量），因为原生代码无法消费 CSS 变量。正确做法是在 transform 阶段先做引用解析（resolve），再按目标平台决定"输出变量引用"还是"输出解析后的值"，同时用 token 名保持跨平台命名映射，保证同一语义在各平台指向同一取值。

本题考察对"单一事实源 → 多平台产物"构建管线的理解。答题主线是"输入建模 — transform 转换 — format 输出"三段式，并重点展开引用关系的两种处理策略（Web 保留引用、原生解析字面值），体现对管线内部机制与平台差异的真实理解。能提到 transformGroup 与 platforms 配置说明对工具本身有实操认知。

• controlled / uncontrolled 双模式的价值：简单使用与受控需求
• 复合组件（Context + 子组件）的组合能力
• asChild 多态（Radix 模式）对"语义与样式分离"的支持与代价

controlled / uncontrolled 解决"状态归谁管"：uncontrolled 让组件内部管理状态、开箱即用；controlled 由调用方传 value / onChange 接管状态，便于外部校验、联动与受控渲染。成熟组件库同时支持两种模式（value + defaultValue），并在内部做"受控 / 非受控切换检测"给出警告，避免运行期状态归属漂移。复合组件（compound components）解决"单一组件 API 无法表达复杂结构"的问题：父组件通过 Context 提供状态与行为，子组件（如 Select.Trigger / Select.Option）只负责渲染与消费上下文，调用方自由组合结构、插入任意 DOM，同时保持状态同步。

asChild（Radix UI 模式）解决"语义与样式分离"：组件渲染语义与行为的宿主元素，但不写死标签，通过 cloneElement / Slot 机制把 props 转发给调用方传入的任意元素，从而把样式决定权交还给调用方的设计系统。取舍上：复合组件 + asChild 提供最大灵活性，但提升 API 复杂度、文档负担与测试成本；受控模式提升可组合性但增加使用门槛。工程建议是分层：底层（headless 层）提供 asChild + 受控 + 复合组件的能力，顶层（样式化层）封装默认样式与简单 props，兼顾灵活性与开箱即用。

本题考察组件 API 设计的演进思路。三个模式分别回答"状态归属、结构组合、语义宿主"三个问题，答题时先各自讲清解决的问题与机制（Context、cloneElement / Slot），再给出分层组合的工程结论，避免只罗列名词。能指出 headless + 样式化两层架构是本题的理想落点。

• Storybook 的 stories 即开发环境、测试基线与文档载体
• 视觉回归（Chromatic / Loki / Percy）的拦截价值
• Histoire 的 Vite 原生、零附加构建差异

Storybook 把"组件状态样例（stories）"作为一等公民：每个 story 是组件在特定 props / 上下文下的渲染实例，天然成为开发调试环境、交互文档与测试基线。工程价值体现在三处：其一，开发体验——组件在隔离环境中开发与验证（controls 调试面板、MDX 文档），无需启动整个业务应用；其二，质量——stories 可被视觉回归工具（Chromatic、Loki、Percy）截图对比，结合 Playwright 交互测试在 CI 中拦截样式与行为回归；其三，协作——stories 作为可交互文档让设计、产品、测试在同一演示上评审，配合 addon-a11y 做无障碍扫描，docs 插件自动生成 API 文档。

Histoire 是 Vite 原生、框架无关的替代方案，核心差异：不引入依赖注重的故事格式（用 .story.vue / .story.svelte 等文件约定），按需构建、加载速度更快，更贴合 Vite 生态（对 Vue 3 + Composition API 支持顺滑），无第三方云依赖时配合 Playwright 自建视觉回归。工程取舍：团队已有 React 生态与 Chromatic 工作流选 Storybook；Vite 化 Vue / Svelte 项目、追求轻量与构建速度选 Histoire。两者都遵循"stories 即资产"原则：story 数量与质量直接决定视觉回归覆盖率与文档完整度。

本题考察对组件开发基础设施的理解。先讲 stories 作为"开发环境、测试基线、文档载体"三位一体的价值，再讲视觉回归如何拦截回归，最后对比 Histoire 与 Storybook 在 Vite 生态下的差异，落到"按团队技术栈选型"的结论。能提到 addon-a11y 与 docs 自动生成体现对生态的熟悉度。

• 贡献流程：RFC → 评审 → 实现 → 发布的受控开放
• No-code 编辑的边界与审批机制
• 品牌一致性度量：token 引用率、组件使用率与设计走查

设计系统治理的本质是"开放贡献、受控发布"。贡献流程通常分两级：小改动（bug 修复、新 token）走轻量 PR + 代码评审；涉及 API 或设计语言变更的走 RFC——先写提案文档说明背景、方案与影响面，由设计系统委员会评审，通过后再进入设计与实现，保证每个改动都"知其所以然"。No-code 编辑（如 Token Studio、Figma 变量编辑、低代码平台的主题配置）降低非工程角色的参与门槛，但必须设置边界：允许修改"实例值"（品牌色、间距刻度），禁止直接改动"结构层"（token 层级、组件 API），并配套自动校验（对比度、命名规范）与人工审批。

品牌一致性度量从"设计侧"与"代码侧"双向进行。代码侧可量化：全仓库 token 引用率（硬编码色值 / 间距占比）、组件库组件使用率（裸标签使用数 vs 设计系统组件数）、跨页面视觉基线偏差（视觉回归差异数）；设计侧用设计走查（design review）抽样评估对齐度，配合 Figma 变量使用统计。度量结果进入仪表盘与准入门槛（如 CI 中硬编码色值超阈值即报警），让"一致性"从口号变为可追踪的工程指标，并反向驱动 token 语义层的完善。

本题考察设计系统作为"组织协作产品"的治理能力。答题结构：先讲贡献与 RFC 的分级流程，再讲 No-code 编辑的边界与审批，最后给出品牌一致性从代码侧（引用率、使用率）与设计侧（走查）双向量化的方案。核心观点是"可度量才可治理"，量化指标要与 CI 门槛绑定才有执行力。

• 组件库 a11y 责任：语义、键盘交互与焦点管理
• 自动化工具链：jest-axe / vitest-axe、Playwright + axe、视觉回归
• 自动化边界：语义恰当性与真实屏幕阅读器验证

组件库对 WCAG 的承诺应写进契约：每个组件必须自带正确的语义（role / aria）、完整键盘交互（Tab 顺序、焦点陷阱、Esc 关闭）与焦点管理（焦点归还、aria-activedescendant）。边界在于：组件库只能保证"组件自身的可访问性"，组合层面的问题（页面结构、阅读顺序、内容语言、对比度由 token 保证）属于应用责任；同时组件库应提供"无障碍友好"的默认值（如 Button 用原生 button、Modal 内置焦点管理），把复杂部分封装好，让业务侧默认合规。

a11y 自动化分层落地：第一层单元 / 渲染级——用 jest-axe（React）或 vitest-axe（Vue）在组件测试中断言渲染结果无 axe 违规；第二层端到端——Playwright 集成 axe-core 扫描真实交互路径（含键盘操作、焦点行为断言）；第三层视觉回归——截图对比防样式级退化影响可读性。自动化存在边界：axe 无法判断"语义是否恰当"（如用 div 冒充按钮但补全了 aria 属性）、无法替代真实屏幕阅读器的朗读体验与手势操作。因此成熟团队保留定期人工审计（含 NVDA / VoiceOver 实测）与 WCAG 逐条 checklist 评审，并把组件库 a11y 合规纳入发布门槛。

本题考察"自动化能做什么、不能做什么"的认知。先明确组件库的 a11y 契约与责任边界（组件 vs 应用），再给出 jest-axe / Playwright + axe / 视觉回归三层自动化，最后诚实指出语义恰当性与真实读屏验证无法自动化、需人工兜底，体现工程判断的成熟度。回答"边界"是本题的得分关键。

• Design → Code：token 生成管线与组件实现校验
• Code → Design：规范回写与设计变量同步
• 文档同源生成与视觉回归作为闭环质量闸门

双向同步的起点是"单一事实源"。正向（Design → Code）：设计侧在 Figma 变量 / Tokens Studio 中维护 token 与组件规范，提交后经构建管线（Style Dictionary）自动生成各平台 token 产物，组件库按规范实现，CI 中视觉回归（Chromatic / Playwright 截图对比）校验实现与设计稿一致，任何偏差立即暴露。反向（Code → Design）：实现过程中发现规范缺口或设计稿与 token 不一致时，通过 issue / RFC 回写规范，或借助插件（Figma Tokens 推送、Figma API 批量更新变量）把代码侧确认的取值同步回设计文件，保证设计稿不"漂移"。

闭环的关键是三个闸门：Token 产物 diff（token 变更必须经过评审，且自动对比各平台产物是否同步更新）、组件文档（由 stories / API 声明自动生成，保证文档与实现同源，杜绝手写文档过期）、视觉回归（每个组件变更必须过基线对比）。三者任一失败则发布拦截。这样设计系统从"一次性交付物"变成"持续进化的活系统"，任何一端的变更都会被另一端感知并验证。

本题考察"设计系统是协作闭环而非静态交付"的认知。答题按正向链路、反向链路、质量闸门三段组织：token 生成管线和视觉回归保证 Design → Code 一致，规范回写与变量同步保证 Code → Design 一致，文档同源生成与产物 diff 保证闭环不腐化。能点出"手写文档必然过期，文档必须从代码与 token 自动生成"是本题的亮点。

• SemVer 在组件库中的严格执行
• 破坏性变更的识别、宣告与"先弃用后移除"
• 消费方升级策略：codemod、兼容层与质量闸门

组件库必须严格执行语义化版本（SemVer）：Major 对应破坏性变更（props 删除、默认行为改变、样式基线变更），Minor 新增向后兼容能力，Patch 只修缺陷。关键实践是"先 deprecate 后移除"：破坏性变更至少提前一个 Minor 版本在代码中标记 @deprecated 并在控制台 / 文档发出警告，让消费方有迁移窗口；发布 Major 时提供完整的升级指南与 changelog，把每个破坏点、原因与替换写法一一列出。

消费方升级策略：其一自动化迁移——为常见破坏性变更提供 codemod（jscodeshift 规则）自动改写调用代码，把升级成本从"人工排查"降为"跑一遍脚本 + 人工复核"；其二渐进升级——先升级到"兼容版"（同时保留新旧 API）验证存量代码，再分批次切换到新 API；其三质量闸门——升级前用 API 快照与类型测试对比差异，升级后跑视觉回归与 a11y 扫描，防止"升级即回归"。组织层面建立"组件库变更委员会"统一节奏，重大变更随版本发布公告并统计消费方升级率，确保版本演进可预期、可迁移、可验证。

本题考察组件库"如何安全地演进"的治理能力。答题主线：SemVer 的定义与严格性 → 破坏性变更的"先弃用后移除"流程 → 消费方升级的 codemod / 兼容层 / 质量闸门三板斧。核心观点是"变更不可怕，可怕的是不可预期与不可迁移"，能提到升级率统计说明具备组织级视角。

• 迁移成本构成：存量替换、行为差异、样式与 Token 迁移
• 渐进迁移与双系统共存策略
• 回退保障：小步提交、特性开关与监控

跨设计系统迁移成本主要来自三块：存量代码替换（全仓引用 Material 组件与样式的改造成本，规模与业务耦合度成正比）、行为差异适配（Material 的交互细节、焦点管理、弹层定位等与自研组件存在细微差别，需要逐点确认）、样式与 Token 迁移（Material 主题机制换成自研 token 体系，涉及全局样式基线调整，易出现视觉回归）。此外还有隐性成本：文档与测试基线重建、团队学习成本、第三方库对 Material 样式的依赖。

降低风险的核心是渐进迁移而非"大爆炸"：让两套系统在过渡期共存——自研组件通过独立前缀与样式隔离（CSS 命名空间 / Shadow DOM）与 Material 并行部署，按页面或模块灰度替换，组件级迁移完成后立即删除对应 Material 引用并跑视觉回归。回退策略：每个页面级迁移都做成可独立回滚的提交（小步提交、特性开关控制渲染路径），配合线上监控（页面错误率、交互埋点、视觉基线 diff）决定继续或回退；若遇阻塞问题，开关一键回退到 Material 版本，迁移数据（进度、待办清单、踩坑记录）全部沉淀，保证随时可暂停、可恢复、可复盘。

迁移类题目的答题框架是"成本识别 + 渐进策略 + 回退保障"。先分类算清成本，再讲双系统共存与灰度替换，最后落在特性开关与监控回退机制上。核心观点是"迁移是一次工程迭代而非一次性事件"，能提到样式隔离（命名空间 / Shadow DOM）与迁移台账说明实操经验丰富。

• LTR / RTL 双向布局：CSS 逻辑属性与镜像机制
• 中日韩文本：字体栈、行高与断行策略
• Token 层与自动化测试对国际化的保障

设计系统对国际化的弹性要从布局与排版两个维度内建。布局维度：采用 CSS 逻辑属性（margin-inline-start、inset-inline、border-inline 等）替代物理方向属性，配合 text-align: start 与 flex / grid 的 inline 轴布局，使 RTL 语言（阿拉伯语、希伯来语）自动镜像而无需逐组件改造；图标、箭头、进度方向等需语义化设计（方向由 dir 属性驱动而非写死），弹层定位（popover / tooltip 的 placement）也要支持 rtl 自动翻转。排版维度：中日韩文本的字符宽度、行高、字间距与西文差异显著，token 层需提供 CJK 专用的行高刻度（如西文 1.5、CJK 1.6~1.8）与字体栈回退（包含系统 CJK 字体族），字号梯度需验证中日韩的过宽截断问题，同时为长词断行（overflow-wrap / word-break）与竖排（writing-mode）预留能力。

实现机制上，所有方向相关 token 尽量用语义化命名（--space-inline-start 而非 --margin-left），通过 CSS 逻辑属性消费；主题中为 RTL 提供 overrides 层（如 :dir(rtl) 选择器修正少数物理属性），并用自动化测试（Playwright 以 dir=rtl 渲染全组件走查截图）与字数密度测试守护双向布局。这样设计系统从第一天就具备多语言弹性，避免"国际化补丁式改造"。

本题考察设计系统的"国际化原生"意识。答题按"布局（逻辑属性与 RTL 镜像）— 排版（CJK 字体与行高）— 机制（语义 token + 自动化验证）"三层组织。核心观点是"从 token 与逻辑属性层面预防，而非事后打补丁"，能提到 :dir() 选择器与自动化 RTL 走查是加分项。

• AI 生成 UI 的一致性问题与模型自由度
• Tokens 作为约束空间：收敛合法取值与结构
• 三层约束落地：prompt 注入、静态校验、视觉回归

AI 生成 UI 的能力越强，一致性的失控风险越大：大模型会自由发挥出五花八门的色值、间距与组件结构，生成结果与品牌基线脱节。设计系统在此刻的角色从"设计师的规范文档"变为"生成结果的约束空间"：Tokens 把合法的视觉取值收敛为有限集合，组件库把合法的结构收敛为有限模式，模型只能在集合内组合，从而在源头限制自由度的同时保留创造性。

工程落地有三层约束：第一层提示词 / 上下文约束——把 token 清单、组件 API 与示例代码注入 prompt（或 RAG 检索），要求生成代码"只使用语义 token 与白名单组件"；第二层静态校验——用 eslint 规则（如禁止十六进制色值、禁止裸 div 用于按钮）与 design-token 引用扫描在 CI 中检查生成代码，硬编码即失败；第三层运行期回归——视觉回归与 token 覆盖率统计（硬编码占比趋零）验证最终效果。Tokens 语义化程度决定约束质量：语义 token（--color-bg-primary）比原始值（#1677ff）更适合作为模型的约束语言，因为模型更容易学会"用途"而非记住数值。

本题考察 AI 时代设计系统的定位转变：从"规范文档"到"约束空间"。答题主线是"问题（AI 自由度导致不一致）→ 解法（Tokens + 组件收敛合法集合）→ 落地（prompt 约束、静态扫描、视觉回归三层）"，并点出语义 token 比原始值更适合做约束语言。能提到"约束的同时保留创造性"体现辩证思考。

• CSS Variables 运行时覆盖与 data-theme 机制
• 定制粒度：全局品牌 vs 局部组件子树
• 性能、FOUC 与平台边界等注意事项

运行时切换的核心机制是"同名变量、按作用域覆盖"：默认主题定义在 :root，切换主题时在根元素设置 data-theme="dark" / "brand-a" 属性，CSS 用 [data-theme="dark"] 选择器覆盖同名语义 token（如 --color-bg-primary），组件与业务代码不感知变化，切换只改一个属性，浏览器即时重绘。更精细的品牌定制可以把作用域收到局部：在某个容器上挂 class 或 data-* 属性即可实现"页面某区域用品牌 A、其余用品牌 B"，token 级联天然支持这种局部覆盖，无需为每个组件写主题样式。

注意事项有四条：其一，变量覆盖存在级联与优先级问题——组件内部若写了物理属性或内联样式会破坏主题，因此组件必须只消费语义 token 且不内联硬编码；其二，海量 token 全量定义会增大样式体积与解析开销，可按主题按需注入（构建期拆分主题 CSS，运行时按需加载）；其三，主题切换瞬间的闪烁（FOUC）——在脚本执行前通过内联脚本先设置 data-theme 或预加载主题 CSS；其四，原生端与 SSR 不消费 CSS 变量，运行时切换方案只适用于浏览器端，服务端渲染与原生平台需回到构建期多产物（按主题生成静态资源）。

本题考察主题切换的实现细节。答题核心是"作用域覆盖"思想：根级切换与局部定制共享同一机制；注意事项要覆盖优先级陷阱、性能、FOUC 与平台边界，展示从"能切"到"切得好"的工程纵深。能提到按需加载主题 CSS 与内联脚本防闪烁说明对生产环境问题有认知。

• API 稳定性承诺：契约意识与 API 快照守卫
• 兼容策略：deprecation、兼容层与 alias 桥接
• 迁移工具链：codemod、升级指南与类型测试

API 稳定性首先靠"契约意识"：props、事件、插槽、样式协议一经发布即视为承诺，变更必须走评审。稳定性的落地工具是严格 SemVer 与 API 快照：用类型定义（.d.ts）与 API 提取工具（如 api-extractor）生成 API 基线，任何公开 API 的形状变化（新增 / 删除 / 改签名）在 CI 中 diff 出来，由人判断属于 Minor 还是 Major，杜绝"悄悄破坏"。

API 演进与迁移按三步组织：第一步 deprecate——在旧版本中标记 @deprecated 并输出运行时警告（dev 环境），文档中声明替代 API 与迁移说明；第二步兼容过渡——提供兼容层（新旧 API 并存、alias props 桥接）、codemod 自动迁移脚本（jscodeshift 批量改写调用方代码）与升级指南，让消费方分阶段切换；第三步移除——在约定的 Major 版本中删除旧 API，并保证升级文档覆盖每个破坏点。整个过程中类型测试（tsd）与消费方 CI 冒烟保障迁移后行为一致。对团队而言，还可统计 API 使用率，对使用量低的 API 优先激进清理、对核心 API 提供长期稳定承诺。

本题聚焦"API 本身"的稳定性与迁移动作。答题主线是"契约冻结 + 快照守卫 → 弃用 / 兼容层 / codemod 三段迁移 → 数据驱动的清理决策"，把"稳定"落实为可执行的工程机制而非口号。能提到 api-extractor 与使用率统计说明对工具链与治理有实操认知。