Token 不是色板文件，是发布契约
很多团队有一份漂亮的 Figma 色板，却在生产里硬编码魔法数字。设计系统 Token 如何落到生产，关键是把 token 当成版本化契约：命名稳定、分层清晰、流水线可重复、变更可审。可上线在品牌站与产品同仓时，用 token 管道连接体验设计与工程，避免「设计稿是圆角 12、线上是 8」。下文给出可落地的分层与 PR 规则。下文给出可落地的判断框架、分步清单与常见误区，便于上海及跨境团队在两到四周内推进，并把相关服务能力组合进同一交付节奏。
三层 token：原始-别名-组件
原始值（色阶、字号刻度）→ 语义别名（surface/danger）→ 组件映射。组件层不直接引用原始色，主题切换才不崩。结合可上线探索→设计→开发→上线节奏，把该项写入验收与预发检查，避免口头对齐后遗漏。
命名在跨端前先稳定
Web/iOS/Android 共用语义名。禁止在名称里写死 hex 或「new」。废弃走别名重定向，给一个版本的缓冲。结合可上线探索→设计→开发→上线节奏，把该项写入验收与预发检查，避免口头对齐后遗漏。
Figma 与代码的单一来源
选定方向：设计导出 JSON 或代码生成插件反哺。双写必漂。流水线在 CI 校验缺失 token 引用。结合可上线探索→设计→开发→上线节奏，把该项写入验收与预发检查，避免口头对齐后遗漏。结合可上线（KSX Studio）探索→设计→开发→上线节奏，把该项写成可验收产物：负责人、完成定义、预发验证与回滚策略，避免口头对齐后再次发散。
主题与品牌白标
多品牌只替换语义层与少量组件映射，不复制整套组件库。暗色模式先定义表面层级再调强调色。结合可上线探索→设计→开发→上线节奏，把该项写入验收与预发检查，避免口头对齐后遗漏。结合可上线（KSX Studio）探索→设计→开发→上线节奏，把该项写成可验收产物：负责人、完成定义、预发验证与回滚策略，避免口头对齐后再次发散。
动效与间距同样 token 化
时长、缓动、间距刻度进同一体系，营销动效才守得住性能预算。与 motion performance 文章交叉约束。结合可上线探索→设计→开发→上线节奏，把该项写入验收与预发检查，避免口头对齐后遗漏。结合可上线（KSX Studio）探索→设计→开发→上线节奏，把该项写成可验收产物：负责人、完成定义、预发验证与回滚策略，避免口头对齐后再次发散。
变更评审与视觉回归
token PR 必须附影响面与截图对比。破坏性变更走 major 版本。设计评审看 token 使用率，而不是再贴一层局部覆盖。结合可上线探索→设计→开发→上线节奏，把该项写入验收与预发检查，避免口头对齐后遗漏。
落地两周节奏
W1 盘点硬编码与命名；W2 接通管道与替换高流量模板。不要等「完美系统」再替换首页。结合可上线探索→设计→开发→上线节奏，把该项写入验收与预发检查，避免口头对齐后遗漏。结合可上线（KSX Studio）探索→设计→开发→上线节奏，把该项写成可验收产物：负责人、完成定义、预发验证与回滚策略，避免口头对齐后再次发散。
可执行清单
- 1定义三层 token 与命名规范
- 2选定单一来源与 CI 校验
- 3语义层支持亮/暗与品牌
- 4禁止组件引用原始色阶
- 5token PR 模板含影响面
核心要点
- Token 是工程契约，不是设计附件。
- 语义层稳定比色值完美更重要。
- 流水线与 CI 比再开一次规范会有效。
常见问题
- 小团队也要三层吗？
- 至少原始+语义两层。组件层可薄，但别让页面直接写 hex。
- 用 CSS 变量还是 JS theme？
- 营销站优先 CSS 变量；复杂产品主题可双轨，但来源仍应一份 token JSON。
- 历史项目如何迁移？
- 按模板替换，设 lint 禁新硬编码。不搞大爆炸重写。