很多团队的规范之所以越做越乱，是因为把视觉风格、交互规则、组件实现混在一份文档里。建议从一开始就把规范拆成三层：基础（Tokens）、组件（Components）、使用（Guidelines）。
基础层解决“用什么值”：字号、行高、颜色、圆角、阴影、间距等都要有一组可复用的刻度；组件层解决“怎么拼”：按钮、输入框、卡片等组件的结构、状态、变体；使用层解决“何时用”：场景、禁用项、可访问性、文案长度限制、错误提示规则。
这三层分开管理的好处是：基础层稳定，组件层可演进，使用层面向业务迭代。你每次改动都能明确影响范围，避免牵一发动全身。
字号体系建议用“级差”而不是“随手挑几个”。常见做法是确定一个基准字号（例如 14 或 16），再用固定比例或固定步长向上向下扩展。移动端和网页端都建议同时定义字号与行高（Line height），因为阅读体验取决于两者的组合。
一个可落地的方案示例（你可以按产品气质微调）：
正文：14/20；次要信息：12/18；强调信息：16/24；标题：20/28、24/32、32/40。
规则上强调三点：1）同一页面的正文不要混用两套字号；2）同一层级的标题在全站一致；3）行高不要“跟着感觉走”，而是跟着字号体系一起定义。
间距体系建议选择 4pt 或 8pt 作为基准单位。这样做的目的不是形式主义，而是让页面在快速迭代时仍然保持秩序感：组件内边距、组件间距、区块留白都能落到同一把尺子上。
推荐的间距刻度：4/8/12/16/24/32/40/48。组件内边距常用 12/16；区块间距常用 24/32；页面大区块留白常用 40/48。你只要坚持这些刻度，页面即使被不同设计师接手，也不会“越改越散”。
栅格方面：网页端可用 12 列（常见 1140/1200 容器），移动端可用 4/6 列。关键不是列数，而是：间距（gutter）要和间距体系对齐、断点（breakpoints）要写清楚、容器宽度要明确。
只列一堆色值很难落地，因为业务增长后你会出现“同一个红色到底用哪一个”。建议把颜色拆成两类：基础色板（例如 Blue 50~900）与语义颜色（Primary/Success/Warning/Danger/Info/Neutral）。
语义颜色要覆盖常见状态：默认、悬停、按下、禁用、浅色背景、边框色、文本色。并且明确对比度要求（例如正文文本对比度至少 4.5:1）。只要语义清晰，你就能在换主题或品牌升级时“整体替换”，而不是逐页修补。
组件命名建议遵循“组件名/属性=值”的结构，例如 Button/Type=Primary、Button/Size=MD、Button/State=Loading。这样在 Figma、Sketch 或代码里都能保持一致，也方便做批量替换。
变体（Variants）尽量用属性组合而不是复制粘贴：把 Size、Type、State、Icon、FullWidth 等拆成可组合属性。并且为每个组件写清楚：最小/最大宽度、文案长度上限、图标尺寸、左右间距、可点击区域（hit area）。这些细节往往比“外观”更影响体验与实现成本。
建议为每次交付准备一个 10 分钟就能过完的检查清单，减少返工：
1）字号与行高是否使用体系内数值；2）间距是否落在 4/8 倍数；3）颜色是否使用语义色而非随手取色；4）组件是否来自组件库且命名正确；5）状态是否完整（默认/悬停/按下/禁用/加载/错误）；6）文案是否超出规则（长度、标点、大小写）；7）空状态/异常状态是否提供反馈；8）对齐与栅格是否一致；9）切图与标注是否必要且清晰；10）交互说明是否可被研发实现。
当你把规范写成“可执行的规则 + 可复用的资产 + 可验证的清单”，它就不再是一份漂亮的 PDF，而会成为团队协作的共同语言。
如果你现在是一人或小团队，不要试图一次性做全量组件。先把基础 Tokens（字号、间距、颜色、圆角、阴影）定下来，再做 6 个最高频组件：Button、Input、Select、Checkbox/Radio、Modal、Card。把它们的状态做全、命名做对、示例做清楚。等业务跑起来，再按实际页面把缺口补齐。
最后提醒：规范不是“做完一次就结束”，而是“每次迭代都有记录”。你可以用版本号或变更日志（Changelog）记录：新增了什么、废弃了什么、替代方案是什么。这样团队的信任会越来越高，规范也会越来越有生命力。
