ميتا تفتح مصدر Astryx: نظام تصميم على React 19 وStyleX للبشر ووكلاء الذكاء الاصطناعي

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

ما المشكلة التي يحلها Astryx؟

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

كُتب نظام التصميم الكلاسيكي للبشر. يُقرأ بالعين، عبر الصور في Figma والصفحات في Confluence. أما الوكيل فيحتاج إلى شيء آخر: قائمة واضحة بالمكوّنات، وأسماء مفهومة، وأمثلة استخدام، وقيود لا يستطيع تجاوزها. فكرة Astryx هي منح الوكيل نظاماً حقيقياً بدلاً من حرية الإبداع. يستخدم المطوّر ومساعده مجموعة المكوّنات نفسها.

ما المعروف حتى اليوم

من الإعلان تتضح الحقائق التالية:

• النظام قابل للتخصيص بالكامل؛
• مبني على React 19 وStyleX؛
• يتوفر توثيق وStorybook وساحة تجارب تفاعلية؛
• ترخيص MIT؛
• المشروع في مرحلة بيتا.

StyleX هي مكتبة CSS-in-JS من ميتا نفسها، تحوّل الأنماط أثناء البناء إلى فئات ذرّية ثابتة. وهذا مناسب للوكيل: فالأنماط تُوصف بطريقة متوقعة وذات أنواع محددة، لا كمجموعة نصوص عشوائية متناثرة. ويعني ترخيص MIT أنه يمكن استخدام النظام في منتج تجاري وعمل fork له دون متاعب قانونية.

لا يتضح من المنشور كيف يعمل النظام مع الوكلاء تحديداً. ولا يُعرف إن كانت هناك تعليمات منفصلة للوكلاء أو قواعد جاهزة أو تكامل مع بروتوكولات مثل MCP. يجب التحقق من ذلك في التوثيق بدلاً من استنتاجه من العنوان.

كيف يبدو ذلك عملياً

تخيّل المهمة: «ابنِ صفحة إعدادات الملف الشخصي». دون نظام تصميم يكتب الوكيل حقول الإدخال والمفاتيح والشبكة الخاصة به. ومع Astryx يستورد مكوّنات جاهزة ويبني منها الصفحة. وإذا احتاج مكوّن إلى تعديل، فإن التعديل يتم مرة واحدة في النظام وينعكس فوراً على كل الشاشات.

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

القيود وما العمل

أهم قيد هو أن المشروع في مرحلة بيتا. قد تتغير واجهات API، وقد تكون بعض المكوّنات غير ناضجة. ومن المخاطرة اليوم إدخال Astryx في منتج فعلي لديه مليون مستخدم. القيد الثاني هو البنية التقنية. إذا كنت تستخدم Vue أو Svelte أو React مع Tailwind الخاص بك، فقد تكلّف الهجرة إلى StyleX أكثر من مكاسبها.

خلاصة عملية للفرق التي تعمل بالفعل مع الوكلاء:

1. افتح ساحة التجارب ومرّر شاشة حقيقية واحدة عبر وكيلك، مع منحه إمكانية الوصول إلى توثيق Astryx.
2. قارن النتيجة بما ينتجه الوكيل دون النظام: كم تعديلاً احتاج المراجع؟
3. حتى لو لم يناسبك Astryx، فاحتفظ بالمبدأ. الوكيل لا يحتاج إلى صورة في Figma، بل إلى كتالوج مكوّنات مقروء آلياً مع أمثلة وقيود.

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