UI 设计稿直接生成代码,做过设计或前端的人,大概都听说过。
早在几年前,设计工具就已经能导出样式参数、标注间距,甚至直接给到一段 CSS 代码。但在实际开发中,这些导出的参数更多是当作开发的辅助参考。毕竟,设计稿依然是静态图,逻辑代码依然要开发一个字符一个字符地敲,这两者之间的鸿沟,过去并没有真正填平。
真正的变化,其实是最近两年才开始集中显现的。产品迭代周期持续压缩,需求变更为常态;再加上新平台、新框架层出不穷,尤其是鸿蒙 HarmonyOS 这类新生态的崛起,让UI还原的成本被进一步放大。行业里关于 D2C(Design to Code设计稿转代码) 的讨论热度回升,其实是因为传统产研协作模式已难以应对当前的效率挑战。
最近看到国内智能原型设计与产研协作平台——墨刀推出了 D2C 功能,号称能把设计稿直接生成可运行前端代码。团队试着去拆解了一下,发现这不再是以前那种“效率幻想”,而是被反复拉到桌面上讨论的现实解决方案。
![]()
UI 设计稿生成代码的演进之路
从行业演进的角度看,UI转代码这件事,其实是在不断“进化”的。在不同阶段,它解决的问题并不一样:
最早是参数化阶段,解决的是“看不清”的问题。设计工具解决的是“量化设计”:字号、颜色、圆角、间距都可以被精确读取,开发不再靠目测,但还得手写。
后来到了样式生成阶段,开始有工具尝试直接导出 CSS 甚至简单的 DOM 结构。但也仅此而已了,生成的代码结构混乱、缺乏语义化,可读性与复用率低,导致“一次生成,长期维护成本高昂”,离真实工程还有不小的距离。
而现在,行业正在进入结构级生成阶段。这也是墨刀 D2C 这类工具在做的事:它不只是盯着像素看,而是试图去“理解”设计稿。它能自动拆解页面结构、识别组件层级、理清布局关系,最终生成可运行、可维护的工程级代码。本质上,它改变的是设计稿在整个流程里的“角色”。
![]()
从“画完交付”到“生成代码”
和早期那些暴力导出代码的方案不同,墨刀 D2C 的切入点并不是帮开发少写几行样式,而是试图理解设计稿本身的结构含义。在实际使用中,它做了几件比较关键的事情:
一是自动拆解设计稿结构。页面不再被当作一张扁平的图片,而是被识别为布局、容器、组件的有机组合。这一步至关重要,因为它直接决定了生成的代码是乱码还是人能看懂的逻辑。
二是直接生成可运行代码。不是零散的代码片段,而是可以在工程中运行、预览的完整结构。
三是覆盖主流技术栈与鸿蒙 ArkUI。对于多端项目,尤其是正在尝试鸿蒙生态的团队,这一点非常现实。
这类能力的价值,是把设计与开发之间最容易反复沟通、反复返工的那段“扯皮时间”,提前对齐了。
![]()
特别聊聊“鸿蒙代码”这个痛点
如果说 Web 或 App 开发中,UI 还原只是个“老慢难”的问题,那在鸿蒙 ArkUI 场景下,这个问题会被放大。很多开发者的直观感受是:ArkUI 的布局方式和传统前端差异不小,组件结构、状态管理、样式写法都有新的学习成本。设计稿稍微复杂一点,还原成本就会蹭蹭往上涨。设计师不懂ArkUI的组件限制,开发又不理解设计的视觉意图,两边很容易僵住。
墨刀 D2C 在这里,实际上充当了一个“翻译官”的角色。它把设计稿中的布局关系,准确映射成了 ArkUI 的标准结构。设计师画好符合鸿蒙规范的界面,系统就能生成符合 ArkTS 语法的代码。这个过程,直接让设计稿成了“可以直接运行”的中间成果。
对于开发人员来说,不需要再去纠结 ArkUI 里的容器嵌套该怎么写,直接拿着生成的代码微调逻辑就行。在目前鸿蒙生态急需快速铺量的背景下,这种降低门槛的“翻译”能力,切入点确实很精准。
![]()
设计与开发的协作正在改变
回过头看,从最早的手写标注,到现在的 UI 设计稿生成可运行代码,工具进化的本质,是让设计和开发的语言开始互通。你会发现,D2C 带来的最大改变,其实是设计交付物形态的演变。未来的产研交付,设计师给出去的可能不再是一堆静态的 PNG,而是一份某种程度上的可运行代码。
放在整个协作流程里看,墨刀 D2C 这次的动作,更像是在提前适配下一阶段的交付方式。至少在一些真实项目里,这条从设计到代码的自动化链路,已经开始站得住脚了。
特别声明:以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布,本平台仅提供信息存储服务。
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.