设计系统长期面临一个老问题:Figma里有一套组件,React、iOS和Android里各有实现,文档又是另一份解释。人工智能让生成速度变快,也把不一致放大。
解决方向不是再宣布一个唯一真相,而是建立可版本化、可转换、可验证的规格中枢。
早期组件规格常被当作设计师交给工程师的标注页,记录尺寸、颜色和间距。更完整的规格应覆盖组件名称、属性、元素、变体、令牌绑定、插槽、组合、布局和示例。
结构化数据不仅便于人阅读,也便于脚本和代理稳定消费。能够从Figma确定性提取的部分应尽量自动生成,减少手工抄写。
行为、无障碍、复杂属性约束和平台差异,则需要人工或代理补充。两类规格并存并不矛盾:生成部分负责忠实,补充部分负责表达设计工具无法承载的意图。
日期选择器可能先在Figma完成,另一款卡片却先在网页原型里被验证;工程师还会在实现中发现无障碍和接口问题。若强迫所有决定只从一个工具产生,信息会在迁移时丢失。
更合理的目标,是承认多个起点,再用规格统一表达。这要求双向转换:Figma到规格、规格回到Figma、规格到原型、原型再回到规格。
![]()
转换必须尽量无损、快速且成本可控。确定性脚本适合处理样式、属性和结构,代理适合处理暂时无法严格映射的语义,但推断结果必须接受验证。
规格一旦成为中枢,就要像代码一样版本化。删除属性可能构成破坏性变更,新增元素属于功能扩展,更换令牌绑定可能只是修补。
清晰的架构能够让影响判断从争论转向规则,也让不同平台逐步吸收变化。重要设计取舍可写入架构决策记录,包含背景、问题、备选方案、决定和后果。
结构化规格还可以自动生成分析报告,回答某个颜色令牌被哪些组件使用、不同组件的状态属性如何变化、修改图标接口会影响哪里。提前看见影响,能减少发布后的连锁返工。
![]()
规格可以生成CSS、类型契约、React骨架和测试示例,也可以驱动跨平台工厂。生成代码适合作为起点,却不必被包装成无需审查的成品。
平台习惯、性能、无障碍和复杂交互仍需工程人员判断,设计人员也要审核实际体验。真正成熟的规格驱动开发,不是让设计工具或人工智能统治全部环节,而是让意图可见、变更可追、转换可验证。
Figma、原型、代码和文档各自保留擅长的表达方式,中间由规格建立契约。这样,速度提升才不会以一致性和可维护性为代价。
团队还应为规格设定所有者与审核流程,明确谁能批准破坏性变更、谁维护转换器、谁处理平台例外。若只有文件格式没有治理,规格很快会成为新的孤岛。
![]()
真正的中枢不仅要能被生成,还要能在日常协作中被持续采用和及时更新。落地时可先选择少量高频组件试点,记录从设计到实现的差异类型,再逐步扩大范围。
试点的价值不是证明工具万能,而是找出哪些字段可以确定转换、哪些判断必须保留人工审核,并据此调整规范与协作流程。
特别声明:以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布,本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.