أين تتوقف حلقة أداة تصحيح الأخطاء Trae عن التقدّم
يستطيع الوكيل الذي يصحّح الأخطاء انطلاقًا من الشيفرة المصدرية أن يقرأ ويستنتج ويعدّل، لكنه لا يستطيع أن يراقب. أنت من يوفّر الملاحظة، بصياغة لغوية ومن الذاكرة، وهذه قناة ضيّقة: تنقل ما انتبهت إليه وتُسقط ما لم تظنّه ذا صلة، وهو في كثير من الأحيان الجزء المهم.
يأتي هذا التوقف حين يستنفد الوكيل الفرضيات التي يسمح بها وصفك. ولا تُجدي الجولات الإضافية نفعًا، لأن المدخلات لم تتحسّن.
ثلاثة أنواع من الأخطاء يطالها هذا الأمر أكثر من غيرها
التوقيت
يُعرَض شيء قبل وصول البيانات، أو يكتمل طلب بعد اختفاء المكوّن.
يتعذّر رصده في فروق الشيفرة، ويتضح تمامًا حين تراه يحدث.
حالة متبقّية
ينجح الإجراء الأول ويفشل الثاني، لأن شيئًا ما لم تجرِ إعادة ضبطه.
ولن تُظهره أبدًا إعادة إنتاج تبدأ من نقطة نظيفة.
عدم تطابق البيئة
الشيفرة صحيحة والبيئة هي المخالِفة: متغيّر مفقود، أو ذاكرة تخزين مؤقت قديمة، أو بيانات مختلفة.
ويظل الوكيل يُصلح شيفرة لم تكن معطوبة أصلًا.
أضِف خطوة الملاحظة
بدلًا من وصف ما رأيته، اجعل شيئًا ما يُشغّل التطبيق المنشور ويُبلّغ بما حدث. عندئذٍ تصبح النتيجة التي يتلقّاها الوكيل سجلًّا لا استرجاعًا من الذاكرة: ما جرت محاولته، وما فعله التطبيق، وأين افترق الاثنان.
يُثبّت الإعداد هذه القدرة داخل الوكيل، فيصير قادرًا على إنتاج أدلّته وقراءتها بنفسه بدل انتظار أن تنقلها إليه.
الطرفية
npm install -g @testsprite/testsprite-cli
testsprite setup
الإعداد نفسه متاح في لوحة تحكم TestSprite إن كنت تفضّل ألّا تثبّت شيئًا محليًا. أما بقية إمكانات CLI فتجدها في مستودع CLI.
سؤالان يكسران حالة الجمود
هل يفشل انطلاقًا من بداية نظيفة؟ إن كان الجواب نعم فالمشكلة في المنطق. وإن حدث في المحاولة الثانية فقط فالسبب حالة متبقّية، ويكون كل فرض على مستوى الشيفرة حتى الآن قد استهدف الشيء الخطأ.
هل يفشل في بيئة مختلفة؟ إذا تصرّفت النسخة نفسها تصرّفًا مختلفًا في مكانين، فتوقّف عن تعديل الشيفرة. الفارق بين البيئتين هو الخلل نفسه.
الإجابة عن كليهما زهيدة التكلفة، وكلاهما يعيد توجيه الجلسة بأكملها متى جاء الجواب مفاجئًا.
احتفظ بحالة إعادة الإنتاج بعد الإصلاح
الحالة التي بنيتها لرؤية الخلل هي نفسها الفحص الذي يمنع عودته. شغّلها مع كل تغيير بدل حذفها مع انتهاء المحادثة.
المُشغِّل أهم من الآلية. فتوجيهها إلى حدث النشر لديك يعني فحص كل تغيير دون أن يقرّر أحد ذلك؛ فيتولّى GitHub App ذلك من لوحة التحكم، بينما تقوم به خطوة GitHub Actions من داخل سير عملك.
لماذا يواصل الوكيل اقتراح إصلاحات متشابهة؟
لأن المدخلات لم تتغيّر. فمن دون ملاحظات جديدة، لا يسعه سوى إعادة استكشاف فضاء الفرضيات نفسه بصياغة مختلفة.
هل يجدر بي لصق مزيد من السجلات؟
زيادة الإشارات مفيدة، والسجلات تصف ما قرّرته الشيفرة لا ما اختبره المستخدم. أما تشغيل اختبار على التطبيق الحقيقي فيسدّ الفجوة التي تتركها السجلات.
هل هذا خاص بـ Trae؟
لا. فأي وكيل يصحّح الأخطاء انطلاقًا من الشيفرة المصدرية لديه النقطة العمياء نفسها. يختلف سير العمل، وتبقى الخطوة الناقصة واحدة.
ماذا لو تعذّر عليّ إعادة إنتاجه بشكل موثوق؟
عندئذٍ يكون التقطّع نفسه هو النتيجة. شغّل الحالة نفسها عدة مرات وقارِن. فالمسار الذي يفشل مرة من كل أربع هو مشكلة توقيت أو حالة، وهذا يضيّق نطاق البحث كثيرًا.
هل يحتاج الإصلاح إلى تحقق منفصل؟
نعم. فالإصلاح الذي يقترحه ويؤكّده المنطق نفسه لا يحمل دليلًا مستقلًا. لا بدّ من شيء يراقب السلوك بعد تصحيحه.
ما تحتاجه الحلقة ملاحظة، لا جولة أخرى.
تتوقف الجلسة مع أداة تصحيح الأخطاء Trae عن التقدّم حين تنفد من الوكيل الفرضيات التي يسمح بها وصفك. امنحه ملاحظات حقيقية عن التطبيق أثناء تشغيله، واسأل هل يصمد الفشل أمام بداية نظيفة وأمام بيئة مختلفة، واحتفظ بحالة إعادة الإنتاج فحصًا دائمًا.