设计系统、组件库与 AI 协同

• AI 生成设计稿到代码的链路环节（设计稿 → 组件识别 → 代码生成 → 校验）
• 准确度瓶颈：布局识别、组件映射、视觉还原
• 准确度提升：设计系统约束、映射增强、校验闭环

AI 设计到代码的工程链路通常为：设计意图 → 设计稿 / 生成稿 → 布局与组件识别（AI 把视觉稿解析为组件树与布局结构）→ 代码生成（映射到设计系统组件与 token）→ 校验与人工评审 → 进入常规开发流程。以 v0 为例，用户用自然语言或设计稿输入，模型生成 React / JSX + Tailwind 代码；Galileo AI、Figma AI 更侧重设计稿侧的生成与编辑。链路的"准确性"体现在三个层面：布局还原度（间距、对齐、响应式）、组件映射正确性（视觉元素是否映射到正确的语义组件）、视觉还原度（色彩、字体、圆角是否精确命中 token）。

准确度的瓶颈主要在：复杂布局的识别（栅格、弹性布局推断）、设计稿与代码的语义鸿沟（视觉上像按钮的可能是链接或 div）、以及非设计系统元素（AI 自由发挥的组件）。提升准确度的工程手段：一是约束——提示词与上下文注入设计系统规范（组件清单、token 清单、代码示例），限定生成空间；二是映射增强——提供设计稿与组件的映射表或训练数据，让模型优先复用既有组件；三是校验闭环——生成代码过 lint / 设计规则扫描（硬编码检查、组件白名单）、视觉回归与人工评审，把"准确度"从主观感受变为可量化指标（还原度得分、组件命中率），迭代优化。准确度不追求 100%：合理的定位是"生成初稿 → 人机协作精修"，把 AI 放在"快速产出初稿"的位置，由设计系统与人工评审兜底质量。

本题考察对 AI 生成 UI 工程链路的整体认知。答题按"链路环节 → 准确度三维度（布局 / 映射 / 视觉）→ 瓶颈 → 提升手段（约束、映射、校验闭环）"组织，最后给出"初稿定位 + 人机协作"的现实预期。能提到可量化指标（还原度得分、组件命中率）说明理解"准确度"如何被工程化度量。

• 设计系统产物的 SemVer 版本化（tokens、组件、文档）
• Breaking Change 的定义、声明与节奏
• 消费方协作：变更公告、迁移工具、升级节奏对齐

设计系统作为"基础设施产物"，版本化要覆盖 tokens、组件库、文档与工具链多个产物（可统一版本或独立版本 + 兼容矩阵）。SemVer 严格落地：Major 破坏性变更（token 语义改变、组件 API 删除、样式基线变化）、Minor 新增能力（新 token、新组件、新特性）、Patch 缺陷修复（不改语义与 API）。对 tokens 而言，"值变了但语义没变"（品牌换色）属 Minor 还是 Major 需明确定义——通常语义层签名不变、底层取值变化算 Minor，但若影响面是"视觉大改"应走 Major 或发布公告，由平台方与消费方约定规则。

与下游消费方的协作是版本化成功的另一半：其一，提前公告——Breaking Change 至少提前一个大版本周期通过 changelog、RFC、社区公告告知，标注影响的 token / 组件与迁移路径；其二，迁移工具——提供 codemod、token 映射表（旧 token → 新 token 自动替换）、升级指南与视觉对比（迁移前后截图），降低升级成本；其三，节奏对齐——与业务大版本周期协同发布（如随业务发版窗口），统计消费方升级率，必要时提供"兼容版本"过渡（新旧 token 并存一段时期）。工程上，版本发布前用"消费方代表项目"做 CI 冒烟（升级后构建、视觉回归、a11y 扫描），确保升级即验证。核心原则："变更可预期、迁移有工具、升级有验证"，让设计系统演进不成为消费方的噩梦。

本题考察"设计系统即产品"的版本运营思维。答题按"产物与 SemVer 定义 → Breaking Change 规则 → 消费方协作（公告 / 工具 / 节奏）→ 发布验证"展开。能讲到 token 值变更与语义变更的版本归属争议，说明理解 token 版本化不同于普通库的特殊性。

• 组件白名单与禁止裸标签的 eslint 规则实现
• 一致性保障：从"生成随机"到"约束合规"
• 规则治理：强制与自动修复、例外通道

AI 生成的代码天然发散：同一需求可能生成出原生 button、div + click、任意类名或陌生组件，视觉与行为一致性失控。工程解法是把设计系统约束"编码进 lint 规则"，让 CI 强制合规。典型规则：组件白名单（no-restricted-imports 限制只能从设计系统包导入 UI 组件）、禁止裸标签（如 button / a / input 必须替换为设计系统 Button / Link / Input，可通过 jsx-a11y 自定义规则或自研规则实现）、禁用硬编码样式值（色值 / 间距必须使用 token 变量）、禁止任意类名（样式必须走设计系统提供的 className 协议）。

工程价值有三层：一是把一致性从"评审靠人眼"变为"机器强制"——AI 生成的代码与人类代码走同一道闸门，不合规直接 CI 失败，从源头阻断不一致扩散；二是可迁移——规则是团队沉淀的"一致性知识库"，AI 模型更新、新人入职都不影响约束效力；三是可度量——违规数量、合规率成为设计系统落地程度的量化指标。落地要点：规则分级（error 级强校验 + warn 级提示 + 建议级），自动修复能力（fixable 规则自动替换裸标签为组件），例外通道（显式注释豁免 + 审批流，避免规则"一刀切"卡死业务）；配合 AI 提示词在生成阶段就注入规范（prompt 声明"必须使用设计系统组件"），形成"生成端约束 + 校验端强制"双保险。

本题考察"用工程手段驯化 AI 生成"的思路。答题主线："问题（AI 发散）→ 解法（lint 编码设计系统约束）→ 价值（机器强制 / 知识沉淀 / 可度量）→ 落地（分级、自动修复、例外通道、提示词配合）"。核心句是"把一致性从人的自觉变成系统的强制"，能提到 no-restricted-imports 与 fixable 规则说明对 eslint 生态熟悉。

• Token 反查：从硬编码值 / 设计稿反查对应 token
• 组件使用分析：使用率统计与模式识别
• 不一致性发现：偏差扫描与 AI 的置信度边界

AI 在三个场景有实际价值：其一，Token 反查——从代码中的硬编码值（#1677ff、16px）或设计稿取色反查最可能的语义 token（依据值与语义 token 的映射表、历史替换记录），输出"候选 token + 置信度"，加速存量代码的 token 化改造；其二，组件使用分析——扫描代码库统计设计系统组件使用率、裸标签占比、API 使用模式（如 Button 的 danger 属性滥用率），输出结构化报告，辅助组件库演进决策（哪些 API 该废弃、哪些组件该新增）；其三，不一致性发现——对比设计与代码、页面与页面之间的偏差（视觉回归差异聚类、token 漂移检测、同类组件不同实现的风格差异），定位不一致点并归因（哪次提交、哪个组件、哪个 token）。

边界要清醒：AI 的产出是"候选与建议"，置信度再高也需要人工复核，原因是语义判断的不可靠性——同一个 #1677ff 在不同上下文可能对应不同 token，AI 无法真正理解业务语义；同时，分析结论依赖输入质量（代码库覆盖率、设计稿与代码的对应关系），误报与漏报并存。工程上把 AI 定位为"扫描与提效器"：批量初筛、生成候选、人机复核确认，自动化替换必须加规则约束与评审；不一致性发现则以确定性工具（静态扫描、视觉回归）为主、AI 聚类与归因为辅，避免把不可解释的模型输出当作事实依据。

本题考察"AI 在工程分析中的定位"。答题结构："三个应用场景（反查 / 分析 / 发现）各讲价值 → 边界（语义不可靠、置信度需复核）→ 工程定位（AI 初筛 + 人工确认，确定性工具为主）"。核心观点是"AI 提升效率，确定性保障正确"，能提到"候选 + 置信度"的输出范式说明理解 AI 应用的正确姿势。

• 设计系统资产作为"约束知识"注入 prompt 的价值
• 知识库嵌入方式：静态注入、RAG 检索、函数调用
• 效果验证与维护成本

设计系统资产是 LLM 生成代码时的"约束知识"：没有规范注入时，模型凭训练记忆自由发挥；注入 token 清单、组件 API、编码规范与示例后，模型被限定在设计系统表达空间内，一致性、可用性与维护性显著提升。工程价值体现在：生成代码可直接进入既有质量链路（lint / 视觉回归），返工成本低；团队的设计决策（为什么用这个 token、组件边界在哪）作为知识被模型"引用"，形成组织知识的复用。

嵌入方式按成熟度分三级：第一级，prompt 静态注入——把核心规范（token 清单、组件白名单、示例代码）作为 system prompt 的一部分，适合规范精简的场景，成本低但有 token 长度上限；第二级，RAG 检索增强——把设计系统文档、组件 API、升级指南、代码示例切片向量化入库，生成时按用户需求检索相关片段注入上下文，解决"知识量大、单次注入装不下"的问题，需维护索引与文档更新；第三级，结构化工具 / 函数调用——把组件注册表、token 查询做成 LLM 可调用的工具（function calling），模型按需查询组件 API 与 token 值，准确性最高，适合平台化产品。配套实践：示例优先（few-shot 用真实设计系统代码）、注入内容版本化（与设计系统版本同步）、效果度量（生成代码的 lint 合规率、组件命中率、人工评审通过率），并把"文档即知识源"作为设计系统文档化的新要求（结构化、可检索、含代码示例）。

本题考察"知识资产 × LLM"的工程结合。答题按"价值（约束生成空间）→ 三种嵌入方式（静态注入 / RAG / 函数调用）的取舍 → 配套实践（示例、版本化、度量）"组织。核心观点是"设计系统资产升级为 LLM 时代的模型知识源"，能提到 function calling 说明对最新工程模式有了解。

• 组件级单元测试（渲染、交互、状态）与 a11y 测试
• 视觉回归工具（Chromatic / Loki / Percy）的 CI 集成机制
• 组件解耦的价值：独立验证、回归拦截、安全升级

组件库的测试体系分两层。单元 / 交互层：用组件测试框架（React Testing Library / Vitest + Vue Test Utils）验证渲染结果、props 变化、事件触发与状态流转，配合 jest-axe 做 a11y 断言；视觉层：用 Chromatic、Loki、Percy 等工具在 CI 中对每个 story 截图并与基线对比，任何视觉偏差（哪怕是 1px 的间距变化）都会产生 diff，需要人工确认是"预期变更"还是"回归"——确认后更新基线。

CI 集成链路：提交 → 构建 → 单元测试与类型检查 → 视觉回归（渲染全部 stories 截图对比）→ 报告与门禁（diff 需评审通过才可合并）。关键实践：视觉测试与 story 绑定（story 即测试用例，组件覆盖度由 story 数量决定）；基线管理（基线随版本演进，需评审后更新）；快照优化（并行渲染、浏览器矩阵按需）。组件解耦的价值是这套体系的前提与结果：组件库与业务应用独立开发、独立版本、独立 CI，组件质量在库内闭环——业务侧引用的是"经过验证的组件"，无需重复测试；组件变更的回归影响被视觉回归及时拦截在库内，业务侧通过版本升级获得"已验证"的变更；配合语义化版本，业务侧可以放心升级（Patch / Minor 风险受控），形成"库内严测、库外轻测"的分工。

本题考察组件质量基建的完整链路。答题按"两层测试（单元 / 视觉）→ CI 门禁流程 → 解耦价值（独立验证、回归拦截、安全升级）"组织。核心逻辑是"解耦让测试可以在源头闭环，测试又让解耦变得安全"，能提到"库内严测、库外轻测"的分工说明理解了组件库与业务的分层关系。

• W3C Design Tokens 规范的结构与版本演进
• Schema 版本管理与迁移（新增、删除、重命名、值变更）
• 跨平台同步：单一事实源、产物回归、语义一致性

W3C Design Tokens 规范用 JSON 描述 token：token 对象含 $value、$type（color、dimension、fontFamily、fontWeight、duration 等）、$description 注释，支持 $extensions 扩展与别名引用（$value 为字符串指向其他 token），文件按组组织成层级结构。Schema 版本管理要区分两层：规范版本（W3C 规范本身演进，如草案阶段的结构调整）与组织自身 token 集的版本（组织的数据演进）。工程上维护"token schema 版本号"，变更分类管理：新增 token（非破坏，缺省值兜底）、重命名（走别名映射，旧名保留为 deprecated 别名）、值变更（语义不变则 Minor，视觉大改需评审）、删除（先 deprecate 再移除）。

跨平台同步的保障核心是"单一事实源 + 生成管线 + 回归验证"：token JSON 唯一维护，Style Dictionary 等管线生成各平台产物（Web 的 CSS / SCSS、iOS 的 Swift 常量、Android 的 XML / Kotlin），任何平台产物都不可手改（改则被校验拦截）；同步验证要覆盖"语义一致性与数值一致性"——同一语义 token 在各平台产物中的最终值必须一致（管线测试断言），新增 token 必须同步生成全平台产物（缺失即 CI 失败）；跨平台使用场景（如 Web 与原生混编）要校验命名映射（token 名到各平台命名规范的转换）。版本发布时，各平台产物与 token 版本对齐发布，升级文档注明"各平台如何升级到新 token 版本"。核心原则："一个源头、全端生成、机器验证、无手改"，杜绝"Web 改了 iOS 忘改"的漂移。

本题考察"规范理解 + 平台工程"的组合。答题按"W3C 结构与版本分层 → 变更分类治理 → 单一事实源 + 管线 + 回归验证"组织。重点落在"同步不是靠流程自觉，而是靠机器校验"的工程主张，能提到"语义一致性与数值一致性"双验证说明理解到位。

• Storybook / Histoire 在 Vue 3 + Vite 下的集成差异
• Composition API 组件 story 的写法（setup 语法、args）
• 文档版本化：文档与组件版本绑定、多版本预览

在 Vue 3 + Vite 下，Histoire 与 Storybook 都能工作但取向不同：Histoire 是 Vite 原生、零附加构建的轻量方案，用 .story.vue 单文件约定与 setup 语法（defineStory 定义 args / variants），对 Composition API 项目构建速度与体积有优势；Storybook 功能更全（addon 生态：controls、a11y、interactions、docs），Vue3 支持完善，但依赖自己的构建层，集成复杂度略高。协作流上二者一致：组件开发 → 写 story / variant（覆盖 props 组合与状态）→ 本地预览调试 → CI 中跑视觉回归与交互测试 → 生成文档站点。工程上可以"环境分离"：开发用 Histoire 快速迭代（轻量），发布用 Storybook 出全量文档与 Chromatic 回归，或全量采用其一保持单一工具链。

文档版本化解决"文档跟随组件版本"的问题：文档站点按组件库版本构建（每个 release 发布对应版本文档），URL 带版本号（/docs/v2.3.0/button），支持多版本切换预览，且文档内容从 stories / API 声明自动生成（同源保证不过期）；关键实践：组件库发布流程与文档构建绑定（发布即构建对应版本文档）、changelog 与迁移指南随版本归档、老版本文档保留可访问（消费方升级时的依据）。版本化文档与语义化版本配合，消费方可以在"升级前查新版本 API、升级时看迁移指南、出问题时查旧版本文档"，形成完整的版本协作闭环。

本题考察"工具链选型 + 文档治理"的组合。答题先对比 Histoire / Storybook 在 Vite + Composition API 下的取舍与协作流，再讲文档版本化机制（按版本构建、同源生成、多版本切换）。能提到"环境分离"与 URL 带版本号说明对文档运营有实操认知。

• 各库的定位与生态差异（设计语言、框架支持、企业级能力）
• 可定制性对比（token 体系、主题机制、组件覆盖）
• 选型方法论：匹配度、风险与迁移成本评估

头部组件库的差异主要体现在设计语言、技术栈与定制能力上：Ant Design 是蚂蚁企业级中后台的事实标准，设计规范完整、组件覆盖广、国际化与无障碍投入深、Vue / React 双生态，但定制主题需掌握其 token 体系；Material UI（MUI）基于 Material Design，自带设计哲学与组件完备性，主题机制（ThemeProvider + sx）灵活，在追求"开箱即用的设计感"的场景有优势；Arco（字节）与 TDesign（腾讯）都是企业级多端方案，设计 token 体系现代（Arco 的 Design Token 覆盖 CSS 变量与样式生成，TDesign 有跨框架版本），对中文企业场景适配好。差异集中在：默认设计语言的适配度、主题定制深度（token 粒度）、性能与体积、无障碍成熟度、社区与文档、以及是否支持多框架（Vue2 / Vue3 / React）。

选型方法论不是"比功能多少"，而是评估"匹配度 × 风险"：第一步匹配度——设计语言与品牌基调是否契合（换设计语言的改造成本最高）、技术栈与框架版本匹配、业务形态（中后台 / 移动端 / 营销页）是否在库的覆盖范围、定制需求（品牌换肤、暗色、token 粒度）能否满足；第二步风险——库的维护活跃度与社区健康度、升级频率与破坏性变更记录、对旧框架（Vue2）的支持周期、体积与性能基线；第三步成本——接入成本（国际化、无障碍、主题）、长期维护成本（自研定制 vs 跟随上游升级的权衡）、退出成本（vendor 化）。工程上可建立"组件需求矩阵 × 候选库能力矩阵"打分，并做 POC（关键组件实做 + 主题定制实测 + 性能压测），用数据而非直觉决策。

本题考察"选型方法论"而非"背书"能力。答题先客观对比各库定位差异（设计语言 / 生态 / 定制性），再给"匹配度 × 风险 × 成本"的选型框架与 POC 验证方法。能提到"退出成本"与 vendor 化说明考虑到了长期风险，这是资深工程师的视角。

• 链路环节：设计稿解析 → 组件识别 → 代码生成 → 组装校验
• 关键问题：识别准确度、设计系统映射、生成代码质量
• 人机协作与质量闸门

从设计稿生成组件的链路一般分五段：其一，设计稿解析——读取 Figma / 设计稿图层结构（图层树、样式属性、布局约束），去噪归一（分组、命名、冗余图层清理）；其二，组件识别——把视觉元素分类（按钮 / 输入框 / 卡片），识别布局结构（栅格、flex 关系、间距规律），并尽可能映射到设计系统既有组件；其三，代码生成——生成组件代码（props 化、token 引用、状态与事件占位），可借助 LLM 或规则模板；其四，组装与校验——把生成代码放入项目运行，过 lint、类型检查、视觉对比（生成稿与设计稿截图对比）；其五，人工评审与入库——确认后纳入组件库或页面代码。

各环节关键工程问题：解析层的图层噪声与命名混乱（需清理规范与启发式规则）；识别层的"语义鸿沟"——视觉上相似的组件可能语义不同（div 模拟的按钮 vs 真按钮），需要组件映射表与人工确认；生成层的设计系统一致性（硬编码色值、裸标签、props 命名随意）需 lint 与 token 扫描强制；校验层的"还原度量化"（像素级 diff、布局对齐误差）需要可解释的指标。链路成熟度决定自动化程度：初期"识别辅助 + 人工生成"，中期"自动生成 + 强校验 + 人工确认"，成熟期"全自动生成 + 异常人审"。始终保留"人机协作"的本质：AI 负责速度与批量，人负责语义判断与质量把关，任何一步的确定性校验（lint、视觉回归、类型）都是质量闸门。

本题考察"设计到代码"链路的工程组织。答题按五段链路展开并逐段点出关键问题（噪声清理、语义鸿沟、一致性强制、还原度量化），最后落到"人机协作 + 确定性校验闸门"的成熟度演进。能画出"自动化程度随链路成熟度递进"的路径说明有全局规划意识。

• 可维护性风险：还原度不足、API 设计随意、结构不一致
• API 漂移：生成代码与设计系统契约不一致
• 治理：生成规范、确定性校验、人工评审与版本管理

AI 生成组件代码的可维护性风险有三：还原度问题（间距 / 颜色 / 响应式细节与设计稿偏差，需要返工打磨）、API 漂移（生成代码的 props / 事件命名与设计系统契约不一致，或与既有组件 API 冲突，导致调用方混乱）、结构不一致（生成的组件内部结构、样式组织、注释风格各异，长期维护困难）。核心矛盾是"AI 擅长快速产出、不擅长维护长期契约"。

治理手段分三层：生成端约束——提供生成规范（组件 API 风格指南、token 使用规则、目录结构模板）并作为 prompt 注入，生成后强制过 lint（命名规范、禁止硬编码、组件白名单）与类型检查，把"漂移"拦截在生成阶段；校验端量化——视觉回归对比设计稿（还原度指标）、API 快照对比契约（生成的 props 与既有 API 基线 diff），自动化暴露偏差；维护端治理——生成的组件按统一评审流程入库（设计评审 + 代码评审 + 测试补充），纳入组件库版本管理（可追溯、可回滚），后续迭代遵循 SemVer，AI 生成只是"初稿"，正式契约由人工评审确立。实践要点是"AI 产出初稿、工具强制合规、评审确立契约"，把 AI 的可维护性风险转化为"人机分工"的流程问题：模型负责写出来，规则负责查出来，人负责定下来。

本题考察对"AI 产物生命周期"的认知。答题按"三类风险（还原度 / API 漂移 / 结构不一致）→ 三层治理（生成约束 / 校验量化 / 评审入库）"展开。核心观点是"可维护性不是模型的属性，而是流程与工具赋予的属性"，能提到 API 快照对比说明对契约守卫机制熟悉。

• AI 迁移转换的能力边界：组件映射、token 替换、API 改写
• 转换风险：语义误解、边界情况、风格漂移
• 人机分工：AI 批量初转、工具校验、人工抽审与确认

跨设计系统迁移的工作量集中在三块：组件替换（Material 组件 → 自研组件）、样式转换（Material 主题 → 自研 token）、行为适配（交互细节对齐）。AI 的价值在"批量初转"：基于映射表（组件 / API / token 的对应关系）对存量代码做自动改写——替换组件标签与 import、把硬编码样式改写为 token 引用、调整 props 与事件签名，同时识别无法自动处理的边界（结构差异大的组件、自定义样式、复杂行为）并打标记。

但 AI 转换有明确风险：映射错误（组件不完全等价，如 MUI 的 Select 与自研 Select 的交互细节不同）、语义误解（代码意图理解错误导致逻辑变化）、风格漂移（转换后代码风格不一致）、以及"看起来对了但行为错了"的隐性错误。因此人机分工的原则是"AI 负责量，人负责质"：AI 完成批量初转与差异清单；确定性工具负责机械校验（编译通过、类型检查、lint、视觉回归、token 扫描）；人工负责语义级评审——对差异清单逐项确认（尤其 AI 标记的边界案例）、抽查同构转换的正确性、验收行为差异（交互走查、a11y 验证）。流程上把迁移拆成小批次（按模块 / 页面），每批"AI 转换 → 工具校验 → 人工确认 → 提交回滚点"，避免一次性大迁移的风险。结论：AI 把迁移成本从"全人工重写"降为"人工评审差异"，核心工作从写代码变成审差异。

本题考察"AI 在重构场景的合理分工"。答题按"AI 能力（批量初转 + 映射表）→ 风险（语义误解 / 隐性错误）→ 分工（AI 初转 + 工具校验 + 人工语义评审 + 小批次回滚）"组织。核心观点是"迁移的瓶颈从产出代码变成验证正确性，AI 加速前者、人守住后者"。

• Tokens Studio 的 token 管理与导出（本地 / 远程同步、多主题）
• Figma 变量与插件生态的联动方式
• 取舍：同步方向、冲突处理、版本管理与自动化成本

Figma Tokens Studio 是当前 design → code 联动的主力工具：设计侧在 Figma 中维护 token（颜色、字体、间距等，支持分组、主题、别名引用与多环境），通过插件可一键导出为 W3C Design Tokens JSON、Style Dictionary 配置或 CSS 变量，并支持与 Git 仓库双向同步（token 变更以 JSON 提交入库，构建管线消费后生成各平台产物）；新版还支持 Figma 原生 Variables 的导入导出，兼容两种生态。Figma Open Source Plugin 则泛指开放的插件能力（Figma API / 插件 API），可实现从设计稿提取样式、导出资源、批量规范检查等自定义联动，适合按团队需求定制（如自动生成组件代码骨架、设计走查脚本）。

工程取舍的要点：其一，同步方向——设计是事实源还是代码是事实源？常规以设计为源（token 在 Figma 维护 → 导出入库），代码侧修改需回写设计，冲突由人工仲裁；若团队以代码为源，则需要反向插件支持，成熟度低，需明确边界。其二，自动化收益与成本——插件同步省去手工转录，但引入依赖（插件版本、Figma 文件结构规范、命名约定），需投入规范化建设（文件组织、命名、评审流程），否则同步产生噪声提交；其三，版本与质量——token 入库后必须走构建管线回归（各平台产物生成、消费方视觉回归），避免"同步了但没人用"；其四，多主题与跨端——插件的多主题导出与原生端产物生成能力需验证，必要时以 Style Dictionary 管线承接。结论：联动工具解决"搬运"，治理解决"质量"，先定事实源与规范，再上自动化。

本题考察"设计工具与代码工程接缝"的实践认知。答题先讲 Tokens Studio 与插件的能力（导出、Git 同步、变量兼容），再重点展开取舍四要素（事实源、成本收益、版本质量、跨端）。能提到"同步了但没人用"的陷阱说明对自动化失效场景有真实观察。

• 暗色模式：语义 token + 主题变量
• 高对比度：强制颜色、对比度 token、非颜色状态提示
• 减少动画：prefers-reduced-motion 的动效降级

三种模式本质是"同一语义、不同环境取值"的变量问题，设计系统用语义 token 承接：暗色模式通过主题层覆盖语义 token（--color-bg-primary 等由 light 值切换为 dark 值），配合颜色适配细节（暗色下的阴影减弱、透明度层级、强调色亮度调整），组件只消费语义 token 即可自动适配；实现上支持"跟随系统（prefers-color-scheme）+ 手动切换（data-theme）"双策略，切换时避免闪烁（内联脚本预置主题）。

高对比度模式：依赖语义 token 的对比度保证（文本 / 背景对比度达标 WCAG），并提供强制的高对比度主题覆盖（如强化 focus 环、边框可辨识、非文本对比），支持 prefers-contrast 与强制颜色模式（forced-colors）下用 forced-color-adjust 保留关键语义；同时所有状态（hover / focus / active）必须有非颜色依赖的提示（图标、下划线），避免只靠颜色传达状态。减少动画：用 prefers-reduced-motion 媒体查询降级动效——移除 / 缩短位移与缩放动画、保留关键信息过渡（淡入淡出替代位移动画）、关闭自动播放轮播，且 CSS 动画与 JS 动效（Web Animations API、gsap）都要检查该媒体查询。动态切换的工程要点：所有适配都基于"媒体查询 / 主题变量"而非硬编码，组件层零改动；提供统一的切换入口（跟随系统 / 手动 / 强制高对比）与切换后的自动化走查（暗色、高对比、减少动画三种环境下截图回归），把适配内建为设计系统的一等能力。

本题考察"无障碍与主题适配"的叠加处理。答题按"暗色（语义 token 主题化）→ 高对比（对比度保证 + forced-colors + 非颜色状态提示）→ 减少动画（媒体查询降级）"三块展开。能提到 forced-colors 与"非颜色依赖的状态提示"说明理解 WCAG 的深水区。

• 语义 token 对 AI 生成的约束与可理解性价值
• 语义化设计：命名、层级、用途绑定
• 语义化提升手段：清单治理、用量驱动、AI 辅助审计

token 语义化指 token 命名与组织表达"用途"而非"表象"（--color-bg-primary 而非 --color-blue-1）。在 AI 协同背景下其价值被放大：一是约束价值——AI 生成代码时，语义 token 是"可学习的约束语言"，模型更容易学会"背景用 bg-primary、文本用 text-default"的用途规则，而不是记忆数值；语义化越清晰，生成代码命中 token 的概率越高、硬编码越少；二是可理解价值——语义 token 让 AI（和新人）无需设计背景就能读懂代码意图，作为知识库注入 prompt 时质量更高；三是治理价值——语义层级完备时，主题切换、品牌换肤、AI 生成的差异扫描都能建立在"用途"维度上。

提升语义化的手段：命名规范治理（用途导向命名 + 分组层级 + 文档化每个 token 的使用场景与反例）；用量驱动（通过硬编码扫描与 AI 反查统计"高频裸值"，反向推导缺失的语义 token）；AI 辅助审计（用 LLM 对 token 清单做语义一致性审查——命名是否表达用途、层级是否合理、是否存在同义 token，输出整改建议）；以及配套校验（lint 禁止硬编码值，强制走语义 token，防止语义层被绕过）。关键原则：语义化不是给 token 起好名字，而是"每个 token 都有明确的用途契约，且契约被工具与 AI 共同消费"。

本题考察"token 语义化在 AI 时代的战略意义"。答题按"语义化的定义与三重价值（约束 / 理解 / 治理）→ 提升手段（命名治理、用量驱动、AI 审计、lint 强制）"展开。核心观点是"语义化让 token 从设计变量升级为 AI 可消费的知识"，能提到"高频裸值反推缺失 token"说明有数据驱动的意识。

• 一致性风险：样式、API、语义、结构偏差
• 校验手段：lint / 扫描、视觉回归、类型与 API 对比
• 流程保障：生成规范、评审、反馈闭环

AI 生成组件的质量风险集中在一致性：样式不一致（硬编码色值 / 间距、自造类名）、API 不一致（props 命名与设计系统契约冲突）、语义不一致（用 div 模拟按钮、缺少 a11y 属性）、结构不一致（组件内部组织随意）。一致性校验的工程体系分四层：静态校验——lint（禁止裸标签、禁止硬编码 token 值、命名规范）+ 类型检查 + token 引用扫描（未使用 token 的硬编码自动报错）；视觉校验——生成组件与设计基线（设计稿或既有组件）的视觉回归对比，量化还原度；契约校验——API 快照对比（生成组件的 props 与组件库 API 基线 diff，新增 / 删除 / 改名即报警）+ 组件白名单检查（只能基于设计系统原语构建）；行为校验——交互测试（键盘可达、焦点管理、a11y 扫描）覆盖生成组件。

流程保障上，把一致性要求前置：生成规范（prompt 注入组件 API 指南、token 清单、代码风格）让模型"生成即合规"；生成后强制走校验门禁，不合规自动反馈给生成端（记录违规类型，反哺提示词与校验规则，形成"生成 → 校验 → 反馈 → 改进"闭环）；入库前人工评审兜底语义判断。度量上用"一次性通过率、违规率、返工次数"跟踪质量趋势。核心原则："AI 负责生成，规则负责校验，闭环负责改进"，一致性不是抽查出来的，而是被强制出来的。

本题考察"AI 产物的质量体系"。答题按"四类风险 → 四层校验（静态 / 视觉 / 契约 / 行为）→ 流程闭环（规范前置、门禁反馈、人工兜底）→ 度量"组织。核心观点是"一致性校验要构成强制门禁与反馈闭环，而非事后抽查"，能提到反馈闭环说明理解 AI 时代的质量体系是持续演化的。

• 硬编码检测：AST 扫描 CSS / 内联样式 / JSX 属性中的色值与间距
• 自动替换：值与语义 token 的匹配（精确匹配、相似匹配、上下文判断）
• 替换安全：分级确认、白名单、回归验证

方案分"检测、映射、替换、验证"四步。检测：用 AST 工具（PostCSS 遍历样式、Babel / TypeScript AST 遍历 JSX 的 style 属性与类名文件）扫描所有字面量，识别硬编码设计值——色值（hex / rgb / hsl / oklch）、间距（px / rem 数值）、字号、圆角、阴影等，按类型归类并生成"硬编码清单"；规则层面区分"可疑硬编码"（在 token 覆盖范围内的值）与"合法字面量"（如透明度 0.5 用于 hover 的叠加、响应式断点），避免误报。

映射与替换：建立"值 → 语义 token"的匹配机制——精确匹配（值与某个 token 相等直接命中，如 #1677ff → --color-primary）+ 相似匹配（色相 / 明度相近、间距数值处于 token 刻度，如 15px → 16px 候选 --space-4，给出置信度与备选列表）；LLM 可辅助生成候选（结合上下文判断用途：按钮背景、边框、内边距），但替换必须"带确认"——高危自动替换（精确命中）、中危批量确认（相似匹配出确认清单）、低危人工处理（无法判定的标记）。自动替换时用 lint 规则（no-hardcoded-color 等）保证替换后不再出现硬编码。验证：替换后跑类型检查、构建、视觉回归（替换前后截图对比确认视觉无变化），并输出报告（替换统计、置信度分布、未处理清单）；替换逻辑本身做成可复用的 CLI / 插件，纳入 CI 对新生成代码持续扫描。核心原则："检测要全、映射要准、替换要稳（确认制）、验证要严"，把硬编码治理从人工体力活变成可持续的自动化管线。

本题考察"AI 时代代码治理自动化"的具体方案设计。答题按"检测（AST + 分类防误报）→ 映射替换（精确 / 相似 / LLM 候选 + 分级确认）→ 验证（视觉回归 + lint 防复发）"四步组织。核心是"准确性优先、替换可控、回归验证"的工程安全观，能提到"合法字面量豁免"说明考虑了误报治理。