Figma MCP בפרודקשן: כך אני בונה עמודי וורדפרס מדויקים לפיקסל

כל דמו של Figma MCP נראה אותו הדבר: מכוונים את הסוכן לפריים, מקבלים קומפוננטת React, וסיימנו.

אבל כשמנסים את זה על פרויקט אמיתי, מגלים שהדמו דילג על כל מה שחשוב: לעיצוב יש שתי נקודות שבירה שלא מסכימות זו עם זו, הקוד שנוצר מניח כיווניות משמאל לימין (LTR), והסוכן ממציא מחדש את מערכת העיצוב בכל עמוד ועמוד.

לאחרונה סיימתי בדיוק פרויקט פרודקשן כזה. אתר של משרד עורכי דין, עברית RTL, תבנית וורדפרס קלאסית, Tailwind CSS v4. כל תבנית עמוד (page temaplte) נבנתה מעיצובי ה-Figma דרך שרת ה-MCP של Figma ו-Claude Code, ואז נבדקה מול העיצוב עד רמת הפיקסל.

השירות עצמו אינו חדש; אני עושה פרויקטים של Figma לוורדפרס כבר שנים. מה שהשתנה הוא כמה מהעבודה הסוכן יודע לקחת על עצמו היום.

בפוסט זה אציג את שיטת העבודה ששרדה את אותו פרויקט, כולל המקומות שבהם הפלט של ה-MCP היה פשוט שגוי.

קפצו ישר לצ'קליסט: מה למסור לסוכן

מה שרת ה-MCP של Figma באמת נותן לכם

השרת חושף לא מעט כלים, אבל ארבעה מהם מחזיקים את כל שיטת העבודה.

השורה השלישית היא שינוי התפיסה המרכזי. get_design_context מחזיר משהו שנראה כמו קוד מוגמר, ובדמו React ב-LTR הוא כמעט באמת כזה.

בפרויקט אמיתי קוראים אותו בשביל המספרים: גדלי פונט, משקלים, ריווחים, ערכי hex מדויקים. את סדר ה-DOM ואת ערכי המיקום זורקים. בהמשך, בחלק על ה-RTL, תבינו למה.

התקנה: חיבור אפליקציית Figma ל-Claude Code

שרת ה-MCP של Figma (השם המקורי ״Dev Mode MCP server״ כבר ירד בינתיים) רץ בתוך אפליקציית הדסקטופ של Figma, לא בענן. האפליקציה צריכה להיות פתוחה, ואתם צריכים Dev Seat או Full Seat בתוכנית בתשלום.

מפעילים אותו מתפריט Figma תחת Preferences (ההעדפות), והוא מתחיל להאזין לוקאלית. התיעוד המלא נמצא במדריך הרשמי של Figma לשרת ה-MCP. אגב, ל-Figma יש כיום גם endpoint מרוחק בענן, אבל שיטת העבודה בפוסט זה רצה על השרת הלוקאלי, והתנהגות ״הטאב הפעיל״ שתכף נגיע אליה רלוונטית רק אליו.

לאחר מכן רושמים אותו ב-Claude Code:

claude mcp add --transport http figma-dev-mode http://127.0.0.1:3845/mcp

אם עוד לא רשמתם שרת MCP בעבר, התהליך זהה לכל שרת לוקאלי אחר. הסברתי עליו בהרחבה במדריך שרתי ה-MCP ל-Claude Code.

מזהי ה-Node מגיעים מכתובת ה-URL של Figma. העתיקו קישור לפריים כלשהו ותקבלו ?node-id=1074-15632. החליפו את המקף בנקודתיים, וזהו המזהה שה-MCP מצפה לו: 1074:15632.

מדריך העיצוב (Style Guide) ישב בקובץ אחד ועיצובי העמודים בקובץ אחר, כך שכל מעבר בין ״מה אומר המפרט של הכפתור״ ל״איך נראה עמוד הבית״ חייב קודם כול החלפת טאב באפליקציה.

שיטת העבודה לכל עמוד: מפריים לתבנית

אחרי כמה תבניות, התהליך התייצב על אותם חמישה שלבים בכל פעם.

1. מריצים get_metadata על הקנבס הראשי פעם אחת. מקבלים את כל עץ הפריימים, ומאתרים את זוג הפריימים של כל עמוד. בקובץ שלנו לכל עמוד היו שניים: פריים דסקטופ של 1920 ופריים מובייל של 360, עם שמות כמו 001a 1920 Homepage ו-001a 360 Homepage.
2. מריצים get_screenshot על כל פריים, ועל סקשנים בודדים בעמודים ארוכים. הצילום מכריע כל שאלת מיקום. אם הקוד והצילום לא מסכימים מה יושב בקצה הימני, הצילום מנצח.
3. מריצים get_design_context לכל סקשן, לא לכל עמוד. קריאה על עמוד שלם שורפת טוקנים ומטשטשת פרטים. קריאה על סקשן נותנת ערכים מדויקים שאפשר לתמלל.
4. בונים את הסקשן עם הטוקנים ומחלקות הקומפוננטות שלכם, ומריצים build.
5. מאמתים באמצעות מדידה, לא באמצעות קריאה חוזרת של הקלאסים. מדמים את ה-viewports האמיתיים, קוראים computed styles, ומניחים את הצילום שלכם ליד העיצוב.

השלב האחרון הוא המקום שבו רוב העמודים שנבנו על ידי AI נכשלים בשקט. הסוכן כתב text-base, הקלאס נראה נכון, כולם ממשיכים הלאה.

אבל האם הדפדפן באמת חישב 16px על אותו אלמנט באותו viewport? זו כבר שאלה אחרת. אז מודדים עם ה-MCP של Chrome DevTools:

// chrome-devtools MCP: emulate "360x800x3,mobile,touch",
// reload with ignoreCache, then per element:
const el = document.querySelector('.stats-bar .pill');
const cs = getComputedStyle(el);
JSON.stringify({
  fontSize: cs.fontSize,     // spec says 16px on mobile
  fontWeight: cs.fontWeight, // spec says 500
  color: cs.color,
  padding: cs.padding
});
// then emulate "1920x1200x1" and measure again

אותו שרת DevTools משמש אותי בדרך כלל לבדיקות ביצועים ו-Lighthouse; כאן התפקיד שלו שונה: בדיקת נאמנות לעיצוב.

מתמללים את מערכת העיצוב פעם אחת

זה המכפיל הגדול ביותר בכל שיטת העבודה, וכמעט אף אחד לא מדבר עליו.

הלולאה הנאיבית שואלת את ה-MCP על צבעים וסגנונות טיפוגרפיה בכל עמוד מחדש. כך מפענחים את אותה מערכת עיצוב עשרות פעמים, שורפים טוקנים, וגרוע מזה: מקבלים תשובות מעט שונות בכל פעם.

במקום זאת, השקענו סשן אחד בתמלול כל מדריך העיצוב של Figma לשני מקומות: קובץ skill קבוע של הסוכן וטוקנים של Tailwind v4.

Tailwind v4 עובדת בגישת CSS-first, כך שאין קובץ קונפיגורציה (אם עבודה עם Tailwind בתוך תבנית וורדפרס חדשה לכם, המדריך שלי להתקנת Tailwind CSS v4 בוורדפרס מכסה את כל התהליך). הטוקנים יושבים בבלוק @theme:

@theme {
  /* transcribed from the Figma style guide, node 12:340 */
  --color-blue-900: #081722; /* NOT #081822 - that hex belongs to a different ramp */
  --color-mint-300: #ACF8CB; /* fill only, never use as text color */
  --font-display: "Rubik", sans-serif;
}

קובץ ה-skill מחזיק את כל השאר: שש רמפות צבע, 21 סגנונות טיפוגרפיה של Rubik עם שמות, ומחלקות קומפוננטות כמו btn btn-primary ו-chip עם מטריצות המצבים המלאות שלהן.

מאותו רגע הסוכן קורא את ה-skill, לא את Figma, לכל דבר ברמת המערכת. Figma נשארת המקור; ה-skill הוא ה-cache. קובץ ה-skill מנסח את הכלל במפורש:

״כשהמסמך הזה ו-Figma לא מסכימים, Figma מנצחת. אבל קראו שוב את ה-Node ועדכנו את הקובץ.״ – מתוך קובץ ה-skill של מערכת העיצוב בפרויקט

דבר אחד שהייתי עושה שוב כבר ביום הראשון: לתעד את מה שמערכת העיצוב לא מגדירה. במדריך העיצוב שלנו לא היו מצבי focus, לא כפתורים במצב disabled, ולא סגנונות ל-blockquote או לכיתובי תמונה.

בלי הכוונה, הסוכן ממציא את אלה מחדש, ובכל עמוד אחרת. כתבנו את ההחלטות פעם אחת (כולל טבעת focus לפי WCAG 2.4.7 שהעיצוב מעולם לא הגדיר) וחוסר העקביות נעצר.

לקחים שצצו במהלך הפרויקט נשמרו באותה שיטה כקבצי זיכרון קבועים. ״בדקו גם את פריים ה-360״ ו-״justify-end מתהפך שמאלה ב-RTL״ עלו לנו כל אחד בבאג אחד בדיוק.

בודקים את שתי נקודות השבירה, בכל פעם

הנה כישלון אמיתי. לקראת סוף הפרויקט הרצתי בדיקת טיפוגרפיה (audit) מול עיצובי הדסקטופ. הדוח חזר נקי: הכול תואם.

ואז בדקנו את פריימי ה-360. ה-pills של הסטטיסטיקות במובייל (תראו בתמונה מיד) יצאו ב-14px מול מפרט של 16px, ושורה אחת רונדרה בסדר הפוך. הבדיקה של הדסקטופ לא הייתה שגויה, היא פשוט ענתה על שאלה אחרת.

אותו סקשן סטטיסטיקות בשני הפריימים: שורה של ארבעה בדסקטופ, גריד 2×2 במובייל. ה-pills בצבע מנטה מתחת למספרים הם אלה שיצאו ב-14px מול מפרט של 16px.

הסיבה שזה כואב היא שבמערכת עיצוב אמיתית, שני הפריימים שונים זה מזה יותר משהם דומים, ולא רק בגודל.

בפרויקט הזה ה-H1 של עמוד מאמר היה SemiBold 600 בצבע blue-500 בדסקטופ, אבל Medium 500 בצבע blue-900 במובייל.

הכלל הפרקטי: ערך ה-360 הוא מה שמחלקות הבסיס של Tailwind צריכות לייצר, וערך ה-1920 הוא מה שוריאנטים של lg: או clamp() צריכים להגיע אליו. clamp() נחשב תואם רק אחרי שמדדתם אותו בשני הרוחבים.

RTL: המקום שבו הקוד שנוצר פשוט שגוי

כל מה שכתבתי עד כאן נכון לכל פרויקט. החלק הזה הוא הסיבה ששיטת הדמו מתפרקת באתר עברי, ואף אחד מהמאמרים על Figma MCP שקראתי בכלל לא מזכיר אותו.

לעולם לא מעתיקים סדר DOM או ערכי מיקום

הקוד ש-Figma מייצרת נכתב מנקודת מבט של LTR ובתכונות פיזיות. סדר הילדים ב-DOM וכל ערך left: או right: מניחים עמוד משמאל לימין. תחת dir="rtl" הילד הראשון ב-DOM מרונדר מימין, וזו תמונת מראה של העיצוב שאתם מסתכלים עליו.

ערך כמו left: 478px בתוך קונטיינר של 506px לא באמת אומר ״שמאל״. הוא אומר ״inline-start״, שבעמוד שלכם הוא דווקא הקצה הימני.

תכונות לוגיות בלבד

כל utility כיווני בבנייה חייב להיות לוגי: ms-* ו-me-* במקום ml-* ו-mr-*, וכך גם ps-* ו-pe-*, start-* ו-end-*, ו-text-start במקום text-left.

אם המיפוי של start/end חדש לכם, המדריך שלי לתכונות לוגיות ב-CSS מכסה את השיטה כולה.

אבל הבאג שחזר שוב ושוב לא היה margin. הוא היה יישור flex:

<!-- Figma's output: right-aligned in the comp, but this
     resolves to the physical LEFT under dir="rtl" -->
<div class="flex justify-end">
  <span class="ml-4">04</span>
</div>

<!-- What actually right-aligns the row on an RTL page -->
<div class="flex justify-start">
  <span class="ms-4">04</span>
</div>

justify-end, items-end ו-self-end מתיישרים כולם לשמאל הפיזי ב-RTL. כדי ליישר שורת flex לימין כותבים justify-start, מה שנשמע הפוך לגמרי עד שזה מתיישב בראש.

הבאג הזה תפס אותנו בלייבלים של טפסים, בכותרות בפוטר ובשדות של טופס יצירת קשר, לפני שהוא נכנס לקובץ ה-skill ככלל קבוע.

מתאימים לצילום, שורה אחר שורה

הייתם חושבים שהפתרון הוא כלל גורף של ״להפוך הכול״. אבל לא, כי עיצובים אמיתיים אינם עקביים.

בפרויקט שלנו הסטפר הממוספר נקרא מימין לשמאל, החל מהקצה הימני. פס הסטטיסטיקות ושורת הבאדג'ים רצו 1 עד N דווקא משמאל, באותם עמודים בדיוק. אם זו הייתה כוונת מעצב או תאונה, זה כבר לא משנה; זה מה שהלקוח אישר.

הסטפר הממוספר מהעיצוב: המסילה יושבת על הקצה הימני ונקראת 1 עד 4 מלמעלה למטה. הגרסה הראשונה שבנינו יצאה משוקפת לצד שמאל.

אז הכלל הפך להיות: מתאימים לצילום לכל שורה. בונים את השורה, מצלמים את מה שבניתם באותו viewport, ומשווים איזה אלמנט יושב בכל קצה. גם הסטפר וגם שורת הבאדג'ים יצאו הפוכים לפני שאכפנו את ההשוואה הזו.

קרוסלות מקבלות את אותו יחס: בעמוד RTL חץ ה״הבא״ מצביע שמאלה (כן, שמאלה), ולוגיקת ההתקדמות מתהפכת יחד איתו.

מספרים נשארים LTR

בתוך טקסט RTL, חלק מהתוכן עדיין רץ משמאל לימין: מספרים, מחירים בשקלים, מספרי טלפון, שמות מותגים באותיות לטיניות. עטפו אותם ב-<bdi> או ב-span עם dir="ltr" כדי שאלגוריתם ה-bidi לא יערבב אותם באמצע משפט.

המלכודת של Chrome במצב Headless

Chrome במצב headless (ללא ממשק) לא יורד מתחת לרוחב viewport של בערך 500px.

בקשו ממנו צילום מסך ברוחב 390px של עמוד RTL ותקבלו תמונה שנראית חתוכה בצד ימין. היא לא. העמוד תקין; הכלי פברק את הבאג.

בדקו מובייל דרך אמולציה של DevTools, לעולם לא דרך דגל window-size של headless.

מה מוסרים לסוכן: הצ'קליסט המלא

לחבר את ה-MCP זה החלק הקל. מה שקובע את איכות התוצאה הוא ההקשר שאתם מוסרים לסוכן מיד אחר כך. הנה הרשימה המלאה שהתכנסנו אליה:

1. קישורים לקבצי ה-Figma ומזהי ה-Node של הפריימים המדויקים, וגם מי מהקבצים הוא מדריך העיצוב ומי עיצובי העמודים. שמרו על הקובץ הנכון בפוקוס באפליקציית הדסקטופ.
2. שני הפריימים של כל עמוד, 1920 ו-360, לפי שם או מזהה Node.
3. הקשר הסטאק: תבנית וורדפרס קלאסית, Tailwind v4 בגישת CSS-first, פקודת ה-build, איפה יושבים הטוקנים, והעובדה שהאתר הוא dir="rtl" עם lang="he".
4. החוזה של קבוע מול חופשי: אילו טוקנים, סגנונות טיפוגרפיה וצבעים הם חוק מותג, ואיפה לסוכן יש חופש פעולה (קומפוזיציה, אנימציה). כללו גם כללי ניגודיות, כמו צבע המנטה שלנו שעובד כמילוי אבל לעולם לא כטקסט.
5. נכסים אמיתיים: קבצי פונט באחסון עצמי ותמונות מיוצאות. אל תיתנו לסוכן לחתוך תמונות מתוך צילומי מסך של Figma.
6. חוקי הבית: id ייחודי לכל סקשן, רף מינימלי של HTML סמנטי ונגישות, ופונקציות escaping ו-i18n.
7. דרישת אימות מפורשת: מדידת computed styles בשתי נקודות השבירה והשוואת צילומי מסך מול העיצובים לפני שמכריזים ״סיימתי״.

סעיף 7 הוא החשוב מכולם: סוכן שקיבל הוראה ״תבנה, ואז תוכיח שזה תואם ב-360 וב-1920״ תופס את הטעויות של עצמו, ואתם מפסיקים להיות ה-QA היחיד בלולאה.

מוקשים שעלו לנו בזמן יקר

כמה מוקשים קטנים יותר, כל אחד מהם נלמד בדרך הקשה:

• מזהי Node זזים. מזהה ששמרתם בשבוע שעבר עלול להצביע על כלום אחרי שהמעצב עשה סדר בקובץ. אשררו אותו מחדש לפני שאתם מסתמכים עליו.
• ערכי hex כמעט זהים יכולים להשתייך לרמפות שונות. אצלנו #081722 ו-#081822 היו טוקנים נפרדים. התמלול חייב להיות מדויק, כי העיניים שלכם לעולם לא יתפסו את ההבדל בצילום מסך.
• טוקנים מבריף מוקדם לא בהכרח קיימים במדריך הסופי. המסמכים המוקדמים שלנו הזכירו סט של צבעי קרם שמדריך העיצוב הסופי כבר ויתר עליו. אמתו כל טוקן מול עיצוב עדכני.
• בונוס ייחודי לוורדפרס: הליבה מזריקה כלל :where(figure) ללא layer עם margin תחתון, ו-CSS שיושב מחוץ ל-layer גובר על כל utility של Tailwind. אלמנטים מסוג figure צריכים m-0! כדי להתאפס באמת.

שאלות נפוצות

תשובות קצרות לשאלות שחוזרות הכי הרבה סביב שיטת העבודה הזו.

סיכום

שרת ה-MCP של Figma באמת טוב במה שהוא עושה: הוא מוסר לסוכן שלכם ערכי עיצוב מדויקים ישירות מהמקור. הדיוק ברמת פרודקשן מגיע מכל מה שמסביב.

התייחסו לפלט שנוצר כמפרט, תמללו את מערכת העיצוב פעם אחת לטוקנים ול-skill קבוע, בדקו את שתי נקודות השבירה בכל עמוד, בנו מחדש את כל הכיווניות עם תכונות לוגיות באתרי RTL, ודרשו מהסוכן להוכיח את ההתאמה עם computed styles במקום להצהיר עליה.

הדמו נותן לכם קומפוננטה. שיטת העבודה הזו נתנה לנו אתר לקוח שתואם את העיצובים שלו ב-360 וב-1920, בשפה שהפלט של ה-MCP בכלל לא יודע שהיא קיימת.