De ce folosesc Cursor cu Figma MCP – și de ce încă testez pe un iPhone cu cablu

„Interfață asistată de inteligență artificială” însemna inserarea unei capturi de ecran într-un chat și recuperarea unui CSS care era aproape, dar niciodată decalajul potrivit, griul potrivit, înălțimea corectă a liniei. Modelul Context Protocol a schimbat asta în special pentru transferul de proiectare. Cursor vorbește cu serverul MCP al lui Figma și, în loc să aplatizeze un cadru în pixeli pentru ca modelul să-l ghicească, primește arborele nodurilor real: aspect automat, valori de spațiere, variabile legate, nume de componente, scară de tip. Aceasta este partea pe care mă bazez zilnic.

1. Ceea ce MCP face de fapt corect

Selectez un cadru în Figma, dau Cursor link-ul și interogează serverul MCP pentru acel nod. Ceea ce revine este structurat: un decalaj de 8px este numărul literal 8, nu ceva ce măsoară cu un instrument de riglă pe un PNG. O culoare este simbolul de design sau hexagonul legat de designer, nu o valoare pe care o aleg cu pipeta și sper că se potrivește. Greutatea fontului, înălțimea liniei, raza colțului, ierarhia componentelor actuale - toate acestea ajung ca date, nu ca o imagine pe care o proiectez invers.

• Spațiere care se potrivește cu sistemul de proiectare, nu cu cel mai apropiat număr rotund pe care l-am ghicit.
• Culori și tipul ca simboluri, astfel încât o rebrand actualizează o variabilă în loc de un grep între componente.
• Limitele componentelor care se potrivesc cu modul în care designerul a grupat de fapt lucrurile, ceea ce face ca marcajul generat să fie mai ușor de păstrat semantic.

2. Ce mai verific manual

Datele structurate nu sunt o judecată. Un cadru Figma arată câte un punct de întrerupere la un moment dat; nu spune Cursor ce se întâmplă între 768px și 1024px sau cum arată un card cu un titlu pe două rânduri în loc de unul. Nu are nicio stare goală, nicio stare de eroare, nici un schelet de încărcare, pentru că aceia nu au avut niciodată un cadru de design pentru început. Iar marcajul generat poate fi precis structural pentru cadru, fiind în același timp un div unde îi aparține un buton, un navigator sau o etichetă de antet - încă citesc fiecare componentă pentru semantică și acces la tastatură înainte de a se îmbina.

3. De ce nu este suficient un emulator

Bara de instrumente a dispozitivului Chrome DevTools este Chromium, redând o fereastră de vizualizare redimensionată. Nu este WebKit, nu are comportamentul de vizualizare dinamic al iOS Safari și nu vă va arăta erorile care există doar pe motorul real. Deci, ultimul pas înainte ca ceva să fie livrat este conectarea unui iPhone real la Mac-ul meu cu un cablu. Setări → Safari → Avansat → Web Inspector, activat o dată pe telefon. Apoi un cablu Lightning sau USB-C la Mac, meniul Develop din Safari preia dispozitivul și primesc un inspector web live – DOM real, consolă reală, panou de rețea real – atașat la o pagină care rulează de fapt pe iOS Safari, nu o simulare a acesteia.

Acolo prind erorile pe care le ascunde un emulator: căptușeală-zonă sigură care arată bine în DevTools și clipuri sub crestătură pe telefonul real, sărituri de 100vh când bara de adrese a lui Safari se prăbușește la derulare (dvh o remediază, dar doar testarea live demonstrează asta), focalizarea de intrare sare cu o bandă de tastatură deschisă, tragerea de tastatură fixă pe ecran. întregul aspect și modul în care pagina se comportă de fapt adăugat la ecranul de pornire ca PWA autonom. Nimic din toate acestea nu apare într-un emulator. Toate acestea apar prima dată când un client real deschide linkul pe propriul telefon – așa că aș prefera să-l văd mai întâi.

4. De ce anume Safari – browserul pentru care de fapt expediez

Mă uit la analiză înainte de a decide ce înseamnă „corect” chiar și pentru un proiect. Pentru majoritatea site-urilor de afaceri mici și de servicii pe care le construiesc, clientul care deschide site-ul este pe un telefon, care sosește de pe Instagram, Telegram, Google Maps sau un mesaj text – și pentru o mare parte din acest trafic, acel telefon este un iPhone. Desktop Chrome este locul unde dezvolt. iOS Safari este locul în care se află de fapt persoana cu cardul de credit. Optimizarea perfecțiunii pixelilor pentru browserul pe care îl privesc toată ziua și sărirea peste cel pe care clientul clientului meu îl deține este optimizarea pentru publicul greșit.

Bucla reală

Figma cadru, selectat și predat lui Cursor prin MCP. Componentă construită din jetoane reale, nu pixeli ghicit. O trecere pentru semantică, stări și puncte de întrerupere pe care cadrul nu le-a arătat niciodată. Apoi iPhone-ul iese din sertar, se conectează la Mac și aceeași pagină rulează live în Inspectorul web al Safari pe motorul real. Abia după asta se îmbină ceva. Două instrumente diferite, două sarcini diferite: unul mă apropie rapid de design, celălalt îmi spune adevărul despre dispozitivul pe care clientul clientului îl va folosi de fapt.

Vrei să arate exact pe telefonul pe care îl deține clientul tău?

Acesta este canalul pe care îl rulez pentru fiecare construcție: jetoane de design reale, ieșire dispozitiv real. Luați legătura prin formularul de contact și spuneți-mi ce platformă folosesc de fapt clienții dvs. - voi construi și testa pentru acea, nu pentru browserul care este convenabil pentru mine.