Widgets تتحقق من البنية التحتية الخاصة بها: probe_url، وكيل تحقق، وإصلاح مجاني واحد
أكبر مصدر للـ widgets المعطلة كان كوداً مكتوباً ضد واجهة برمجة متخيّلة. الآن الباني يجلب نقطة النهاية أثناء الكتابة، المحقّق يعيد فحص ما تخطاه، وتعطّل في أول 45 ثانية يمنح إصلاحاً تلقائياً.
الطريقة الأكثر شيوعاً لفشل widget مُولَّد لم تكن خطأ في الكود المُولَّد. كانت نقطة نهاية لم تكن موجودة أبداً.
النموذج أخذ عنوان URL من الذاكرة — أو من صف في دليل رابطه صفحة توثيق لا نقطة نهاية — خمّن شكل الاستجابة، كتب كود تحليل دقيقاً ضد ذلك التخمين، وأرسله. ما حصلت عليه كان مؤشر تحميل أبدياً أو رسم بياني فارغاً، بلا شيء على الشاشة يقول لماذا.
هذا الإصدار يغلق تلك الحلقة ثلاث مرات: أثناء كتابة النموذج، مباشرة بعد الكتابة، ومرة أخرى إذا استمر بالتعطّل أمامك.
أثناء الكتابة: probe_url
الباني لديه الآن أداة تنفّذ GET لنقطة نهاية عامة بلا
مفتاح الآن، عبر نفس وكيل الخادم الذي يستخدمه
ctx.data.http() في وقت التشغيل، وتعيد حالة HTTP
الحقيقية وجسم الاستجابة الحقيقي.
هذه الهوية هي كل النقطة. فحص ينجح هو استدعاء وقت تشغيل ينجح. فحص يفشل هو widget كان سيُرسَل معطلاً — ويفشل الآن، بينما ما زال دور متبقٍ لإصلاحه، لا في اللوحة.
تقع في أسفل سلّم يُطلب من الباني أن يعمله بدلاً من التفكير من الذاكرة: وثائق مرجع المنصة أولاً، ثم دليل من 691 واجهة برمجة عامة بلا مفتاح في 47 فئة، قابلة للبحث بالموضوع عبر اسم و وصف كل مدخل — لأن طلبات حقيقية («أوقات المد»، «جودة الهواء») نادراً ما تطابق فئة يخمّنها أحد. ذلك الدليل متاح دائماً للباني الآن، مهما كان النطاق، لأنه البديل العام بلا مفتاح. روابطه توثيق، لذا الخطوة الأخيرة دائماً نفسها: استنتج نقطة النهاية، ثم افحصها.
«هل هناك بيانات لـ X؟» سؤال يُجاب بالنظر، لا بالتفكير في أي مجموعات بيانات ربما موجودة. الوصول لنهاية السلّم وقول لا بعد فحص حقيقي نتيجة جيدة. التأكيد من الذاكرة ليس كذلك، وكان مخطئاً أكثر بكثير مما بدا.
مباشرة بعد الكتابة: المحقّق
طلب من النموذج التحقق من عمله طلب لا ضمان. لذا اللحظة التي يصل فيها كود الـ widget، أمران يحدثان لا يعتمدان على موافقة النموذج.
أولاً، نتيجة الأداة تسمّي نقاط النهاية التي لم تُفحص هذا الدور وتخبره أن يتحقق منها بينما تبقى جولات.
ثانياً — وهذا الجزء لا يعتمد على التعاون — محقّق يعمل بالتوازي مع النموذج وهو يكتب ملخصه، وينجز العمل بنفسه:
- فحص الوحدة لفئات الفشل الصامتة بالتصميم. export
renderمفقود. كود لا يُ parse.fetchأوWebSocketخام إلى مضيف طرف ثالث، الذي يحجبه sandbox — أكثر فشل صامت ضرراً في widgets مُولَّدة، لأن لا شيء يظهر في console. URL صورة أو فيديو خارجي يُعيَّن مباشرة إلىsrc. URL tile ثابتة تُسلَّم لمكتبة maps، التي ت mount وت pan بشكل مثالي بينما كل طلب tile يُرفض بصمت. - فحص كل نقطة نهاية تخطاها النموذج (حتى خمسة لكل module)، وقراءة الحكم كما يفعل النموذج: غير reachable، أو 4xx يقول URL أو parameters خاطئة.
المشاكل الحقيقية تمنح جولة إصلاح تلقائية واحدة ضمن الدور، مع مخرجات الفحص مرفقة كدليل وتعليمات لإصلاح المُسمّى فقط. تلك الجولة تحدث بينما سياق البناء الكامل ما زال ساخناً — أرخص بكثير من الإرسال معطلاً وإنفاق دور كامل لاحقاً. إذا أعاد النموذج كتابة module أثناء التنفيذ، التحقق الجاري يُستبدَل وحكمه يُتجاهل. محقّق يفشل داخلياً يُبلّغ نظيفاً: يمكنه تأخير بناء، لا كسره أبداً.
إذا استمر بالتعطّل: إصلاح واحد، محدود بشدة
سياق الإصلاح الذاتي كان يغذي أخطاء وقت التشغيل إلى دور المحادثة التالي — لكن فقط عند الإرسال. widget تعطّل بعد بنائه بثوانٍ بقي معطلاً حتى تلاحظ، تعيد فتح المحرّر وتكتب «إنه معطل».
الآن مضيف وقت التشغيل ينفق دور إصلاح تلقائي واحد عندما بناء جديد يتعطّل. دور تلقائي هو التطبيق ينفق رصيدك أو مفتاحك، لذا الحدود ضيقة عمداً:
- الإصدار الذي بناء ذكاء اصطناعي أنتج للتو فقط — تعطّل في إصدار قديم استعدته، أو في كود عدّلته يدوياً، لا ي calify أبداً;
- فقط خلال 45 ثانية من ذلك البناء، لأن تعطّلاً بعد ساعة معلومات جديدة لك، لا عيب بناء واضح;
- مرة لكل إصدار، وإصدار أنتجه دور إصلاح تلقائي نفسه غير مؤهل. بناء واحد يمكنه إطلاق متابعة تلقائية واحدة كحد أقصى — لا سلسلة من النموذج يدفع لنفسه للاستمرار بالفشل.
دور الإصلاح صيغ كالتطبيق يبلّغ عن عيب، ويحمل نفس التعليمات ككل ما سبق: إذا الفشل يتعلق بنقطة نهاية بيانات، افحصها قبل إعادة الكتابة. أصلح، احتفظ بما يعمل، لا تكبر نطاق الـ widget.
على الخادم، بناء خلفية مُنقَذ ينتظر الآن عندما دور آخر من نفس الـ widget نشط، بدلاً من التسابق إلى إصدار مكرر.
نفس الحلقة، كل وضع
كل هذا في module مشترك، لذا بناءات المنصة، بناءات bring-your-own-key في المتصفح، ومسح البناء من الخادم يحصلون على سلوك متطابق — نفس الأدوات، نفس تنسيق الفحص، نفس المحقّق، نفس ميزانية الإصلاح. الأوضاع لا يمكنها diverge في أي أدوات موجودة أو مدى صرامة فحص widget، لأنه implementation واحد فقط للإجابة. إنه أيضاً الحلقة التي أنتجت العشرة widgets مثال التي تأتي مع الإصدار القادم: بُنيت بهذا بالضبط، بهذه الفحوصات بالضبط.
لا شيء من هذا يجعل النموذج صحيحاً. يجعل الخطأ قابلاً للتحمّل، وعادة غير مرئي: نقطة النهاية تُفحص قبل أن يعتمد الكود عليها، الفحص يعمل سواء شعر النموذج بالرغبة في تشغيله أم لا، وأول تعطّل يحصل على محاولة إصلاح صادقة قبل أن يصل إليك.
شغّل Nexow واطلب شيئاً غريباً — أوقات المد، جودة الهواء، عطلات عامة. راقب شريط النشاط يفحص نقطة النهاية قبل كتابة سطر واحد من كود التحليل.
بناء أول أداة في الدقيقة التالية
المعاينة حية ومجانية للمحاولة. لا تسجيل ولا إعداد — فقط صِف ما تريد رؤيته.

