Qoder Canvas: نظام تصميم صُنع للوكلاء، لا للبشر

اطلب من وكيل برمجة بالذكاء الاصطناعي أن يلخّص طلب سحب (pull request) وستصل الإجابة في نافذة الدردشة: Markdown، وكتل برمجية، وملخصات diff. ينجح هذا ما دامت المهمة صغيرة. لكن حالما تتعقّد المهمة، يتحول النص إلى لعبة بحث عن الكنز. تُدفن المخاطر والملفات والخطوات التالية في الرد، ويضطر الإنسان إلى نسخ أجزاء منه وإعادتها إلى الموجّه لمواصلة العمل.

لفريق Qoder إجابة محددة، يقدّمها في منشور على مجتمع Alibaba Cloud يعرض التفكير الكامن خلف Qoder Canvas. يصف الفريق تحولًا حديثًا: بدأ الوكلاء يولّدون نتائج معقدة بصيغة HTML. لوحات المعلومات، ومراجعات PR، ومخططات البنية، وتقارير الاختبارات، ونتائج الأبحاث تتحول إلى صفحات يمكن قراءتها وتصفيتها والنقر عليها. المغزى: مخرجات الوكيل ليست مضطرة لأن تكون نصًا. يمكنها أن تكون مصنوعًا تفاعليًا.

HTML حرّ للغاية بحيث لا يصلح ليكون الإجابة

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

القارئ التالي لنظام التصميم هو آلة

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

كل ما يفهمه الوكيل عن مكتبة المكونات ينبع مما تجعله قاعدة التعليمات البرمجية مقروءًا: إعلانات الأنواع، وعلاقات التصدير، والتعليقات، والأمثلة، وتكرار الاستخدام، وبنية الملفات، وآثار التعديلات الأخيرة. يرى الفريق أن جودة المخرجات لا تعتمد على المكتبة نفسها بقدر ما تعتمد على الكيفية التي تُعبَّر بها المكتبة في الكود. المكوّن الذي يظهر كإعلان نوع مجرّد لا يخبر الوكيل إلا أنه قابل للاستخدام؛ أما المكوّن الذي يوضح حالات الاستخدام والحدود والأمثلة المضادة والأمثلة فيخبره كيف ينبغي استخدامه. بالنسبة إلى الوكيل، تعليق على مكوّن PieChart يلاحظ أنه يناسب النسب لا الاتجاهات أو الترتيبات، التي تستدعي LineChart أو BarChart، هو جزء من نظام التصميم. وإذا لم يُكتب هذا التعليق أبدًا، يختار الوكيل المخطط الخطأ.

الذرات والمكونات وطبقة الوصفات

ينظّم Qoder بنية Canvas وفق خطوط Atomic Design. في الأسفل تقع الذرات: رموز تصميم للألوان والخطوط والتباعد ونصف قطر الزوايا والظلال ودلالات الحالات. لا تحمل أي معنى تجاري، بل بدائيات بصرية مستقرة فقط، وعلى الوكيل أن يسحب القيم من الرموز الدلالية مثل useHostTheme().tokens بدلًا من اختراع لوحة ألوان جديدة في كل مرة. وفوقها تقع المكونات الأساسية: Button وTag وCard وTable وInput وPieChart وLineChart وFileReview وDiffGroup. تعبّر مكونات Tag عن الحالة، وتعبر المخططات عن علاقات البيانات، وتعبر الـ diff عن تغييرات الكود.

المهام الحقيقية للوكلاء نادرًا ما تكون «ارسم مكوّنًا». إنها تبدو أشبه بـ«ولّد مراجعة كود» أو «اشرح اختبارًا فاشلًا». وهنا يأتي دور طبقة الوصفات. لا يسرد ملف recipe.md المكونات؛ بل يخبر الوكيل كيف ينبغي تنظيم المعلومات لنوع مهمة معين، وأين توضع الأدلة، وما الإجراءات التي ينبغي إظهارها، وأي الأشكال البصرية ينبغي تجنبها. مثال الفريق: وصفة مراجعة كود تتطلب من الوكيل أن يشرح التغيير أولًا، ثم يرتب المشكلات حسب درجة الخطورة، ويعرض أدلة diff للنتائج الرئيسية، ويرفق خيار AI Fix بكل مشكلة قابلة للإصلاح.

Canvas منضدة عمل، لا تقرير

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

النقر على AI Fix لا يرسل «ساعدني في إصلاح هذا» بصورة مجردة. بل يحزم النتيجة، والملفات ذات الصلة، وأدلة diff، وقيود نظام التصميم، ومتطلبات التحقق، ويعيدها إلى Chat. والنقر على Generate Test يحمل منطق التغطية المفقودة، ومسارات المخاطر، وشروط الحدود إلى عملية توليد الاختبارات. هذا هو الخط الفاصل بين Canvas وHTML العادي. HTML ينظّم النتائج. أما Canvas فيضع النتائج والسياق والإجراءات التالية في البنية نفسها. وبدون هذا السياق، يظل الزر مجرد زر؛ ومع نظام تصميم ووصفة خلفه، يتحول الزر إلى نقطة تعاون قابلة للتنفيذ.

الوكيل الآن داخل الواجهة

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

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

ما إذا كان Canvas سيصمد يعتمد على ما إذا كانت الفرق تحافظ على صدق وصفاتها. نظام التصميم للوكلاء لا يعمل إلا إذا كانت قاعدة التعليمات البرمجية تقول فعلًا ما يدّعي الفريق أنها تقوله. لن يستنتج القارئ الآلي القرارات التي لم يكتبها أحد.