Vercel تعلّم وكلاء الذكاء الاصطناعي فهم القرارات المنتجية بدل الاكتفاء بنسخ الشيفرة

نشرت Vercel وصفًا مفصّلًا لنظامها product-design، وهو مجموعة أدوات تساعد وكلاء الذكاء الاصطناعي على فهم سبب تحوّل مكوّن أو عبارة أو تفاعل بعينه إلى معيار في المنتج، بدل الاكتفاء بنسخ الأسلوب والأنماط.

الوكلاء لا يفهمون «السبب»

تنجز وكلاء البرمجة الحديثة المهام بسرعة: تكتب واجهة مستخدم عاملة، وتنسخ الأسلوب البصري، وتكرر الأنماط الموجودة في المستودع. لكن المشكلة في مكان آخر: فهي لا تفهم الأسباب التي تقف وراء هذه القرارات. فمنطق مكوّن معيّن أو صياغة معيّنة أو تفاعل معيّن يُحفظ عادةً في سلاسل محادثات Slack، وفي تعليقات مراجعات التصميم (design review)، وفي ملاحظات طلبات الدمج (PR)، وفي ذاكرة الأشخاص الذين حضروا ذلك الاجتماع. وهذا السياق غير موجود بالنسبة إلى الوكيل، إذ لا يعمل إلا بما وصل إلى قاعدة الشيفرة.

تعاملت Vercel مع المشكلة بأسلوب جذري: كل القرارات المنتجية المعتمدة أصبحت الآن تُحفظ في المستودع على قدم المساواة مع الشيفرة. فهي تخضع للمراجعة عند أي تغيير، وتتوافر تلقائيًا لأي وكيل يعمل في المشروع.

ما الذي يتضمنه النظام

يتكوّن النظام من ثلاثة مكوّنات.

المهارة (skill) تعيش في المسار `.agents/skills/product-design/` بجوار الشيفرة التي تديرها مباشرة. وتضم قسمين أساسيين. يحتوي `references/` على وثائق عن القرارات المنتجية وجودة الواجهة والمتانة (resilience) والكتابة التسويقية والتحريرية (copywriting)، إضافةً إلى قاموس للمصطلحات والملف `coverage-gaps.md`، وهو قائمة بالمجالات التي لم يتشكّل فيها معيار بعد. أما `exemplars/` فيوثّق قرارات من طلبات دمج سابقة ينبغي تكرارها، وأخطاء ينبغي تجنّبها.

أدوات الفحص (linters) تتحقق تلقائيًا من كل ما يمكن التحقق منه آليًا. فما يمكن فحصه دون تدخل بشري يجب أن يُفحص دونه.

دورة التحديث تجمع الإشارات من Slack وFigma وGitHub، وتجمّعها، وتعدّ تحديثات الإرشادات لتُعرض على الفريق للموافقة النهائية.

كيف توجّه المهارة المهام

يعمل الملف SKILL.md كموجّه (router). فهو يحدد أولًا نمط الطلب: shape أو implement أو review أو copy أو harden. وهذا أمر جوهري، فلا ينبغي أن يتحول التدقيق إلى تحرير نصي، ولا أن تتوسع مهمة الكتابة إلى إعادة تصميم. كما تتجاوز المهارة المهام التي لا أثر ظاهرًا لها على واجهة المستخدم، مثل منطق الواجهة الخلفية (backend) فقط، والقياس عن بُعد (telemetry)، والملفات المولَّدة.

وبعد تحديد النمط، توجّه المهارة الوكيل إلى المصادر المناسبة بحسب نوع المهمة والسطح المعني تحديدًا:

• تغييرات مواد الواجهة تحمّل `product-judgment.md` و`interface-quality.md`
• العمل على النصوص يقود إلى `copy.md` وإلى صيغ الأفعال المعتمدة في المنتج
• النافذة المنبثقة (modal) تستدعي أنماط الإجراءات الهدّامة (destructive actions) والأفعال المعتمدة (canonical verbs)
• نموذج الإعدادات يستدعي التسميات (labels) والتحقق من صحة المدخلات (validation) والإفصاح التدريجي (progressive disclosure) وإرشادات الأسماء المتاحة للوصول (accessible-name)

ولا تكرر المهارة المصادر نفسها: فواجهة برمجة المكوّنات (Component API) وقواعد نظام التصميم ومعايير إمكانية الوصول تبقى لدى أصحابها، وتكتفي المهارة بالإشارة إليها.

«تُظهر الشيفرة للوكلاء ما تم إصداره، لكنها لا تُظهر لماذا أصبح هذا المكوّن أو التفاعل تحديدًا هو المعيار»، من وثائق

Vercel.

ماذا يعني هذا

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