لا تمنح الوكيل موافقتك دون تدقيق: سدّد دين الفهم بست طرق، منها «دع الذكاء الاصطناعي يضع أسئلة لاختبارك»

ملاحظة الكاتب: تستند هذه المقالة إلى أفكار Addy Osmani حول «الاستسلام المعرفي» و«ديون الفهم»، وتقدم قائمة مراجعة ذاتية وقوالب موجهات للاستخدام قبل دمج طلبات السحب (PR)، مع مقارنة بنهج LobeHub في المراجعة المعتمد على تقارير قبول التغييرات، لمساعدتك على اختيار مستوى المراجعة المناسب للمخاطر.

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

هذه ليست دعوة للعودة إلى كتابة الشفرة يدويًا. فقد أوضح Addy Osmani، المهندس في Claude Code، أنه لا أحد يطلب من المهندسين حفظ قاعدة الشفرة بأكملها. المسألة ليست في قراءة كل سطر، بل في معرفة ما تفهمه وما لا تفهمه.

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

لا تمنح الوكيل موافقتك تلقائيًا: أهم ما تحتاج إلى معرفته عن دَين الفهم

بحسب تقرير لـ QbitAI أعادت نشره 36Kr، تناول Addy Osmani، مهندس Google السابق الذي يعمل حاليًا على Claude Code، مشكلة لافتة: كلما زادت موثوقية ما ينتجه الذكاء الاصطناعي، قلّ تدقيق البشر فيه. وقسّم هذه العملية إلى مراحل متتابعة، وطرح نوعين جديدين من «الدَّين». تجدر الإشارة إلى أن المفاهيم التالية منقولة عن التغطية الإعلامية، وللاطلاع على الصياغة الدقيقة يُرجى الرجوع إلى نص Addy الأصلي.

كيف يتدرج الاستسلام المعرفي ويتراكم دين الفهم؟

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

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

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

6 طرق لسداد دين الفهم

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

اطلب من الذكاء الاصطناعي اختبارك: أهم خطوة للتحقق من دين الفهم

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

اسأل عن القرارات غير المصرّح بها وما لم يُختبر

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

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

دليل سريع للفحص الذاتي قبل الدمج: 5 خطوات بدلًا من الموافقة العمياء على عمل Agent

عند جمع الطرق السابقة معًا، نحصل على عملية يمكن تنفيذها قبل دمج كل طلب سحب (PR). لا تتطلب مراجعة كل سطر، لكنها تتطلب أن تترك في كل خطوة أثرًا يدل على أنك فكرت فيما تراجعه.

1. اكتب توقعاتك قبل البدء: صِف المتطلبات وما تتوقع حدوثه بكلماتك الخاصة. إذا لم تكن راضيًا بعد تعديل الموجه مرتين متتاليتين، فأعد النظر في المتطلبات بدلًا من إضافة المزيد إلى الموجه.
2. اطلب توضيح القرارات: بعد انتهاء المهمة، اطلب من Agent سرد القرارات التي اتخذها دون تفويض، والافتراضات، والأمور التي لم يتحقق منها.
3. تحقق من الاختبارات الفعلية: راجع أوامر الاختبار التي نُفذت ونتائجها، واسأل عن الحالات الحدّية التي لم تغطها الاختبارات.
4. دع Agent يضع لك أسئلة: اطلب منه إعداد أسئلة للاختبار الذاتي بناءً على التغييرات في diff، ثم عد إلى الشفرة لقراءة الأجزاء التي أخطأت في الإجابة عنها وفهمها.
5. ابحث عن أمر فات فحصه: بعد أن ينتهي Agent من عمله، ابحث بنفسك عن أمر واحد على الأقل قد يكون أغفل التحقق منه.

مثال مبسّط لموجه اختبار فهم التغييرات

إليك موجهًا شائعًا لطلب أسئلة تختبر فهمك، ويمكنك لصقه مباشرة في محادثة Claude Code أو Cursor أو Cline:

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

# المرحلة A: قبل البدء (لسداد دين توضيح النية، أملأ هذا القسم بنفسي أولًا)
وصف المتطلبات:
- الفئة المستهدفة:
- المشكلة المطلوب حلها:
- ما لن يشمله العمل بوضوح:
- معايير الإكمال (ما الذي يُعد إنجازًا للمهمة):
- نطاق التغييرات والنتائج المتوقعة:

# المرحلة B: بعد انتهاء المهمة (أجب يا Agent عن كل نقطة)
1. ما القرارات التي اتخذتها دون تفويض صريح مني؟ اذكر كل قرار وسببه.
2. أين اعتمدت على افتراضاتك الخاصة؟ وماذا يحدث إذا لم تصح هذه الافتراضات؟
3. ما الأمور التي لم تتحقق منها بعد؟
4. ما التغييرات التي قد تؤثر في وظائف أو وحدات أخرى؟
5. ما أوامر الاختبار التي شغّلتها فعليًا؟ أرفق المخرجات الأصلية بدلًا من تلخيصها.
6. ما الحالات الحدّية التي لم تشملها الاختبارات؟

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

# المرحلة D: خطوة إضافية للتغييرات عالية المخاطر (يمكن إسنادها إلى جلسة مستقلة أخرى)
بصفتك مراجعًا مستقلًا، ودون الرجوع إلى ملخص الجلسة السابقة،
حدّد أكثر 3 مواضع يُحتمل أن تحدث فيها مشكلات، اعتمادًا فقط على المتطلبات الأصلية وdiff.

🎯 نصيحة للاستخدام: احرص على ملء المرحلة A بنفسك قبل بدء العمل، بدلًا من ترك Agent يكتبها نيابةً عنك. ويُفضّل فتح جلسة جديدة للمرحلة D، حتى لا يتأثر المراجع المستقل بملخص Agent السابق. وهذا يتفق مع تنبيه Addy بشأن فقدان المعلومات عند تناقلها بين عدة وكلاء.

قائمة سريعة بالأسئلة قبل الدمج

اختبارك بأسئلة من الذكاء الاصطناعي مقابل المراجعة بتقرير قبول

تأتي فكرة مختلفة تمامًا من LobeHub، منصة التعاون مفتوحة المصدر للوكلاء، التي تضم نحو 84 ألف نجمة على GitHub. وفقًا لتقرير صادر عن مختبر BaiJing، يقول الفريق إنه «يكاد لا ينظر إلى الشفرة البرمجية»، بل يركز على تقارير القبول متعددة الوسائط التي يقدمها الوكيل.

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

مقارنة بين نهجي المراجعة

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

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

اختر مستوى مراجعة دين الفهم بحسب مخاطر التغيير

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

💡 نصيحة للاختيار: إذا كان فريقك يمتلك نظامًا ناضجًا لاختبارات القبول الآلية، فيمكنك التركيز على الاختبارات القائمة على الأسئلة في التغييرات عالية المخاطر. أما إذا لم يكن لديه ذلك، فالتزم على الأقل بمبدأ «لا دمج إلا بعد الإجابة الصحيحة» في طلبات السحب المتعلقة باتساق البيانات والصلاحيات.

الأسئلة الشائعة FAQ

لا تصادق على عمل الـ Agent دون فهم: أبرز النقاط حول دَين الفهم

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

الخلاصة

أبرز النقاط لتجنب الموافقة على مخرجات الوكيل دون تدقيق:

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

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

📚 المراجع

1. 量子位: دليل شامل للوكلاء من مهندس Claude (أعادت 36 氪 نشره): يعرض آراء Addy Osmani وأساليبه العملية بشأن الاستسلام المعرفي ودَين الفهم ودَين النية.
2. الرابط: 36kr.com/p/4056027738116995

3. توضيح: مصدر الخط العام للمنهجية في هذا المقال، وهو عرض إعلامي لآراء الكاتب.

4. المنشور الأصلي لـ Addy Osmani: مصدر النص الأصلي المقتبس في التقرير.

5. الرابط: x.com/addyosmani/status/2117512471930167377

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

7. 白鲸实验室: شركة ذكاء اصطناعي حاصلة على 8万 نجمة تقرر أن تدع الذكاء الاصطناعي يتولى زمام أمورها (أعادت 36 氪 نشره): يعرض بنية الوكيل المشرف في LobeHub وممارسة إعداد تقارير القبول (Acceptance).

8. الرابط: 36kr.com/p/4056040123945860
9. توضيح: مصدر للمقارنة بشأن المراجعة باستخدام تقارير القبول. وعبارة «يكاد الفريق لا ينظر إلى الشفرة» من وصف الفريق نفسه.

الكاتب: الفريق التقني في APIYI