设计系统的组织方式如何变化
Design Token：设计与代码的统一语言
Design Token 把颜色、间距、圆角和组件语义连接到设计与代码。理解它的分层方式，是建立多主题和多品牌系统的基础：
这套分层架构的威力在于：切换品牌主题时，只需要修改语义 Token 指向的原始 Token 值，所有组件自动更新。一个设计系统可以支撑 10 个品牌，而不需要维护 10 套组件库。Figma Variables 的多模式功能（Light/Dark/Brand A/Brand B）正是这套理念的直接实现。
自动化工具可以参与哪些工作
v0 by Vercel、Anima、Locofy 可以从 Figma 设计稿直接生成 React/Vue 组件代码。在有完善 Token 系统的前提下，生成的代码质量已经可以作为起点直接进入 PR 审核流程，而非从零手写。
Figma 的 Analytics 功能 + AI 分析可以告诉你哪些组件被高频使用，哪些已经成为"僵尸组件"。这让设计系统的维护从经验驱动变为数据驱动——砍掉没人用的组件，重点打磨高频组件。
AI 辅助的无障碍检测工具（axe AI、Stark）可以在设计阶段就标记对比度不足、缺少 alt text、焦点顺序错误等问题。设计系统可以内置这些检测规则，让每个组件在发布前自动通过基础无障碍检查。
Zeroheight、Supernova 等平台可以根据组件属性和使用示例生成文档初稿，适合补齐重复说明，但发布前仍需要检查状态、例外和研发约束。
AI 带来的新挑战
我在系统维护中关注什么
在 Pisell 主导设计系统从 0 到 1 的过程中，我逐步把基础规则、组件状态、配置项和研发说明放到同一套维护方式里。组件数量增加以后，命名和状态规则比单个界面的完成度更影响协作。
Token 架构可以帮助自动生成的界面继续使用团队已有的品牌与语义规则，但前提是命名清楚、层级稳定，并有对应的组件状态和代码约束。
设计系统负责人还需要持续和产品、设计、研发对齐：哪些情况应该复用，哪些情况允许例外，何时需要把新模式收回系统。
设计系统需要让团队在变化中仍能做出一致的选择。Token 提供语言，组件提供边界，文档和评审负责把规则落到实际产品中。