同一套后台页面，即使使用了相近的配色，也可能在表格密度、按钮层级和状态提示上越做越不一样。让AI参与以后，这种差异还可能在多个页面里同时出现。Wayne Lin在Figma官方文章中讨论了怎样把组件库、规则和示例提供给agent。兰亭妙微借这个话题，分享一些围绕企业工作台的整理思路：与其反复要求“保持统一”，不如先把可以复用的东西与需要判断的地方说得更具体。下文界面均为独立AI概念示意，不是Figma实际功能截图。
假设团队正在维护一套设备运维后台。文件里可能同时留着旧版按钮、临时测试的状态标签，以及已经批准使用的表格样式。若它们没有清楚的边界，使用者和AI都需要猜测哪个才是当前标准。整理组件库的第一步，可以是让批准使用的资产与探索中的方案容易区分。
AI概念示意：组件库与设备工作表放在同一工作区中，不代表Figma官方界面。
名称也要能够帮助选择。单纯的“按钮一”“按钮二”难以说明差别，而名称里出现用途、层级或状态，读者就能先缩小范围。这里不需要建立一套很复杂的术语体系，先从最常复用的几个对象开始：主要动作、次要动作、状态标签、数据行，以及常见的详情面板。
还可以记录组件目前在哪些页面使用过。某个样式只在一次视觉探索中出现，与已经在多种业务页面中验证过，是不同的情况。标清这些差异，能让讨论更具体，也方便在规则改变以后找到受影响的页面。统一并不是让所有界面一样，而是知道哪些关系应该共同维护。
一张表格如果只留下默认外观，真正使用时还会遇到加载中、没有结果、部分失败和只读等情况。设计系统里可以先说明这些状态分别表达什么，再讨论具体样式。不同状态若都被画成一块灰色区域，开发同事就容易在实现时补出另一套解释。
AI概念示意：默认、加载、空内容与错误等状态，连同语义规则一起维护。
语义变量也应围绕含义维护，而不是只保存一批颜色。以设备状态为例，待处理、处理中和处理失败各自对应什么信息与动作，需要有明确约定。颜色是其中一种表达，文字和位置同样重要。把状态说明与组件放在一起，比让使用者到另一份很长的文档里搜索更容易理解。
对于暂时不可用的按钮，还应核对原因是否可见、条件变化后怎样恢复。不能只用一个低透明度样式代替全部逻辑。这些规则不必一次覆盖所有边角，可以优先整理最常出现、最容易解释不一致的状态，再随着真实任务逐步补充，让组件与使用场景一起成长。
零散组件说明了“有什么”，完整页面则能说明“怎样一起用”。例如设备工单页面，筛选条件、数据表、选中行、详情抽屉和提交动作之间有连续关系。只把这些组件分别交给别人，并不能保证组合以后还保留相同的阅读顺序。
AI概念示意：完整工单模式连接筛选、表格、详情和主要动作。
可以选择一张业务含义清楚的页面作为示例，保留适量的真实长度内容：较长名称、不同状态、空字段和需要再次确认的动作。示例不必展示所有功能，而要表达一套可以理解的组合关系。使用者由此能看到，什么时候需要抽屉，什么时候需要独立详情页，主要动作应该靠近哪一类信息。
如果另一个模块的任务不同，也要允许它采用不同组合。把一种页面生硬套到所有后台，只会把差异转移成大量例外。比较合适的做法是，在示例旁说明它解决的任务与适用范围，再列出哪些部分可以变化。给AI提供上下文时，这种完整但有边界的参考，比一句“照这个风格做”更有用。
AI给出一版界面以后，仍然需要回到具体页面检查。可以观察它是否沿用了正确组件、是否用新的颜色代替已有状态，以及是否只生成了成功画面。发现问题时，先指向出现的位置和影响，再决定应该修这一个页面，还是更新更上游的规则。
AI概念示意：定位脱离组件、写死颜色和缺失状态等问题，不是agent的真实审计结果。
有些问题只属于当前任务，有些则会在多个页面反复出现。例如相同的长名称总被截到无法区分，就可能需要回看表格模式与内容规则，而不是逐页加宽某一列。把这类重复问题记录下来，也能帮助团队判断哪些示例已经过时、哪些组件需要增加变体。
复查结果可以随着组件库一起维护：最近一次调整解决了什么，哪些页面需要跟进，还有哪些状态尚未补齐。这样设计系统就能支持后续工作，而不是变成一份看起来完整、实际没人知道能否继续使用的展示文件。AI可以参与其中，但每项规则的业务含义与最终取舍仍需要团队明确。
设计系统的价值，在于把团队已经形成的判断留下来，并让下一次工作能够接着使用。组件、状态、页面示例和反馈相互连接以后，“保持统一”才有可落到画面上的含义。对于持续增加功能的B端产品，我们更看重这种可延续的协作关系，而不仅是一组整齐的组件缩略图。
