组件库整理得很漂亮，业务页面却还是会出现另一套按钮、另一种间距和含义不同的状态。设计系统在持续使用之后，最难回答的常常不是“有没有规范”，而是“规范与实际产品还有多大距离”。Supernova在11月10日发布的设计系统审查文章，讨论了设计、代码与文档的核对。我们借这个话题，分享一种更接近日常项目的阅读方式：从使用中的页面出发，找到不一致产生的位置，再决定哪些需要合并、补充或逐步替换。本文不是工具测评，也不把厂商案例结果当成通用效率结论。
如果一开始只查看组件库，很容易得到一个令人满意的结果：命名统一、分组整齐、颜色也有标准值。但业务人员面对的并不是这个目录，而是具体的列表、表单和审批页。同一个产品里出现两种风格相近的选择框，可能是历史遗留，也可能是某个特殊场景没有被基础组件覆盖。
原文Supernova界面示例：在设计系统工作区检查重复组件。具体能力以原文说明为准。
设想我们要审查一套工业后台，可以先选三条常用路径：查找设备、修改配置、处理告警。把路径中实际出现的按钮、输入框和状态提示收集出来，再对照组件库。这样发现的差异会带着上下文，不会一看到自定义组件就判定它应该被删除。
收集时也要保留页面和组件版本。否则，讨论很容易变成“我记得已经改过”。截图、实际页面入口和当前版本可以一起形成简短记录，让设计与开发围绕同一处现象讨论。对于还在使用的老页面，先记录事实，再决定迁移节奏，会比一次要求全部替换更容易落地。
组件在画板上最常展示的是默认状态，业务页面的问题却往往发生在点击之后。下面的概念图把按钮放进表单与审批场景，是为了观察加载、禁用和焦点等状态。它呈现的是一种检查思路，其中数字和对比项均为示意，不能当作自动检测结果。
AI概念示意：将按钮状态放入工单审批场景检查，非Supernova截图，非真实验收数据。
例如，“提交中”的按钮如果突然变窄，邻近操作可能跟着移动；禁用按钮若没有解释，使用者就要猜测还缺什么条件。一个危险操作在组件库里有醒目的样式，到了复杂页面却被放在普通工具栏中，也可能失去原本的提示作用。
因此，评审时可以把最容易被忽略的中间过程补出来：请求较慢、保存失败、权限不足、内容为空，以及键盘操作。不是要求每页画满所有状态，而是选出会影响任务理解的几种情况，看看同一组件在不同页面里是否仍然表达相同含义。
设计变量能够减少重复定义，但名称相同并不意味着使用方式相同。一个叫“成功”的绿色，可能在某页代表任务完成，在另一页却代表设备在线。这两种含义在业务上不同，如果只因为颜色一致就归入同一规则，后续修改时就可能牵动不该一起变化的内容。
原文Supernova界面示例：查看设计变量相关的审查说明。
我们会先问变量究竟描述什么：是基础颜色，还是业务状态？间距是通用层级，还是某种布局的局部要求？对于桌面端界面设计，数据表格的紧凑行高和普通表单的点击区域也未必适合共用同一个尺寸。把用途解释清楚，往往比继续增加命名缩写更有帮助。
这类核对需要回到实际页面。比如改动一个数字字号，应同时检查金额、统计卡片和密集表格，而不只看单个文本示例。只要能让团队理解变化会影响哪些地方，记录就不一定很长。过度复杂的命名系统，反而可能让后来加入的人更难正确选择。
设计系统的文档如果只是重复组件名称，使用时的疑问仍然存在。一个组件适合什么内容、不适合什么情况、需要与哪些状态配合，才是业务团队最常遇到的问题。尤其当新旧组件同时存在时，简单加上“废弃”标签，还不足以指导迁移。
原文Supernova界面示例：为设计变量补充可理解的说明。本文不将示例输出作为已核实规范。
假设一套旧筛选栏需要替换，可以让说明带上替代组件、受影响页面和迁移后的交互变化。若新组件还不能覆盖某个复杂条件，就保留清楚的例外说明。团队需要知道暂时为什么这样做，以及之后由谁继续维护，而不只是看到一个红色警告。
审查结果也应当有可承接的落点。重复组件、说明缺失和实际行为冲突，处理优先级并不相同。我们可以按影响范围和业务重要性安排修正，让每项问题都有负责人和复核入口。组件数量变少并不是唯一目标，使用者是否更容易选对、产品是否更容易维护，才更值得持续观察。
维护入口最好贴近文档本身。阅读者发现示例与页面不一致时，能够直接提交对应问题，而不是另起一段没有链接的聊天。少量但可定位的反馈，可以让规范的修正沿着真实使用继续发生，避免审查结束后又回到无人维护的状态。
设计系统的完整感，不只来自画板上的排列，还来自设计、代码、文档和业务页面能否互相解释。把审查做成一次带场景的共同阅读，很多“看着差不多”的问题才会露出来。对长期维护的B端产品来说，这是一项需要慢慢积累、也很值得投入的日常工作。
