تقنية Gauntlet Loop: كيف تجبر الذكاء الاصطناعي يحسّن شغله فعليًا
بدل ما تقول له «خليه أفضل» وتتمنى، هذي طريقة تفرض عليه معيارًا واضحًا، ناقد منفصل، ومقارنة عمياء — لين يفوز فعلاً لا لين يتعب.
متقدم10 دقيقة قراءة
وش راح تقدر تسوي بعد هذا الشرح
- تفهم ليش «اجعله أفضل» تعليمات ضعيفة، وتستبدلها بمعيار قابل للمقارنة
- تطبّق حلقة Build → Critic → Compare → Fix → Re-test على أي مهمة قابلة للفحص
- تملك برومبت جاهز تنسخه مباشرة لـChatGPT أو Claude أو Gemini أو أي وكيل برمجة
- تعرف الحالات اللي التقنية تفشل فيها، وليش المشروع بدون مرجع مقارنة يفشل معها
- تتحكم بالتكلفة والتوكنز بدل ما تخليها تلف بلا حدود
قبل ما تبدأ
- وصول لأداة ذكاء اصطناعي تقدر تدير محادثة طويلة أو وكيل (ChatGPT، Claude، Gemini، أو وكيل برمجة زي Cursor)
- فكرة عن المخرج اللي تبيه ومثال حقيقي واحد على الأقل تقارن عليه
معظم الناس يستخدمون الذكاء الاصطناعي بطلب واحد وتعديل واحد: «اكتب لي هذا»، ثم «حسّنه شوي». المشكلة إن كلمة «حسّنه» ما فيها معيار — النموذج يخمّن وش تقصد، ويرجّع نسخة معدّلة شكليًا بدون ضمان إنها أفضل فعليًا.
Gauntlet Loop تقنية طلعت مؤخرًا لحل هذي بالضبط: تجبر الذكاء الاصطناعي يحكم على شغله بمعيار حقيقي، بواسطة ناقد منفصل، بمقارنة عمياء — وتكرر العملية لين يفوز المخرج فعليًا لا لين تنتهي محاولات معدودة.
من وين طلعت التقنية؟
التقنية مرتبطة بمطوّر يدعى Matt Shumer، اللي كتب البرومبت الأصلي وسمّاه أثناء بنائه مشروعًا تجريبيًا بالكود يحاكي أسلوب لعبة فيديو (أطلق عليه اسم Claude of Duty) كإثبات مفهوم لقدرة النموذج على تحسين شغله ذاتيًا لما يُعطى معيارًا صارمًا. بعدها صارت التقنية موضوع نقاش واسع، وطلعت لها حزم وأدوات جاهزة من مطورين ثانين (منها مستودعات مفتوحة المصدر تعبّئ البرومبت كـ«مهارة» جاهزة لوكلاء البرمجة).
البرومبت الجاهز — انسخه واستخدمه
الصق هذا مباشرة في محادثة جديدة مع ChatGPT أو Claude أو Gemini، أو في وكيل برمجة:
أريدك تطبّق أسلوب "Gauntlet Loop" على المهمة التالية:
الهدف: [صف المطلوب بدقة — مثلاً: صفحة هبوط لمنتجي، أو دالة برمجية تسوي X]
المعيار (Bar): [أعطِ مثالاً حقيقيًا وملموسًا تُقارن عليه — منتج منافس، كود يشتغل صح، نص تعتبره ممتازًا]
قواعد العمل:
1. اقسم المهمة لأصغر أجزاء ممكن الحكم عليها كل واحد لحاله.
2. لكل جزء: أنشئ نسخة (Build)، ثم افتح تقييمًا منفصلًا تمامًا كناقد (Critic) بلا معرفة مسبقة بمن بنى وش.
3. الناقد يقارن مخرجي بالمعيار بشكل أعمى (Compare) — بدون ما تخبره أيهما الأصل.
4. لو خسر المخرج، حدد أكبر فجوة وحيدة بينه وبين المعيار، وأصلحها تحديدًا (Fix) — لا تعدّل كل شي عشوائيًا.
5. أعد المقارنة من جديد (Re-test).
6. استمر بالحلقة لين يفوز المخرج فعليًا بالمقارنة العمياء، مو لين تنتهي عدد جولات معين.
7. سقف أقصى: لا تتجاوز [8] جولات لكل جزء. لو وصلت الحد بدون فوز، أخبرني بآخر فجوة متبقية وتوقف.
ابدأ بتقسيم المهمة، واعرض عليّ خطتك قبل ما تبدأ التنفيذ.النقطة الحرجة اللي تحدد نجاح البرومبت من فشله: معيار حقيقي وملموس بالخطوة الثانية. لو كتبت «جودة عالية» بدل مثال فعلي، الحلقة كلها تفشل من نقطة البداية.
الحلقة بالتفصيل: Build → Critic → Compare → Fix → Re-test
- Build — وكيل ينتج نسخة أولى من الجزء المطلوب.
- Critic — وكيل ثاني، بسياق جديد كليًا، يفحص المخرج بدون معرفة مسبقة.
- Compare — الناقد يقارن مخرجك بالمعيار الحقيقي، بشكل أعمى، ويقرر أيهما أفضل.
- Fix — لو خسر مخرجك، يحدد أكبر فجوة وحيدة، ووكيل البناء يصلحها تحديدًا.
- Re-test — تُعاد المقارنة من الصفر، والحلقة تستمر لين الفوز الفعلي.
متى تستخدمها، ومتى لا
استخدمها لما عندك مرجع حقيقي تقارن عليه (منتج منافس، اختبارات تلقائية، معيار أداء رقمي)، والمهمة قابلة للتقسيم، ومستعد تدفع وقت وتكلفة إضافية مقابل نتيجة أوضح.
لا تستخدمها لمشروع جديد كليًا بدون أي مرجع — هنا الناقد يخترع معياره الخاص، وهذا العيب المعروف بالتقنية. وتجنبها كذلك للمهام الصغيرة اللي تنجز بطلب واحد.
التكلفة — كوني واعيًا
الحلقة تشغّل عدة وكلاء بجولات متكررة، مو طلب واحد — فهي أغلى بوضوح من محادثة عادية. مشاريع كبيرة ومعقدة استهلكت عند بعض المستخدمين مبالغ كبيرة من التوكنز. حدد سقف جولات صريح بالبرومبت، وقسّم المهمة لأجزاء صغيرة بدل تشغيلها على مشروع ضخم دفعة وحدة.
المصادر
الخطوات
الخطوة 1: وش هي Gauntlet Loop؟
التقنية طلعت مع مطوّر يدعى Matt Shumer، اللي كتب البرومبت الأصلي وسمّاه أثناء بنائه لعبة تجريبية بالكود سمّاها Claude of Duty كإثبات مفهوم. الفكرة: بدل ما تطلب من النموذج «حسّن هذا» وتترك له تقدير معنى «أحسن»، تعطيه معيار حقيقي — مثال ملموس أو خصم يقارن نفسه فيه — وتخلي وكيلًا منفصلًا (الناقد) يحكم مقارنة عمياء بين مخرجك والمعيار، بدون ما يعرف أيهما أيهما. لو خسر مخرجك، يحدد أكبر فجوة، ووكيل البناء يصلحها، وتعيد المقارنة. تتكرر الحلقة لين يفوز مخرجك فعليًا — مو لين تنتهي جولات معدودة.
ملاحظة: الاسم مو مصادفة: «Gauntlet» يعني ممر اختبار قاسي يازوره المخرج مرارًا حتى يثبت جدارته، مو مراجعة واحدة سطحية.
الخطوة 2: ليش «اجعله أفضل» تعليمات ضعيفة
لما تقول للنموذج «حسّنه» أو «اجعله احترافي أكثر»، ما فيه معيار يقيس عليه نفسه — فيرجع لك نسخة معدّلة شكليًا بدون تحسن حقيقي، أو يبالغ بتغييرات ما تحتاجها. المشكلة إن «الجودة» بدون مرجع ملموس كلمة مطاطة يقدر أي مخرج يدّعي إنه يحققها. القاعدة الأساسية بالتقنية: أي معيار ما يقدر الوكيل يعرّفه بدقة، مو معيار فعليًا. «أفضل من الموقع الرسمي لتطبيق X» معيار حقيقي تقدر تُختبر عليه؛ «جودة احترافية» مو معيار، هو رغبة.
ملاحظة: اختبر معيارك بسؤال: هل يقدر شخصان مختلفان يتفقان بسهولة إذا مخرج معين حققه أو لا؟ لو الجواب لا، المعيار غامض.
الخطوة 3: الحلقة: Build → Critic → Compare → Fix → Re-test
خمس خطوات تتكرر: **Build** — وكيل البناء ينتج نسخة من المطلوب (كود، نص، تصميم). **Critic** — وكيل ناقد منفصل تمامًا، بسياق جديد، يفحص المخرج بدون ما يعرف إنه هو من كتبه أو غيره. **Compare** — الناقد يقارن مخرجك بالمعيار (المثال الحقيقي) بشكل أعمى — ما يُقال له وش الأصل ووش النسخة. **Fix** — لو خسر مخرجك، الناقد يحدد أكبر فجوة وحيدة (مو قائمة عشوائية من الملاحظات)، ووكيل البناء يصلح تلك الفجوة تحديدًا. **Re-test** — تعاد المقارنة من الصفر. الحلقة تستمر لين يفوز مخرجك، لا لين تنتهي 3 أو 5 جولات — عدد جولات ثابت يكسر الفكرة كلها.
ملاحظة: الشرط الأهم: الناقد لازم يكون منفصلًا فعليًا عن البنّاء — سياق مختلف، ما يشوف كيف اتّخذ القرارات. لو نفس الوكيل يبني ويحكم على شغله، النتيجة تحيّز تلقائي.
الخطوة 4: مثال عملي 1: صفحة هبوط (Landing Page)
المعيار: صفحة هبوط منتج منافس ناجح تعرفه وتحبه. تعطي الوكيل رابط أو وصف الصفحة المرجعية، وتطلب صفحة لمنتجك بنفس المستوى. الناقد يقارن الاثنين على معايير ملموسة: وضوح العرض بأول 5 ثوانٍ، عدد النقرات لبلوغ الفعل المطلوب، التسلسل البصري. أول جولة غالبًا تخسر — والفجوة المحددة (مثلاً «العنوان الرئيسي يشرح الميزة مو الفائدة») هي اللي توجّه الإصلاح، مو تعليق عام زي «حسّن التصميم».
ملاحظة: لو ما عندك منافس تقارن عليه، خذ صفحة من صناعة مختلفة تمامًا لكن بنفس نمط التحويل (مثلاً صفحة تسجيل SaaS) — المعيار البنيوي أهم من التطابق بالمجال.
الخطوة 5: مثال عملي 2: مراجعة كود أو دالة برمجية
المعيار هنا مو موقع، هو معايير قابلة للتشغيل: يمر كل الاختبارات، وقت التنفيذ تحت حد معين، عدد أسطر أقل من نسخة معينة تعرفها تشتغل صح. وكيل البناء يكتب الحل، وكيل ناقد منفصل (ممكن حتى نموذج مختلف) يشغّل الاختبارات ويقارن الأداء الفعلي — مو رأيه عن «جودة الكود». هذا استخدام شائع مع وكلاء البرمجة (Cursor، Claude Code) لأن النتيجة قابلة للقياس الآلي، مو حكم ذوقي.
ملاحظة: بالكود تحديدًا، خلّ المعيار رقميًا كل ما أمكن (زمن تنفيذ، عدد اختبارات ناجحة) بدل وصفي — يقلّل احتمال إن الناقد يخترع معيارًا شخصيًا.
الخطوة 6: متى تستخدمها ومتى لا
**استخدمها لما**: عندك مثال حقيقي وملموس تقارن عليه (منتج منافس، اختبارات تلقائية، معيار أداء رقمي)، والمهمة قابلة للتقسيم لأجزاء صغيرة يُحكم عليها منفصلة، ومستعد تدفع وقت/تكلفة إضافية مقابل نتيجة أعلى بوضوح. **لا تستخدمها لما**: المشروع جديد كليًا وما فيه أي مرجع تقارن عليه — هنا الناقد يخترع معياره الخاص، وهذا بالضبط العيب المعروف بالتقنية: بدون مرجع حقيقي، Gauntlet Loop تفقد أساسها. كذلك تجنبها للمهام البسيطة اللي تنجز بطلب واحد — الحلقة تستهلك وقتًا وتوكنز ما تستاهلها مهمة صغيرة.
ملاحظة: قاعدة سريعة: لو تقدر تشرح المعيار بجملة واحدة قابلة للقياس، جرّبها. لو احتجت فقرة كاملة تشرح فيها «وش يعني أفضل»، المعيار مو جاهز بعد.
الخطوة 7: التحكم بالتكلفة والتوكنز
الحلقة مكلفة لأنها تشغّل عدة وكلاء (بنّاء + ناقد) بجولات متكررة، مو طلب واحد. تقارير من مستخدمين ذكروا مبالغ وصلت لمئات الدولارات بمشاريع كبيرة ومعقدة زي محاكاة لعبة كاملة. للتحكم: (1) حدد سقف جولات أقصى صريح بالبرومبت (مثلاً «توقف بعد 8 جولات حتى لو ما فزت، واعرض لي آخر فجوة») بدل ما تتركها مفتوحة كليًا. (2) قسّم المهمة الكبيرة لأجزاء صغيرة تُختبر كل واحدة لحالها بدل تشغيل الحلقة على المشروع كامل دفعة وحدة. (3) استخدم نموذجًا أخف للناقد لو المهمة ما تحتاج تحليلًا عميقًا، واحفظ النموذج الأقوى للبنّاء.
ملاحظة: راقب عدد الجولات الفعلي بعد أول تجربة — لو توقفت عند 3-4 جولات باستمرار، حط سقفك عند 6 بدل ما تتركه بلا حد.
أخطاء شائعة — وكيف تتجنبها
الخطأ«حسّن هذا الكود / التصميم / النص.» — بدون معيار، الوكيل يقرر بنفسه وش يعني أفضل.
الصحأعطه مثالًا حقيقيًا محددًا يقارن عليه: «اجعله بمستوى [مثال ملموس]، وأخبرني بالفجوة الأكبر لو خسر.»
الخطأتخلي نفس الوكيل يبني الحل ويحكم عليه بنفس المحادثة.
الصحافتح سياقًا منفصلًا تمامًا للناقد — ما يشوف كيف بُني المخرج ولا يعرف مين كتب أيهما.
الخطأتحدد عدد جولات ثابت («جرّب 3 مرات ووقف») بغض النظر عن النتيجة.
الصحاطلب استمرار الحلقة لين يفوز المخرج فعليًا، مع سقف أقصى كحماية من التكلفة، لا كهدف بحد ذاته.
الخطأتشغّل الحلقة على مشروع كامل ضخم بدون مرجع واضح.
الصحقسّمه لأجزاء صغيرة، كل جزء بمعيار مقارنة واضح خاص فيه.
الخطأتتجاهل التكلفة وتترك الحلقة تلف بلا مراقبة على مهمة كبيرة.
الصححدد سقف جولات صريح وراقب أول تجربة قبل ما تكررها على مشروع أكبر.
❓ أسئلة شائعة
من اخترع تقنية Gauntlet Loop؟
طلعت مع مطوّر يدعى Matt Shumer، اللي كتب البرومبت الأصلي وسمّى التقنية أثناء بنائه مشروعًا تجريبيًا بالكود (Claude of Duty) كإثبات مفهوم. بعدها انتشرت وصار فيها إصدارات وأدوات معبّأة من مطورين ثانين مبنية على نفس الفكرة.
هل Gauntlet Loop تشتغل مع أي أداة ذكاء اصطناعي؟
المبدأ عام ويشتغل مع أي أداة تقدر تدير محادثة طويلة أو تفصل بين وكيلين بسياقين منفصلين — ChatGPT، Claude، Gemini، أو وكلاء البرمجة زي Cursor وClaude Code. الفرق العملي إن وكلاء البرمجة أقدر على أتمتة الحلقة كاملة (تشغيل، فحص، إصلاح) لأنها متكاملة مع بيئة تنفيذ فعلية.
ليش تكلفتها عالية؟
لأنها ما تشغّل طلبًا واحدًا — تشغّل وكيل بنّاء ووكيل ناقد بسياقات منفصلة، بجولات متكررة، لكل جزء من المهمة. مشاريع معقدة (زي محاكاة لعبة كاملة) استهلكت عند بعض المستخدمين مبالغ كبيرة من التوكنز. حدد سقف جولات وقسّم المهمة لتتحكم بالتكلفة.
وش الفرق بينها وبين مجرد تكرار الطلب على النموذج؟
التكرار العادي («عدّل هذا مرة ثانية») ما فيه معيار خارجي ولا فاحص منفصل — النموذج نفسه يقرر متى يوقف. Gauntlet Loop تضيف ثلاث عناصر غايبة بالتكرار العادي: معيار ملموس تُقارن عليه، ناقد منفصل بلا تحيّز لصالح البنّاء، ومقارنة عمياء تمنع النموذج من معرفة إنه يحكم على شغله.
متى تفشل هذي التقنية؟
أوضح حالة فشل: مشروع جديد كليًا بدون أي مرجع حقيقي تقارن عليه. هنا الناقد يضطر يخترع معياره الخاص، وهذا يرجّعك لنفس مشكلة «اجعله أفضل» اللي كانت التقنية أصلاً تحاول تحلّها.
أقدر أستخدمها لكتابة مقال أو محتوى تسويقي؟
إي، المبدأ ينطبق على أي مخرج قابل للفحص والمقارنة — مو بس الكود. المعيار يكون مقال أو نص حقيقي تعتبره ممتازًا بنفس النوع، والناقد يقارن الأسلوب والبنية والوضوح بينه وبين مسودتك بشكل أعمى.