ما هو Codex ومتى تحتاجه؟

وكيل للعمل على الشيفرة

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

اكتب المهمة كعقد صغير: ما النتيجة المطلوبة، وما الملفات أو المشروع في النطاق، وما الذي لا ينبغي تغييره، وكيف نتحقق. مثال: «أصلح فشل التحقق من البريد في نموذج التسجيل. لا تغيّر التصميم أو واجهة الخادم. أضف اختباراً للحالة، ثم شغّل lint وtype-check والاختبارات». هذه الحدود تقلل التوسع غير المقصود.

راجع قبل الدمج

يستطيع Codex تنفيذ أوامر وتعديل شيفرة، لكنه قد يسيء فهم بنية المشروع أو ينجح اختبار مع بقاء مشكلة أخرى. اطلب قراءة تعليمات المستودع أولاً، وفحص التغييرات الحالية حتى لا يكتب فوق عملك. بعد التنفيذ، راجع الفرق والاختبارات الفعلية، ولا تكتفِ بعبارة «يجب أن يعمل».

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

قد تتغير أسطح Codex وطرق استخدامه. راجع وثائق Codex الرسمية وإعدادات البيئة الحالية. تجنب لصق مفاتيح سرية في المهمة، واستخدم إدارة الأسرار المناسبة للمشروع.

أعطِه دليلاً على الاكتمال

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

اقرأ التقرير النهائي وقارن كل ادعاء بمخرجات الأوامر والفرق الفعلي قبل اعتماد التغيير.

راجع تحديثات المحتوى