المهارات المتقدمة وتسريع العمليات: ما يبطئ عملك ليس النموذج، بل السياق الضعيف الذي تقدمه
📚 التنقل في السلسلة: شرحت المقالة السابقة «30 كيفية اختيار النموذج» أي نموذج نرسل وبأي قوة استدلال لكل عبارة. وتأتي هذه المقالة لتكمل المسيرة — فاختيار النموذج الصحيح وحده لا يكفي، بل الذي يحدد مقدار العمل الذي يمكنك إنجازه يوميًا هو كيفية تقديم السياق، وكيفية إدارة الجلسات، وكيفية تشغيل مسارات عمل متعددة في نفس الوقت. تتحدث المقالة التالية «32 الهجرة من Claude Code» عن كيفية انتقال المستخدمين القدامى بسلاسة.
في نهاية المقالة السابقة، تركت هذه العبارة: في كثير من الأحيان، ما يبطئ عملك ليس ضعف النموذج، بل هو عشوائية السياق الذي تقدمه، مما يجعله يسلك مسارًا خاطئًا. وتأتي هذه المقالة للإجابة بالتفصيل عن هذا الموضوع.
دعني أشاركك تجربة شخصية. في مارس 2025، كنت أقوم بتطوير أداة Python صغيرة، وظللت أتنقل مع Codex طوال بعد الظهر لإضافة ميزة واحدة — عندما راجعت سجل الجلسات لاحقًا عبر /status، وجدت أننا قمنا بـ 11 جولة من الأسئلة والأجوبة لهذا الطلب وحده، وخلالها قام بتعديل ملفين خاطئين، وقام بـ «تحسين» ملف تكوين لم أطلب منه لمسه على الإطلاق. وعند مراجعة الأمر، أدركت أن المشكلة لم تكن في نموذج gpt-5.5، بل كانت في أن أول جملة لي كانت غامضة للغاية «ساعدني في إضافة ميزة التصدير»، وقضيت الجولات العشر التالية في محاولة تقديم السياق الذي كان ينبغي علي تقديمه بوضوح من المرة الأولى.
الحقيقة هي أنه في البرمجة المدعومة بالذكاء الاصطناعي، البطء الأكبر لا يأتي أبدًا من ثواني الانتظار أثناء تشغيل النموذج، بل يأتي من إعادة العمل. إذا لم توضح مقصدك من المرة الأولى، فسيسلك الذكاء الاصطناعي مسارًا خاطئًا، وتضطر لإعادته، وتكرر ذلك ثلاث مرات لتضيع نصف ساعة من وقتك. بغض النظر عن سرعة النموذج، لن يتفوق شيء على توفير الوقت الناتج عن «إنجاز العمل بشكل صحيح من المرة الأولى».
لا تعلمك هذه المقالة تعاويذ سحرية، بل تركز على ستة إجراءات عملية لتقليل إعادة العمل وجعل تدفق العمل يسير بسلاسة.
بعد قراءة هذه المقالة، ستحصل على:
- مبدأ لتسريع العمل قد يبدو معاكسًا للبديهة: تقليل إعادة العمل > البحث الأعمى عن السرعة، فإنجاز العمل من أول مرة هو «التسريع» الحقيقي الموفر للوقت
- وصفة ثابتة لـ «الطلب الجيد»: الهدف + السياق + القيود + معايير القبول، مع جدول مقارنة للعبارات قبل وبعد التعديل
- ثلاث طرق لإدارة نافذة السياق: ضغط السياق عبر
/compact، وفتح جلسات جديدة عند الحاجة، واستخدام@لتغذية الملفات المعنية بدقة بدلاً من تحميل المستودع بأكمله - طريقة تفكير لخفض مستويات النماذج حسب المهمة لتوفير الوقت والمال (امتدادًا لاختيار النماذج في المقالة السابقة)
- أساليب متقدمة لتشغيل مسارات عمل متعددة بالتوازي، وجعل Codex يتحقق من عمله بنفسه
- تمرين عملي للتطبيق فورًا: تحويل طلب غامض إلى صيغة الأجزاء الأربعة، لمعرفة كيف تنخفض معدلات إعادة العمل عمليًا
⚠️ تعتمد الأوامر ومفاتيح التكوين والسلوك الافتراضي المذكورة في هذه المقالة على مستندات Codex الرسمية؛ وقد تتغير أسماء النماذج، ونسب احتساب الرصيد (credit)، وأوامر مثل
/fastحسب الإصدارات، لذا اعتمد دائمًا على ما يظهره أمرcodex --helpالمحلي والمستندات الرسمية.
01 جوهر التسريع: تقليل إعادة العمل، وليس مجرد البحث عن السرعة
دعنا نضبط طريقة تفكيرنا أولاً، وإلا فإن كل المهارات اللاحقة ستكون دون جدوى.
عندما يفكر المبتدئون في «التسريع»، فإن أول ما يتبادر إلى أذهانهم هو «استخدام نموذج أسرع» أو «خفض قوة الاستدلال» أو «تفعيل وضع التسريع». سنتحدث عن كل هذا لاحقًا، لكنها تفاصيل ثانوية. العقبة الكبرى الحقيقية هي إعادة العمل.
تشبيه: إعداد الطعام. عندما تكون بطيئًا في إعداد وجبة ما، نادرًا ما يكون السبب هو أن شعلة الموقد ليست قوية بما يكفي. في أغلب الأحيان، يرجع ذلك إلى أنك تكتشف في منتصف التقطيع أنك نسيت شراء البصل، أو وضعت الكثير من الملح وتضطر للبدء من جديد، أو أخطأت في خطوات الوصفة. ما يلتهم الوقت حقًا هو هذه الأخطاء وإعادات العمل، وليس حجم الشعلة. رفع الشعلة إلى أقصى حد لن ينقذ طاهيًا يعيد العمل باستمرار أثناء الطهي.
الأمر نفسه تمامًا في البرمجة مع الذكاء الاصطناعي. عندما يسلك Codex مسارًا خاطئًا، أو يعدل ملفًا غير مقصود، أو يسيء فهم نيتك، وتضطر لإعادته وتوضيح الأمر مرة أخرى — فإن تكلفة هذا الذهاب والإياب تفوق بكثير ثواني التفكير الإضافية للنموذج.
هناك جملة في المستندات الرسمية تركت أثرًا عميقًا لدي، ومؤداها: تكون جودة مخرجات Codex أعلى بكثير عندما يكون قادرًا على التحقق من عمله بنفسه. بمعنى آخر، جعله يسير في المسار الصحيح والمستقر من المرة الأولى أهم بكثير من جعله يسير بسرعة.
لقد مررت بتجربة نموذجية في نهاية العام الماضي عندما طلبت منه «تحسين هذه الدالة»، دون تحديد ما يجب تحسينه، وما الذي لا يجب لمسه، وما الذي يعتبر تحسينًا ناجحًا. قام بحماس بإعادة كتابة الدالة، وعدل توقيع الواجهة (interface signature) بالتبعية، مما تسبب في ظهور أخطاء في ثلاثة أطراف استدعاء. واستغرق الأمر مني عشرين دقيقة للتراجع عن الفوضى التي أحدثها تحت مسمى «التحسين». منذ ذلك الحين، وضعت قاعدة صارمة: لا أطلب أبدًا «التحسين» بشكل غامض، بل أفضل كتابة سطرين إضافيين لتوضيح التفاصيل.
تذكر هذا الترتيب، حيث تدور الأقسام الخمسة التالية حوله تمامًا:
| ما تعتقده عن التسريع | التسريع الحقيقي |
|---|---|
| ❌ التبديل السريع إلى نموذج أسرع مباشرة | ✅ التوضيح من أول جملة لتقليل جولات إعادة العمل |
| ❌ خفض قوة الاستدلال بشكل عشوائي للسرعة | ✅ مطابقة القوة الحسابية مع صعوبة المهمة (تحدثنا عنها سابقًا) |
| ❌ تحميل المشروع بأكمله ليقرأه | ✅ استخدام @ للإشارة بدقة للملفات المعنية |
| ❌ استخدام جلسة واحدة من الصباح إلى المساء | ✅ جلسة واحدة لكل مهمة، والضغط أو البدء من جديد في الوقت المناسب |
| ❌ فحص التعديلات سطرًا بسطر بالعين المجردة | ✅ تقديم معايير قبول ودعه يشغل الاختبارات بنفسه للتحقق |
💡 الخلاصة في جملة واحدة: البطء الأكبر في البرمجة مع الذكاء الاصطناعي هو إعادة العمل، والمبدأ الأول للتسريع هو «إنجاز العمل بشكل صحيح من المرة الأولى» وليس «التشغيل بشكل أسرع».
02 تقديم سياق كافٍ ودون تركه للتخمين: الوصفة الثابتة للطلب الجيد
ذكرنا في القسم السابق أن إعادة العمل هي العقبة الكبرى، فمن أين تأتي إعادة العمل؟ تأتي الأغلبية العظمى منها من عدم التوضيح في الجملة الأولى، مما يجبر Codex على التخمين. وعندما يخمن، فهناك احتمال كبير أن يخطئ، مما يضطرك لإعادة العمل.
تشبيه: ملاحظات توصيل الطعام. إذا كتبت فقط «أريد أرزًا مقليًا»، فسيقوم عامل التوصيل والمطبخ بإعداده بالطريقة الافتراضية — قد يحتوي على البصل، أو يكون حارًا، أو مالحًا. أما إذا كتبت «أرز مقلي على طريقة يانغتشو، بدون بصل، حار قليلاً، والأرز لين بعض الشيء»، فستحصل على طلبك الصحيح من المرة الأولى. الأمر نفسه ينطبق على طلباتك لـ Codex، فكل كلمة توفرها سيضطر لتخمينها، وإذا أخطأ فستضطر لإعادة العمل.
قدمت الجهة الرسمية في «أفضل الممارسات» وصفة ألتزم بها حتى اليوم. يتضمن الطلب الجيد افتراضيًا أربعة عناصر:
- الهدف (Goal): ما الذي تريد تعديله أو بنائه تحديدًا؟
- السياق (Context): ما هي الملفات أو المستندات أو الأخطاء ذات الصلة بالموضوع؟ استخدم
@للإشارة إليها. - القيود (Constraints): ما هي المعايير أو البنية التي يجب الالتزام بها، وما الذي لا يسمح بلمسه؟
- معايير القبول (Done when): متى يعتبر العمل منتهيًا؟ بعد تشغيل الاختبارات، أو تغير السلوك، أو عدم تكرار الخطأ؟
لا داعي لملء كل التفاصيل في كل عنصر، ولكن الهدف ومعايير القبول لا يمكن الاستغناء عنهما تقريبًا. عندما أكتب طلبًا الآن، حتى لو كنت على عجل، سأمر على هذه الخانات الأربع في ذهني.
الجدول التالي يعرض المقارنة بين طلبات قديمة غير واضحة قمت بصياغتها سابقًا والنسخ المعدلة منها، لتشعر بالفرق بنفسك:
| ❌ قبل التعديل (غامض، يؤدي حتمًا لإعادة العمل) | ✅ بعد التعديل (صيغة الأجزاء الأربعة، احتمالية نجاح عالية من المرة الأولى) |
|---|---|
| ساعدني في إضافة ميزة التصدير | الهدف: إضافة دالة في report.py لتصدير التقارير إلى صيغة CSV. السياق: راجع طريقة الكتابة الحالية في @export/json_export.py. القيود: أعد استخدام فئة البيانات Report الحالية، ولا تعدل حقولها. القبول: إمكانية تصدير ملف CSV يحتوي على الرأس، واجتياز جميع اختبارات tests/test_export.py |
| هذه الدالة بطيئة بعض الشيء، قم بتحسينها | الهدف: تقليل وقت تشغيل search() على 10,000 سجل من ثانيتين إلى أقل من 200 مللي ثانية. السياق: الدالة موجودة في @core/search.py. القيود: لا تغير توقيع الدالة ولا هيكل البيانات المرتجعة. القبول: تشغيل pytest tests/test_search.py::test_perf والتأكد من اجتياز التحقق بوقت تشغيل < 0.2 ثانية |
| أصلح هذا الخطأ (bug) | الهدف: إصلاح مشكلة الانتقال إلى صفحة بيضاء بعد تسجيل الدخول. السياق: خطوات إعادة إنتاج الخطأ هي «إدخال اسم المستخدم وكلمة المرور بشكل صحيح ← النقر على تسجيل الدخول ← ظهور صفحة بيضاء»، الكود المعني في @auth/login.py. القيود: لا تقم بتعديل منطق التحقق من الصلاحيات. القبول: تكرار خطوات إعادة الإنتاج يؤدي للانتقال لصفحة البداية بشكل صحيح |
هل لاحظت الفارق؟ الجانب الأيمن ليس أكثر إسهابًا، بل هو يكمل المعلومات التي هي موجودة بالفعل في ذهنك ولكنك كسلت عن كتابتها. إذا لم تقدمها، فسيخمنها Codex؛ وإذا قدمتها، فسيذهب مباشرة نحو الهدف.
عندما قمت بمراجعة أداة Python الصغيرة التي طورتها، وجدت أن كتابة نفس الطلب بالطريقة اليسرى استغرقت في المتوسط 5 إلى 8 جولات لإنجازها، بينما مع صيغة الأجزاء الأربعة اليمنى، تم إنجاز العمل في معظم الأوقات خلال جولة أو جولتين. الأسطر الإضافية التي تكتبها توفر عليك عناء الذهاب والإياب لاحقًا.
هناك أيضًا طريقة عملية وبسيطة: عندما تكون المهمة صعبة للغاية ولا تعرف كيف تصفها بنفسك، لا تحاول كتابتها مباشرة، بل دع Codex يساعدك في تنظيمها أولاً. تنصح الجهة الرسمية باستخدام وضع الخطة (Plan mode)، ويمكنك التبديل إليه في الـ CLI باستخدام /plan أو عبر الاختصار Shift+Tab، حيث سيقوم أولاً بجمع السياق وطرح بعض الأسئلة عليك وتقديم خطة عمل، ثم يبدأ التنفيذ بمجرد موافقتك. بدلاً من تركه يبدأ الكتابة بناءً على فهم خاطئ، من الأفضل قضاء دقيقة في تنظيم الخطة أولاً.
💡 الخلاصة في جملة واحدة: الطلب الجيد = الهدف + السياق + القيود + معايير القبول، وكل كلمة توفرها سيضطر Codex لتخمينها، والتخمين الخاطئ يعني إعادة العمل.
03 إدارة نافذة السياق: لا تضع المستودع بأكمله دفعة واحدة
عالج القسم الثاني موضوع «التوضيح»، ويعالج هذا القسم موضوع «عدم المبالغة في التفاصيل». قد يبدو الأمران متناقضين، لكنهما ليسا كذلك — المطلوب هو تقديم المعلومات ذات الصلة كاملة، وتجنب المعلومات غير الصلة.
لكل جلسة (يطلق عليها في Codex اسم thread) حد أقصى للمعلومات التي يمكن أن تستوعبها، وهذا ما يسمى نافذة السياق (context window)، وتشير إلى الحجم الإجمالي للمحتوى الذي يمكن للنموذج «تذكره» دفعة واحدة. إذا امتلأت، فسيتم إما ضغط المعلومات القديمة أو استبعادها، مما يؤدي إلى تراجع جودة المخرجات.
تشبيه: مكتب العمل. مساحة المكتب محدودة. إذا قمت بفرد الملفات الثلاثة التي تحتاجها للمهمة الحالية، فسيكون العمل سلسًا. أما إذا قمت بصب مئات المستندات من خزانة الملفات بأكملها على المكتب، فستجد صعوبة في العثور على الملف الذي تحتاجه. نافذة سياق Codex تشبه هذا المكتب؛ فكلما كانت التغذية دقيقة، كان تركيزه أعلى؛ وإذا وضعت المستودع بأكمله، فسيشتت انتباهه بالمعلومات غير الصلة.
لإدارتها بشكل جيد، تذكر ثلاث طرق:
الطريقة الأولى: استخدام @ لتغذية الملفات بدقة، وتجنب تركه يبحث في المستودع بأكمله عشوائيًا. عندما تعرف بدقة الملفات التي تريد تعديلها، أشر إليها مباشرة باستخدام @. لن يضطر لاستهلاك السياق في البحث عبر أوامر grep، وسيعمل بدقة وسرعة أكبر. في تجربتي البرمجية المذكورة سابقًا، كان أحد الأسباب الرئيسية للمشكلة هو عدم تحديد الملفات، فقام بقراءة سبع أو ثماني وحدات غير ذات صلة قبل العثور على المكان المطلوب تعديله — وتلك المعلومات المقروءة ظلت تشغل مساحة المكتب دون داعٍ.
الطريقة الثانية: استخدام /compact عندما تطول الجلسة. عندما يطول الحوار في الجلسة، تتراكم المحتويات السابقة بشكل كبير. يتيح لك أمر /compact توجيه Codex لضغط السياق المبكر وتلخيصه في نسخة موجزة، مما يوفر مساحة للاستمرار. وتشير الجهة الرسمية أيضًا إلى أن Codex يقوم بالضغط تلقائيًا عند الحاجة، ولكن استخدامك اليدوي لأمر /compact يتيح لك تنظيف المساحة بشكل فعال قبل أن يبدأ النموذج في فقدان تركيزه.
الطريقة الثالثة: وهي التي تؤكد عليها الجهة الرسمية باستمرار — جلسة واحدة لكل مهمة، وتجنب استخدام جلسة واحدة من الصباح إلى المساء. تذكر المستندات الرسمية صراحة في قسم «الأخطاء الشائعة»: إن استخدام «جلسة واحدة للمشروع بأكمله» بدلاً من «جلسة واحدة لكل مهمة» يؤدي إلى تراكم السياق بشكل مفرط وتراجع جودة النتائج تدريجيًا.
ألتزم الآن بقاعدة صارمة: بمجرد الانتهاء من مهمة معينة، أبدأ جلسة جديدة تمامًا للمهمة التالية غير ذات الصلة. الأوامر التالية في الـ CLI عملية للغاية:
/compact يضغط السياق المبكر للجلسة الحالية في ملخص لتوفير مساحة
/status يعرض حالة الجلسة الحالية، بما في ذلك المساحة المتبقية للسياق
/fork ينشئ مسارًا جديدًا متفرعًا من الجلسة الحالية مع الاحتفاظ بالسجلات الأصلية
/resume يستعيد جلسة سابقة تم حفظهاقاعدة تقييم: يجب أن يكون السياق «دقيقًا» وليس «كثيرًا». ابق في نفس الجلسة لنفس السؤال للحفاظ على سلسلة الاستدلال؛ وإذا تفرعت المهام فعليًا، استخدم /fork أو ابدأ جلسة جديدة.
معيار التقييم بسيط للغاية: إذا كان العمل استمرارًا لنفس المشكلة، فابق في الجلسة الأصلية؛ وإذا انتقلت لمهمة أخرى غير ذات صلة، فابدأ جلسة جديدة. لا تتردد في التخلي عن «سجل المحادثة»، فالسياق المتضخم يأتي بنتائج أسوأ، وهو أمر غير مجدٍ.
💡 الخلاصة في جملة واحدة: يجب أن يكون السياق دقيقًا وليس كثيرًا. استخدام
@لتحديد الملفات، وضغط السياق عبر/compactفي الوقت المناسب، وتخصيص جلسة لكل مهمة هي الأدوات الثلاث لإدارة نافذة السياق.
04 خفض المستويات حسب المهمة: لا تستخدم النموذج الرائد للمهام البسيطة
يرتبط هذا القسم بالمقالة السابقة، وسنمر عليه سريعًا — حيث قمنا بتوضيح كيفية اختيار النماذج بالتفصيل، ونضيف هنا منظور «التسريع».
تشبيه: اختيار وسيلة الانتقال للذهاب للعمل. للذهاب لشراء زجاجة ماء من أسفل المبنى لن تستخدم السيارة، بل ستسير بضع خطوات؛ وللسفر إلى مدينة أخرى لن تستخدم الدراجة المشتركة. تحدد صعوبة المهمة حجم القوة الحسابية المطلوبة، تمامًا كما تحدد مسافة السفر وسيلة الانتقال المناسبة.
عند التطبيق العملي، تذكر قاعدة واحدة: للمهام البسيطة والمحددة بوضوح، استخدم مستويات أقل. نصائح قوة الاستدلال المقدمة في «أفضل الممارسات» الرسمية واضحة للغاية —
- للمهام السريعة واضحة النطاق: استخدم
low، أو مستويات أقل للمهام الأكثر بساطة - للتعديلات المعقدة وتصحيح الأخطاء: استخدم
mediumأوhigh - للمهام الطويلة والثقيلة التي تتطلب استدلالاً مكثفاً: استخدم فقط
xhigh
الأمر نفسه ينطبق على اختيار النماذج، فللمهام الروتينية والتحققات التي يقوم بها الوكلاء الفرعيون، يكفي استخدام النموذج الخفيف gpt-5.4-mini، ولا داعي لاستدعاء النموذج الرائد gpt-5.5 في كل صغيرة وكبيرة. لتصحيح الأخطاء الإملائية (typos)، أو تغيير اسم متغير، أو تشغيل استعلام بسيط، قم بالخفض إلى gpt-5.4-mini + low للعمل بسرعة وتوفير رصيد الاستهلاك.
التكوين الافتراضي لدي في ملف ~/.codex/config.toml هو المستوى المتوسط، وأقوم برفعه مؤقتًا داخل الجلسة عند مواجهة المهام الصعبة. تجنب قفل الإعداد الافتراضي على gpt-5.5 + xhigh كما كنت أفعل سابقًا — فانتظار دقيقة كاملة ليقوم «بالتفكير العميق» من أجل تعديل اسم متغير هو أمر غير مجدٍ. لمراجعة كيفية إعداد ذلك وطرق التبديل الأربع، ارجع إلى المقالة 30.
💡 الخلاصة في جملة واحدة: للمهام البسيطة استخدم مستويات أقل، حيث إن المزيج
gpt-5.4-mini+lowسريع وموفر، واحتفظ بالنموذج الرائد ذي الإعدادات القصوى للمهام الصعبة حقًا.
05 العمل المتوازي: تشغيل مسارات متعددة في نفس الوقت
ركزت الأقسام الأربعة السابقة على جعل المسار الواحد يسير بسلاسة. ويضيف هذا القسم بعدًا آخر — لا تنتظر انتهاء مسار واحد حتى تبدأ الآخر، بل شغل مسارات متعددة بالتوازي.
تذكر المستندات الرسمية في قسم «الأخطاء الشائعة» بوضوح: التعامل مع Codex كأداة يجب عليك مراقبتها خطوة بخطوة، بدلاً من اعتباره شريكًا يعمل معك بالتوازي، هو خطأ نموذجي يقع فيه المبتدئون. يمكنك تمامًا تركه يقوم بإعادة هيكلة الكود في جانب، بينما تستمر أنت في العمل على أشياء أخرى في جانب آخر.
ولكن هناك مشكلة يجب تجنبها — لا تدع مسارين يعدلان نفس الملفات في نفس الوقت. سيؤدي ذلك إلى تداخل التعديلات وتخريب منطقة العمل الخاصة بك. الحل المقدم رسميًا هو استخدام مساحات عمل git (git worktrees)، وتحدثنا عنه بالتفصيل في المقالة 25.
تشبيه: دخول عمال تخصصات مختلفة لموقع البناء في نفس الوقت. لتشغيل أعمال الكهرباء والنجارة والطلاء بالتوازي، يجب أن يعمل كل منهم في غرفة مستقلة، ولا يمكنهم التجمع في غرفة واحدة وإعاقة بعضهم البعض. يقوم worktree بمنح كل مسار عمل «غرفة» مستقلة خاصة به ليعمل دون تداخل.
هناك طريقتان شائعتان للعمل المتوازي، وتتوافقان مع المقالات السابقة:
| أسلوب العمل | كيفية العزل | المقالة ذات الصلة |
|---|---|---|
| تشغيل مهام متعددة في نفس الوقت | تخصيص git worktree لكل مسار في دليل مستقل | المقالة 25 (worktrees) |
| المسار الرئيسي + تقسيم المهام | تركيز الوكيل الرئيسي على المشكلة الجوهرية، وتفويض التحقق والاختبار والبحث للوكلاء الفرعيين | المقالة 21 (subagents) |
النصيحة الرسمية بشأن الوكلاء الفرعيين (subagents) هي: دع الوكيل الرئيسي يركز على المشاكل الجوهرية، وقم بتفويض المهام واضحة الحدود — مثل استكشاف الكود، وكتابة الاختبارات، وتتبع المشاكل — لوكلاء فرعيين. عدم مقاطعة المسار الرئيسي بهذه المهام الجانبية يجعل العمل الإجمالي أسرع.
عندما أقوم بتنفيذ مهام كبيرة نسبيًا، تكون عادتي كالتالي: دفع المنطق الجوهري في الجلسة الرئيسية، وفي نفس الوقت فتح worktree آخر ليدع Codex يقوم بتشغيل الاختبارات وأدوات الفحص (lint). عندما أنتهي من كتابة المسار الرئيسي، تكون نتائج الفحص لديه قد ظهرت تقريبًا، وتشغيل الأمرين بالتوازي يوفر وقتًا كبيرًا مقارنة بالتشغيل المتتالي.
💡 الخلاصة في جملة واحدة: شغل مسارات عمل متعددة بالتوازي، واستخدم worktree للعزل وتفويض المهام الجانبية للوكلاء الفرعيين، ولكن لا تدع مسارين يعدلان نفس الملفات في نفس الوقت أبدًا.
06 دعه يتحقق بنفسه: تقليل جولات التأكيد اليدوية المتبادلة
الطريقة الأخيرة، وهي الأكثر تجاهلاً في الغالب ولكنها تعطي أعلى عائد — دع Codex يتحقق من عمله بنفسه، وتجنب فحص كل شيء يدويًا بنفسك.
بالعودة إلى مبدأ القسم الأول: إعادة العمل هي العقبة الكبرى للسرعة. وقيامك بالتحقق والتأكيد ذهابًا وإيابًا هو في حد ذاته بطء. قيامه بالتعديل، ثم قيامك بفتح الملف وفحصه سطرًا بسطر، واكتشاف خطأ وتوجيهه مرة أخرى — كل هذه الجولات من الفحص البشري تستهلك وقتًا طويلاً.
توضح الجهة الرسمية أن مخرجات Codex تكون أفضل عندما يكون قادرًا على التحقق من عمله بنفسه، ولكن الشرط الأساسي هو أن يعرف كيف يبدو العمل «الصحيح». وتأتي هذه المعايير إما من طلبك (prompt) أو من ملف تعليمات المشروع AGENTS.md.
تشبيه: قائمة التحقق قبل تسليم الواجب. عندما تكلف موظفًا بمهمة، وترفق بها قائمة «تحقق من هذه النقاط الخمس بنفسك قبل التسليم»، فسيقوم بالفحص الذاتي قبل التسليم وتقتصر مهمتك على المراجعة السريعة. أما إذا لم تكن هناك قائمة، واعتمدت بالكامل على تصحيح أخطائه بنفسك سطرًا بسطر، فستصبح أنت عقبة في سير العمل. تقديم معايير قبول لـ Codex يشبه إعطاءه قائمة الفحص الذاتي هذه.
وجهه للقيام بهذه الأمور بنفسه تحديدًا (مستوحاة من «أفضل الممارسات» الرسمية):
- كتابة أو تحديث الاختبارات للتعديلات الجديدة
- تشغيل مجموعات الاختبارات المعنية
- تشغيل أدوات الفحص (lint) والتنسيق والتحقق من الأنواع (type checking)
- التأكد من أن السلوك النهائي يتوافق مع ما طلبته
- مراجعة الفروق (diff) بنفسه للبحث عن أخطاء أو تراجعات في الأداء أو كتابة برمجية خطرة
أمر /review في الـ CLI مفيد جدًا، ويمكنه إجراء المراجعة بناءً على الفرع الرئيسي مثل مراجعة طلبات السحب (PR)، أو مراجعة التغييرات غير الملتزم بها، أو المراجعة وفقًا لقواعد مخصصة تحددها أنت.
ولإعداد حل دائم: اكتب «كيفية التحقق من انتهاء العمل» و«ما هي الاختبارات التي يجب تشغيلها» في ملف AGENTS.md، وسيقوم بتطبيقها تلقائيًا في كل مرة دون الحاجة لتكرارها في طلباتك. تحدثنا عن هذا بالتفصيل في المقالة 11.
الإجراء المعتاد لدي الآن هو تضمين عبارة «شغل pytest بعد التعديل، وأخبرني بالنتيجة بمجرد نجاح جميع الاختبارات» مباشرة في الطلب. يقوم بتشغيل الاختبارات والتأكد من نجاحها قبل العودة إلي، مما يوفر عليّ جولات الذهاب والإياب المتمثلة في «يقول إنه عدل الكود ← أقوم بتشغيل الاختبارات ← أجدها تفشل ← أوجهه للإصلاح مجددًا». ببساطة، دع الذكاء الاصطناعي يتولى خطوة التحقق بالكامل لتتحرر أنت من مراقبته المستمرة.
💡 الخلاصة في جملة واحدة: تقديم معايير القبول وتوجيه Codex لتشغيل الاختبارات والمراجعة بنفسه يغنيك عن جولات التأكيد البشري المتبادلة، وهو الإجراء الأعلى عائدًا لتسريع العمل.
07 على الهامش: ميزات بسيطة مثل وضع السرعة الفائقة
كانت الأقسام الستة السابقة هي الهيكل الأساسي، ويأتي هذا القسم كمكمل لها لبيان التفاصيل.
يحتوي Codex على وضع السرعة الفائقة (Fast mode)، والذي يمكنه تسريع النماذج المدعومة بنحو 1.5 مرة، مقابل استهلاك أعلى للرصيد (credit). ووفقًا لتوضيحات الجهة الرسمية، فإنه يدعم حاليًا GPT-5.5 و GPT-5.4، حيث يتم خصم الرصيد بمعدل 2.5 ضعف للمعدل القياسي عند استخدام وضع السرعة مع GPT-5.5، و 2 ضعف مع GPT-5.4.
يمكنك تفعيل وإغلاق واستعراض الحالة في الـ CLI باستخدام الأوامر التالية:
/fast on تفعيل وضع السرعة الفائقة
/fast off إغلاق الوضع
/fast status عرض الحالة الحاليةولجعله مفعلًا افتراضيًا، يمكنك كتابة الإعداد في ملف ~/.codex/config.toml للاحتفاظ به:
service_tier = "fast"
[features]
fast_mode = trueتذكر شرطين أساسيين: الأول هو أن وضع السرعة الفائقة متاح فقط عند تسجيل الدخول عبر حساب ChatGPT، أما إذا كنت تستخدم API key للاتصال فسيتم الاحتساب بالأسعار القياسية للـ API ولا يمكنك استخدام هذا الوضع؛ والثاني هو أن هذا الوضع يستهلك مالاً (رصيدًا) مقابل السرعة، وليس مجانيًا.
الحقيقة هي أن وضع السرعة الفائقة هو ميزة تكميلية للمرحلة الأخيرة، وليس العنصر الأساسي. توفير الوقت الذي تحققه الإجراءات الستة السابقة (توضيح الطلبات، وإدارة السياق، وخفض المستويات حسب المهمة، والعمل المتوازي، والتحقق الذاتي) يقاس بـ «جولات كاملة» ومنع إعادة العمل بالكامل؛ بينما يوفر وضع السرعة الفائقة 1.5 مرة من سرعة الاستجابة الواحدة فقط. احرص على تطبيق النقاط الست السابقة أولاً بشكل صحيح، ثم فكر في مدى حاجتك لدفع رصيد إضافي مقابل هذه السرعة. لا أقوم بتفعيله عادةً في عملي اليومي، وأستخدم /fast on مؤقتًا فقط عندما أكون على عجل وبشرط أن تكون المهمة تستحق التكلفة.
💡 الخلاصة في جملة واحدة: يوفر وضع السرعة الفائقة سرعة أكبر بنحو 1.5 مرة مقابل استهلاك رصيد إضافي، وهو ميزة تكميلية؛ بينما توفر النقاط الست السابقة عناء إعادة العمل بالكامل، فابدأ بها أولاً قبل التفكير في هذه الميزة.
08 الجزء العملي: تحويل طلب غامض إلى صيغة الأجزاء الأربعة
القراءة دون تطبيق غير مفيدة لتذكر المعلومات. لن يستغرق هذا التمرين أكثر من خمس دقائق، لتشعر بالفارق بين «النجاح من المرة الأولى» و«إعادة العمل ذهابًا وإيابًا».
الخطوة الأولى: ابحث عن طلب غامض تعودت على كتابته بشكل عابر. على سبيل المثال:
帮我给这个项目加个日志功能الخطوة الثانية: أعد صياغته باستخدام صيغة الأجزاء الأربعة المذكورة في القسم 02. حدد العناصر الأربعة التالية في ذهنك أو اكتبها مباشرة:
الهدف: إضافة أداة سجلات (logging) موحدة للمشروع، بحيث يمكن تصنيف السجلات إلى INFO/ERROR وتوجيه المخرجات إلى وحدة التحكم (console) وملف السجلات.
السياق: راجع طريقة قراءة التكوين في @utils/config.py، بحيث يتم قراءة مستوى السجل من ملف التكوين.
القيود: استخدم مكتبة logging القياسية، ولا تستخدم أي مكتبات خارجية؛ ولا تقم بتغيير توقيع أي دالة حالية.
القبول: إمكانية استيراد الأداة في ملف المدخل main وطباعة سجل بمستوى INFO في logs/app.log، مع توليد ملف السجلات بشكل صحيح.الخطوة الثالثة: أرسل النسختين إلى Codex في جلستين مختلفتين، واحسب عدد الجولات. ابدأ أولاً بجلسة جديدة وأرسل النسخة الغامضة، وانتظر حتى ينتهي العمل (لاحظ أنه قد يطرح عليك بعض الأسئلة أو يختار حلولاً من تلقاء نفسه)، واحسب عدد جولات الذهاب والإياب حتى تصل للنتيجة المطلوبة؛ ثم ابدأ جلسة جديدة وأرسل النسخة المكونة من أربعة أجزاء، واحسب الجولات بنفس الطريقة.
من المتوقع أن تلاحظ:
- النسخة الغامضة: سيقوم Codex على الأرجح بطرح أسئلة مثل «أين يتم توجيه المخرجات» أو «هل تحتاج لتصنيف السجلات» أو «ما هي المكتبة التي تفضلها»، أو قد يختار مباشرة حلولاً قد لا تفضلها، وتستغرق العملية عادة 3 جولات على الأقل.
- نسخة الأجزاء الأربعة: سيبدأ التنفيذ مباشرة نحو الهدف، وينتهي العمل في أغلب الأوقات خلال جولة أو جولتين، وتكون النتيجة مطابقة تمامًا لتوقعاتك.
الفكرة الأساسية من هذا التمرين ليست عدد الجولات الفعلي في محاولة معينة، بل هي جعلك تشعر عمليًا بأن: الأسطر الإضافية التي تكتبها توفر عليك عناء الذهاب والإياب لاحقًا. وهي مقايضة رابحة دائمًا.
بعد الانتهاء من هذا التمرين، يمكنك تدوين قيودك المفضلة وعادات القبول في ملف AGENTS.md لتطبيقها تلقائيًا في المستقبل دون الحاجة لكتابتها يدويًا في كل مرة.
💡 الخلاصة في جملة واحدة: تشغيل النسخة الغامضة ونسخة الأجزاء الأربعة ومقارنة عدد الجولات سيظهر لك بوضوح كيف توفر كتابة أربعة أسطر إضافية عناء إعادة العمل بالكامل.
ملخص
أعادت هذه المقالة توجيه مفهوم «التسريع» بعيدًا عن الفهم الخاطئ المتمثل في «استخدام نموذج أسرع»، لتضعه في ستة إجراءات عملية توفر الوقت الفعلي:
- مبدأ التفكير: تقليل إعادة العمل > البحث الأعمى عن السرعة، فإنجاز العمل بشكل صحيح من المرة الأولى هو التسريع الحقيقي.
- توضيح الطلبات: الهدف + السياق + القيود + معايير القبول، فكل كلمة توفرها سيضطر Codex لتخمينها.
- إدارة السياق: استخدام
@لتحديد الملفات بدقة، وضغط السياق عبر/compact، وتخصيص جلسة لكل مهمة. - خفض المستويات حسب المهمة: تشغيل المهام البسيطة باستخدام
gpt-5.4-mini+lowلتوفير الوقت والرصيد، والاحتفاظ بالنموذج الرائد للمهام الصعبة. - العمل المتوازي: استخدام worktree للعزل وتفويض المهام الجانبية للوكلاء الفرعيين، وتجنب تعديل نفس الملفات بالتوازي.
- التحقق الذاتي: تقديم معايير قبول ودع الذكاء الاصطناعي يشغل الاختبارات والمراجعة بنفسه لتقليل جولات التأكيد البشري.
- تظل ميزات مثل وضع السرعة الفائقة إضافات تكميلية، فاحرص على ضبط الإجراءات السابقة أولاً قبل التفكير فيها.
ينبغي عليك الآن أن تكون قادرًا على: التفكير في صيغة الأجزاء الأربعة بمجرد حصولك على مهمة جديدة بدلاً من إرسال طلب غامض؛ واستخدام @ و /compact للحفاظ على سياق نظيف ودقيق؛ ومعرفة متى تخفض مستويات النماذج ومتى تشغل المهام بالتوازي وتجعل Codex يتحقق من عمله بنفسه. بمجرد أن تصبح هذه الممارسات جزءًا من عاداتك اليومية، ستلاحظ زيادة كبيرة في إنتاجيتك — ليس لأن النموذج أصبح أسرع، بل لأنك توقفت عن جعله يسلك مسارات خاطئة.
المقالة التالية 〔32 الهجرة من Claude Code〕 مخصصة لمجموعة معينة من القراء: الذين ينتقلون من Claude Code. أين توجد ملفات مثل CLAUDE.md هنا؟ وكيف يتم نقل مفاهيم مثل الصلاحيات والمهارات (Skills) والوكلاء الفرعيين؟ وما هي العادات التي يمكن نقلها مباشرة وتلك التي يجب تعديلها؟ فكر في هذا السؤال البسيط — ما هي العادة التي اعتدت عليها في Claude Code وقد تؤدي لإبطاء عملك عند الانتقال إلى Codex؟ سنوضح ذلك في المقالة القادمة.