مبارزة ويدجتات الفن البيكسلي: ثلاثة وكلاء برمجة، تكليف واحد، ومؤلفان

تم كتابة التعليمات أدناه في شهر أغسطس لـ dsh، وهو وكيل البرمجة التابع لشركة DeepSeek. وفي سبتمبر، قمت بتشغيل نفس التعليمات عبر Kimi K3 وMiniMax M3؛ كلاهما استخدما حلقة الوكيل الخاصة بـ OpenClaw على نفس الوكيل العامل، واحد تلو الآخر. اثنان منهم كتبا ويدجتًا، أما الثالث فقال إنه فعل ذلك أيضًا. أهم شيء خرج من هذا الاختبار ليس ترتيب الويدجتات، بل الحاجة إلى قراءة ما كتبه الوكيل قبل تصديق ما يقول إنه كتبه.

الأرقام

تم تشغيل كل وكيل مرة واحدة، لكن Kimi احتاج إلى ثلاث محاولات؛ لذا يجب اعتبار ذلك تجربة فردية ذات أدلة، وليس معيارًا مقارنًا. الأعمدة تمثل ملفات الويدجت الثلاثة الموجودة في هذه الصفحة.

العمود الذي لم يُذكر في الجدول هو محاولة Kimi الأولى؛ فقد فكر لمدة 8.8 دقائق باستخدام التعليمات الأصلية، لكنه لم يكتب أي كود للويدجت، وتوقف بعد ذلك بتكلفة تقريبية 0.31 دولار. إجمالي تكلفة محاولات Kimi الثلاث بلغ حوالي 1.50 دولار مقابل ويدجتين. أما dsh فقد كلفته المحاولة الأولى الفاشلة قرابة سنتين، ليصبح إجمالي تكلفة تشغيله 51 سنتًا.

تكلفة المحاولة الثالثة مأخوذة من إيصال JSON الخاص بها؛ أما المحاولتان الأولى والثانية فلم ينتجا عنهما إيصالات، لذا تم حساب التكلفة بناءً على أسعار الرسائل المسجلة في OpenClaw لكل جلسة؛ ويتطابق المجموع مع تكلفة المحاولة الثالثة المذكورة. جميع أرقام Kimi محسوبة حسب أسعار Moonshot ضمن إعدادات OpenClaw الخاصة بي.

ماذا فعل MiniMax؟

تلقى MiniMax M3 نفس التعليمات الأصلية، بعد ساعة تقريبًا من محاولة Kimi الثانية، على نفس الوكيل العامل وبالتالي في نفس مساحة العمل؛ حيث كانت ملفات المحاولة الثانية لـ Kimi لا تزال موجودة هناك. خلال 59 ثانية فقط (25 دورة، 24 استدعاء أداة، بتكلفة 0.13 دولار وفق الأسعار المعلنة ضمن خطة مدفوعة شهريًا) قرأ MiniMax تلك الملفات الخمسة وتقرير Kimi، ثم نفذ اختباراته، وردّ قائلًا: "تم بناء والتحقق من مجموعة الويدجتات بالكامل". لم يكتب أي سطر كود للويدجت؛ والملفات الوحيدة التي أنشأها كانت تقرير التشغيل الخاص به وملف الحالة.

صدقت ذلك الرد في البداية. النسخة الأولى من هذه الصفحة أظهرت لـ MiniMax عمودًا فارغًا يحتوي على محاولة واحدة، زمن 59 ثانية وتكلفة 0.13 دولار، مع استنتاج بأنها أرخص وأسرع تجربة نجحت من المحاولة الأولى. لكن سجل الجلسة أوضح أن الملف في ذلك العمود هو نفسه الذي كتبته محاولة Kimi الثانية في تمام الساعة 08:11 صباحًا بتوقيت طوكيو، وأن MiniMax لم يقم بأي تعديل عليه؛ لذا لا يوجد ويدجت خاص به على هذه الصفحة. الاختبار العادل هو تشغيله مرة أخرى في مجلد فارغ، وهو ما لم أفعله بعد.

الحالة المعاكسة هي محاولة Kimi الثانية؛ فقد كتب ويدجته واختباراته وتقريره في مساحة عمله، لكن تم قطع تشغيله قبل أن يردّ، مما جعله يبدو وكأنه لم ينتج شيئًا. إحدى المحاولات ادعت إنجاز ما لم تفعله فعليًا؛ والأخرى فعلت ما لم يرَه أحد. في الحالتين، كان الرد مخالفًا للملفات الفعلية على القرص، والتي كانت هي الصحيحة.

جربوا الثلاثة

كانت هناك مسودة سابقة لهذه الصفحة تضمنت عمودًا رابعًا فارغًا لـ Reasonix؛ لكنه لم ينفذ التعليمات قط، وقد حذفته من جهازي لاحقًا، لذا خرج من المقارنة.

ما الذي يختلف فعليًا؟

كل ما يُذكر هنا مبني على قراءة السكريبتات الثلاثة، لا على وصف الوكلاء لها.

ما يشتركون فيه: جميعهم يستخدمون الألوان الأربعة المحددة في التعليمات بدقة. عند التوقف، تظل البكسلات قريبة من لون اللوجو الأزرق؛ بينما تتوهج بكسلة مُنحرفة من الأزرق إلى الأزرق الفاتح ثم السيان. كلهم ينفذون أول تأثير نقر مقترح في التعليمات: يتحطم اللوجو إلى بكسلات تسقط تحت تأثير الجاذبية ثم تعود للتجمع مجددًا. اختار dsh ومحاولة Kimi الثانية ذلك من بين خيارين؛ أما المحاولة الثالثة فقد قدمت خيارًا واحدًا فقط بسبب التعديل على التعليمات. جميعهم يحترمون إعداد prefers-reduced-motion، ويعملون مع اللمس، ويبقون تحت حدود 400 سطر المطلوبة.

الشكل: طلبت التعليمات حلقة نصف قطرها بين 0.82R وR مع ميل للحروف بنسبة 20° تقريبًا. اتبعت محاولة Kimi الثالثة ذلك بدقة (Math.tan(20 * Math.PI / 180))، مما أدى إلى أخف تشكيل بـ 510 خلايا مضاءة؛ بينما جاءت محاولة Kimi الثانية بميل 0.42 (23°) وسيقان سميكة بـ 4.6 خلايا: 602 خلية. أما dsh فاستخدم ميلًا قدره 0.453 (24°)، وسيقان بـ 4.2 خلايا وحلقة أكثر سمكًا تبدأ من 0.80R: 656 خلية، وهو الأثقل بينهم. لا أحد منهم يطابق اللوجو الأصلي بدقة كافية ليُستبدل به.

التفاعل عند النقر: يستمر انفجار dsh لمدة 0.72 ثانية، ثم تعود البكسلات إلى مواقعها عشوائيًا خلال نصف ثانية؛ فتتحرك بعيدًا عن الجدران الأربعة ولا تتأثر بالتمرير السريع. بينما يستمر طيران Kimi الثالث لمدة 0.85 ثانية، ثم يعود للتجمع، ويتجاهل أي نقرات حتى يكتمل اللوجو مجددًا. في حالة تقليل الحركة، يُظهر نبضة خفيفة بدلًا من التحطيم المطلوب. أما محاولة Kimi الثانية فتستمر لمدة 0.85 ثانية، ثم تعود خلال ثانية كاملة، وترتد عن الأرض فقط؛ أي نقر جديد أثناء طيرانها يُحطمها مجددًا.

الحالة الساكنة: يُظهر dsh تلألؤًا بطيئًا للألوان ويضيف من 1 إلى 3 بكسلات عنبرية أو سيانية كل 1.2 إلى 3.8 ثانية. بينما تغير محاولة Kimi الثالثة شفافية كل البكسلات وتضيف وميضًا عنبرياً كل 0.2 إلى 0.6 ثانية، مما يجعلها الأكثر نشاطًا؛ أما محاولة Kimi الثانية فتومض بكسلة واحدة كل ثانيتين تقريبًا مع هالة ناعمة خلف البكسلات القريبة من المؤشر.

الكود: يستخدم dsh دالة Widget مع طرق بروتوتيبية ودالة mount() منفصلة، وتتضمن أزرار التحكم data-size وdata-speed وdata-static. محاولة Kimi الثالثة تستخدم دالة Logo مع مساعدات هندسية (inPara وmakeL) وأزرار تحكم مثل data-interactive. أما المحاولة الثانية فلا تحتوي على دالة بناء؛ بل تعيد createInstance() كائنًا عاديًا وتستخدم دوالًا مستقلة للفيزياء، كما تصدر نفسها كوحدة Node لكي تعمل اختباراتها بدون متصفح. نفس النموذج، لكن ملفاتهما لا تشترك في أي هيكل تقريبًا.

لماذا كل ويدجت في إطار منفصل؟ طلبت التعليمات أن "يبحث السكريبت عن كل عنصر .ll-pixel-logo ويثبت لوحة رسم داخله"، وهو ما فعله الجميع. كل واحد يُسجل الحاويات التي استخدمها باسم خاص، ويتجاوز المتغير المشترك window.LLPixelLogo. لذا مع وجود جميع السكريبتات في صفحة واحدة، تُراكمت اللوحات الثلاثة فوق بعضها. ظهر هذا الخطأ في المسودة الأولى التي لاحظته فقط على هاتفي؛ واستخدام إطار منفصل لكل ويدجت يحافظ على استقلالية السكريبتات دون تغيير كودها.

ما الذي تعلمته من ذلك؟

كتب وكيلان ويدجتات من هذه التعليمات؛ فاستغرق dsh محاولتين وأنفق 49 سنتًا للويدجت الناجح، قبل ثلاثة أسابيع رغم أنه أخفق فيها سابقًا. بينما احتاج Kimi إلى ثلاث محاولات بتكلفة 1.50 دولار لينتج ويدجتين مختلفتين، لم أكن أعلم بوجود الثاني إلا بعد بحثي. أما الوكيل الثالث فكانت مساهمته ردًا واثقًا عن ملفات غيره.

لن أستخدم ذلك لتصنيف الويدجتات؛ فهذه تجربة واحدة لكل وكيل، والتعليمات الموجهة لـ dsh تغيرت بعد فشله الأول، بينما كانت التعليمات الموجهة لمحاولة Kimi الثالثة مختصرة أكثر. ما أستخلصه هو أهمية العملية: تعليمات دقيقة مع قواعد هندسية إجرائية تؤدي في النهاية إلى ويدجت يعمل بواسطة وكيل قادر. لكن معرفة أي وكيل أنتجه تعتمد على ما تتحقق منه. في المرة القادمة، سأعطي كل وكيل مجلدًا فارغًا، وأقرأ ملفات الكتابة قبل قراءة ملخصه.

التعليمات (نص كامل)

هذا هو الموجز بالضبط كما تلقاه dsh في محاولته الثانية، وكذلك أولى محاولتين لـ Kimi وMiniMax؛ حجمه 3,301 بايت. في المحاولة الأولى لـ dsh، تم استخدام نسخة سابقة من الموجز كانت تسمح برسم صورة نقطية يدويًا؛ أما الجملة “لا ترسم صورة نقطية يدويًا” فهي التعديل الذي أُجري لاحقًا. أما المحاولة الثالثة لـ Kimi، فقد كانت نسخة مختصرة من الموجز تحتوي على التعليمات المذكورة في الجدول.

# الموجز: أداة تفاعلية لعرض شعار LaserLloyd بأسلوب الفن النقطي

قم بإنشاء نسخة مستقلة وقابلة للتضمين من **شعار LaserLloyd بأسلوب الفن النقطي** (انظر ملف `reference-logo.png`): عبارة عن حلقة زرقاء سميكة بلون #1f3f8f على خلفية بيضاء، تحتوي على حرفين “L” كبيرين مائلين ومترابطين؛ حيث يمتد جزء الحرف الأيسر العلوي تحت جزء الحرف الأيمن السفلي، وكأن الحرفين موضوعان بشكل قطري.

## المخرجات المطلوبة (كلها في هذا المجلد)
1. `ll-pixel-logo.js` — ملف واحد مكتوب بلغة JavaScript العادية، بدون أي تبعيات أو خطوات بناء أو طلبات شبكة. يمكن لأي صفحة تضمينه عبر الكود التالي:
     <div class="ll-pixel-logo" data-size="320"></div>
     <script src="ll-pixel-logo.js"></script>
   يقوم الملف بالبحث عن كل عنصر من نوع `.ll-pixel-logo` وإدراج عنصر `` داخله. يكون الرسم متجاوبًا مع الحجم؛ حيث يملأ الكانفاس عرض الحاوية (ويكون مربع الشكل)، كما يظهر بشكل واضح على شاشات HiDPI (باستخدام قيمة devicePixelRatio). يجب توفير دالة `window.LLPixelLogo.mount(el)`.
2. `index.html` — صفحة تجريبية تعرض الأداة بثلاثة أحجام مختلفة مع وصف مختصر للتفاعلات الممكنة.
3. `README.md` — يشرح كيفية تضمين الأداة، التفاعلات المتاحة، بالإضافة إلى خصائصها عبر سمات data-.

## التفاصيل الفنية للتصميم
- شبكة نقطية مكونة من 40×40 خلية. لا ترسم صورة نقطية يدويًا (لا تستخدم أسطرًا تحتوي على رموز مثل ‘#’ أو ‘.’؛ ذلك بطيء ومعرض للأخطاء). بدلًا من ذلك، يجب إنشاء التصميم برمجيًا عبر دالة `isLit(col,row)` التي تعيد القيمة true في حالتين: (أ) النقاط الواقعة على الحلقة الزرقاء (حيث تكون المسافة عن المركز بين 0.82R وR)، و(ب) النقاط التي تشكل حرفي “L” المائلين؛ حيث يتكون كل حرف من مستطيلين متوازيين مائلين بزاوية تقريبًا 20 درجة؛ ويجب أن يكون جزء الحرف الأيسر العلوي تحت جزء الحرف الأيمن السفلي تمامًا كما في الصورة المرجعية. يجب ضبط القيم الثابتة قليلًا لضمان ظهور التصميم بشكل صحيح عند عرضه بحجم 200 بكسل. يتم حساب النقاط المضاءة مرة واحدة فقط عند تفعيل الأداة.
- لوحة الألوان: اللون الأزرق للشعار #1f3f8f؛ اللون الأزرق اللامع #2ea8ff؛ اللون العنبري #ffb64a؛ اللون السماوي #00e6cf؛ الخلفية شفافة.

## التفاعلات المطلوبة (الجزء الأساسي من التمرين – يجب أن تكون ممتعة!)
- **عند تحريك المؤشر/اللمس:** تتفاعل النقاط القريبة من المؤشر بشكل فيزيائي؛ فتُدفع بعيدًا عنه كما لو كانت سائلة أو تتأثر بقوة مغناطيسية، ثم تعود إلى مواقعها مع تخفيف التأثير؛ أثناء ذلك، تتوهج النقاط بلون #2ea8ff أو #00e6cf. يجب أن يكون الأداء سلسًا بمعدل 60 إطارًا في الثانية باستخدام `requestAnimationFrame` دون أي تقطيع.
- **عند النقر/اللمس:** يجب أن يحدث تأثير مميز ومُرضٍ للمستخدم. اختر تأثيرًا واحدًا قويًا ونفذه بشكل جيد؛ مثلاً: يتحطم الشعار إلى نقاط تتطاير بفعل الجاذبية ثم تعود لتشكل الشعار مجددًا (يستغرق ذلك حوالي 1.5–2 ثانية)؛ أو أن “ليزرًا” يمر عبر الشعار ويعيد رسمه نقطة تلو الأخرى مع إضافة شرارات متلألئة. يجب أن يكون النقر المتكرر ممتعًا دون حدوث أي انقطاع في التأثير الحالي.
- **في حالة الخمول:** يجب أن يكون هناك حركة بسيطة وخفية (توهج خفيف أو وميض عابر للنقاط) لإعطاء إحساس بالحياة دون تشتيت الانتباه.
- يجب احترام إعداد `prefers-reduced-motion: reduce`؛ حيث يتم عرض الشعار بشكل ثابت مع الاحتفاظ بتأثير اللمعان عند التحريك فقط.
- يجب أن تعمل الأداة مع الفأرة واللمس معًا، دون التأثير على حركة التمرير.

## معايير الجودة
- الكود نظيف ومزود بتعليقات؛ لا توجد متغيرات عالمية سوى `LLPixelLogo`. يستخدم المسافات بعرض 2 أحرف. عدد الأسطر يجب أن يكون أقل من 400.
- يجب أن يعمل الكود عند تشغيله مباشرة عبر بروتوكول file:// دون أي أخطاء في وحدة التحكم. قم باختباره بنفسك؛ يمكن استخدام نص برمجي صغير بلغة Node.js أو أي أداة تفحص صياغة الكود؛ ملاحظة: لا تتوفر مكتبة jsdom، لذا قم بتشغيل `node --check` ثم اختبر وظيفة حساب النقاط المضاءة بشكل منفصل عن DOM، مثل التأكد من وجود الحلقة والحروف في الأماكن الصحيحة.
- في النهاية، يجب طباعة تقرير مختصر يوضح ما تم إنشاؤه، كيفية تضمين الأداة، وما تم التحقق منه.

الحزمة البرمجية المستخدمة

• الموجز: كما ورد أعلاه بالكامل.
• dsh: النسخة 0.1.0-rc.7 عند إنشاء الأداة في شهر أغسطس (والنسخة الحالية هي 0.1.1-rc.2 بتاريخ 2026-09-11)، باستخدام نموذج DeepSeek V4-Flash.
• Kimi K3 وMiniMax M3: كلاهما يستخدم نموج OpenClaw الإصدار 2026.9.2، بالإضافة إلى حلقة عملاء خاصة بهم؛ حيث يشترك الاثنان في استخدام نفس العامل المساعد.
• الأدوات المطورة: dsh، Kimi، المحاولة الثالثة، Kimi، المحاولة الثانية؛ جميعها غير معدلة. يتم تضمين كل أداة عبر صفحة HTML تحتوي على حاوية واحدة فقط داخل إطار iframe منفصل.
• الاختبارات التي أجريتها على هذه الصفحة: تشغيل node --check على جميع الملفات الثلاثة؛ حساب عدد النقاط المضاءة باستخدام دالة isLit الخاصة بكل ملف على شبكة 40×40؛ تحديد صاحب كل ملف عبر مقارنة قيمة التجزئة الخاصة به مع سجلات الأنشطة المسجلة من قبل العمال؛ إجراء اختبارات باستخدام متصفح Chromium بدون واجهة رسومية عند أحجام 390 و768 و1280 بكسل للتأكد من وجود كانفاس واحد لكل إطار، وظهور كامل محتويات الموجز، وعدم حدوث تمرير جانبي أو أخطاء في وحدة التحكم.
• الغلاف: تم رسمه يدويًا باستخدام SVG، دون استخدام أي نماذج صورية.

مرتبط بـ: DeepSeek Harness (dsh) (المصدر الأصلي للموجز والأداة الأولى)، Kimi K3 كوكيل برمجي (جميع محاولات Kimi الثلاث)، وMiniMax M3 كوكيل برمجي (اختبار الأداء عبر خمس مهام، بالإضافة إلى توضيح كيفية حدوث الخلط بين الأدوات).