作為一個前端或管理者，您是否遇到過以下場景
- 作為前端老鳥照樣需要寫頁面佈局，雖然你已經寫了無數遍，但是效率和三年前的你差別不大
- 專案死亡線越來越近，而你還得出頁面/元件， 無法專注於業務邏輯
- 你已經費盡心力抽象了很多元件， 但還是發現很多頁面內容沒辦法用元件來表達，然後又開始寫頁面
- 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切圖， 不需要設計或開發手動切圖導圖
- 自動生成
iconsvg檔案， 可直接上傳到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或者加我微信討論。
同時， 該系列的文章也在列大綱梳理中，敬請期待