Projekty z Figmy zamieniane w gotowy do wdrożenia kod frontendu
Produkcyjny system, który zamienia projekty z Figmy w czysty, gotowy do wdrożenia kod frontendu — wielomodalny LLM działa na JSON pliku i jego wyrenderowanych pikselach, osadzony we wzorcach komponentów danego projektu.
- Stack
- Python · wielomodalny LLM · RAG · LangChain · Pydantic
- Zakres
- Generowanie kodu z projektu (design-to-code)
- Niezawodność
- ~15% rozjechanych klatek → wyłapane przez walidację pixel-diff
Plik Figmy to nie specyfikacja — to niejednoznaczny zbiór wskazówek
Większość narzędzi design-to-code ignoruje to samo: plik Figmy nie jest specyfikacją, tylko zbiorem wizualnych wskazówek. Przyciski nie mają nazw semantycznych. Design tokens żyją w osobnej bibliotece. Reguły auto-layoutu znaczą co innego w różnych kontekstach, a projekt zostawia to wszystko domyślne.
Skieruj na tę niejednoznaczność zwykły LLM, a wypełni luki zgadywaniem. Halucynuje nazwy klas, wymyśla propy, które nie istnieją, i produkuje kod, który renderuje się źle już przy pierwszym uruchomieniu. Wynik wygląda wiarygodnie i wykłada się na review — co jest gorsze niż brak wyniku.
Dwa sygnały — JSON i vision — łączone przed generowaniem
System parsuje JSON eksportowany z Figmy i wyciąga hierarchię komponentów, design tokens oraz reguły constraintów. Warstwa RAG pobiera następnie pasujące wzorce komponentów z bazy wiedzy specyficznej dla danego repozytorium, więc model generuje kod zgodny z istniejącymi konwencjami projektu, a nie generyczny boilerplate.
Równolegle wielomodalny vision działa na wyrenderowanej klatce i wyłapuje to, co JSON pomija — nachodzące się elementy, rytm wizualny, breakpointy responsywne. Oba sygnały są łączone przed generowaniem, a ustrukturyzowane wyjścia przez Pydantic wymuszają, że każda nazwa komponentu, prop i import się resolvują, zanim powstanie jakikolwiek plik.
Zagnieżdżone komponenty i fix, który je oswoił
Zagnieżdżone komponenty były najtrudniejszym przypadkiem na produkcji. Gdy karta zawiera badge, który zawiera ikonę, okno kontekstu wypełnia się szumem komponentu-rodzica, a model zaczyna wymyślać nazwy propów, żeby połączyć to, czego już wyraźnie nie widzi.
Fixem był hierarchiczny chunking: najpierw generujemy komponenty liściowe, cache'ujemy ich schematy i wstrzykujemy do kontekstu rodzica tylko właściwy interfejs. Rodzic nie rozumuje już nad surowymi dziećmi — rozumuje nad ich zresolvowanymi kontraktami, a wymyślane propy przestają się pojawiać.
Nic nie trafia dalej, dopóki piksele się nie zgadzają
Między generowaniem a dostarczeniem stoją dwie bramki. Pierwszą wymusza Pydantic: każda nazwa komponentu, prop i import muszą się resolvować, zanim powstanie plik, więc strukturalnie zepsuty kod nigdy nie opuszcza pipeline'u.
Druga bramka jest wizualna. Skrajne przypadki auto-layoutu powodowały rozjechany wynik w ~15% klatek, więc krok walidacji renderuje wygenerowany kod headlessowo i porównuje piksele z oryginalną klatką. Niepowodzenia wracają do kolejki z diffem jako dodatkowym kontekstem, więc model poprawia się względem konkretnej rozbieżności, a nie zgaduje ponownie. Klient dostaje kod, o którym już wiadomo, że renderuje się tak jak projekt, a działa to tylko dlatego, że błędny wynik jest tu wykrywalny maszynowo, a nie kwestią wyczucia.
Zobacz, jak wyglądałoby to w Twoich procesach.
30 minut · wskazujemy 3 najlepsze obszary do automatyzacji · bez zobowiązań