إليك سير العمل الذي أصبح افتراضيًا في كل فريق تصميم إلى كود الآن: تصدير إطار من Figma، لصق صورة PNG في Claude أو Cursor، كتابة "ابنِ هذا"، والتكرار من المخرج المُختلَق. يعمل بما يكفي لتشعر بإنتاجية. لا يعمل بما يكفي للشحن منه.
هذه ليست مشكلة قدرة نموذج. إنها مشكلة مدخلات. لقطة الشاشة هي أسوأ تمثيل ممكن لتصميم Figma حتى يستدل عليه نموذج لغة كبير — وهي تقريبًا ما تصل إليه الفرق أولًا. حزمة سياق figmascope هي البديل المنظّم.
التسلسل الهرمي ذهب
ملف Figma شجرة. الإطارات تحتوي على مجموعات auto-layout، التي تحتوي على نسخ مكوّنات، التي تحتوي على طبقات نص وتعبئة. تلك الشجرة تُرمّز نية التخطيط: هذا الصف حاوية flex، هذه البطاقة صندوق بحشو، هذه العناصر الثلاثة أشقاء بفجوات 16px بينها.
لقطة الشاشة تُسطّح تلك الشجرة إلى شبكة من البكسلات. نموذج اللغة الكبير يرى الأشكال والألوان. لا يرى بنية التخطيط — يستنتجها. والاستنتاج تفقيدي في الاتجاهين: قد يعيد النموذج بناء بنية تبدو صحيحة بصريًا لكنها خاطئة دلاليًا (div بعرض ثابت بدلًا من فرع flex، وضع مطلق بدلًا من auto-layout)، أو قد يرى غموضًا بنيويًا ويختار بشكل عشوائي.
لا يمكنك معرفة من PNG ما إذا كان صف أفقي من العناصر مُطبَّقًا بـ display: flex أو CSS Grid أو HStack مخصص أو ثلاثة divs بوضع مطلق. إنها متطابقة بصريًا. نموذج اللغة الكبير يختار واحدة. الاختيار يتغيّر بين التشغيلات.
الدلالات لا تنجو من التنقيط
يستطيع نموذج اللغة الكبير رؤية أن مستطيلًا بزوايا مدوّرة يحتوي على نص وأيقونة. ما لا يستطيع رؤيته:
- هل هذا مكوّن
Buttonأم بطاقة مخصصة؟ - إن كان زرًا، ما نوعه — أساسي، ثانوي، شبح؟
- هل الأيقونة زخرفية أم ذات معنى؟
- هل لهذا العنصر حالات تفاعلية في نظام التصميم، أم هو حالة فردية؟
الدلالات في Figma تعيش في شجرة الطبقات: أسماء المكوّنات وخصائص المتغيرات وأنواع العقد. مكوّن Button/Primary/Large مكتوب صراحةً. في لقطة الشاشة، إنه مستطيل بزوايا مدوّرة وظل وتسمية. يخمّن النموذج "هذا على الأرجح زر" بشكل صحيح في معظم الأوقات — ثم يخمّن "هذا على الأرجح النوع الأساسي" استنادًا إلى اللون، الذي قد يتوافق أو لا يتوافق مع التسمية الفعلية لنظام التصميم.
التناقضات الصغيرة تتضاعف. زر شبح مُصيَّر كزر مُحاط. تلميح مُصيَّر كمشغّل نافذة مشروطة. حالة معطّلة مُصيَّرة كنشطة. كل هذه خطوة استنتاج لقطة شاشة واحدة بعيدة عن مصدر الحقيقة.
أنظمة المسافات لا تُحلّ إلى أرقام
انظر إلى لقطة شاشة لبطاقة بحشو. ما الحشو؟ لا يمكنك معرفة ذلك دون قياس البكسلات، معرفة مقياس اللوحة، معرفة دقة التصدير، وإجراء الحساب. نموذج اللغة الكبير يُجري الحساب بشكل سيئ — يُقدّر ويُقرّب، وليس لديه طريقة لمعرفة ما إذا كان نظام المسافات يستخدم شبكة أساسية 8px أو 4px أو شيئًا مخصصًا.
لذا يخمّن. يولّد padding: 12px حين التصميم يقول 16. يولّد gap: 8px حين التصميم يقول 12. هذه الأرقام تبدو معقولة بشكل منفرد لكنها خاطئة — وإن كان نظام تصميمك يستخدم رموز مسافات كـ spacing.md أو Spacing/400، فنموذج اللغة الكبير لا يعرف عنها شيئًا. يُثبّت قيمًا حرفية ستنجرف عن نظامك في لحظة أي تغيير.
نموذج اللغة الكبير لا يختلق. إنه يفعل تمامًا ما ستفعله بلقطة شاشة فقط: يخمّن. أنت فقط تفاجأ حين تكون التخمينات خاطئة لأنك كنت ترى الإجابة الصحيحة في ملف Figma طوال الوقت.
علاقات الرموز تتلاشى
المصمم ضبط تلك الخلفية على #7F5CFE. في Figma، ذلك hex مرتبط بمتغير: color/brand/primary. الارتباط ذو معنى — يعني أن اللون يشارك في التنسيق، يعني أن الوضع الداكن يبدّله، يعني أنه إن تغيّر لون العلامة التجارية تُحدّث متغيرًا واحدًا وكل النسخ تتحدث.
في لقطة الشاشة: إنه أرجواني. يولّد نموذج اللغة الكبير background-color: #7F5CFE. علاقة الرمز ذهبت. قاعدة الكود الخاصة بك لديها الآن hex مُثبَّت لن يتتبع نظام تصميمك أبدًا. اضرب هذا في كل مكوّن في الشاشة.
ينطبق الأمر ذاته على مقاييس الطباعة وأنصاف أقطار الحدود وتعريفات الظل. كل قيمة في ملف Figma محافَظ عليه هي رمز مُسمَّى محتمل. كل قيمة في لقطة الشاشة مجرد رقم.
إعادة استخدام المكوّنات غير مرئية
الشاشة المؤلَّفة جيدًا تُعيد استخدام المكوّنات. بطاقات المنتج الأربع هي أربع نسخ من المكوّن ذاته ProductCard. الصورة الرمزية في التنقل والصورة الرمزية في خيط التعليق هما نسختا Avatar/Medium. هذا مهم للكود: تريد مكوّن React واحدًا لا أربعة أشكال يدوية ستتباين.
من لقطة الشاشة، يرى نموذج اللغة الكبير أربعة مستطيلات متشابهة بصريًا. قد يولّد مكوّنًا واحدًا قابلًا لإعادة الاستخدام — أو قد يولّد أربعة كتل JSX شبه متطابقة لأنه لم يلاحظ أنها الشيء ذاته. لا إشارة في الصورة تخبره أيّهما صحيح.
الـ IR الذي تُصدّره figmascope يحمل componentId على كل عقدة نسخة. يعرف الوكيل: هذه العقد الأربع كلها ProductCard. ولّدها مرة واحدة، أصيّرها أربع مرات بخصائص مختلفة. هذا هو المخرج الذي تريده. هذا هو المخرج الذي لا يمكن الحصول عليه من البكسلات.
هوية النصوص ضائعة
لديك زر "Continue" في ثلاث شاشات مختلفة. هل هذه النسخ الثلاث النص ذاته، أم كتبها مصمم بشكل مستقل؟ في ملف Figma المبني بشكل جيد، تُشير إلى مفتاح النص ذاته. هذا يعني إدخال i18n واحدًا، تغيير واحد ينتشر في كل مكان.
في ثلاث لقطات شاشة: ثلاث مرات يولّد نموذج اللغة الكبير نصًا مُثبَّتًا. إن كنت تبني تطبيقًا مُعوْلَمًا، لديك الآن ثلاثة نصوص لإيجادها واستبدالها بدلًا من واحد للبحث عنه. شيء صغير. يتضاعف عبر قاعدة كود حقيقية.
لماذا يختلق نموذج اللغة الكبير: يعيد اشتقاق البنية في كل مرة
النموذج لا يتذكر التشغيلات السابقة. في كل مرة تلصق لقطة الشاشة ذاتها، يعيد بناء البنية من الصفر. الإعادة احتمالية — ما يعني أن لقطة الشاشة ذاتها + الموجّه ذاته + النموذج ذاته يمكن أن يُنتجا مخرجات مختلفة قابلة للقياس في تشغيلات مختلفة. نفس التصميم، كود مختلف. أسماء مكوّنات مختلفة، أنماط className مختلفة، خيارات تخطيط مختلفة.
هذه ليست ثغرة نموذج. إنه السلوك المتوقع من نموذج احتمالي عند إعطائه قيودًا غير كافية. لقطة الشاشة توفّر قيودًا غير كافية. يملأ النموذج الثغرات. الثغرات تُملأ بشكل مختلف في كل مرة.
يمكنك التحايل جزئيًا على هذا بموجّهات أطول وأكثر تفصيلًا — "استخدم Tailwind، استخدم شبكة 8px، استخدم أسماء المكوّنات هذه..." — لكنك حينها حدّدت يدويًا البنية التي كان ينبغي أن تكون في ملف التصميم أصلًا. أنت تقوم بعمل الاستخراج الذي يجب أن تقوم به الأداة.
مشكلة قابلية الاستنساخ
الفرق التي تستخدم لقطات الشاشة لتسليم التصميم إلى الكود تواجه المشكلة ذاتها: المخرج غير قابل للاستنساخ. مطوّران، نفس لقطة شاشة Figma، يوجّهان Claude بشكل مستقل — يحصلان على بنيتَي مكوّنات مختلفتين، وأنماط className مختلفة، وقرارات تداخل مختلفة. الآن لديك قاعدتا كود تبدوان بصريًا متطابقتين لكنهما غير متسقتين معماريًا.
هذا يُصعّب مراجعة الكود. يُصعّب إعادة الهيكلة. يجعل تدقيق توافق نظام التصميم مستحيلًا. لا يمكنك مقارنة "ما ولّده الوكيل من هذا التصميم" إن كانت الإجابة تتغيّر في كل تشغيل.
السياق المنظّم يُصلح قابلية الاستنساخ لأنه يُصلح المدخلات. حزمة مدخلات حتمية — نفس JSON بنفس معرّفات العقد وأسماء المكوّنات وقيم الرموز والعلاقات المكانية — ستُنتج مخرجات أكثر اتساقًا بكثير عبر التشغيلات والوكلاء والمطوّرين. ليست حتمية كليًا: النموذج لا يزال احتماليًا. لكن التباين يتراجع بشكل حاد حين تُحدَّد البنية لا تُستنتج.
ما تمنحه لقطة الشاشة مقابل ما يمنحه IR
خذ بطاقة منتج: صورة، عنوان، عنوان فرعي، سعر، زر "أضف إلى السلة". إليك ما يمنح كل مدخل للوكيل:
مدخل لقطة الشاشة: مستطيل بصورة في الأعلى وسطرين من النص ورقم وزر. الألوان مستنتجة. الحشو مُقدَّر. ما إذا كان هذا مكوّنًا أو حالة فردية غير معروف. نوع الزر مستنتج من اللون. نظام المسافات غير معروف.
مدخل IR: نوع العقدة FRAME، الاسم ProductCard، معرّف المكوّن الذي يرتبط بتعريف المكوّن. auto-layout باتجاه رأسي، فجوة 16px، حشو أفقي 16px، حشو رأسي 12px. العقد الفرعية: IMAGE (تملأ العرض، ارتفاع ثابت)، TEXT بـ stringRef.key: "product.title" ونمط typography/heading.sm، TEXT بـ stringRef.key: "product.subtitle" ونمط typography/body.md، TEXT بتعبئة color/price، INSTANCE من Button/Primary/Medium. تعبئة خلفية color/surface.card. نصف قطر حدود radius/card.
IR يمنح الوكيل مواصفة. لقطة الشاشة تمنحه اقتراحًا.
الإطار: هذه مشكلة التوثيق
حللنا هذه المشكلة بالضبط للكود المصدري منذ عقود. لا تعطي وكيلًا لقطة شاشة لقاعدة كودك وتطلب منه الاستدلال على البنية. تعطيه الكود — التمثيل المنظّم القابل للتحليل ذو المعنى الدلالي. شجرة البنية التجريدية، لا صورة من المحرر.
تصاميم Figma بيانات منظّمة. لها بنية شجرة محددة جيدًا مع عقد مكتوبة وقيم مُسمَّاة. تعرض واجهة Figma البرمجية هذه البنية بالكامل. السبب الوحيد لاستمرار سير عمل لقطة الشاشة هو أن استخراج البنية وتنسيقها كسياق يواجه احتكاكًا.
تقليل ذلك الاحتكاك هو ما تفعله figmascope. تلصق رابط Figma، يعمل التصدير في متصفحك، وتحصل على ZIP بسياق منظّم: CONTEXT.md، tokens.json، IR لكل شاشة، مخزون المكوّنات، بيان النصوص. كل ما يحتاجه الوكيل، لا شيء منه مستنتَج من البكسلات.
احتفظ بلقطات الشاشة للتأكيد البصري — الحزمة تتضمن صور PNG بضعف الدقة لهذا الغرض تحديدًا. استخدم البنية لكل شيء آخر. شاهده في التطبيق: سير عمل Cursor، سير عمل Claude Code، أو سير عمل Aider.