مطوّر يعيد بناء Winamp لنظام Mac بمساعدة وكلاء الذكاء الاصطناعي ويحافظ على استهلاك 2–3% من المعالج

قصة مألوفة: مجلد مهمل يضم مشروعًا شخصيًا توقف قبل ثلاث أو أربع سنوات عند الشاشة الأولى والتشغيل الأساسي. كان المطوّر Alexrel يبحث لنظام Mac عن مشغّل بسيط على طراز Winamp، لكن المشغّلات الحديثة إما تحولت إلى حزم متكاملة مع خدمات البث، أو تعمل على Electron وتثقل المعالج دون داع. وأخيرًا أنهى مشغّله الخاص بمساعدة وكلاء الذكاء الاصطناعي. والنتيجة هي MacAmp: نسخة مفتوحة المصدر من Winamp 2.95 بلغة Swift وSwiftUI وAppKit، دون web view، بإصدار شامل لمعالجات Apple Silicon وIntel، ويتطلب macOS 14 أو أحدث.

ما الذي تحقق في النهاية

يكرر المشغّل الأصل بدقة حتى النوافذ والقوائم واختصارات لوحة المفاتيح. النافذة الرئيسية والمعادل وقائمة التشغيل تلتصق ببعضها مغناطيسيًا، وتتوفر وضعيتا Shade وDouble Size. تعمل أي سكينات Winamp 2.x، وتُشغَّل صيغ MP3 وAAC وFLAC وOgg وMIDI وغيرها، ويدعم المشغّل الراديو عبر الإنترنت ونسخ الأقراص المضغوطة ومعادلًا بعشرة نطاقات. الوظائف الحديثة مخبأة في الداخل: فالصوت مثلًا ينتقل تلقائيًا إلى جهاز الإخراج الجديد.

المقياس الأهم لأداة يُفترض أن تبقى في زاوية الشاشة هو استهلاكها للموارد. على M1 يستهلك المشغّل في وضع الإيقاف المؤقت نحو 0.01% من المعالج، وعند التشغيل مع محلّل الطيف 2–3%. وحين لا يُشغَّل شيء يتوقف المحرك، ويكف المحلّل عن إرسال الإطارات بعد ثانيتين من الصمت.

تفاصيل هندسية تستحق الاطلاع

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

التفصيل الثاني يخص السكينات. فهي صور BMP نقطية مصممة لشاشات الكثافة القديمة، ومع الرسم القياسي على شاشات Retina يصبح الخط وأرقام المؤقت ضبابيين. لذلك ترسم النوافذ نفسها بالخيار interpolationQuality = .none، وتُقتطع السبرايتات بحسب بكسلات الأصل. بُني المعادل على AVAudioUnitEQ: النطاقات فيه مرشحات بارامترية، ومضخم ما قبل التضخيم منفَّذ عبر globalGain.

كيف عمل الوكلاء هنا

بحسب المطوّر، كتب وكلاء الذكاء الاصطناعي معظم الشيفرة. أما هو فكان يبتكر الأفكار ويحدد المهام ويراجع النتيجة ويقرر ما يُطرح. نجح هذا الأسلوب لأن الإنسان يفهم كيف ينبغي أن يكون المنتج ويلاحظ حين تنحرف البنية، بينما يعرف الوكيل استدعاءات AppKit المحددة.

ساعدت ثلاثة أمور:

• مستندات في المستودع. الرؤية، وخطة بمراحل، وقائمة تحقق، ودليل مرجعي لأحجام Winamp 2.x وسلوكه، ولقطات شاشة من الأصل. يقرأ الوكيل كل ذلك قبل العمل، فلا حاجة لتوضيح معنى «كما في Winamp» حرفيًا في كل مرة.
• AGENTS.md والمهارات. قواعد وتعليمات حول كيفية تعديل المعادل وقائمة التشغيل بأمان تمنع الوكيل من إفساد ما يعمل.
• اختبارات بأمر واحد. يتيح ./build.sh test فحص كل تغيير بسرعة.

لم ينجح تفويض الإحساس إلى الوكلاء: كيف يستقر السحب في اليد، وهل يرتجف الحقل، وهل اللون صحيح، وكيف يبدو الكروس فيد على مقطوعات حقيقية. هذا لا يُفحص إلا باليدين والأذنين.

القيود والخلاصة العملية

للمشروع ثغرات صريحة. لا توجد تصورات Milkdrop، ولا مشفّر MP3 وOgg للأقراص المضغوطة، ولا وحدات tracker، ولا Last.fm scrobbler. والتطبيق غير موقَّع عمدًا بمعرّف Developer ID: فالمشغّل يستبدل أيقونات الملفات داخل حزمته (bundle) ويعيد توقيع نفسه محليًا، ولذلك سيعرض Gatekeeper تحذيرًا عند التشغيل الأول. ويمكن تجاوزه عبر إعدادات الأمان أو بالأمر xattr -dr com.apple.quarantine. إضافة إلى ذلك، اختبر المطوّر المشغّل على جهاز Mac واحد ومكتبة موسيقية واحدة، ولذلك يطلب تقارير عن الكروس فيد وملفات CUE والراديو بعد انقطاع الشبكة والبلوتوث وسكون Mac وقوائم التشغيل الكبيرة.

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