أصبح السياق هو عنق الزجاجة في التطوير بمساعدة الذكاء الاصطناعي. ليس قدرة النموذج. النماذج تتطور بسرعة كافية بحيث إنها لا تمثّل القيد في الغالب. ما يحدّ من جودة الكود المولَّد بالذكاء الاصطناعي هو جودة السياق الذي تتلقاه تلك النماذج.

في سير عمل Figma إلى كود، يأتي السياق في صورتين مختلفتين جوهريًا: سياق البكسل (لقطات الشاشة، الصور المصيَّرة) والسياق المنظّم (IR مكتوب، رموز، علاقات دلالية). هذه ليست مجرد صيغ مختلفة للمعلومة ذاتها. إنها فئات مختلفة من المدخلات، بخصائص مختلفة، وخصائص فقدان مختلفة، وسقوف مختلفة لما يمكن للوكيل إنتاجه منها.

لا تزال الصناعة تستخدم سياق البكسل في معظمها. هذا خطأ. تُصدّر figmascope السياق المنظّم — المدخل الصحيح من البداية.

ما هو سياق البكسل

سياق البكسل هو أي تمثيل بكسلي لتصميم: لقطة شاشة مُصدَّرة من Figma، صورة PNG من "Export frame"، تصيير من أداة تصميم. هو ما تحصل عليه حين تضغط Cmd+Shift+4 فوق لوحة Figma.

تستطيع نماذج اللغة الكبيرة ذات القدرة البصرية معالجة سياق البكسل بشكل مثير للإعجاب. تتعرف على أنماط الواجهة، وتحدد مناطق التخطيط، وتستنتج أنواع المكوّنات من المظهر البصري، وتولّد كودًا معقولًا من الصور وحدها. إن كنت استخدمت Claude أو GPT-4V للتحويل من لقطة الشاشة إلى كود، فقد رأيت هذا. المخرجات تبدو صحيحة أكثر مما تتوقع.

لكن "يبدو صحيحًا" و"هو صحيح" ليسا الشيء ذاته، والفجوة بينهما هي حيث تعيش مطابقة نظام التصميم، وأمانة الرموز، وهوية المكوّنات، وقابلية الاستنساخ.

ما هو السياق المنظّم

السياق المنظّم هو تمثيل مكتوب وقابل للقراءة آليًا يحفظ دلالات التصميم: ما كل عنصر هو، لا مجرد ما يبدو عليه. يشمل:

IR الخاص بـ figmascope هو هذا بالضبط. كل عقدة في JSON لكل شاشة لها kind وname وabsoluteBoundingBox وchildren وتعبئات محوَّلة إلى مراجع رموز حيثما توفّرت، وخصائص auto-layout إن وُجدت، وcomponentId على النسخ. إنها شجرة التصميم مُوضَحة صراحةً.

سياق البكسل يخبر الوكيل كيف يبدو التصميم. السياق المنظّم يخبره ماذا يعني التصميم. وكيل البرمجة يحتاج المعنى لكتابة الكود لا المظهر. المظهر هو ما الاختبارات البصرية مخصصة له.

ما يُفقد في اتجاه البكسل إلى المنظّم

نمط الفشل الأساسي لسياق البكسل هو فقدان المعلومات الذي لا يمكن عكسه. حين تُصيَّر Figma إطارًا إلى PNG، تتخلص تحديدًا من المعلومات الأهم لتوليد الكود:

تنهار شجرة الطبقات. لم يعد هناك "مجموعة من ثلاثة عناصر بفجوات 8px". يوجد منطقة من البكسلات تُوحي بمجموعة. على الوكيل إعادة بناء بنية الشجرة من دليل بصري، والإعادة تقريبية. ستكون خاطئة في نسبة مئوية من الأوقات. تلك النسبة ترتفع مع تعقيد التصاميم.

تختفي روابط الرموز. الخلفية البرتقالية المرتبطة بـ color/action/primary تصبح #FF6B00. يولّد الوكيل hex مُثبَّتًا. إن تغيّر لونك يومًا، أو دعمت الوضع الداكن، أو احتجت مراجعة استخدام الرموز، فذلك القيمة المُثبَّتة مسؤولية.

هوية المكوّنات ذهبت. أربع نسخ من مكوّن البطاقة ذاته تصبح أربعة مستطيلات متشابهة المظهر. قد يولّد الوكيل مكوّنًا واحدًا قابلًا لإعادة الاستخدام أو أربعة كتل متشابهة لكنها غير متطابقة، بحسب مقدار التشابه البنيوي الذي يستنتجه. تريد مخرجات قابلة للتنبؤ؛ تحصل على مخرجات احتمالية.

نية التخطيط غامضة. هل هذا صف flex أم grid؟ هل المسافة بين العناصر فجوة أم هامش أم حشو لكل عنصر؟ البكسلات لا تقول. الوكيل يختار. الاختيارات تتباين بين التشغيلات.

مسار Figma إلى React، مع ودون البنية

فكر في المسار من Figma إلى React للإنتاج.

مع سياق البكسل: صدّر PNG. الصقه في Claude. احصل على JSX. راجع JSX للصحة. لاحظ القيم المُثبَّتة. لاحظ بنية المكوّن الخاطئة. اطلب التصحيحات. كرّر. في النهاية احصل على شيء معقول. حرّره يدويًا لمطابقة نظام التصميم. أشحن. الشاشة التالية: كرّر من الصفر لأن مخرجات التشغيل السابق لا تتكامل.

مع السياق المنظّم: صدّر الحزمة (نقرة واحدة، تعمل في المتصفح). مرّر CONTEXT.md + IR الشاشة إلى Claude مع موجّه النظام الذي يحدد الإطار والاتفاقيات. احصل على JSX يستخدم أسماء رموزك وأسماء مكوّناتك وبنية التخطيط الصحيحة. راجع للصحة. أشحن. الشاشة التالية: نفس الحزمة، نفس الوكيل، مخرجات متكاملة لأن المدخلات متسقة.

توفير العمل حقيقي لكن ثانوي. المكسب الأساسي هو قابلية التكامل. السياق المنظّم يُمكّن مخرجات تتكامل عبر الشاشات والوكلاء. سياق البكسل لا يفعل — مخرجات كل شاشة جزيرة مولَّدة من تمريرة استنتاج جديدة.

البنية تعني: مكتوب

لكل عقدة في IR نوع kind. هذا مهم فورًا. عقدة TEXT تولّد عنصر نص. FRAME بـ auto-layout يولّد حاوية. نسخة Button/Primary/Large تولّد استدعاء مكوّن زر بالخصائص الصحيحة. VECTOR يولّد مرجع أيقونة.

الوكيل لا يخمّن. يُعيّن الأنواع إلى بدائيات الكود. التعيين مُحدَّد في CONTEXT.md للإطار المستهدف. "لعقد INSTANCE، استخدم اسم المكوّن لتحديد مكوّن React. لـ FRAME بـ layoutMode أفقي، استخدم صف flex. لـ TEXT بنمط typography/heading.lg، استخدم مكوّن Heading." هذه قواعد شبيهة بالمُصرِّف، لا مهام استنتاج.

البنية تعني: مكاني

يمنح absoluteBoundingBox على كل عقدة الموضع والحجم في فضاء إحداثيات Figma. مقترنًا بخصائص auto-layout — layoutMode وitemSpacing وpaddingLeft/Right/Top/Bottom وprimaryAxisAlignItems وcounterAxisAlignItems — لدى الوكيل كل ما يحتاجه لتوليد كود تخطيط صحيح دون عدّ البكسلات.

تتيح الصناديق المحيطة المطلقة أيضًا للوكيل التحقق من مخرجاته: إذا كان للمكوّن المولَّد أبعاد مختلفة عما حدده IR، فشيء ما أخطأ. هذه خاصية قابلة للاختبار في السياق المنظّم لا مكافئ لها في سياق البكسل.

البنية تعني: مُدركة للهوية

حين تشترك أربع عقد في IR في componentId واحد، يعرف الوكيل أنها نسخ من المكوّن ذاته. يولّد تعريف المكوّن مرة واحدة، ويشتق الخصائص من المتغيرات في النسخ، ويصيّر أربعة استدعاءات. هذا هو المخرج الصحيح. لا يمكن تحقيقه من سياق البكسل دون هندسة موجّه مكثّفة تطلب من الوكيل إعادة اشتقاق البنية التي ملف التصميم يمتلكها أصلًا.

المراجع الصليبية للنصوص تعمل بالطريقة ذاتها. حين تُشير عقد نصية متعددة إلى stringRef.key: "action.continue"، يعرف الوكيل استخدام بحث i18n واحد لا ثلاثة نصوص مُثبَّتة. المعلومة هوياتية في IR؛ الوكيل فقط يقرأها.

البنية تعني: قابل للإصدار

ملفات JSON العادية تُفرَّق بنظافة. قيمة حشو متغيرة تظهر كتغيير سطر واحد في IR لكل شاشة. رمز مُعاد تسميته يظهر كفرق بحث-واستبدال عبر ملف الرموز. نسخة مكوّن جديدة تظهر ككائن مضاف في مصفوفة children.

هذا تاريخ إصدار تصميم مفيد فعلًا للمهندسين. ليس "التصميم تحدّث يوم الثلاثاء" بل "إليك الخصائص الثلاث التي تغيّرت بين تصدير v2 وv3 لهذه الشاشة." يمكنك وضع هذا في وصف PR الخاص بك. يمكنك تشغيل فحوصات آلية عليه. يمكنك استخدامه للتحقق مما إذا كان تغيير الكود يتوافق مع تغيير التصميم.

أين يقود هذا: بنية تحتية لسياق التصميم

فئة الأدوات التي تتشكّل هنا ليست "تصدير Figma، لكن أفضل." إنها طبقة جديدة في المكدّس: بنية تحتية لسياق التصميم. مهمة هذه الطبقة تحويل مصدر التصميم (ملفات Figma، مكتبات المكوّنات، أنظمة الرموز) إلى نتائج منظّمة وقابلة للقراءة من قِبَل الوكلاء ومُصنَّفة إصدارًا تغذّي طبقة توليد الكود.

هذه الطبقة تقع بين أداة التصميم ووكيل البرمجة. لها مسؤوليات لا يمتلكها أي من الجانبين حاليًا: إدارة اللقطات، الاستخراج الدلالي، تحليل الرموز، مخزون المكوّنات، فهرسة النصوص عبر الشاشات، إصدار الحزم. هذه هموم بنية تحتية، لا هموم أداة تصميم ولا هموم نموذج لغة كبير.

معاملتها كبنية تحتية تعني: إنها آلية، مُصنَّفة إصدارًا، تعمل في CI، لها صيغة محدودة، قابلة للتفتيش. بنفس الطريقة التي نظام البناء بنية تحتية للكود — ليس الكود نفسه، وليس الثنائي المستهدف، بل المسار الموثوق والمُستنسَخ الذي يحوّل الأول إلى الثاني.

بصدق: البكسلات لا تزال مهمة

تتضمن حزم figmascope صور PNG بضعف الدقة لكل شاشة مُصدَّرة. ليس لأن PNG يقود توليد الكود، بل لأن التأكيد البصري مهم. ينبغي للوكيل أن يُقاطع مخرجاته المولَّدة مع PNG. يجب على المطوّر رؤية الشاشة دون فتح Figma. PNG فحص منطقي لا مواصفة.

هذا التمييز — البكسلات للتأكيد، البنية للمواصفة — هو النموذج الذهني الصحيح. لا تُلغي سياق البكسل؛ تُخفضه إلى دوره الصحيح. إنه نتاج ضمان الجودة، لا مدخل البناء.

بنفس الطريقة التي لن تعطي فيها مُصرِّفًا لقطة شاشة لكودك المصدري: تعطيه المصدر، وتستخدم لقطات الشاشة للتوثيق. ملف التصميم هو المصدر. الحزمة هي نتاج التجميع. PNG هي صورة التوثيق.

أين يقود هذا لتوليد كود متعدد الأهداف

السياق المنظّم يُمكّن سير عمل لا يستطيع سياق البكسل تحقيقه: تصميم واحد، أهداف متعددة. يمكن لنفس IR تغذية مولّد React/Tailwind ومولّد Jetpack Compose ومولّد SwiftUI. التصميم الأساسي واحد؛ السياق الخاص بكل هدف (بدائيات الإطار، اتفاقيات التسمية، واجهات برمجة التخطيط) يعيش في CONTEXT.md الذي يُولَّد لكل هدف.

هذا توليد كود متعدد الأهداف يتوسع فعلًا. تُصدّر حزمة واحدة من التصميم. تُشغّل ثلاثة وكلاء بثلاثة ملفات CONTEXT.md مختلفة. تحصل على ثلاثة تطبيقات متكافئة بنيويًا لأنها مولَّدة من نفس IR لا من ثلاث تمريرات استنتاج مستقلة على ثلاث لقطات شاشة.

عنق الزجاجة في هذا سير العمل ليس قدرة النموذج. إنه جودة السياق. السياق المنظّم هو ما يجعله ممكنًا.

صدّر حزمة السياق المنظّم من تطبيق figmascope الرئيسي، ثم استخدمها مع Cursor أو Claude Code أو Aider لتوليد واجهة متكاملة متعددة الأهداف.