作為一個前端或管理者，您是否遇到過以下場景

• 作為前端老鳥照樣需要寫頁面布局，雖然你已經寫了無數遍，但是效率和三年前的你差別不大
• 項目死亡線越來越近，而你還得出頁面/組件， 無法專注于業務邏輯
• 你已經費盡心力抽象了很多組件， 但還是發現很多頁面內容沒辦法用組件來表達，然后又開始寫頁面
• CTO/前端架構在試了所有的工程化、組件化方案后還苦于找不到前端有效提升產出的辦法
• 剛做完頁面， 老板/客戶/產品說這個頁面要改版/改交互…
• UI走查在一點點扣像素， 而你表示：我的心好累

是不是越看越痛心疾首？

但請問，你想過改變嗎？

你嘗試過去解決這些問題嗎？

為了徹底解決這些問題， 我做了深入而廣泛的調研和思考，從調研，預研，實踐，驗證已經有三年有余的時間了。

這里面結合SVG設計稿描述，系統字體識別和字蛛轉換，多種空間/特征算法，視覺識別，機器學習，DSL和AST轉換等多種技術，已經實現了從設計稿到前端頁面的順滑直出，并且對前端、設計、操作系統毫無侵入。

在項目實踐中，設計稿還原度中位數0.95，最高可達0.99， 復雜頁面代碼保留率70%，而且符合開發預期， 二開體驗一流。

解決方案傳送門：https://gitee.com/d2-c/lens

介紹

zuoyan lens是一個通過智能算法將設計稿轉換為前端頁面的產品（design to code），是低代碼平臺的一個分支方向， 他的輸入是設計稿產出是前端頁面，中間無需值守即可自動完成。

此項目可以一鍵將 Sketch、Photoshop 的設計稿轉換為可維護的前端代碼。100 個 page 的工作量 10 分鐘內即可輕松搞定，極大釋放前端生產力。

特點

生產級代碼

• 通過智能算法推算出和手寫代碼一樣的結構和css邏輯，產出的代碼約等于一個中級前端的水平
• 全flex布局
• 根據元素所處的環境， 自動修正像素誤差，符合設計表達。
• 代碼可閱讀、可維護.

智能切圖

• 自動生成透明png切圖， 不需要設計或開發手動切圖導圖
• 自動生成icon svg文件， 可直接上傳到iconfont等作為字體圖標使用，亦可轉為 svg 雪碧

自動檢測字體

• 自動檢測設計稿字體，如果字體缺失會自動提示安裝， 如果字體不一致會影響到頁面還原度，不方便安裝的字體，可以讓設計師或自行合并圖層

循環布局識別

• 自動識別list，grid等布局方式
• 獨有結點空間結構匹配算法，智能排除噪音元素干擾，精確推算循環體，而且性能表現優異

跨平臺，系統無關

• 兼容所有平臺，windows和linux上也可以解析Sketch文件

設計師學習成本為0

• 只需要準守正常的設計規范即可， 其他無任何要求

開放DSL轉換，可以自由定義輸出

• 采用GoGoCode來做AST轉換, 可以自由定義輸出語言，語法， 比如轉為：React， 微信原生，Vue，uniapp，Taro，RN等

還原度高

• 項目實測設計稿的還原度中位數為0.95，完全可以達到生產交付標準，極大降低 UI 走查成本

使用場景

移動端推薦， PC端暫無適配

• 移動端全頁面開發 - 特別推薦
• 移動端細粒度模塊開發場景 - 特別推薦
• 移動端活動頁 - 推薦

適用于什么群體

1，前端開發人員

2，業務運營人員

解決了什么問題

1，前端開發人員
前端開發可以快速完成頁面交付，不用擔心UI走查，專注頁面邏輯等核心問題，對于項目快速交付，減少技術債務等都有立竿見影的效果

2，業務運營人員
解決業務運營人員快速執行策劃落地，無須等待技術排期或技術短暫工期，可以極速完成創新、驗證、試錯的問題，

亦可快速創建體驗demo供客戶/老板體驗， 快速達成成交意向，或者減少返工等問題

技術難點

對于D2C類型的項目， 生成代碼的準確性、可用性和可維護性是成敗的關鍵，而設計稿的解析和推算本身就非常復雜。

這里只做簡單的羅列，不做細致的分析， 因為這個東西復雜度蠻高，沒有過經驗的人只會云里霧里摸不清頭腦,同時這些問題，我將出系列文章分享自己的經驗，歡迎大家討論

• 如果轉換設計稿為可分析的DSL和圖片用于智能算法識別，并且要系統無關
• 如何劃分盒子模型
• 如果定義絕對定位
• 如何處理字體
• 如果處理icon
• 如何識別相似結構，劃分循環單元
• 如何處理冗余圖層
• 組件識別如何足夠精確，機器學習在推導過程中的應用

先天不足：一個靜態的東西無法完全表達動態效果

因為設計稿是純靜態的， 所以想要表達動態交互效果就只能靠腦補。
目前來看, 無論是根據環境推導還是AI識別，效果都不理想。
這里面要分為多個場景來細說。

1，可以預先定義的動效交互，
這部分的動態效果可以通過組件識別來表達， 因為動效已經在組件里定義過了， 直接命中組件即可

2，可腦補但沒有預先定義或不能預先定義的
改造代碼，甚至重構布局結構，已經沒有什么方案可以解決了

3，產品或者UI不說， 前端根本就想不到的交互
這種的也沒辦法， 開發通過大腦都沒辦法命中， 更別提一個機器系統了

規劃

對于一個以降本增效為目標的項目來講： D2C只是其中的一環(雖然這一環就足夠掉頭發了)，后面的開發鏈路還有：

邏輯/事件編排

服務端數據理解

只有這兩塊內容完全開發完畢后，才能勉強說達到設計目標了，這個時候不管對開發還是產品、運營才算是一個完整的閉環鏈路， 慶幸的是， 這兩塊的算法復雜度沒有D2C環節的高

后續

對于開發者，這個開源項目（https://gitee.com/d2-c/lens ）， 完成度不能算是完美，歡迎大家使用，提issues或者加我微信討論。

同時， 該系列的文章也在列大綱梳理中，敬請期待

總結

以上是生活随笔為你收集整理的低代码开源， 一键设计稿生成代码，帮您解决生产痛点的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。