去很多 SaaS 公司做设计咨询时，对方设计主管都会自豪地打开 Figma 给我们看：“你看，我们已经搭好自己的 Design System（设计系统）了！”点进去一看，第一页是品牌色阶（Blue-100 到 Blue-900），第二页是字号表，第三页是几种大小的按钮、单选框和输入框——然后就没有然后了。
等到去他们真实的线上产品里转一圈，问题全暴露出来了：A 业务线的表格筛选栏放在表头上方，B 业务线的筛选栏藏在右侧抽屉里；财务模块的批量删除是弹窗确认，订单模块的批量删除是行内气泡确认；每个业务设计师都在用那套一模一样的蓝色按钮，拼凑出交互逻辑完全割裂的业务页面。
这就是为什么我们常说：只停留在“颜色、字体和基础按钮”的设计系统，在复杂 SaaS 产品里只能解决 30% 的问题；真正能统一全局体验、帮前端提效的，是往上再走一步——把高频出现的“业务组件（Business Patterns）”固定下来。
第一层（地基）：用语义化 Design Tokens 替代死色值
不要让设计师和前端在代码里直接引用 #2563EB 或者 Blue-600。一旦以后产品要做深色模式，或者针对大客户做贴牌换肤（White-label），改起来会要命。
正确的做法是建立语义化变量（Semantic Tokens）：
- 背景层定义为
bg-surface-primary（主画布底色）、bg-surface-elevated（悬浮卡片/弹窗底色）； - 文字层定义为
text-primary、text-secondary、text-muted； - 边框与状态定义为
border-subtle、status-warning-bg等。设计师只管按语义角色贴标签，前端 CSS 变量一键映射。
第二层（砖瓦）：基础原子组件必须补齐“极端态与脏数据态”
很多团队画基础组件（Button、Input、Select、Table）时，只画了文字长短刚好的“理想状态”。到了真实研发阶段，前端就会不停地来问设计师：
- 下拉多选框如果用户一口气选了 15 个标签，框体是横向滚动、折行撑高，还是显示
已选 15 项？ - 表格某一列的客户公司名称长达 40 个字，是省略号截断加 Hover 气泡，还是允许折成两行？ 把这些边界规则直接在 Figma 组件的 Auto Layout 和变体属性（Variants）里定死，前端写一次组件就能全站复用。
第三层（预制房）：沉淀 6～8 个跨模块通用的“业务级复合组件”
在像 NEXIVA 企业财务协作平台 这样的中大型 SaaS 产品中，真正决定用户操作顺手程度的，是下面这几个高频业务模板：
- 标准高级筛选与视图保存条（Filter & Saved Views Bar）：统一规定搜索框、常用高频筛选项、高级条件组合器以及“保存为我的常用视图”的位置与交互。
- 表格批量操作悬浮栏（Bulk Action Bar）：当用户在列表勾选 1 条或多条记录时，统一在底部或表头浮现深色操作条（显示已选数量、批量导出、批量改状态、取消选择）。
- 主从详情抽屉与分步向导模板（Slide-over & Stepper）：统一规定多大信息量用弹窗（Modal）、多大信息量用右侧抽屉（Drawer）、多大信息量跳独立详情页。
当这三层结构搭齐之后，新业务模块立项时，设计师和前端就像搭乐高一样，80% 的界面直接调用现成的业务级组件拼装，把宝贵的精力真正花在那 20% 核心业务逻辑的创新上。
