用途：为网站或 Web 应用提取、创建或完善一套可直接实施的设计系统，目标是构建让产品更一致的最小系统，优先采用组件可用的语义契约，而非大量装饰性数值。
模式选择：产品视觉一致但无文档时用提取；多种模式冲突时用调和；新产品尚无 UI 语言时用创建；功能需要系统缺失的状态或组件时用扩展。
工作流程：先检查框架、CSS 策略、主题文件、基础组件、组件库、图标集与代表性页面；盘点重复值与模式，区分有意变化与意外漂移；在改代码前把原始值映射到语义角色（如 blue-600 映射为 action-primary，而非替换所有蓝色）；定义最小 token 层级，包括 foundations（颜色、字体、间距、圆角、边框、阴影、动效）、语义 token（背景、表面、文本、边框、动作、焦点、状态），仅在组件确实需要时定义组件 token；规定组件结构、变体、尺寸与状态行为，并包含内容约束；定义响应式行为与密度规则，不臆造设备专属副本；编码无障碍默认值，如语义元素、名称、标签、focus-visible、键盘行为、对比度、错误、目标尺寸与减少动效；在既有样式机制内实现，避免并行 token 系统；迁移一个代表性组件或页面，并在安全时移除被取代的值；验证明暗主题、核心状态、窄宽布局及至少一个真实内容压力场景。
系统规则：按用途而非当前外观命名 token；保留原始值逃生通道，但让正确路径更易走；不要强行把每个区域做成卡片；不要仅用颜色表达状态；保持组件 API 精简，优先组合而非变体爆炸；除非损害可用性、无障碍或可维护性，否则保留既有模式；在后续贡献者可能重新制造不一致处记录决策。
交付契约：提供模式与审计（现状、冲突、遗留）、token 映射（现有值→语义角色→实现位置）、组件契约（结构、变体、状态、内容限制、响应式行为）、迁移切片（要求改代码时至少一个真实组件）、验证证据（已测试的主题、状态、视口与例外）。定义或审计 token 与组件状态时可阅读 references/token-checklist.md。
限制：资料未提供具体收费、价格、平台支持范围或效果数据。