Dlaczego używam Cursor z Figma MCP – i dlaczego nadal testuję na kablowym iPhonie

„frontend wspomagany sztuczną inteligencją” oznaczał kiedyś wklejenie zrzutu ekranu do czatu i odzyskanie CSS, który był zbliżony, ale nigdy nie miał odpowiedniej przerwy, właściwej szarości i właściwej wysokości linii. Model Context Protocol zmienił to specjalnie w przypadku przekazywania projektu. Cursor komunikuje się z serwerem MCP Figma i zamiast spłaszczać ramkę w pikselach, aby model mógł odgadnąć, pobiera rzeczywiste drzewo węzłów: automatyczny układ, wartości odstępów, powiązane zmienne, nazwy komponentów, skalę typów. To jest część, na której tak naprawdę polegam każdego dnia.

1. Co właściwie MCP robi dobrze

Wybieram ramkę w Figma, przekazuję Cursor łącze, a ono wysyła zapytanie do serwera MCP o ten węzeł. To, co wraca, ma strukturę: przerwa 8 pikseli to dosłowna liczba 8, a nie coś, co mierzę za pomocą linijki w PNG. Kolor to żeton projektu lub heks przypisany przez projektanta, a nie wartość, którą wybieram za pomocą zakraplacza i mam nadzieję, że będzie pasować. Grubość czcionki, wysokość linii, promień narożnika, rzeczywista hierarchia komponentów – wszystko to pojawia się jako dane, a nie jako obraz, który poddaję inżynierii wstecznej.

• Odstępy zgodne z systemem projektowym, a nie najbliższa okrągła liczba, jaką zgadłem.
• Kolory i typ służą jako tokeny, więc rebranding aktualizuje jedną zmienną zamiast grepa w komponentach.
• Granice komponentów odpowiadają faktycznemu pogrupowaniu elementów przez projektanta, co ułatwia zachowanie semantyki wygenerowanych znaczników.

2. Co nadal sprawdzam ręcznie

Dane strukturalne nie są oceną. Ramka Figma pokazuje jeden punkt przerwania na raz; nie mówi Cursor, co dzieje się pomiędzy 768 a 1024 px ani jak wygląda karta z dwuwierszowym tytułem zamiast jednego. Nie ma stanu pustego, stanu błędu ani szkieletu ładowania, ponieważ te elementy nigdy nie miały ramki projektowej. Wygenerowane znaczniki mogą być strukturalnie zgodne z ramką, a jednocześnie stanowić element div, do którego należy przycisk, element nawigacyjny lub znacznik nagłówka — nadal czytam każdy komponent pod kątem semantyki i dostępu do klawiatury przed jego połączeniem.

3. Dlaczego emulator nie wystarczy

Pasek narzędzi urządzenia Chrome DevTools to Chromium renderujący rzutnię o zmienionym rozmiarze. To nie jest WebKit, nie ma dynamicznego zachowania rzutni w iOS Safari i nie pokaże błędów, które istnieją tylko w prawdziwym silniku. Zatem ostatnim krokiem przed wysłaniem czegokolwiek jest podłączenie prawdziwego iPhone'a do mojego Maca za pomocą kabla. Ustawienia → Safari → Zaawansowane → Inspektor sieciowy, włączone raz na telefonie. Następnie podłączam kabel Lightning lub USB-C do komputera Mac, menu Develop przeglądarki Safari wybiera urządzenie i otrzymuję działający na żywo inspektor sieciowy – prawdziwy DOM, prawdziwą konsolę, prawdziwy panel sieciowy – podłączony do strony, która faktycznie działa w przeglądarce iOS Safari, a nie jej symulacji.

Tutaj wyłapuję błędy ukrywane przez emulator: dopełnienie w bezpiecznym obszarze, które wygląda dobrze w DevTools i klipy pod wycięciem na prawdziwym telefonie, skoki o 100 vh, gdy pasek adresu przeglądarki Safari zapada się podczas przewijania (dvh naprawia to, ale tylko testowanie tego na żywo to potwierdza), przeskakiwanie fokusu wejściowego, gdy klawiatura otwiera się ze stałą stopką na ekranie, przewijanie gumką przeciągającą cały układ i faktyczne zachowanie strony dodane do ekranie głównym jako samodzielnym PWA. Nic z tego nie pojawia się w emulatorze. Wszystko to pojawia się, gdy prawdziwy klient po raz pierwszy otworzy link na swoim telefonie – więc wolałbym to najpierw zobaczyć.

4. Dlaczego akurat Safari – właśnie ta przeglądarka, dla której aktualnie dostarczam

Zanim zdecyduję, co „poprawny” w ogóle oznacza dla projektu, patrzę na statystyki. W przypadku większości witryn małych firm i usług, które tworzę, klient otwierający witrynę odbywa się na telefonie, przychodzi z Instagrama, Telegram, Google Maps lub wysyła wiadomość tekstową – i w przypadku dużej części tego ruchu tym telefonem jest iPhone. Chrome na komputery stacjonarne to miejsce, w którym się rozwijam. Safari w systemie iOS to miejsce, w którym faktycznie znajduje się osoba posiadająca kartę kredytową. Optymalizacja doskonałości pikseli dla przeglądarki, na którą patrzę cały dzień i pomijanie tej, którą faktycznie trzyma klient mojego klienta, jest optymalizacją pod kątem niewłaściwych odbiorców.

Rzeczywista pętla

Figma ramka, wybrana i przekazana do Cursor poprzez MCP. Komponent zbudowany z prawdziwych tokenów, a nie zgadniętych pikseli. Przepustka dla semantyki, stanów i punktów przerwania, których ramka nigdy nie pokazała. Następnie iPhone wyciąga się z szuflady, podłącza do komputera Mac i ta sama strona uruchamia się na żywo w inspektorze sieciowym przeglądarki Safari na prawdziwym silniku. Dopiero potem cokolwiek się łączy. Dwa różne narzędzia, dwa różne zadania: jedno szybko przybliża mnie do projektu, drugie mówi mi prawdę o urządzeniu, z którego będzie korzystał klient klienta.

Chcesz, żeby rzeczywiście wyglądało to dobrze na telefonie, który trzyma Twój klient?

To jest potok, który uruchamiam w każdej kompilacji: prawdziwe tokeny projektu, prawdziwe urządzenie. Skontaktuj się przez formularz kontaktowy i powiedz mi, z jakiej platformy faktycznie korzystają Twoi klienci – zbuduję i przetestuję dla tej platformy, a nie dla wygodnej dla mnie przeglądarki.