أنشأ Claude Opus 5.5 لعبة RTS يمكن لعبها عبر الصوت: داخل المودم الصوتي في Battle Drones

هاتفان على طاولة، لا Wi-Fi، لا Bluetooth، ولا خادم في أي مكان. أحد الهاتفين يستضيف مباراة استراتيجية في الوقت الحقيقي، والآخر ينضم إليها، والشيء الوحيد الذي يمر بينهما هو الضجيج — موجة حاملة بتردد نحو 10 kHz في اتجاه، و17 kHz في الاتجاه الآخر، تحمل أوامر اللاعبين بسرعة تقارب 1,880 بت في الثانية. تلك هي أحدث ميزة في Claude Opus 5.5، أكثر أعماله العامة طموحًا حتى الآن: Battle Drones، وهي لعبة RTS في المتصفح على طراز Command & Conquer نشرها Simon Willison في 20 أكتوبر 2026، بعد اثنتي عشرة دورة تطوير رئيسية و321 إيداعًا، معظمها من وكلاء برمجة. أطلقت Anthropic نموذج Claude Opus 5.5 في 22 سبتمبر 2026 بسعر 4 دولارات لكل مليون رمز إدخال و20 دولارًا لكل مليون رمز إخراج، لذا يبلغ عمر النموذج نفسه شهرًا واحدًا؛ الجديد هذا الأسبوع هو الشيء الذي استُخدم لبنائه، والمواصفة المفتوحة التي تأتي معه. تميل الأعمال العامة كهذا إلى إغفال كيفية فشل النموذج في العمق، والحوادث المسجلة مفهرسة في OrcaRouter AI Incident Archive حيث يحمل كل مدخل مصادره الخاصة ودرجة خطورته ودرجة ثقته وعلامة كونه محل خلاف.

يمكن التحقق من كلا شطري ذلك الادعاء. تعمل اللعبة على simonw.github.io/battledrones/، والشيفرة المصدرية متاحة على GitHub بموجب Apache-2.0، والرابط الصوتي ليس صندوقًا أسود — فالمستودع يضم SOUND-DUEL.md، مواصفات مودم كاملة تتضمن مخططات النطاقات ومعدلات الترميز وصيغ الحزم وأرقامًا مقاسة لنسبة الإشارة إلى الضوضاء. وما يلي هو ما تقوله تلك الوثيقة والمنشور فعليًا، منفصلًا عما لا يقولانه.

ما الذي تم شحنه في 20 أكتوبر؟

Battle Drones ليس عرضًا تجريبيًا. وكما هو موضح في المقال، فهو يضم تسعة مبانٍ، وسبع مركبات أرضية، وست مركبات جوية، وثلاثة أنواع من المشاة، وكلها مبنية كنماذج ثلاثية الأبعاد مولّدة في TypeScript بدلًا من تحميلها من حزمة أصول. وتوجد فيه ضباب حرب، مع متطلبات منفصلة للأسلحة المضادة للطيران والمضادة للأرض. وتمتد ست خرائط عبر خمسة أحياء أحيائية، إضافة إلى مولّد خرائط عشوائي ببذرة ينتج ساحة معركة متناظرة نقطيًا بحجم 108×108 — بُني، وفق المنشور، في دفعة سريعة مدتها 45 دقيقة بعد أن لاحظ المؤلف أن لديه 25% من حصة Claude الأسبوعية متبقية و45 دقيقة حتى إعادة تعيينها.

تشمل الأوضاع مناوشات، وموجات نجاة Last Stand، ومشاهدة مواجهات الذكاء الاصطناعي ضد الذكاء الاصطناعي، وحملة من ثماني مهام، وشيئًا غير معتاد حقًا: وضع وكيل ضد وكيل حيث يلعب نموذجان لغويان ضد بعضهما بعضًا عبر أداة لا تكشف سوى حالة اللعبة غير البصرية والمرئية ضمن ضباب الحرب. تُرفَق تسجيلات إعادة تلك المباريات بالمستودع، إلى جانب عارض تصحيح يعرض استجابات النموذج الأساسية.

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

رابط الصوت، بالأرقام

هذا هو الجزء الذي يستحق قراءة المواصفات من أجله، لأن "اللعب الجماعي عبر الصوت" يبدو عملًا استعراضيًا حتى ترى الميزانية الهندسية التي كان عليه أن يتناسب معها. يتشارك جهازان غرفة واحدة وقناة صوتية واحدة، لذا فإن التصميم قائم على الإرسال المزدوج بتقسيم التردد: يرسل الهاتفان باستمرار، المضيف في نطاق 9.525–12.5 كيلوهرتز والضيف في 15.975–18.95 كيلوهرتز، مع وضع النطاقات بحيث يبدأ التوافقي الثاني للمضيف فوق 19.05 كيلوهرتز، ويبقى التشكيل البيني من الدرجة الثالثة الناتج عن كل نطاق بعيدًا عن النطاق الآخر.

• التعديل — OFDM بتباعد نغمات 25 هرتز، ورمز مفيد 40 مللي ثانية بالإضافة إلى بادئة دورية 10 مللي ثانية، أي 50 مللي ثانية لكل رمز و20 رمزًا في الثانية

• الحمولة — 188 بتًا لكل حزمة على خطة النطاق العالي، و186 على خطة النطاق المنخفض الاحتياطية، متطابقة في كلا الوضعين بحيث لا يغيّر تبديل الوضع أبدًا ما يتسع له.

• الإنتاجية — 1,880 بت/ثانية في الوضع السريع العالي، و940 بت/ثانية في الوضع المتين العالي، و930 و465 في الخطة المنخفضة؛ وتستغرق الحزم 100 و200 و200 و400 مللي ثانية على الترتيب

• التحكم في الأخطاء — شفرة تلافيفية عند K=7، بمعدل ½، وكثيرات حدود 133/171، وفك ترميز فيتربي ناعم، وتشابك عبر الرموز والنغمات، وCRC-16 بكثيرة حدود 0x1021، ورفض صارم إذا اختلف أكثر من 10% من البتات المعاد ترميزها

• التأطير — رمز مزامنة واحد بالإضافة إلى 40 رمز بيانات لكل إطار فائق، 41 رمزًا أو 2.05 ثانية، يحمل 20 أو 10 أو 10 أو 5 حزم حسب الخطة والوضع

• الوصلة المقاسة — نسبة إشارة إلى ضوضاء للقدرة تبلغ 40–70 dB في كل نطاق بعرض 1 kHz من 1 إلى 21 kHz على مسافة 10–30 cm، لتنخفض إلى نسبة فعالة تتراوح بين 17–31 dB عند 10 cm و9–19 dB عند 30 cm بعد احتساب الصدى، مع وصول الانعكاسات بعد 8–15 ms خلف المسار المباشر

الجزء الصادق من المواصفة هو ما ترفض أن تَعِد به. لا يوجد ARQ: الحزمة المفقودة لا يُعاد إرسالها، بل تعيد الحزمة التالية ببساطة وصف كل دور لم يُقَرّ باستلامه، وإذا تجاوز التراكم حزمة واحدة فإنه يُقسَّم على ما يصل إلى أربعة مقاطع متناوبة. وهكذا تتحول التراكمات الكبيرة إلى توقفات تزامنية صارمة بدلًا من فساد البيانات. تُقبل كل دورة مرة واحدة بواسطة علامة الماء العالي، وتُحمى حزم اللعب بـ CRC مفتاحه مبني على nonce الاقترانين، لذا يفشل تسجيل مباراة مختلفة في اجتياز فحصه. وكما تقول المواصفة، يمكن النجاة من التشويش لكن لا يمكن منعه: تتوقف، ولا تفقد التزامن بصمت أبدًا.

أرقام التسليم من اختبارات نموذج الغرفة هي 99% أو أفضل عند 20 سم و95% عند 40 سم في الوضع المتين، و98% عند 20 سم في الوضع السريع. هذه نتائج محاكاة وردت في المواصفات، وليست دراسة ميدانية — كما يقول المنشور نفسه إن الميزة كانت جديدة جدًا حين طُرحت: "لم أتمكن من تشغيل هذا إلا للتو، لذا لم يكن لديّ وقت كافٍ لاختباره فعليًا بعد."

الخطأ البرمجي الذي يهم أكثر من المودم

يختبئ بين الملاحظات الختامية التفصيل الذي يُرجّح أن يكون الأكثر فائدة لأي شخص يبني برمجيات ذات حالة باستخدام وكيل. ولأن عمليات إعادة التشغيل واللعب متعدد اللاعبين المتزامن بإحكام يتطلبان أن تكون المحاكاة متطابقة بتًا على كل جهاز، اضطر Claude إلى التوقف عن استدعاء Math.sin() وMath.cos() — إذ تُرجع Chrome وSafari قيمًا مختلفة اختلافًا طفيفًا جدًا — واستبدالهما بتنفيذاته الخاصة. إن اختلاف متصفحين في البتات الأخيرة من دالة متسامية يكفي لفقدان التزامن في مباراة بعد دقائق.

هذا {{1}}قيد هندسي حقيقي{{/1}}، اكتشفه النموذج وأصلحه النموذج، وهو يعمّم على نحو يتجاوز الألعاب بكثير. أي نظام يبنيه وكيل وله نواة حتمية — سواء أكان مجدولًا، أو إعادة تشغيل لدفتر أستاذ مالي، أو منصة محاكاة، أو بناءً قابلًا لإعادة الإنتاج — سيواجه الفئة نفسها من المشكلات، وسيواجهها بصمت. والدرس الذي يستخلصه القارئ ليس "{{2}}Claude بارع في الألعاب.{{/2}}" بل إن الحتمية يجب أن تكون متطلبًا صريحًا في المطالبة، لأن لا شيء في التنفيذ الافتراضي يجعلها صحيحة.

مسبار الراديو، ونمط مطالبة يستحق أن يُقتبس

قبل كتابة المودم، بنى النموذج صفحة قياس. تصف التدوينة أداة "Radio Probe"، التي لا تزال موجودة في المستودع باسم radio-probe.html، وكانت مهمتها الإجابة عن سؤال واحد: كم عرض النطاق الترددي الذي يمكن لجهازين فعليًا الحصول عليه بينهما، في هذه الغرفة، على هذه المسافة؟ لم يمضِ التنفيذ الكامل إلا بعد أن أعادت أداة الفحص أرقامًا جيدة بما يكفي لتبرير المضي فيه. ويوثّق الملف نفسه الأمرين اللذين لم تقسهما أداة الفحص — إرسال iPhone وميكروفونه مفتوح، واستماع هاتف إلى إرساله الخاص — وهما بالضبط أنماط الفشل التي ستهم في الميدان.

هذا النمط يستحق أن يُحتذى أيًّا كان النموذج الذي تستخدمه: اطلب من الوكيل أن يبني أداة القياس قبل أن يبني الميزة. القياس أولًا ثم البناء هو ما يجنّبك أن يرتكز أسبوع من العمل على افتراض لم يتحقق منه أحد. وهو كذلك يوفّر الأرقام التي تجعل عبارة مثل «الصوت الجماعي يعمل» قابلة للتحقق بدلًا من أن تكون مجرد كلام جذّاب.

ماذا يقول هذا عن Claude Opus 5.5، وما لا يقوله

أقوى الادعاءات في المنشور محددة. يكتب ويليسون أن Claude Opus 5.5 «مذهل في النمذجة ثلاثية الأبعاد باستخدام Three.js» — فكل مبنى ومركبة ومشهد طبيعي في اللعبة يُبنى إجرائياً بالكود، وهو يصنّف GPT-6 Astra في المرتبة نفسها. ويشير أيضاً إلى أن النموذج يكتب الموسيقى: فلا توجد ملفات صوتية في المشروع، والموسيقى التصويرية تُولَّد بالكود، وتتنوع حسب الخريطة وتشتد مع احتدام القتال.

هناك نتيجتان إضافيتان أبلغ عنهما المؤلف بدلًا من إعادة إنتاجهما بشكل مستقل، وينبغي قراءتهما على هذا الأساس. كانت "تحديثة المتعة" عبارة عن طلب واحد — "هذه اللعبة ليست ممتعة بما يكفي بعد. اجعلها أكثر متعة بكثير." — شُغّل في وضع سير عمل ديناميكي ينسّق العديد من الوكلاء الفرعيين لساعات عديدة، وخلاله أجرى النموذج أكثر من ألف جلسة اختبار لعب محاكاة. النتيجة المبلّغ عنها، من 1,200 مباراة بين الذكاء الاصطناعي والذكاء الاصطناعي على مستوى الصعوبة العادي: انخفضت المباريات التي ظلت دون حسم بعد 25 دقيقة من 14% إلى 0.9%، وارتفعت حصة الانتصارات التي حققها طرف كان متأخرًا بمقدار 800+ من الخردة من 24% إلى 46%. هذه قياسات المؤلف للعبته الخاصة، وليست معيارًا قياسيًا للنموذج.

ما لا يظهره المقال لا يقل أهمية. فلا يوجد تقييم من طرف ثالث لـ Claude Opus 5.5 في تطوير الألعاب، ولا مقارنة مباشرة مع نموذج آخر على المهمة نفسها، ولا حساب للرموز أو الدولارات الخاصة بالتشغيلات. ويصوغ المؤلف الأمر بنفسه على أساس أنه لا يعرف "تقريبًا شيئًا عن تطوير الألعاب"، وأنه "لم يراجع إلا القليل جدًا من الشيفرة"، ولا يعتبر النتيجة مشروعًا إندي جادًا. وهذه مجموعة تحفظات صريحة على نحو غير معتاد، وهي تحدّ من مدى إمكانية تعميم النتيجة: فهذا ممارس واحد، وقاعدة شيفرة واحدة، وشهر واحد.

كم تبلغ تكلفة تشغيل مشروع مثل هذا؟

قائمة الأسعار المنشورة من Anthropic لـ Claude Opus 5.5 هي 4.00 دولارات لكل مليون رمز إدخال، و20.00 دولارًا لكل مليون رمز إخراج، و0.20 دولار لكل مليون قراءة من ذاكرة التخزين المؤقت. والمشروع بهذا الشكل معتمد تقريبًا بالكامل على الإخراج — فالنموذج يكتب TypeScript، لا يقرأ مجموعة ثابتة كبيرة — لذا فإن بند الإخراج البالغ 20 دولارًا هو الذي يحكم الفاتورة، والتشغيلات الليلية الممتدة لساعات عديدة وبتوازٍ عالٍ هي ما يحوّل «الرخيص لكل رمز» إلى رقم حقيقي. لم يُنشر إجمالي لـ Battle Drones، لذا فإن البيان الصادق هو أن السقف يحدده عدد ساعات عمل الوكيل التي ترغب في شرائها، لا أي رقم في المنشور.

وهذا أيضًا هو الحجة ضد تثبيت مسار إنتاجي على نموذج واحد بناءً على مُخرَج واحد مبهر. كلود أوبوس 5.5 متاح على OrcaRouter بالسعر المدرج لدى Anthropic وبهامش ربح 0%، لذا فإن أي تغيير في السعر من المورّد يصبح ساريًا لدينا في اليوم نفسه، والتبديل التلقائي عند الفشل يعني أن تشغيل وكيل طويل لا ينتهي لأن نقطة نهاية واحدة في المنبع تمرّ بفترة سيئة. إذا أردت اختبار ما إذا كان بناء ليلي كهذا قابلًا للتكرار على نموذج مختلف، فإن واجهة API واحدة لأكثر من 200 نموذج هي أرخص طريقة لمعرفة ذلك — نفس شكل الطلب، اسم نموذج مختلف، ودون عقد ثانٍ.

ما الذي لم يتم إثباته؟

• الشعبية — أظهر المستودع 4 نجوم و0 تفريعات عند التحقق منه في 21 أكتوبر 2026، بعد يوم واحد من نشر المنشور. هذه ليست ظاهرة؛ بل هو مشروع شخص واحد، نُشر.

• موثوقية وصلة الصوت في الميدان — نسب التسليم المذكورة في المواصفات مستمدة من اختبارات على نموذج لغرفة، ويذكر المؤلف أنه لم يُتح له وقت كافٍ لاختبار الميزة فعليًا. فلا تقرأ نسبة 99% على أنها وعدٌ بما ستجده على طاولة مطبخك.

• الأعمال السابقة — تستشهد المقالة بـ Siner من Alon Horesh وggwave من Georgi Gerganov باعتبارهما العملين الوحيدين القابلين للمقارنة اللذين عثرت عليهما، وتصف اللعب الجماعي الصوتي في ألعاب HTML الثابتة بأنه "الأول من نوعه في ألعاب RTS بحسب ما يمكنني تحديده." هذا بحث المؤلف، وليس مراجعة أدبيات.

• إسناد الكود — قاد Claude Opus 5.5 معظم التكرارات اللاحقة، لكن الإصدار الأول بُني باستخدام Claude Fable 5 في يوليو الماضي، ويقول ملف README نفسه إن بقية المستند كتبها Claude. تعامل مع المستودع بوصفه أثرًا مختلطَ المصدر.

• نتيجة اختبار مرجعي — لا توجد نتيجة. لا شيء هنا يقيس Claude Opus 5.5 مقابل نموذج آخر في مهمة لها درجة.

الخلاصة الجديرة بالاستيعاب أضيق نطاقًا وأكثر فائدة من «أنّ الذكاء الاصطناعي بنى لعبة». فلعبة RTS تعمل في المتصفح بلا خادم خلفي، ومحاكاة حتمية، ومودم صوتي عامل، كلها برهان على أن الجزء الصعب في البرمجيات التي يبنيها الوكيل قد انتقل من توليد الشيفرة إلى تحديد القيود — الحتمية والقياس وسلوك الأخطاء — بدقة تكفي لتكون الشيفرة المولّدة قابلة للتحقق. أما وثيقة SOUND-DUEL.md فهي الدليل: فهي موجودة لأن أحدهم جعل النموذج يكتب ما يمكن للوصلة فعله وما لا يمكنها قبل إطلاقها. وإن أردت أن ترى ما إذا كان ذلك الانضباط ينتقل إلى عبء عملك، فشغّل الموجّه نفسه على نموذج ثانٍ وقارن المواصفات، لا لقطات الشاشة.