سايمون ويليسون يطوي أوصاف PR التي يكتبها الذكاء الاصطناعي: جوهر التغييرات في 1 فقرة

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

شرح سايمون ويليسون أسلوبًا يستخدمه مع طلبات الدمج التي يعدها Claude Code وCodex. يُبقي في الأعلى مقدمة قصيرة يتحمل بنفسه مسؤولية محتواها، ويضع وصف الوكيل الكامل داخل قسم قابل للتوسيع. يتيح GitHub تنفيذ ذلك مباشرة داخل Markdown باستخدام وسمَي HTML، وهما <details> و<summary>.

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

ما الذي يجب أن يبقى ظاهرًا

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

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

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

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

كيفية إعداد القسم القابل للتوسيع

يحيط الوسم <details> بالجزء المخفي من الوصف. وداخله، يحدد <summary> العنوان الظاهر، الذي يؤدي النقر عليه إلى إظهار بقية المحتوى. يدعم GitHub هذه البنية في أوصاف طلبات الدمج والتعليقات على المشكلات.

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

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

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

أين تنتهي فائدة التنسيق

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

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

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