本文為 SEE Conf 2022 設(shè)計(jì)場(chǎng)分享《設(shè)計(jì)工程化三部曲》，整理成稿。

《設(shè)計(jì)工程化三部曲》將和大家分享我們探索現(xiàn)代化產(chǎn)研協(xié)同模式 「C2D2C」 中的思考與實(shí)踐。我們將從單點(diǎn)效能、設(shè)計(jì)前端協(xié)作、全流程協(xié)同三個(gè)維度，層層遞進(jìn)地介紹實(shí)際設(shè)計(jì)生產(chǎn)消費(fèi)中多鏈路、多角色“信息流轉(zhuǎn)效率”的相關(guān)案例。

本次我們的主題是「設(shè)計(jì)工程化三部曲」，主要是想和大家分享我們?cè)谔剿餍颅h(huán)境下“產(chǎn)研協(xié)同模式”中的思考，以及通過設(shè)計(jì)工程化的方式，從點(diǎn)線面維度提升實(shí)際生產(chǎn)中多鏈路、多角色“信息流轉(zhuǎn)效率”的相關(guān)實(shí)踐。

在去年 SEE Conf 大會(huì)中，我們分享過 Ant Design 中早期的設(shè)計(jì)工程化實(shí)踐，如何讓設(shè)計(jì)體系背后隱形的設(shè)計(jì)規(guī)則可用而不可見。并很高興看到了在語雀/知乎上對(duì)該領(lǐng)域的后續(xù)探討。

今年的主題叫「設(shè)計(jì)工程化三部曲」，我們想和大家聊聊在設(shè)計(jì)工程化視角下新的產(chǎn)研協(xié)同模式。我們將從點(diǎn)、線、面的維度，來闡述我們對(duì)于提升實(shí)際生產(chǎn)中多鏈路、多角色的 “信息流轉(zhuǎn)效率”的思考。那這也分別對(duì)應(yīng)了是當(dāng)下、即將和未來，我們的探索方向。

點(diǎn) | 設(shè)計(jì)工程化下的低漏損協(xié)同

階段一：C2D2C - Code to Design / Design to Code

首先讓我們從點(diǎn)出發(fā)，聊聊 C2D2C 能力實(shí)現(xiàn)設(shè)計(jì)研發(fā)的低漏損協(xié)同。

我們都知道，在現(xiàn)在的產(chǎn)品協(xié)作流程中，有設(shè)計(jì)師和前端工程師兩個(gè)相愛相殺的角色。設(shè)計(jì)前端的協(xié)作流程大致包含以下圖中5個(gè)環(huán)節(jié)：

首先把視角聚焦給設(shè)計(jì)師，設(shè)計(jì)師常見的工作內(nèi)容包含 設(shè)計(jì)組件、使用組件、設(shè)計(jì)頁面、交付設(shè)計(jì)。讓我們進(jìn)入「使用組件」來看下細(xì)節(jié)：我們會(huì)從 Sketch 的 symbol 庫中拖出一個(gè)組件，那下面是它的屬性面板，配置項(xiàng)非?；靵y、難懂。

這個(gè)時(shí)候，設(shè)計(jì)師就會(huì)產(chǎn)生困惑：

• 這個(gè)組件有沒有設(shè)計(jì)規(guī)范？
• 我可以改成什么樣呢？

如果他沒法一下子找到這個(gè)問題的答案，同時(shí)他又覺得這個(gè)默認(rèn)效果看起來不太滿意的話，那么大概率就會(huì)開始放飛自我，設(shè)計(jì)出來一個(gè)自己覺得很棒的樣式。然后交付給前端開發(fā)同學(xué)。

那再讓我們?cè)賮砜纯唇桓对O(shè)計(jì)的環(huán)節(jié)，前端同學(xué)在網(wǎng)頁中查看設(shè)計(jì)稿時(shí)，也會(huì)產(chǎn)生困惑：

• 這個(gè)設(shè)計(jì)稿和我平時(shí)用的組件怎么不太一樣？
• 我是要自己寫一個(gè)，還是能基于組件配置項(xiàng)配出來嗎？

而當(dāng)開發(fā)同學(xué)沒法一下子找到這個(gè)結(jié)果的答案時(shí)，那么大概率他就會(huì)開始重復(fù)造輪子，寫一個(gè)自己不會(huì)再維護(hù)和迭代的一次性組件。

所以，在使用組件和交付設(shè)計(jì)的兩個(gè)環(huán)節(jié)，都會(huì)存在較為嚴(yán)重的信息漏損，使得協(xié)同鏈路中的信息流轉(zhuǎn)不暢。

而這個(gè)根本原因，則是在實(shí)際的產(chǎn)里流程中，設(shè)計(jì)的工作與前端的工作事實(shí)上是在兩個(gè)完全割裂的環(huán)境中進(jìn)行的：

• 設(shè)計(jì)側(cè)產(chǎn)出設(shè)計(jì)組件庫，以 sketch symbol 的形式，給到業(yè)務(wù)設(shè)計(jì)師進(jìn)行消費(fèi)；
• 開發(fā)側(cè)產(chǎn)出前端組件庫，以 npm 包的形式，給到業(yè)務(wù)前端消費(fèi)；

不「同源」，是混亂之始，漏損之根。

C2D2C的閃念

這個(gè)問題怎么解？

眾所周知，在中后臺(tái)領(lǐng)域， Ant Design 的組件庫在前端研發(fā)中相當(dāng)成熟，基礎(chǔ)設(shè)施非常完善。能極大程度地提升前端的研發(fā)效能。但是如此成熟好用的組件庫卻無法被設(shè)計(jì)師直接使用，實(shí)在遺憾。

就在某一個(gè)晚上，我們看著 Ant Design 官網(wǎng)文檔邊做設(shè)計(jì)邊寫代碼的時(shí)候，一個(gè)念頭突然涌現(xiàn)。這就是 C2D2C 的第一個(gè)閃念，那也是后續(xù)整個(gè) C2D2C 的核心基石。

C2D：前端代碼轉(zhuǎn)設(shè)計(jì)稿

這個(gè)念頭背后，是一個(gè)亟待開墾的新領(lǐng)域，叫做「前端代碼轉(zhuǎn)設(shè)計(jì)稿」，當(dāng)然，字面意思，簡(jiǎn)稱為 C2D，這是我們解決同源問題的核心路徑。

那前端代碼到底該如何轉(zhuǎn)成設(shè)計(jì)稿？中間的流程環(huán)節(jié)到底是怎么樣的？當(dāng)時(shí)的我其實(shí)一無所知。所幸的是，C2D的閃念不僅僅只有我們才有。在業(yè)界也有一些先行者，做了一些探索性的實(shí)踐。

React Sketch App 是由 airbnb 開源的一個(gè)前端模塊，它可以讓使用者通過寫代碼的方式來控制 sketch 中界面的渲染。只要通過修改代碼的方式，就可以非?？焖俚赝瓿稍O(shè)計(jì)稿的變更。他們用了一個(gè)很酷的說法，叫做 Painting with Code，簡(jiǎn)單翻譯過來就是，「用寫代碼的方式做設(shè)計(jì)」

React Sketchapp 是第一個(gè)真正實(shí)現(xiàn)了 C2D 能力的實(shí)踐?？梢哉f是打開了 C2D 這個(gè)領(lǐng)域的大門。甚至 Ant Design 中也有一個(gè) antd-sketchapp 參考了這個(gè)模式，在早期的 kitchen 中進(jìn)行了測(cè)試。當(dāng)然，它又有很明顯的局限性，最明顯的一點(diǎn)就是，設(shè)計(jì)師不會(huì)寫代碼。那從第一步就阻塞了所有流程。當(dāng)然，還有第二個(gè)小問題，就是前端同學(xué)需要為設(shè)計(jì)師定制專門的組件庫。無法直接復(fù)用已有的代碼。而這，更是使得它無法推廣開來。

那看完這一個(gè)先行者，我們來看下一位 —— html-sketchapp。

html sketchapp 是將任何一個(gè)網(wǎng)頁轉(zhuǎn)成 sketch 的模塊。用戶通過命令行的方式，輸入一個(gè)網(wǎng)址，就可以拿到這個(gè)網(wǎng)站可編輯的 sketch 內(nèi)容。因此它自稱為「網(wǎng)頁轉(zhuǎn)為 Sketch 通用方案」。

那作為通用方案，它可以實(shí)現(xiàn)任何前端代碼都能轉(zhuǎn)為設(shè)計(jì)稿。但它并沒有解決設(shè)計(jì)師如何使用的問題。它的使用流程過于晦澀，轉(zhuǎn)換后的設(shè)計(jì)稿無法拿來直接使用。還原細(xì)節(jié)也不夠精致。

總結(jié)一下，現(xiàn)在的C2D方案，都無法真正給到設(shè)計(jì)師可以直接消費(fèi)的設(shè)計(jì)組件。都需要用「工程師」的方式來完成生成或轉(zhuǎn)換。這也是理想與現(xiàn)實(shí)的鴻溝。

究其根源，還是因?yàn)檫@樣的方案完全站在工程師的視角，沒有考慮設(shè)計(jì)師的使用訴求。而我們兼具設(shè)計(jì)與前端開發(fā)的雙重視角，站在設(shè)計(jì)與工程的十字路口，我們的探索思路與純工程師的視角完全不同。

在我們看來，讓 C2D 真正為設(shè)計(jì)師可用，還缺少一個(gè)核心的物件。那就是一個(gè)可視化面板。那這正需要 Kitchen 這個(gè)設(shè)計(jì)工具來承載。

在過去一年的探索中，我們從去年開始做了很多探索，例如網(wǎng)頁組件轉(zhuǎn)成sketch設(shè)計(jì)稿、前端組件轉(zhuǎn)sketch的symbol、可視化面板的形態(tài)探索等等。

那這就是我們探索后的成果， Kitchen C2D。它包含結(jié)合了 Kitchen 的組件面板，和 Ant Design 中的 C2D組件。

在 Kitchen 組件面板的每一個(gè)配置項(xiàng)背后，都對(duì)應(yīng)了一個(gè)前端組件的API，例如操作意圖，就對(duì)應(yīng)了 danger，類型對(duì)應(yīng)了 type等等。而每一個(gè) API，都一定會(huì)存在相應(yīng)的API的類型，比如字符串、布爾值、枚舉值等等。而每一個(gè)類型，我們都可以用一個(gè)統(tǒng)一的屬性可視化配置器來承載。

隨著組件類型的增多，前端組件API數(shù)量也會(huì)增多。但任意一個(gè)前端組件的 API，都是基礎(chǔ) API 類型的組合。而前端組件 API 的基礎(chǔ)類型只有七八個(gè)左右。只要我們完成這幾個(gè)基礎(chǔ)類型的可視化配置器，并提供類型的組合與切換能力，便能用有限個(gè)數(shù)的屬性配置器，承接所有前端組件的可視化配置。

所以利用這樣的思路，我們就可以用一套設(shè)計(jì)方案，實(shí)現(xiàn)所有 antd 組件的可視化配置面板。

根據(jù)我們的計(jì)劃，我們將在2022年中旬實(shí)現(xiàn) Ant Design 組件庫初步的全覆蓋。

D2C：設(shè)計(jì)「意圖」 轉(zhuǎn)前端「代碼」

好的，回過來，我們?cè)賮砜纯催@個(gè)屬性面板。不知道懂前端的同學(xué)有沒有發(fā)現(xiàn)。當(dāng)我們的屬性面板完整記錄下來前端組件的 API 時(shí)，我們是不是就完全可以基于這幾個(gè) API的屬性，直接生成前端代碼？

而這個(gè)又是我們的第二個(gè)關(guān)鍵領(lǐng)域，叫做設(shè)計(jì)稿轉(zhuǎn)前端代碼，簡(jiǎn)稱為 D2C。

D2C在業(yè)界已經(jīng)有很多實(shí)踐，但大部的代碼生成都是如下圖所示。在我們看來，現(xiàn)在的D2C，只做到了樣式的轉(zhuǎn)譯。但對(duì)于交互設(shè)計(jì)來說，真正重要的是設(shè)計(jì)意圖。比如為什么采用實(shí)色填充的按鈕，為什么采用無邊框的警告提示。

除了「美感」以外，設(shè)計(jì)更應(yīng)該關(guān)注向用戶傳遞怎么樣的「設(shè)計(jì)意圖」。而單純的像素級(jí)樣式還原，最終生成的代碼始終是一次性代碼，缺少可維護(hù)性。

而下面這種代碼，才是前端工程師在日常代碼書寫中的代碼，它可以更加精準(zhǔn)地表征設(shè)計(jì)意圖。

我們認(rèn)為，真正的 D2C，不應(yīng)該是「設(shè)計(jì)樣式」轉(zhuǎn)代碼，而是「設(shè)計(jì)意圖」轉(zhuǎn)代碼。樣式只是「皮」，而設(shè)計(jì)意圖才是「骨」。缺少了骨架的皮囊，一拉就散，一戳就破。

C2D 組件的價(jià)值，除了在設(shè)計(jì)階段為設(shè)計(jì)師提供配置項(xiàng)，提升設(shè)計(jì)效率以外，更重要的一點(diǎn)，則是還在于設(shè)計(jì)交付時(shí)提供幾乎零損耗的「設(shè)計(jì)意圖」。

只要在 Kitchen 中打開「D2C」面板（需要在設(shè)置中開啟「開發(fā)者模式」），選中 C2D 組件，該組件相關(guān)的代碼信息就會(huì)完整地展示出來。

如果你是用 Kitchen 的交付工具，在本地預(yù)覽時(shí)也可以查看到組件庫信息和組件代碼，進(jìn)而幫助前端同學(xué)完美還原設(shè)計(jì)意圖。只要選中配置好的 C2D 組件，該組件相關(guān)的代碼信息就會(huì)完整地展示出來。

小結(jié)

再讓我們回過來看一下之前遇到的問題，信息漏損的兩大難題，我們分別使用 C2D 和 D2C 的兩種思路有效解決。

最后，用一張大圖來回顧整個(gè)第一趴的內(nèi)容，那這就是我們?cè)贙itchen中實(shí)現(xiàn)的 C2D2C 設(shè)計(jì)工程化。

線 | 同源讓設(shè)計(jì)中臺(tái)走出孤島

第二階段：ODS - Original Design System Workflow

中臺(tái) 孤島

現(xiàn)在讓我們引入真實(shí)業(yè)務(wù)場(chǎng)景。實(shí)際業(yè)務(wù)中，完全使用原始 Ant Design 業(yè)務(wù)只占據(jù)一部分，常常需要對(duì)系統(tǒng)進(jìn)行定制，比如圓角、顏色等。

在設(shè)計(jì)工具中，一個(gè)覆蓋所有使用場(chǎng)景的按鈕，可能最多需要 1000 多個(gè)相關(guān)的狀態(tài)。 由此可見， 0-1 創(chuàng)建業(yè)務(wù)設(shè)計(jì)系統(tǒng)成本很高，做到完善難度更大，隨之而來的是產(chǎn)生大量 “換皮” 但在組件層面高重合度的影子系統(tǒng)。這將為業(yè)務(wù)設(shè)計(jì)團(tuán)隊(duì)帶來極低 ROI 的重復(fù)建設(shè)和維護(hù)成本。

然而，業(yè)務(wù)發(fā)展迫在眉睫，視覺訴求百花齊放。于是設(shè)計(jì)系統(tǒng)一個(gè)接一個(gè)的涌現(xiàn)，甚至成為妝點(diǎn)業(yè)務(wù)和設(shè)計(jì)團(tuán)隊(duì)門面的 “必需品”。

在我們內(nèi)部的資產(chǎn)管理中心，目前服務(wù)了 200 多個(gè)設(shè)計(jì)系統(tǒng)，沉淀了近 20000 多個(gè)組件。

可以說，這是一個(gè)設(shè)計(jì)系統(tǒng) Big-Bang 的時(shí)代。

但是如此繁榮的表象下，設(shè)計(jì)中臺(tái)卻逐漸變成一個(gè)只出不進(jìn)的孤島。

實(shí)際業(yè)務(wù)中，就算改一個(gè)顏色和圓角，設(shè)計(jì)師都得從頭開始維護(hù)一套自己的設(shè)計(jì)組件，同時(shí)下游的前端也得基于 antd 組件庫二次開發(fā)，并很可能導(dǎo)致分叉，停留在一個(gè)早起的歷史版本，無法做到業(yè)務(wù)組件增量更新和沉淀回流。逐漸的中臺(tái)就變成了一座只出不進(jìn)的“孤島”。

在理想狀態(tài)下，業(yè)務(wù)設(shè)計(jì)系統(tǒng)能夠持續(xù)的跟隨中臺(tái)版本升級(jí)，享受到中臺(tái)能力升級(jí)帶來的技術(shù)升級(jí)與體驗(yàn)升級(jí)。但階段一的 C2D2C 其實(shí)并無法解決上游的生產(chǎn)者從 0 搭建業(yè)務(wù)系統(tǒng)的問題。

那我們?cè)撛趺崔k？

走出「孤島」的最后一塊拼圖

C2D2C可以從根本上解決同源問題，但是并無法滿足業(yè)務(wù)設(shè)計(jì)師從 0 搭建業(yè)務(wù)系統(tǒng)的訴求，我們?nèi)鄙倭俗詈笠粔K拼圖。那就是 Design Token。

Token不是個(gè)新名詞。但是 它作為歷史的孤兒，設(shè)計(jì)師和前端的“假笑”鏈接，相信已經(jīng)不需要再做描述，實(shí)際生產(chǎn)中的體驗(yàn)大家應(yīng)該深有體會(huì)，antd 幾千行的 less 配置文件，誰用誰知道，除了恐怖的數(shù)量級(jí)，關(guān)系不清、功能抽象度不夠的命名問題也寫滿了勸退。

Make Token Great Again

結(jié)合設(shè)計(jì)工程化相關(guān)探索，我們希望讓 Design Token 再次偉大。

其實(shí)不難發(fā)現(xiàn)，傳統(tǒng)的 Token 應(yīng)用有這么幾方面的問題：

• 通用性與規(guī)范：如何保障寫出讓人看懂、甚至能讓機(jī)器看懂的 Token？
• 定義與維護(hù)：如何讓任何一名業(yè)務(wù)設(shè)計(jì)師都可以快速創(chuàng)建業(yè)務(wù)專屬的設(shè)計(jì)系統(tǒng)？
• 保障后續(xù)使用：如何保障在業(yè)務(wù)消費(fèi)環(huán)節(jié)，可以保障 token 規(guī)范消費(fèi)？

經(jīng)過長(zhǎng)時(shí)間的探索，我們定制出一套可計(jì)算可生長(zhǎng)的 Token System。目前這套體系目前正在專利審核期，后續(xù)將會(huì)逐漸向外披露。

在這套 Token 體系上，我們將會(huì)建立基于 Ant Design 的通用主題編輯器，業(yè)務(wù)設(shè)計(jì)師能方便的通過可視化配置的方式，對(duì) Ant Design 進(jìn)行主題定制。

如圖所示，在 C2D2C 的產(chǎn)研鏈路中，設(shè)計(jì)師在資產(chǎn)平臺(tái)上通過主題配置工具，可以快速定義出自己業(yè)務(wù)域的設(shè)計(jì)資產(chǎn)，此時(shí)將自動(dòng)生成并托管一份 Token 配置包，通過 C2D 的能力可以直接得到同源的設(shè)計(jì)資產(chǎn)和前端資產(chǎn)，告別從 0 起步，只需要聚焦于后續(xù)的增量更新。同時(shí)源于皮膚層的剝離，業(yè)務(wù)組件可以更方便的沉淀回流，保障健康生態(tài)；同時(shí)前端開發(fā)可以忽視樣式層面的反復(fù)構(gòu)建，專注于功能邏輯，解決和設(shè)計(jì)職能重疊。

那我們解決了方便定制與維護(hù)的問題，但是如何保證 token 的后續(xù)使用呢？我們都知道，傳統(tǒng) Token 另一個(gè)痛點(diǎn)是制定出來后很難在未來的設(shè)計(jì)研發(fā)中嚴(yán)格使用，意味的極高的成本，用過 Sketch Text Style 的設(shè)計(jì)師應(yīng)該知道，找一個(gè)字體樣式如同大海撈針，Token 的角色也從提效變成了降效。因此人肉的規(guī)范是不可行的。

如何通過設(shè)計(jì)工程化的方式，讓這些復(fù)雜的 Token 可用而不可見，得益于約定式 Token，工具將可以在設(shè)計(jì)師交付環(huán)節(jié)將對(duì)應(yīng)的數(shù)值替換成 Token，即使有漏網(wǎng)之魚，在前端研發(fā)環(huán)節(jié)也將通過 Lint 和智能提示的方式實(shí)現(xiàn) Token 的便捷引入。

小結(jié)

以上便是我們?cè)凇冈聪到y(tǒng)工作流」中的探索，這將是我們今年（2022）的重點(diǎn)攻堅(jiān)方向，而相應(yīng)的能力也會(huì)伴隨著 Ant Design 5.0 的升級(jí)一并對(duì)外。

面 | 分布式產(chǎn)研協(xié)同高速公路

第三階段：DCM - Distributed Collaboration Model

現(xiàn)代業(yè)務(wù)協(xié)作困局

在更加復(fù)雜的商業(yè)項(xiàng)目中，往往還存在更多的角色，設(shè)計(jì)除了與前端的協(xié)同外，我們還會(huì)有與產(chǎn)品的協(xié)同，與運(yùn)營(yíng)的協(xié)同，還有后端、測(cè)試、PM、法務(wù)合規(guī)等等角色。

例如在我們的內(nèi)部業(yè)務(wù)中，一個(gè)關(guān)于業(yè)務(wù)狀態(tài)機(jī)的case，產(chǎn)品和運(yùn)營(yíng)一起協(xié)同維護(hù)了一張表，并要求設(shè)計(jì)側(cè)完全同步維護(hù)一份對(duì)應(yīng)狀態(tài)機(jī)的設(shè)計(jì)稿，輸出給前端。

每次業(yè)務(wù)迭代，PD和運(yùn)營(yíng)又分別要對(duì)文檔做一次維護(hù)，設(shè)計(jì)再做一次維護(hù)，前端、后端再對(duì)應(yīng)改一次。任何一次訂單狀態(tài)機(jī)的小小改動(dòng)，都要從源頭開始瀑布式地往下輪動(dòng)變更。

造成這樣多方角色的協(xié)作困局，根本原因在于瀑布式研發(fā)模式造成的職能錯(cuò)配和重疊，多個(gè)工種之間的只能深度耦合，互相牽制，重疊的部分帶來了大量的重復(fù)勞動(dòng)與溝通成本。

一站式 vs 分布式

在過去的經(jīng)歷中，其實(shí)也有很多種嘗試，比如教 PD或運(yùn)營(yíng)同學(xué) 用Sketch、研發(fā)想開發(fā)出 PD、設(shè)計(jì)都能用的一站式 lowcode 平臺(tái)，但大家都懂的，這些嘗試的結(jié)果都一言難盡。

為什么呢？在現(xiàn)代的產(chǎn)研場(chǎng)景中，不同角色都有專屬的協(xié)作平臺(tái)，業(yè)務(wù)使用語雀維護(hù)產(chǎn)品文檔，設(shè)計(jì)師使用Sketch完成設(shè)計(jì)，前端使用代碼倉庫，這些平臺(tái)在各自的領(lǐng)域，針對(duì)各自領(lǐng)域提供了高效的工具和能力，做到了足夠的高效。但是這些高效的工具和能力針對(duì)另外一個(gè)領(lǐng)域可能就是巨大的阻礙。

因此我們不能在如此宏觀的協(xié)作層面寄希望于一站式的解決方案。

分布式產(chǎn)研協(xié)同高速公路

在我們看來，專業(yè)工作交給專業(yè)工具，讓用戶專注于自己的領(lǐng)域，分布式顯然是更敏捷的選擇。

一方面可控的學(xué)習(xí)成本可以讓用戶專注于自己的領(lǐng)域，PD 不需要去了解Sketch、低代碼平臺(tái)怎么用，而只需要專注與語雀上的產(chǎn)品文檔。另一方面，足夠靈活的接入成本，可以讓各個(gè)產(chǎn)物可以嵌入產(chǎn)研中的各種環(huán)節(jié)，如 PRD、設(shè)計(jì)稿、交付文檔、研發(fā)測(cè)試流程 。

但在實(shí)際的業(yè)務(wù)場(chǎng)景中，只有研發(fā)才能接觸到最終的產(chǎn)品源代碼。

所以，在分布式產(chǎn)研模式的理念下，我們需要一個(gè)信息連接器，來溝通多方角色，讓其可以直接溝通產(chǎn)品源碼。

因此，我們不造輪子，而是造一條連接多方角色的「產(chǎn)研高速公路」。

以常見的表格編輯為例，在我們構(gòu)想的場(chǎng)景下：

• 產(chǎn)品：產(chǎn)品同學(xué)可以在語雀上上快速完成表格的初步繪制，例如我們會(huì)提供一鍵復(fù)制表格的功能，讓 PD 快速完成表格的初步設(shè)計(jì)；
• 設(shè)計(jì)：在產(chǎn)品完成表格字段的確認(rèn)后，設(shè)計(jì)師可以在 Kitchen 中一鍵同步ADS 上的項(xiàng)目，并基于此配置項(xiàng)完成設(shè)計(jì)側(cè)的加工。并基于 C2D 置入到自己的設(shè)計(jì)稿中；
• 開發(fā)：當(dāng)設(shè)計(jì)師完成表格的設(shè)計(jì)后，便可將配置導(dǎo)出給前端同學(xué)。此時(shí)前端同學(xué)只需將此表格快速關(guān)聯(lián)到后端接口，并綁定數(shù)據(jù)源，我們就會(huì)將表格的前端代碼自動(dòng)生成出來。然后前端同學(xué)可以選擇采用自己習(xí)慣的方式，將代碼置入到研發(fā)的項(xiàng)目中。

小結(jié)

以上便是我們?cè)凇阜植际絽f(xié)同模式」中的思考，在我們看來，這是指引設(shè)計(jì)工程化發(fā)展的關(guān)鍵思路。這樣的產(chǎn)品應(yīng)該長(zhǎng)什么樣，用戶具體該如何使用，我們目前也沒有一個(gè)明確的結(jié)論。但這也將在我們探索和前進(jìn)的過程中，逐步得到答案。

總結(jié)

同源與無形

設(shè)計(jì)工程化是一條晦澀且未知的道路，但我們相信只要把握住兩個(gè)關(guān)鍵詞，就能讓我們的探索朝著正確的方向前行，這便是同源與無形。

最后，我們想用兩句話結(jié)束今天關(guān)于設(shè)計(jì)工程化相關(guān)的分享：

同源共流，尚可百花齊放
無形無印，方能變化萬千