אני בונה אתרי וורדפרס על בסיס קבצי Figma, ובשנה האחרונה סוכן AI קורא את אותם קבצים ישירות ומייצר את הגרסה הראשונה של כל עמוד. עד כמה הגרסה הזו שימושית תלוי בכמה הרגלים שלא עולים דבר, וב-Code Connect של Figma.
הסוכן קורא את הקבצים דרך שרת ה-MCP של Figma. ראשי התיבות MCP הם Model Context Protocol, שם די כבד לדבר די פשוט: מחבר שמאפשר לכלי AI להתחבר ישירות לתוכנה אחרת ולקרוא ממנה. ל-Figma יש שרת כזה, כך שבמקום שאני אתאר ל-AI את העיצוב שלכם, הוא פותח את הקובץ ומסתכל בעצמו.
באמת שמאד יעיל, אך מהר מאוד למדתי כי איכות התוצאה מצד הפיתוח נקבעת כבר ברמת קובץ הפיגמה שלכם המעצבים, עוד לפני שהקלדתי הוראה אחת.
שני קבצים יכולים להיראות זהים לחלוטין על המסך ולספק תוצאות שונות מאד. האחד מייצר רכיבים שתואמים את מערכת העיצוב שלכם כבר בסבב הראשון (בלי תיקונים). השני מייצר כפתור מעט שונה בכל עמוד, פשוט כי ל-AI לא היה במה להיאחז מלבד מלבן עם מילוי זהוב ופינות מעוגלות.
זו כמעט אף פעם לא בעיית עיצוב. זו בעיית הכנה.
אז זה הפוסט שאני מתכוון לשלוח בעת הצורך למעצבים בתחילת פרויקט. אין בו שום דבר על איך לעצב טוב יותר, אלא רק מידע על אותם דברים שקובעים אם ה-AI מבין את הקובץ שלכם או מנחש אותו. כתבתי כבר על הצד שלי בתהליך, אז תתייחסו לפוסט זה כחצי השני.
קפצו ישירות לחלק על Code Connect
מה ה-AI באמת רואה כשהוא פותח את הקובץ שלכם
ה-AI לא מסתכל על העיצוב שלכם. הוא מבקש מ-Figma רשימה של שכבות וקורא את ההגדרות שלהן, וזה הרבה יותר קרוב לקריאת דף מפרט מאשר להסתכלות על תמונה.
כלומר, מה שבניתם בלתי נראה עבורו. רק מה שהגדרתם עובר הלאה.
רכיב אמיתי עם properties בעלי שם מגיע בדיוק ככזה. קבוצת צורות שבמקרה נראית כמו כפתור מגיעה כקבוצת צורות, ואז ה-AI צריך לעבוד לאחור מהגאומטריה בכדי להבין למה התכוונתם.
וכשהוא עובד לאחור, הוא מנחש. הוא מנחש טוב, וזה בדיוק החלק המעצבן, כי התוצאה נראית בערך נכונה ואף אחד לא שם לב לסטייה עד עמוד תשע.
אותו כפתור בדיוק בשני קבצים: קבוצת צורות ללא שם, ורכיב שה-properties שלו קריאים ל-AI
סוכן AI יכול לראות רק את מה שהגדרתם, לא את מה שציירתם. רכיבים מפורסמים, properties אמיתיים ומשתנים הם לא ענייני סדר וניקיון. הם הדרך היחידה שלכם לומר לו מה משהו הוא, ולא רק איך הוא נראה.
קודם כל, פרסמו את הספרייה
אני מקבל שוב ושוב קבצים יפים (ואני מתכוון ליפים באמת) שבהם מערכת העיצוב קיימת כאוסף רכיבים שיושב בקובץ עבודה של מישהו ומעולם לא פורסם.
מהצד שלי, לקובץ הזה אין מערכת עיצוב בכלל. ה-AI רואה עותקים בודדים בלי ספרייה מאחוריהם, ומתייחס לכל אחד מהם כמקרה חד-פעמי.
הכלל פשוט: רק רכיבים שפורסמו לספריית צוות ניתנים לחיבור לקוד. רכיב שנבנה בתוך קובץ עמוד, גם אם נבנה בקפידה רבה, בלתי נראה לכל מה שאני עומד לתאר.
אם אתם לוקחים דבר אחד מפוסט זה, פרסמו את הספרייה. כל השאר תלוי בכך.
השתמשו ב-Component Properties אמיתיים, לא בעריכה ידנית של שכבות
ועכשיו לחלק שמעצבים מדלגים עליו לרוב (ולרוב לא בכוונה).
Figma נותנת לכם חמישה סוגים של Component Properties (חמישה, לא יותר), וכל אחד מהם מגיע אליי כמשהו אחר לגמרי. שימוש מודע בהם מאפשר לכם לכתוב הוראות למפתח בלי לגעת בשורת קוד אחת.
| סוג ה-property ב-Figma | למה זה הופך בקוד | מתי להשתמש |
|---|---|---|
| Text | הגדרת טקסט | תוויות, כותרות, טקסט placeholder |
| Boolean | מתג הפעלה וכיבוי | הצגה או הסתרה של אלמנט |
| Variant | רשימה סגורה של אפשרויות | גודל, סגנון, סטטוס, מצב |
| Instance swap | מגירה שמקבלת רכיב אחר | מקום לאייקון, מקום לאווטאר |
| Slot | אזור תוכן פתוח | גוף כרטיס שיכול להכיל כל דבר |
הנה מבחן פשוט. אם אתם מנתקים עותק בכדי לשנות בו משהו, או מסתירים שכבה ידנית במקום להפעיל property, ההחלטה הזו בלתי נראית. היא מגיעה אליי כהבדל בצורות, וה-AI או יתעלם ממנה או יקבע אותה קשיח באותו עמוד בודד ולא באף מקום אחר.
Instance Swap ראוי להתייחסות בפני עצמו. כשאייקון יושב ב-property אמיתי של החלפה, הקוד שנבנה מקבל כל אייקון. כשמדובר רק בשכבה שמישהו שינה לה את השם, הקוד מחפש את אותו אייקון ספציפי לפי שם, ונשבר בשקט ברגע שמישהו מחליף אותו.
תנו שמות ל-Variants כמו שמפתח היה עושה
מישהו חייב להחליט שה-״Large״ שלכם הוא ה-lg בקוד, ושה-״Type: Filled״ שלכם הוא ה-solid שלו. ההחלטה הזו נרשמת פעם אחת (פעם אחת בלבד), וכל רכיב שה-AI בונה יורש אותה.
כששמות ה-Variants שלכם כבר נקראים כמו הגדרות, התרגום מובן מאליו ואף אחד לא צריך לחשוב עליו. כשהם נקראים כמו שמות תואר שנבחרו בזמנים שונים על ידי אנשים שונים, מישהו מקבל החלטה שיפוטית, ובדרך כלל זה דווקא מי שמכיר את העיצוב הכי פחות.
| שמות שמייצרים עבודה | שמות שמתורגמים נקי |
|---|---|
| Style: Main / Alt / Quiet | Variant: Primary / Secondary / Ghost |
| Size: Big / Normal / Tiny | Size: Small / Medium / Large |
| רכיב נפרד לכל מצב | מצב כ-Variant על רכיב אחד |
| ״Icon?״ ברכיב אחד, ״Show icon״ באחר | אותו שם property בכל מקום שבו הוא מופיע |
עקביות לאורך הספרייה חשובה יותר מהמילים המדויקות שתבחרו. אם כל דבר קורא לאותו רעיון באותו שם, התרגום הופך מכני, וכל רכיב שחורג מכך הופך למשא ומתן קטן משל עצמו.
Code Connect: החלק שמפסיק את הניחושים
כל מה שעשינו עד עכשיו הופך את הקובץ שלכם לקריא. Code Connect הוא מה שמונע מה-AI להמציא משהו מלכתחילה.
Mapping ב-Code Connect הוא פתק קטן שמוצמד לרכיב מפורסם ואומר: הרכיב הזה בעיצוב הוא הרכיב ההוא בקוד. הוא כולל שלושה דברים.
- היכן רכיב הקוד יושב, למשל
src/components/Button.tsx, שזה פשוט שם של קובץ עם התיקיות שלו לפניו - איך הוא נקרא בקוד, למשל
Button - לאיזו טכנולוגיה ה-Mapping מיועד, למשל React
ברגע שהפתק הזה קיים, ה-AI מפסיק לקבל תיאור של מלבן ומתחיל לקבל את השם והמיקום האמיתיים של הכפתור שבו הוא אמור להשתמש. לא נשאר לו דבר לבנות מחדש.
Figma בדקה זאת באוגוסט 2026. עם Code Connect פעיל, ה-AI סיים משימות מהר יותר ב-19.6% ואיכות הקוד עלתה בנקודה שלמה בסולם של ארבע נקודות. הוא גם צרך 29.5% פחות tokens, כשהכוונה כאן היא לעומס העבודה של ה-AI עצמו (ולא ל-Design Tokens).
ללא Code Connect, הסוכן היה לפעמים ממציא גרסה משלו לרכיבים: למשל, בונה stepper מתוך progress bars. איתו, הסוכן רואה ייצוג מדויק של העיצוב כקוד […] כך שאיכות הקוד השתפרה משמעותית וחסכנו tokens באותה הזדמנות.
Erich Kuerschner, Frontend Engineer ב-Coinbase, מצוטט בBetter Code, Fewer Tokens
stepper שנבנה מתוך progress bars הוא בדיוק אותו כשל שאני מתאר כאן שוב ושוב, ולכן דווקא מרגיע לראות שצוות ב-Coinbase נתקל באותו קיר. הפתרון שלהם היה זהה לשלי: להפנות את ה-AI לרכיבים האמיתיים לפי שם, במקום לתת לו לאלתר.
אבל המספר שהכי מעניין אותי לא נמצא בכותרת. באותן בדיקות, Code Connect כיסה רק בין 6% ל-20% ממה שה-AI עבד איתו. כיסוי קטן כל כך הביא לתוצאה הזו, וזו התשובה שלי בכל פעם שמישהו אומר לי שאין לו זמן למפות ספרייה שלמה.
המדידות של Figma עצמה: כיסוי חד ספרתי עדיין הזיז כל אחד מהמספרים
כיצד ליצור Mapping בעצמכם
אתם יכולים לעשות זאת לבד (כן, לבד). בלי מפתח, בלי טרמינל, ובלי גישה לקוד.
פתחו את קובץ הספרייה המפורסם שלכם ועברו ל-Dev Mode מסרגל הכלים. לאחר מכן פתחו את התפריט הנפתח שליד שם הקובץ, בחרו Library ואז ״Connect components to code״. תקבלו רשימה של כל רכיב מפורסם בספרייה, עם תיבת חיפוש ופילטרים אם יש הרבה מהם. בחרו אחד ומלאו שני שדות.
- Source, שהוא נתיב הקובץ בצד של המפתח שלכם, משהו כמו
src/components/Button/Button.tsx - Component name, שהוא אופציונלי. השאירו אותו ריק ו-Figma תסיק אותו משם הרכיב בעיצוב
שמרו, וזה פעיל מיידית. אין מה לפרסם ואין צורך לחכות.
יש גם אייקון הגדרות שמקשר את Figma למקום בו המפתחים שלכם שומרים את הקוד, שאצל רוב הצוותים הוא GitHub. כל מה שהוא עושה זה להציע לכם נתיבי קבצים תוך כדי הקלדה ולאפשר לעיין בתיקיות. זה נוח, וזה אופציונלי לחלוטין. בקשו מהמפתח שלכם רשימת נתיבים פעם אחת, הדביקו אותם ידנית, ותוכלו למפות את כל הספרייה גם בלעדיו.
למפתח שלכם זה לוקח בערך חמש דקות וחוסך לשניכם שבועות של תיקונים קטנים.
כתבו את הכללים שאתם חוזרים עליהם שוב ושוב
לכל רכיב מחובר יש אפשרות בשם ״Add instructions for MCP״, ולדעתי זה השדה הכי מוזנח ב-Figma.
זו תיבת טקסט פשוטה, וכל מה שתכתבו בה מועבר ל-AI יחד עם ה-Mapping. כל מה שאתם יודעים על רכיב ושלא נראה בעיצוב שייך לכאן: כללי השימוש, דרישות הנגישות (בין היתר), ובעיקר אותה טעות אחת שכבר תיקנתם בארבעה סבבי עיצוב נפרדים.
הקאץ' הוא שהוראות מעורפלות לא משנות כלום.
| לא עושה כלום | משנה את מה שנבנה |
|---|---|
| השתמשו בכפתור הזה לפעולות. | אף פעם לא יותר מכפתור primary אחד במסך. פעולות משניות משתמשות ב-variant מסוג ghost. |
| ודאו שזה נגיש. | כפתורים עם אייקון בלבד חייבים תווית טקסט לקוראי מסך. |
| זה רכיב הכרטיס שלנו. | כרטיסים אף פעם לא לחיצים. אם עיצוב מציג כרטיס שלם כקישור, שאלו אותי לפני שאתם בונים. |
כתבו את זה פעם אחת, במקום שה-AI באמת קורא, ותפסיקו להשאיר את אותה הערה בסבבי העיצוב. אין כאן קוד, וזו הנקודה היחידה בכל התהליך שבה שיקול הדעת שלכם מגיע ישירות אל הבנייה.
מה למפות קודם
אף אחד לא מבקש מכם כיסוי מלא (באמת שלא). עברו על הרשימה לפי הסדר ועצרו כשהניחושים נפסקים. אם מוותרים על Code Connect לגמרי, עושים את זה ידנית: בבנייה מחדש של GN Law עקבתי אחרי מזהי node בהודעות הקומיט במקום, מה שעובד ולא מתרחב.
- כפתורים וקישורים. הם מופיעים יותר מכל דבר אחר, והם מה שה-AI ממציא מחדש הכי בעקביות
- שדות טופס. שדות טקסט, רשימות נפתחות, תיבות סימון. כל גרסה שגויה כאן היא בעיית נגישות
- רכיבי layout. כרטיסים, מכלים, גרידים. הם קובעים אם מבנה העמוד תואם לשלכם או נלחם בו
- אייקונים. Mapping אחד מכסה בדרך כלל את כל הסט ומסיים את בעיית האייקונים המומצאים
- כל דבר שיש לו כלל. אם אנשים ממשיכים להשתמש ברכיב לא נכון, מפו אותו וכתבו את הכלל בשדה ההוראות
דלגו על רכיבי שיווק חד-פעמיים, על כל דבר שאתם באמצע עיצוב מחדש שלו, ועל כל רכיב שאתם לא בטוחים לאיזה רכיב קוד הוא מתאים. Mapping חסר גורם ל-AI לנחש, ו-Mapping שגוי גורם לו לטעות בביטחון מלא, וזה לוקח הרבה יותר זמן לגלות.
עוד דבר שכדאי לדעת: ה-Mapping מצביע על נתיב קובץ ועל שם רכיב, והוא לא עוקב אחרי מה שקורה לאף אחד מהם. כשהמפתח שלכם מעביר את הרכיב או משנה את שמו, ה-Mapping מתיישן בשקט וה-AI ממשיך לסמוך עליו. ההמלצה של Figma עצמה היא לעדכן את ה-Mapping בכל פעם שהרכיב משתנה בקוד.
זה עובד גם בכיוון ההפוך. אם שיניתם שם או מחקתם רכיב ממופה ב-Figma, עדכנו את המפתח שלכם, כי שום דבר לא יתריע בפניו.
הצ'קליסט שאני שולח למעצבים
זה מה שאני בודק לפני שאני מפנה AI לקובץ, וזה גם הדבר הראשון שאני קורא כשמגיע אליי קובץ לבנייה מ-Figma לוורדפרס. הוא קצר בכוונה (אין טעם ברשימה שאף אחד לא עובר עליה).
- ספריית הרכיבים מפורסמת לספריית צוות
- צבעים, מרווחים וגדלי טקסט הם משתנים, לא ערכים שהוקלדו ידנית
- מכלים משתמשים ב-Auto Layout
- מצבים וגדלים הם Variants, לא רכיבים נפרדים
- טקסט, מתגי הפעלה וכיבוי ומקומות לאייקונים הם properties אמיתיים, לא שכבות שנערכו ידנית
- שמות ה-properties עקביים לאורך כל הספרייה
- שום דבר חשוב אינו עותק מנותק
- לרכיבים המרכזיים שלכם יש Mappings של Code Connect
- לרכיבים הממופים יש הוראות שמתארות כיצד באמת נכון להשתמש בהם
שבעת הראשונים לא עולים דבר מלבד תשומת לב. לפני שאתם מתכננים את שני האחרונים, בדקו דבר אחד עם מי שמשלם על ה-Figma שלכם.
Code Connect דורש מושב Dev או Full בתוכנית Organization או Enterprise. הוא אינו זמין בתוכניות Free או Professional, ואין דרך לעקוף זאת. כל שאר הצ'קליסט עדיין רלוונטי, אז בצעו את כולו. המפתח שלכם יוכל לכתוב את כללי הרכיבים בצד שלו במקום.
שאלות נפוצות
השאלות שמעצבים שואלים אותי בדרך כלל כשהנושא עולה.
סיכום
AI שבונה מתוך קובץ ה-Figma שלכם לא מסתכל על העיצוב. הוא קורא את מה שהגדרתם, וכל פער שתשאירו יתמלא בניחוש.
רוב התיקון לא עולה דבר מלבד תשומת לב. פרסמו את הספרייה, השתמשו ב-Component Properties אמיתיים במקום בעריכה ידנית של שכבות, ותנו שמות ל-Variants כמו שמפתח היה עושה. העבודה הזו משתלמת בין אם מישהו יגדיר Code Connect ובין אם לא, ולכן הייתי מתחיל בה גם בפרויקט שלא יכול להרשות לעצמו את המושבים.
ואז הוסיפו את ה-Mappings. קודם כפתורים, שדות טופס ורכיבי layout, ותוך כדי כתבו את כללי השימוש האמיתיים שלכם בשדה ההוראות. המספרים של Figma עצמה אומרים שלא צריך הרבה כדי שזה יורגש, וזה תואם למה שאני רואה בפרויקטים שלי.
וכשתשבו לעשות את זה, מדריך ההגדרה של Figma ל-Code Connect בממשק עובר על אותם מסכים בדיוק ובאותו סדר, אז שמרו אותו פתוח בלשונית שנייה.
