今年的主题叫「设计工程化三部曲」，我们想和大家聊聊在设计工程化视角下新的产研协同模式。我们将从点、线、面的维度，来阐述我们对于提升实际生产中多链路、多角色的“信息流转效率”的思考。那这也分别对应了是当下、即将和未来，我们的探索方向。
阶段一：C2D2C-CodetoDesign/DesigntoCode
首先让我们从点出发，聊聊C2D2C能力实现设计研发的低漏损协同。
我们都知道，在现在的产品协作流程中，有设计师和前端工程师两个相爱相杀的角色。设计前端的协作流程大致包含以下图中5个环节：
首先把视角聚焦给设计师，设计师常见的工作内容包含设计组件、使用组件、设计页面、交付设计。让我们进入「使用组件」来看下细节：我们会从Sketch的symbol库中拖出一个组件，那下面是它的属性面板，配置项非常混乱、难懂。
这个时候，设计师就会产生困惑：
如果他没法一下子找到这个问题的答案，同时他又觉得这个默认效果看起来不太满意的话，那么大概率就会开始放飞自我，设计出来一个自己觉得很棒的样式。然后交付给前端开发同学。
那再让我们再来看看交付设计的环节，前端同学在网页中查看设计稿时，也会产生困惑：
而当开发同学没法一下子找到这个结果的答案时，那么大概率他就会开始重复造轮子，写一个自己不会再维护和迭代的一次性组件。
所以，在使用组件和交付设计的两个环节，都会存在较为严重的信息漏损，使得协同链路中的信息流转不畅。
而这个根本原因，则是在实际的产里流程中，设计的工作与前端的工作事实上是在两个完全割裂的环境中进行的：
不「同源」，是混乱之始，漏损之根。
这个问题怎么解？
众所周知，在中后台领域，AntDesign的组件库在前端研发中相当成熟，基础设施非常完善。能极大程度地提升前端的研发效能。但是如此成熟好用的组件库却无法被设计师直接使用，实在遗憾。
就在某一个晚上，我们看着AntDesign官网文档边做设计边写代码的时候，一个念头突然涌现。这就是C2D2C的第一个闪念，那也是后续整个C2D2C的核心基石。
这个念头背后，是一个亟待开垦的新领域，叫做「前端代码转设计稿」，当然，字面意思，简称为C2D，这是我们解决同源问题的核心路径。
那前端代码到底该如何转成设计稿？中间的流程环节到底是怎么样的？当时的我其实一无所知。所幸的是，C2D的闪念不仅仅只有我们才有。在业界也有一些先行者，做了一些探索性的实践。
ReactSketchApp是由airbnb开源的一个前端模块，它可以让使用者通过写代码的方式来控制sketch中界面的渲染。只要通过修改代码的方式，就可以非常快速地完成设计稿的变更。他们用了一个很酷的说法，叫做PaintingwithCode，简单翻译过来就是，「用写代码的方式做设计」
ReactSketchapp是第一个真正实现了C2D能力的实践。可以说是打开了C2D这个领域的大门。甚至AntDesign中也有一个antd-sketchapp参考了这个模式，在早期的kitchen中进行了测试。当然，它又有很明显的局限性，最明显的一点就是，设计师不会写代码。那从第一步就阻塞了所有流程。当然，还有第二个小问题，就是前端同学需要为设计师定制专门的组件库。无法直接复用已有的代码。而这，更是使得它无法推广开来。
那看完这一个先行者，我们来看下一位——html-sketchapp。
htmlsketchapp是将任何一个网页转成sketch的模块。用户通过命令行的方式，输入一个网址，就可以拿到这个网站可编辑的sketch内容。因此它自称为「网页转为Sketch通用方案」。
那作为通用方案，它可以实现任何前端代码都能转为设计稿。但它并没有解决设计师如何使用的问题。它的使用流程过于晦涩，转换后的设计稿无法拿来直接使用。还原细节也不够精致。
总结一下，现在的C2D方案，都无法真正给到设计师可以直接消费的设计组件。都需要用「工程师」的方式来完成生成或转换。这也是理想与现实的鸿沟。
究其根源，还是因为这样的方案完全站在工程师的视角，没有考虑设计师的使用诉求。而我们兼具设计与前端开发的双重视角，站在设计与工程的十字路口，我们的探索思路与纯工程师的视角完全不同。
在我们看来，让C2D真正为设计师可用，还缺少一个核心的物件。那就是一个可视化面板。那这正需要Kitchen这个设计工具来承载。
在过去一年的探索中，我们从去年开始做了很多探索，例如网页组件转成sketch设计稿、前端组件转sketch的symbol、可视化面板的形态探索等等。
那这就是我们探索后的成果，KitchenC2D。它包含结合了Kitchen的组件面板，和AntDesign中的C2D组件。
在Kitchen组件面板的每一个配置项背后，都对应了一个前端组件的API，例如操作意图，就对应了danger，类型对应了type等等。而每一个API，都一定会存在相应的API的类型，比如字符串、布尔值、枚举值等等。而每一个类型，我们都可以用一个统一的属性可视化配置器来承载。
随着组件类型的增多，前端组件API数量也会增多。但任意一个前端组件的API，都是基础API类型的组合。而前端组件API的基础类型只有七八个左右。只要我们完成这几个基础类型的可视化配置器，并提供类型的组合与切换能力，便能用有限个数的属性配置器，承接所有前端组件的可视化配置。
所以利用这样的思路，我们就可以用一套设计方案，实现所有antd组件的可视化配置面板。
根据我们的计划，我们将在2022年中旬实现AntDesign组件库初步的全覆盖。
好的，回过来，我们再来看看这个属性面板。不知道懂前端的同学有没有发现。当我们的属性面板完整记录下来前端组件的API时，我们是不是就完全可以基于这几个API的属性，直接生成前端代码？
而这个又是我们的第二个关键领域，叫做设计稿转前端代码，简称为D2C。
D2C在业界已经有很多实践，但大部的代码生成都是如下图所示。在我们看来，现在的D2C，只做到了样式的转译。但对于交互设计来说，真正重要的是设计意图。比如为什么采用实色填充的按钮，为什么采用无边框的警告提示。
而下面这种代码，才是前端工程师在日常代码书写中的代码，它可以更加精准地表征设计意图。
我们认为，真正的D2C，不应该是「设计样式」转代码，而是「设计意图」转代码。样式只是「皮」，而设计意图才是「骨」。缺少了骨架的皮囊，一拉就散，一戳就破。
C2D组件的价值，除了在设计阶段为设计师提供配置项，提升设计效率以外，更重要的一点，则是还在于设计交付时提供几乎零损耗的「设计意图」。
再让我们回过来看一下之前遇到的问题，信息漏损的两大难题，我们分别使用C2D和D2C的两种思路有效解决。
最后，用一张大图来回顾整个第一趴的内容，那这就是我们在Kitchen中实现的C2D2C设计工程化。
第二阶段：ODS-OriginalDesignSystemWorkflow
现在让我们引入真实业务场景。实际业务中，完全使用原始AntDesign业务只占据一部分，常常需要对系统进行定制，比如圆角、颜色等。
然而，业务发展迫在眉睫，视觉诉求百花齐放。于是设计系统一个接一个的涌现，甚至成为妆点业务和设计团队门面的“必需品”。
在我们内部的资产管理中心，目前服务了200多个设计系统，沉淀了近20000多个组件。
可以说，这是一个设计系统Big-Bang的时代。
但是如此繁荣的表象下，设计中台却逐渐变成一个只出不进的孤岛。
实际业务中，就算改一个颜色和圆角，设计师都得从头开始维护一套自己的设计组件，同时下游的前端也得基于antd组件库二次开发，并很可能导致分叉，停留在一个早起的历史版本，无法做到业务组件增量更新和沉淀回流。逐渐的中台就变成了一座只出不进的“孤岛”。
在理想状态下，业务设计系统能够持续的跟随中台版本升级，享受到中台能力升级带来的技术升级与体验升级。但阶段一的C2D2C其实并无法解决上游的生产者从0搭建业务系统的问题。
那我们该怎么办？
C2D2C可以从根本上解决同源问题，但是并无法满足业务设计师从0搭建业务系统的诉求，我们缺少了最后一块拼图。那就是DesignToken。
Token不是个新名词。但是它作为历史的孤儿，设计师和前端的“假笑”链接，相信已经不需要再做描述，实际生产中的体验大家应该深有体会，antd几千行的less配置文件，谁用谁知道，除了恐怖的数量级，关系不清、功能抽象度不够的命名问题也写满了劝退。
其实不难发现，传统的Token应用有这么几方面的问题：
在这套Token体系上，我们将会建立基于AntDesign的通用主题编辑器，业务设计师能方便的通过可视化配置的方式，对AntDesign进行主题定制。
如图所示，在C2D2C的产研链路中，设计师在资产平台上通过主题配置工具，可以快速定义出自己业务域的设计资产，此时将自动生成并托管一份Token配置包，通过C2D的能力可以直接得到同源的设计资产和前端资产，告别从0起步，只需要聚焦于后续的增量更新。同时源于皮肤层的剥离，业务组件可以更方便的沉淀回流，保障健康生态；同时前端开发可以忽视样式层面的反复构建，专注于功能逻辑，解决和设计职能重叠。
那我们解决了方便定制与维护的问题，但是如何保证token的后续使用呢？我们都知道，传统Token另一个痛点是制定出来后很难在未来的设计研发中严格使用，意味的极高的成本，用过SketchTextStyle的设计师应该知道，找一个字体样式如同大海捞针，Token的角色也从提效变成了降效。因此人肉的规范是不可行的。
如何通过设计工程化的方式，让这些复杂的Token可用而不可见，得益于约定式Token，工具将可以在设计师交付环节将对应的数值替换成Token，即使有漏网之鱼，在前端研发环节也将通过Lint和智能提示的方式实现Token的便捷引入。
以上便是我们在「源系统工作流」中的探索，这将是我们今年（2022）的重点攻坚方向，而相应的能力也会伴随着AntDesign5.0的升级一并对外。
第三阶段：DCM-DistributedCollaborationModel
在更加复杂的商业项目中，往往还存在更多的角色，设计除了与前端的协同外，我们还会有与产品的协同，与运营的协同，还有后端、测试、PM、法务合规等等角色。
例如在我们的内部业务中，一个关于业务状态机的case，产品和运营一起协同维护了一张表，并要求设计侧完全同步维护一份对应状态机的设计稿，输出给前端。
每次业务迭代，PD和运营又分别要对文档做一次维护，设计再做一次维护，前端、后端再对应改一次。任何一次订单状态机的小小改动，都要从源头开始瀑布式地往下轮动变更。
造成这样多方角色的协作困局，根本原因在于瀑布式研发模式造成的职能错配和重叠，多个工种之间的只能深度耦合，互相牵制，重叠的部分带来了大量的重复劳动与沟通成本。
在过去的经历中，其实也有很多种尝试，比如教PD或运营同学用Sketch、研发想开发出PD、设计都能用的一站式lowcode平台，但大家都懂的，这些尝试的结果都一言难尽。
为什么呢？在现代的产研场景中，不同角色都有专属的协作平台，业务使用语雀维护产品文档，设计师使用Sketch完成设计，前端使用代码仓库，这些平台在各自的领域，针对各自领域提供了高效的工具和能力，做到了足够的高效。但是这些高效的工具和能力针对另外一个领域可能就是巨大的阻碍。
因此我们不能在如此宏观的协作层面寄希望于一站式的解决方案。
在我们看来，专业工作交给专业工具，让用户专注于自己的领域，分布式显然是更敏捷的选择。
一方面可控的学习成本可以让用户专注于自己的领域，PD不需要去了解Sketch、低代码平台怎么用，而只需要专注与语雀上的产品文档。另一方面，足够灵活的接入成本，可以让各个产物可以嵌入产研中的各种环节，如PRD、设计稿、交付文档、研发测试流程。
但在实际的业务场景中，只有研发才能接触到最终的产品源代码。
所以，在分布式产研模式的理念下，我们需要一个信息连接器，来沟通多方角色，让其可以直接沟通产品源码。
因此，我们不造轮子，而是造一条连接多方角色的「产研高速公路」。
以常见的表格编辑为例，在我们构想的场景下：
以上便是我们在「分布式协同模式」中的思考，在我们看来，这是指引设计工程化发展的关键思路。这样的产品应该长什么样，用户具体该如何使用，我们目前也没有一个明确的结论。但这也将在我们探索和前进的过程中，逐步得到答案。
设计工程化是一条晦涩且未知的道路，但我们相信只要把握住两个关键词，就能让我们的探索朝着正确的方向前行，这便是同源与无形。
同源共流，尚可百花齐放无形无印，方能变化万千
感谢与我们一同探索的小伙伴：@曼桃(mantao.tj)@豆酱(jilin.jjl)@辟起(shengtao.xst)@南取(binghui.dbh)
Kitchen3公网版在圣诞节已经正式发布。欢迎各位大厨前来体验~