سايمون ويليسون يبني مع Claude أداة لتحديد مصدر الصفير ويعثر عليه بدقة نحو 40 سم

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

وبحسب ويليسون، حدد النظام الموقع بدقة نحو 40 سم. وفي كومة الصناديق الصحيحة وُجد جهاز قديم لكشف أول أكسيد الكربون يحتاج إلى تبديل البطاريات. والمثير للمطور هنا هو أسلوب العمل: فقد حصل الوكيل على قياسات من الغرفة، وكان بإمكانه التحقق من نتيجة تعديلاته ومواصلة التحسين اعتمادًا على البيانات الملاحظة.

خمسة أجهزة تتحول إلى أداة قياس

استخدم ويليسون جهازي iPad وهاتفًا وحاسوب MacBook Pro وجهاز Surface Ultra. تتولى خدمة الواجهة الرئيسية خادم Python. أما بقية الأجهزة فتتصل عبر رابط أو رمز QR، وتمنح المتصفح إذن الوصول إلى الميكروفون، وتتبادل البيانات مع الخادم عبر WebSocket. ولم تكن هناك حاجة إلى ميكروفونات خاصة لهذه التجربة.

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

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

واعتمد الوكيل في بحثه على ورقة BeepBeep الصادرة عام 2007 حول القياس الصوتي للمسافات على أجهزة عادية. غير أن نتيجة التجربة المنزلية لا يمكن عدّها تلقائيًا تكرارًا لدقة العمل الأصلي: فالتنفيذ مختلف والظروف مختلفة.

اختبار التصفيق أهم من الخريطة الجميلة

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

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

وكانت الخطوة التالية الاستماع إلى تسجيلات كل جهاز. وكان بإمكان المستخدم تأكيد أن النظام التقط الصفير المطلوب. وبعد التأكيد كان التطبيق يتتبع تردده والفواصل بين الأحداث ويدقق الموضع المفترض. كما ظهر في الواجهة اقتراح بمكان وضع ميكروفون إضافي.

وتتعلق الدقة المعلنة البالغة 40 سم بحالة واحدة موصوفة. ولا تقدم المادة سلسلة اختبارات في غرف مختلفة. وتبقى انعكاسات الصوت والضوضاء وأخطاء إحداثيات الأجهزة أسبابًا للتحقق من النتيجة في الموقع.

يحتاج الوكيل إلى الوصول إلى النتيجة

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

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

الخلاصة العملية: عند اختيار مهمة للوكيل، فكّر مسبقًا في كيفية تحققه من النتيجة. ففي Beep Locator لزمت ذاكرة مؤقتة للصوت، وتشغيل التسجيلات، وتصفيقات اختبارية، وتأكيد يدوي للأحداث. وساعدت هذه الأدوات في تحويل شيفرة تعمل إلى نظام تمكّن المؤلف من استخدامه في بحث حقيقي.