23 lip 2025·8 min
Jak AI odczytuje układ i intencje, aby przekształcić projekty w kod UI
Dowiedz się, jak AI wyciąga układ, hierarchię i intencję z projektów, a następnie generuje kod UI — plus ograniczenia, dobre praktyki i wskazówki przeglądu.
Dowiedz się, jak AI wyciąga układ, hierarchię i intencję z projektów, a następnie generuje kod UI — plus ograniczenia, dobre praktyki i wskazówki przeglądu.
„Design to code” AI tłumaczy wizualny pomysł projektu — zwykle ramkę Figma lub screenshot — na wykonywalny kod UI. Chodzi nie o „perfekcyjny kod”, lecz o użyteczny pierwszy szkic, który uchwyci strukturę, style i podstawowe zachowanie, aby człowiek mógł go dopracować.
W istocie system mapuje to, co może zaobserwować, na sposób, w jaki UI są zazwyczaj budowane.
AI może rozpoznać powszechne wzorce: rząd ikon to prawdopodobnie pasek narzędzi; etykieta + pole w stosie to prawdopodobnie pole formularza; spójne style sugerują komponent do ponownego użycia. Może też odgadnąć zachowanie responsywne na podstawie constraints i odstępów.
Ale zwykle musisz określić to, czego piksele nie gwarantują: rzeczywiste nazwy komponentów, tokeny projektowe (kolory/skale typografii), stany (hover/disabled/error), punkty przerwania, reguły danych i faktyczne interakcje (walidacja, cele nawigacji, analityka).
Traktuj wynik jako punkt wyjścia. Spodziewaj się sprawdzenia struktury, zastąpienia ad-hoc stylów tokenami, dopasowania do biblioteki komponentów i iteracji. „Design to code” to przyspieszenie — nie automatyzacja, która eliminuje potrzebę sądu projektowego i inżynierskiego.
AI nie wyczyta reguł produktu z „ładnego ekranu”. Działa na podstawie dowodów, które mu dostarczysz — niektóre wejścia opisują piksele, inne strukturę. Ta różnica często decyduje, czy otrzymasz czysty kod UI, czy kruche pozycjonowanie absolutne.
Screenshot to najsłabsze wejście: zawiera kolory i kształty, ale brak w nim jednoznacznych informacji, co jest przyciskiem, a co etykietą, co jest wielokrotnego użytku, lub jak układ ma się dopasowywać.
Na podstawie samych pikseli AI musi zgadywać granice elementów (gdzie kończy się jeden element i zaczyna drugi), style tekstu, reguły odstępów, a nawet czy „karta” to jeden komponent czy kilka oddzielnych fragmentów. Nie potrafi też wywnioskować constraints — więc zachowanie responsywne to w dużej mierze domysły.
Kiedy AI ma dostęp do pliku projektu (lub eksportu zachowującego strukturę), zyskuje kluczowe metadane: ramki, grupy, nazwy warstw, ustawienia Auto Layout, constraints i definicje tekstów/stylów.
Wtedy układ staje się czymś więcej niż geometrią. Na przykład ramka Figma z Auto Layout komunikuje intencję typu „ustaw te elementy pionowo z odstępem 16px” znacznie lepiej niż jakikolwiek screenshot. Spójne nazwy warstw też pomagają mapować elementy na role UI (np. „Primary Button”, „Nav Item”, „Input/Error”).
Powiązany system projektowy zmniejsza liczbę domysłów. Tokeny (kolory, odstępy, typografia) pozwalają AI generować kod odwołujący się do wspólnego źródła prawdy zamiast wartości zakodowanych na stałe. Opublikowane komponenty (przyciski, pola, modale) dają gotowe bloki i wyraźniejsze granice dla ponownego użycia.
Nawet małe konwencje — jak nazwy wariantów (Button/Primary, Button/Secondary) i użycie semantycznych tokenów (text/primary zamiast #111111) — poprawiają mapowanie komponentów.
Specyfikacje dodają „dlaczego” stojące za UI: zachowanie hover, stany ładowania i puste, reguły walidacji, zachowanie klawiatury i komunikaty o błędach.
Bez tego AI ma tendencję do generowania statycznego zrzutu. Z nimi wynik może zawierać hooki interakcji, obsługę stanów i bardziej realistyczne API komponentów — bliżej czegoś, co zespół może wypuścić i utrzymywać.
Narzędzia design-to-code nie postrzegają ekranu jak człowiek; starają się wyjaśnić każdą warstwę jako reguły układu: rzędy, kolumny, kontenery i odstępy. Im jaśniejsze są te reguły, tym mniej wynik będzie polegał na kruchej pozycji.
Większość modeli zaczyna od szukania powtarzalnego wyrównania i równych przerw. Jeśli kilka elementów dzieli tę samą lewą krawędź, bazę lub środek, AI często traktuje je jako kolumnę lub tor siatki. Spójne odstępy (np. wzorce 8/16/24px) sugerują, że układ można wyrazić za pomocą gapów w stacku, gutterów siatki lub ztokenizowanych odstępów.
Gdy odstępy różnią się trochę (15px tu, 17px tam), AI może uznać układ za „ręczny” i wrócić do współrzędnych absolutnych, aby zachować pixel-perfect odległości.
AI szuka też wizualnego „ograniczenia”: tła, obramowań, cieni i przestrzeni przypominającej padding, które sugerują kontener. Karta z tłem i wewnętrznym paddingiem to wyraźny sygnał elementu rodzica z dziećmi.
Stamtąd często mapuje strukturę na prymitywy takie jak:
Czyste grupowanie w pliku projektu pomaga odróżnić rodziców od rodzeństwa.
Jeśli projekt zawiera constraints (przypinanie, dopasowywanie, wypełnianie), AI używa ich do decyzji, co się rozciąga, a co pozostaje stałe. Elementy typu „fill” zazwyczaj stają się elastycznymi szerokościami (np. flex: 1), podczas gdy „hug” mapuje się na elementy dopasowane do zawartości.
Pozycjonowanie absolutne zwykle pojawia się, gdy model nie jest pewny, jak wyrazić relacje za pomocą układów przepływowych — często z powodu niespójnych odstępów, nakładających się warstw lub źle wyrównanych elementów. Może wyglądać poprawnie na jednym rozmiarze ekranu, ale psuć responsywność i skalowanie tekstu.
Użycie małej skali odstępów i dostosowanie się do wyraźnej siatki znacząco zwiększa szansę, że AI wygeneruje czysty kod flex/grid zamiast współrzędnych. Spójność to nie tylko estetyka — to wzorzec czytelny dla maszyn.
AI nie „rozumie” hierarchii; wnioskuje ważność z wzorców, które zwykle ją sygnalizują. Im czytelniej projekt komunikuje te sygnały, tym bardziej wygenerowane UI odpowie Twoim intencjom.
Typografia to jeden z najsilniejszych tropów. Większy rozmiar, większa waga, wyższy kontrast kolorystyczny i większa wysokość linii zwykle wskazują wyższy priorytet.
Na przykład 32px pogrubiony tytuł nad 16px zwykłym akapitem to wyraźny wzorzec „nagłówek + body”. Trudniej jest, gdy style się zacierają — np. dwa bloki tekstu różnią się o 1–2px lub używają tej samej wagi z różnymi kolorami. W takich przypadkach AI może oznaczyć oba jako zwykły tekst lub wybrać nieprawidłowy poziom nagłówka.
Hierarchia jest również wnioskowana z relacji przestrzennych. Elementy bliżej siebie, wyrównane i oddzielone od innych treści białą przestrzenią bywają traktowane jako grupa.
Wspólne tła (karty, panele, podbarwione sekcje) działają jak wizualne nawiasy: AI często interpretuje je jako kontenery typu section, aside lub wrapper komponentu. Nierówny padding lub niespójne odstępy mogą spowodować przypadkowe łączenie grup — np. przycisk przyczepiony do niewłaściwej karty.
Powtarzalne wzorce — identyczne karty, elementy listy, wiersze lub pola formularza — to silny dowód na komponent wielokrotnego użytku. Nawet niewielkie różnice (rozmiar ikony, promień narożnika, styl tekstu) mogą sprawić, że AI wygeneruje kilka jednorazowych wersji zamiast jednego komponentu z wariantami.
Przyciski komunikują intencję przez rozmiar, wypełnienie, kontrast i pozycję. Wypełniony przycisk o silnym kontraście jest zwykle traktowany jako akcja główna; przyciski z obramowaniem lub tekstowe stają się drugorzędne. Jeśli dwie akcje wyglądają na równie podkreślone, AI może błędnie odgadnąć, która jest „pierwotna”.
Na koniec AI stara się mapować hierarchię na semantykę: nagłówki (h1–h6), pogrupowane regiony (section) i sensowne klastry (np. „szczegóły produktu” vs. „akcje zakupu”). Wyraźne kroki typograficzne i spójne grupowanie znacznie ułatwiają tę translację.
Modele przewidują intencję przez dopasowanie tego, co widzą, do wzorców wyuczonych z wielu interfejsów: typowe kształty, etykiety, ikonografię i konwencje umiejscowienia.
Niektóre układy wyraźnie sugerują konkretne komponenty. Poziomy pasek u góry z logiem po lewej i tekstowymi elementami po prawej to prawdopodobnie pasek nawigacji. Rząd równych szerokości elementów z jednym wyróżnionym często odpowiada zakładkom. Powtarzalne pudełka z obrazkiem, tytułem i krótkim tekstem czytane są jako karty. Gęste siatki z wyrównanymi nagłówkami i wierszami zwykle stają się tabelami.
Te domysły mają znaczenie, bo wpływają na strukturę: „zakładka” sugeruje stan wybrania i nawigację klawiaturową, podczas gdy „rząd przycisków” może tego nie implikować.
AI szuka sygnałów, które zwykle wskazują interaktywność:\n\n- Kształty przypominające przyciski (wypełnione tła, zaokrąglone prostokąty, silny kontrast)\n- Styl linku (niebieski tekst, podkreślenie) lub umiejscowienie w nawigacji\n- Pola wejściowe (obramowania, placeholdery, wskaźnik kursora)\n- Ikony afordancyjne (chevrons dla dropdownów, lupa dla wyszukiwania, „⋯” dla menu)\n\nNa tej podstawie przypisuje zachowania: klik, otwórz menu, nawiguj, wyślij, rozwiń/zwiń. Im bardziej projekt rozróżnia elementy interaktywne od statycznych, tym dokładniejszy będzie wynik.
Jeśli projekt pokazuje wiele wariantów — hover, active/selected, disabled, error, loading — AI może je zmapować na komponenty stanowe (np. disabled przyciski, komunikaty walidacji, skeletony). Gdy stany nie są jawne, AI może ich pominąć.
Niejasności są powszechne: czy karta jest klikalna czy informacyjna? Czy chevron jest dekoracją czy sterowaniem ujawniania? W takich przypadkach wyjaśnij przez nazwy, adnotacje lub oddzielne ramki pokazujące interakcję.
Gdy AI ma wiarygodny odczyt układu, kolejnym krokiem jest przetłumaczenie „jak to wygląda” na „czym to jest”: semantyczne HTML, komponenty wielokrotnego użytku i spójne style.
Większość narzędzi mapuje warstwy i grupy projektu na drzewo DOM: ramki stają się kontenerami, warstwy tekstowe nagłówkami/akapitami, a powtarzalne elementy listami lub siatkami.
Gdy intencja jest jasna, AI może przypisać lepszą semantykę — np. pasek u góry to <header>, logo i linki to <nav>, klikalna karta to <a> lub <button>. Role ARIA czasem da się wnioskować (np. role="dialog" dla modala), ale tylko gdy wzorzec jest jednoznaczny; w przeciwnym razie bezpieczniejszym wyjściem jest zwykłe HTML z TODO dla przeglądu dostępności.
Aby uniknąć generowania jednego olbrzymiego pliku, AI próbuje podzielić UI na prymitywy:
Typowe sygnały dla „komponentu” to powtarzalność, spójny padding/typografia i grupowany obszar klikalny. Typowe błędy to nadmierna fragmentacja (zbyt dużo malutkich komponentów) lub niedostateczna (wszystko hardkodowane raz).
Generator zwykle wybiera jedno podejście na podstawie docelowego stacku lub domyślnych ustawień:
Wysokiej jakości wynik opiera się na tokenach projektowych — kolory, odstępy, radiusy, cienie — dzięki czemu kod pozostaje spójny, gdy projekt ewoluuje. Ścisłe dopasowanie pikseli często daje jednorazowe wartości (np. 13px odstępu, niemal identyczne szarości), które wyglądają dobrze, ale trudno je utrzymać.
Praktyczna równowaga to: zachowaj hierarchię i rytm odstępów, a potem znormalizuj do tokenów i komponentów, których będziesz używać ponownie (i zrefaktorujesz dalej podczas przeglądu — zobacz /blog/how-to-review-and-refactor-generated-ui-code).
Pliki projektowe często wyglądają „ukończone”, bo rysuje się je w kilku stałych rozmiarach ramki (np. 1440 i 375). Kod nie może tego zakładać. Narzędzie design-to-code musi zdecydować, jak UI zachowuje się w pośrednich szerokościach, używając kombinacji wskazówek i domyślnych zasad.
Jeśli projekt zawiera kilka wersji tego samego ekranu (desktop/tablet/mobile) i struktura jest spójna, AI może je wyrównać i wnioskować, gdzie reguły układu się zmieniają. Bez wariantów zwykle wybiera powszechne punkty przerwania i traktuje rozmiar ramki jako „bazowy”, co może prowadzić do niezgrabnych skoków.
AI patrzy na wzorce: powtarzalne karty w siatce, równe odstępy i wyrównanie. Na tej podstawie może zdecydować, że siatka 3-kolumnowa staje się 2-kolumnowa, potem 1. Ma trudności, gdy projekt polega na ręcznych korektach — elementy wyglądają wyrównane, ale nie są naprawdę spójne — bo nie może stwierdzić, czy to było zamierzone.
Większość projektów używa krótkich, schludnych tekstów. Produkty rzeczywiste — nie. Kod generowany przez AI często ustawia stałe szerokości/wysokości lub obcina tekst zbyt agresywnie.
Szybkie sprawdzenie sanityzacyjne to testy:\n\n- tytuły 2–3× dłuższe (niemieckie związania słowne, pełne nazwy prawne)\n- wieloliniowe przyciski i komunikaty o błędach\n- większe rozmiary tekstu (ustawienia dostępności systemu)
AI może zachować pixel-perfect crop z projektu, ale responsywne UI potrzebuje reguł: zachowaj proporcje, wybierz sposób kadrowania i zdecyduj, kiedy obraz ma skalować się w dół versus zmieniać pozycję. Jeśli projekt tego nie określa, spodziewaj się zachowania „fill”, które przytnie ważne fragmenty.
Zanim zaufasz wynikowi, podglądaj na bardzo małych szerokościach, bardzo dużych monitorach i w rozmiarach pośrednich. Jeśli coś nachodzi, jest obcięte lub nieczytelne, problemem jest zwykle brak intencji układu — nie „zły kod” — i to sygnał, aby dodać jaśniejsze constraints w projekcie.
AI potrafi zaskakująco dobrze przekształcić piksele w kod UI, ale dostępność to miejsce, gdzie „dobrze wygląda” często różni się od „działa dla wszystkich”. Ponieważ wiele wymagań nie jest widocznych na statycznej ramce, model potrzebuje jawnych sygnałów.
Niektóre przyjazne dostępnościom wybory widać wizualnie i AI może je odwzorować w lepszym HTML:\n\n- Kontrast i nacisk: duży, pogrubiony tekst zwykle staje się nagłówkami; wysokokontrastowe przyciski stają się akcjami pierwotnymi.\n- Etykiety przy polach: tekst umieszczony nad/obok pola jest często traktowany jako etykieta pola.\n- Wskazówki porządku fokusu: czytelny układ lewo→prawo, góra→dół może dać rozsądny porządek DOM.
Inne wymagania nie są niezawodnie widoczne:\n\n- Przepływ klawiatury i pułapki: modale, menu i niestandardowe widgety potrzebują jawnego zarządzania fokusem.\n- Znaczące etykiety: „Email” w placeholderze to nie to samo co dostępna etykieta; intencje typu „Szukaj produktów” vs. „Szukaj w serwisie” mogą być niejednoznaczne.\n- Ogłoszenia stanów: błędy, ładowanie i dynamiczne aktualizacje potrzebują wzorców ARIA, których nie widać na wyglądzie.
Spodziewaj się braków typu brakujące label/for powiązania, niepoprawne poziomy nagłówków, klikalne div bez wsparcia klawiatury, słabe style focusa i ikony bez alternatyw tekstowych.
h1 → h2 → h3).\n- Istnieją punkty orientacyjne (header, nav, main, footer) i nie są zdublowane.\n- Obrazy/ikony mają odpowiednie alt (lub alt="" jeśli dekoracyjne).\n- Widoczne style focusa spełniają wymagania kontrastu.\n- Pola wejściowe mają powiązane etykiety i jasne komunikaty o błędach.Dodaj krótką specyfikację, gdy masz modale, drawery, złożone formularze, niestandardowe selecty, drag-and-drop lub cokolwiek ze znaczącymi stanami. Nawet kilka notatek typu „złap fokus w modalu”, „Esc zamyka” i „wyświetlaj komunikaty o błędach inline” może znacząco poprawić wygenerowany kod UI.
AI może wygenerować kod UI, który na pierwszy rzut oka wygląda dobrze, ale małe błędy interpretacyjne szybko się kumulują. Większość problemów wynika z „uzasadnionych zgadnięć”, gdy projekt nie koduje jasno reguł.
Częstą skargą są odstępy niezgodne z projektem: przyciski lekko przesunięte, sekcje oddychające za mocno lub karty stłoczone. Dzieje się tak, gdy padding podobnych elementów jest niespójny lub gdy Auto Layout/constraints mieszają się z ręcznymi poprawkami. Model może założyć wzorzec (np. „16px wszędzie”) i nadpisać wyjątki — albo zachować przypadkowe wyjątki.
Wygenerowany markup często ma za dużo wrapperów. Każde wnioskowane wizualne grupowanie staje się kolejnym <div>. Efekt to trudniejsze stylowanie, trudniejsze debugowanie i czasem wolniejsze renderowanie. Zauważysz to, gdy prosta karta stanie się pięcioma zagnieżdżonymi kontenerami tylko po to, by wyrównać ikonę i tytuł.
AI może podzielić komponenty zbyt granularnie (każda etykieta jako osobny komponent) lub zbyt monolitycznie (cały ekran jako jeden komponent). Przyczyną są niejasne granice: jeśli powtarzalne wzorce nie są identyczne, model nie wyciągnie pewnego wspólnego komponentu.
Typografia często „dryfuje”, bo style tekstu w projekcie nie zawsze mapują się czysto do kodu. Subtelne różnice w wysokości linii, kerningu czy wadze mogą zniknąć, a fallbacki fontów zmieniają metryki między środowiskami. Dlatego nagłówek, który mieścił się w Figma, nagle może zawijać się w kodzie.
Jeśli hover, focus, error, loading lub stany puste nie są przedstawione w projekcie, AI rzadko je wymyśla. UI może wyglądać poprawnie na statycznym zrzucie, ale zawieść przy interakcji użytkownika.
Generatory kodu nie „widzą” projektu jak człowiek — czytają uporządkowany plik pełen warstw, constraints, stylów i instancji komponentów. Im czyściej ta struktura, tym mniej model musi zgadywać (i tym mniej dziwnego div-soupu będziesz potem rozplątywać).
Nazwy warstw to jeden z najsilniejszych sygnałów intencji i mapowania komponentów. Preferuj spójne, opisowe schematy pasujące do twojego sposobu budowy UI:
Button/Primary, Button/Secondary\n- Card/Product, Card/Article\n- Form/Input/Text, Form/CheckboxUnikaj zostawiania wszystkiego jako „Rectangle 12” czy „Group 5” — to popycha AI do generowania ogólnych wrapperów zamiast komponentów wielokrotnego użytku.
Ręczne pozycjonowanie często zamienia się w współrzędne absolutne w kodzie. Jeśli chcesz output bazujący na flex/grid, projekt powinien zachowywać się jak flex/grid:
Gdy projekt dobrze reaguje w narzędziu projektowym, wygenerowane UI ma znacznie większe szanse być domyślnie responsywnym.
Jednorazowe kolory, rozmiary fontów i wartości odstępów zachęcają do jednorazowego CSS. Zamiast tego:\n\n- Twórz i używaj styli kolorów/tekstu (lub zmiennych) dla typografii, powierzchni, obramowań i stanów.\n- Standaryzuj kroki odstępów (np. 4/8/12/16), aby układy tłumaczyły się na spójne tokeny.
To poprawia spójność i ułatwia późniejszą refaktoryzację w system projektowy.
AI nie wywnioskuje tego, czego nie znajdzie. Dodaj kluczowe warianty jak hover/pressed/disabled, stany błędów dla pól, stany ładowania i puste stany.
Gdy zachowanie ma znaczenie, zanotuj krótko: „otwiera modal”, „walidacja po stronie serwera”, „pokazuje toast po sukcesie”. Jedno zdanie przy komponencie może zapobiec błędnej logice interakcji.
Jeśli standaryzujesz workflow zespołu, uchwyć konwencje w lekkim checklistcie i odnośniku wewnętrznym.
Kod UI z AI najlepiej traktować jako szkic: może zaoszczędzić godziny, ale nadal wymaga ludzkiego przeglądu, żeby zapewnić poprawne zachowanie UI, utrzymywalność i zgodność z wymaganiami produktu.
Zacznij od przeczytania markupu tak, jakbyś używał czytnika ekranowego.
\u003ch1\u003e, potem logiczne \u003ch2\u003e/\u003ch3\u003e).\n- Potwierdź, że listy są prawdziwymi listami (\u003cul\u003e/\u003col\u003e) a nie ułożonymi \u003cdiv\u003e.Jeśli semantyka jest zła, poprawa CSS nie wystarczy, żeby uratować dostępność lub użyteczność.
Wiele generatorów polega na pozycjonowaniu absolutnym lub głęboko zagnieżdżonych wrapperach, by „dopasować screenshot”. To zwykle psuje się przy zmianie treści.
Preferuj reguły flex/grid zamiast współrzędnych i redukuj zagnieżdżenie, dopóki każdy wrapper nie ma jasnego powodu istnienia (grupowanie layoutu, odstępy lub granica komponentu). Jeśli widzisz powtarzające się style={{ left, top, width, height }}, przepisz najpierw ten obszar.
Szukaj powtarzalnych wzorców UI (karty, wiersze pól, elementy nawigacji) i zamień je na komponenty wielokrotnego użytku. Potem zastąp wartości na stałe tokenami: odstępy, promienie, typografia i kolory. Jeśli zespół ma już wytyczne dotyczące tokenów, dostosuj się do nich; w przeciwnym razie zacznij od minimalnego zestawu i rozszerzaj go celowo (zobacz /blog/design-tokens).
Nie potrzebujesz ciężkiego zestawu testów, żeby uzyskać wartość.
Generatory zgadują intencję. Zapisz wszystkie zmiany, które wprowadziłeś (reguły interakcji, punkty przerwania, decyzje o mapowaniu komponentów), aby kolejna generacja — lub inny deweloper — ich nie cofnął.
AI „design to code” działa najlepiej, gdy traktujesz go jako przyspieszacz, nie autopilota. Najszybsze zespoły wybierają workflow dopasowany do dojrzałości systemu projektowego i poziomu ryzyka ekranu, który budują.
1) AI w narzędziach projektowych (np. wtyczki Figma): Świetne, jeśli chcesz pozostać blisko pliku źródłowego. Otrzymujesz szybkie szkielety podczas iteracji projektanta i łatwiej zachować nazwy, komponenty i tokeny w pliku.
2) Konwertery zewnętrzne (upload/eksport → kod): Przydatne, gdy potrzebujesz powtarzalnego procesu dla wielu plików lub zespołów. Może być szybsze do masowej konwersji, ale częściej spędzisz więcej czasu na czyszczeniu struktury i podpinaniu interakcji.
W praktyce wiele zespołów łączy design-to-code z szerszym flow „spec do wypuszczonej aplikacji”. Na przykład platformy takie jak Koder.ai wykorzystują tę samą zasadę — przekształcanie intencji w implementację — i rozszerzają ją poza szkielety UI: możesz opisać funkcje w czacie, wygenerować frontend React z backendem Go/PostgreSQL (i Flutter dla mobilnych), a potem iterować trybem planowania, snapshotami, rollbackami i eksportem kodu źródłowego, gdy trzeba zintegr
To asystowane przez AI tłumaczenie wizualnego UI (ramka Figma, eksport projektu lub screenshot) na wykonywalny kod UI. Celem jest solidny szkic — układ, rytm stylu i podstawowa struktura — aby deweloper mógł to zrefaktoryzować do tokenów, komponentów i produkcyjnych semantyk.
Zwykle tłumaczy:
Piksele nie kodują wszystkiego. Zwykle musisz określić lub dostarczyć:
Screenshot to najsłabsze wejście: ma kolor i geometrię, ale brak mu struktury (warstwy, constraints, komponenty). Spodziewaj się więcej zgadywania, pozycji absolutnych i mniej kodu nadającego się do ponownego użycia.
Plik Figma/Sketch lub eksport z zachowaną strukturą zapewnia ramki, nazwy warstw, Auto Layout, constrains i style — sygnały, które pomagają wygenerować czystsze układy flex/grid i dokładniejsze granice komponentów.
AI szuka powtarzalnego wyrównania i spójnych odstępów, aby wyrazić UI jako reguły flex/grid. Jeśli znajdzie wyraźny rytm odstępów (np. 8/16/24), może wygenerować stabilne stosy i siatki.
Jeśli odstępy są niespójne lub elementy lekko się nie wyrównują, model często cofa się do współrzędnych absolutnych by zachować wygląd — kosztem responsywności.
Szukając wizualnych sygnałów „obramowania”:
Czyste grupowanie i spójna struktura w narzędziu projektowym (ramki, Auto Layout) ułatwiają odtworzenie relacji rodzic–dziecko w kodzie.
Pojawiają się, gdy relacje są niejednoznaczne — nakładki, niespójne odstępy, ręczne przesunięcia lub niejasne grupowanie. Mogą pasować na jednym rozmiarze ekranu, ale często psują się przy:
Jeśli chcesz elastycznego wyjścia, spraw, by projekt zachowywał się jak flex/grid przez Auto Layout i constraints.
Wykrywa hierarchię po wskazówkach wizualnych:
Gdy style różnią się tylko o 1–2px lub kroki hierarchii są niejasne, może wybrać zły poziom nagłówka lub potraktować nagłówek jako zwykły tekst.
AI zgaduje interaktywność na podstawie affordance UI:
Jeśli „karta” może być klikalna lub informacyjna, dodaj adnotację lub wariant; inaczej model może przypisać niewłaściwe zachowanie lub je pominąć.
Zrób szybki, uporządkowany przegląd:
Traktuj wynik jako szkic, a potem dokumentuj założenia, żeby przyszłe generacje ich nie nadpisały.