كتابة التعليمات (Prompt): كيف تجعل Codex يفهمك تمامًا
📚 التنقل في السلسلة: الجزء السابق 12 · أوامر الشرطة المائلة والاختصارات علّمك كيف تضع يديك في المكان الصحيح أثناء الجلسة —
/لتغيير الوضع، ومسح السياق، وعرض الحالة، وحفظ كل الاختصارات. هذا الجزء ينتقل إلى مستوى مختلف: أصابعك تعرف أين تضغط، لكن كلماتك يجب أن تعرف كيف تتكلم. نفس الطلب، إذا قيل بطريقة مختلفة، يجعل Codex ينتج نتائج مختلفة تمامًا.
يقول الجميع إن "قوة أدوات البرمجة بالذكاء الاصطناعي تعتمد على النموذج" — لكنني لا أتفق مع هذا.
الحقيقة المُرّة: بنفس GPT-5 وبنفس المستودع، من يعرف كيف يطرح متطلباته يُنجز العمل في ثلاث جمل، أما من لا يعرف فيعيد العمل خمس مرات. النموذج أقوى من الكافي، وما يعيق معظم الناس ليس عقل النموذج، بل الجملة التي يُعطونها له. إذا ألقيت عليه جملة "أصلح هذا الخطأ" التي تكاد تكون بلا معلومات، فعليه أن يخمّن — أي ملف، ما الخطأ، كيف يجب أن يكون الحل، كل شيء بالتخمين. إذا أخطأ في التخمين، وجدت نفسك تتذمر من النتيجة وتقول "هذا الذكاء الاصطناعي لا يساوي شيئًا"، لكن المشكلة الحقيقية ليست فيه.
لقد تعلمت هذا الدرس بالتجربة. كان لديّ خادم Node يُعطي خطأ 500، فكتبت بلا تفكير "واجهة تسجيل الدخول معطلة، أصلحها" وضغطت Enter، دون أن أُرفق حتى السجلات. أمضى Codex وقتًا يبحث في المشروع، واختار ما ظنّه الخطأ، وعدّل ثلاثة ملفات، لم يصب أيًّا منها في مكان الداء الحقيقي — المشكلة الفعلية كانت في متغير بيئة لم أذكره قط. تعلمت حينئذ أن سقف أداء Codex يتحدد إلى حد بعيد بطريقتي في الصياغة.
لذا هذا الجزء لا يعلّمك حفظ قوالب، بل يعلّمك فهم شيء واحد — ما الذي يحتاج Codex معرفته فعلًا كي لا ينحرف عن المسار. حين تفهم هذا جيدًا، ستعرف تلقائيًا كيف تكتب التعليمات.
بعد قراءة هذا الجزء ستحصل على:
- جدول مقارنة بين "السؤال السيئ" و"السؤال الجيد"، قابل للتطبيق فورًا لتقليل إعادة العمل
- إطار عمل "الأربعة الأساسية" لكتابة المتطلبات: الهدف، النطاق، القيود، التحقق — غياب أي عنصر يدفع Codex للتخمين
- كيفية تقسيم المهام الكبيرة إلى خطوات يستطيع Codex إنجازها وتستطيع أنت مراجعتها
- الاستخدام الرسمي لـ
/goal(وضع الهدف) لتثبيت معايير القبول كـ "لا أتوقف حتى الإنجاز" (يتطلب تفعيلfeatures.goalsمسبقًا، التفاصيل في القسم 05) - تجربة عملية "نفس المتطلب بطريقتين" لترى الفرق بأم عينيك
⚠️ كل ما يتعلق بأوامر محددة ومعاملات وسلوكيات افتراضية في هذا الجزء مستند إلى الوثائق الرسمية لـ Codex؛ أسماء النماذج وواجهات المستخدم عرضة للتغيير بحسب الإصدار، فارجع دائمًا إلى ما يظهر فعلًا في بيئتك المحلية.
01 لماذا يكون السؤال سيئًا؟
لنفتح جرح التجربة السابقة ونتأملها. "واجهة تسجيل الدخول معطلة، أصلحها" — من منظور Codex، هذه الجملة تفتقر إلى معلومات كثيرة:
- أي واجهة تسجيل دخول؟ عليه تفتيش المشروع بأكمله.
- كيف تعطلت؟ ما الخطأ؟ في أي ظروف يتكرر؟ لا يعلم شيئًا.
- ما السلوك الصحيح المتوقع؟ لا أمامه إلا التخمين بناءً على "ما يُفترض أن تفعله واجهة تسجيل الدخول عادةً".
كما شرحنا في 06 · تنفيذ أول مهمة، يعمل Codex في حلقة وكيل (agent loop) — يستدعي النموذج، يقرأ الملفات، يُعدّلها، يُشغّل الأوامر، "يُفكّر → يُنفّذ → يُراجع" في دورة متكررة. الوثائق الرسمية تصفه بأنه "يُشغّل أوامر الطرفية في حلقة، يُعدّل الكود ويُجري الفحوصات ويحاول التحقق من عمله". لكن مهما بلغ ذكاء هذه الحلقة، إذا أُدخل إليها "قمامة" في خطوة "التفكير" الأولى، فستدور الحلقة كلها في الاتجاه الخاطئ.
مثال توضيحي: كتابة العنوان في طلب توصيل الطعام. لو كتبت "وصّل إلى ذلك الحي"، سيتجول العامل بين المباني حتى يُحتمل أن يخطئ ثم يتصل بك. أما "الحي الفلاني، مبنى 8، شقة 1503، أمام الباب دولاب أحذية أخضر"، فبإمكانه إغماض عينيه والوصول. كلما كان العنوان أدق، قلّ الدوران؛ كلما كانت الجملة ضبابية، زاد التخمين وزاد احتمال الخطأ. صياغة المتطلبات لـ Codex تمامًا مثل ذلك — دقة "العنوان" الذي تعطيه تحدد مباشرةً مدى دورانه.
إليك جدول المقارنة الذي تُكرر الوثائق الرسمية الإشارة إليه (السيئ على اليسار، الجيد على اليمين):
| الموقف | ❌ سؤال سيئ | ✅ سؤال جيد |
|---|---|---|
| إصلاح خطأ | "واجهة تسجيل الدخول معطلة، أصلحها" | "يُبلّغ المستخدمون بأن POST /api/login يُعيد 500 بعد انتهاء صلاحية الجلسة. اكتب أولًا اختبارًا فاشلًا يُعيد إنتاج المشكلة، ثم حدد مكان الخطأ في منطق تحديث الرمز المميز داخل src/auth/، ثم أصلحه، وأخيرًا شغّل الاختبارات للتأكد من نجاحها" |
| كتابة اختبارات | "أضف اختبارات لـ parser.py" | "اكتب اختبارات لـ parse_date في parser.py، تُغطي الحالتين الحدّيتين: سلسلة نصية فارغة، وتنسيق غير صالح. لا تستخدم محاكاة (mock)، وشغّل pytest للتأكد من النجاح" |
| إضافة ميزة | "أضف ميزة تصدير" | "اطّلع أولًا على export_csv الموجودة في report.py وأضف export_json بنفس النمط، دون استيراد مكتبات جديدة غير تلك المُثبَّتة" |
| قراءة الكود | "لماذا كُتب هذا الوحدة هكذا" | "افحص سجل git لوحدة transform ولخّص كيف تطورت واجهتها البرمجية خطوة بخطوة حتى شكلها الحالي" |
لاحظ الفرق؟ كل سؤال جيد يفعل شيئًا واحدًا: يُزوّد Codex مسبقًا بما كان سيضطر إلى تخمينه. لا تخمين، لا انحراف.
💡 خلاصة بجملة واحدة: السؤال السيئ يترك "فجوات المعلومات" لـ Codex ليملأها بالتخمين، والسؤال الجيد هو ما يقول له مسبقًا ما كان سيخمّنه.
02 الأربعة الأساسية لكتابة المتطلبات: الهدف / النطاق / القيود / التحقق
في القسم السابق قلنا "أعطه ما كان سيخمّنه"، لكن بالضبط ما الذي يجب إعطاؤه؟ لا تعتمد على الحدس، احفظ إطارًا واحدًا — الهدف، النطاق، القيود، التحقق، الأربعة الأساسية. هذه قائمة تحقق استخلصتها من عشرات مرات إعادة العمل: قبل كل طلب راجعها ذهنيًا، ما يغيب منها يتولى Codex اتخاذ القرار عنك فيه.
مثال توضيحي: "وثيقة التسليم" لمقاول التجديد. المقاول الجيد يُثبّت معك أربعة أشياء قبل البدء — ما الذي تريد تحقيقه (الهدف)، أي الغرف تُعدَّل وأيها لا تُمَسّ (النطاق)، أي القيود كالجدران الحاملة التي لا يمكن هدمها (القيود)، وكيف يتم الاستلام (التحقق). إذا اكتملت الأربعة فهو يعمل وفق الخطة ويُنهي العمل بنفسه؛ وإذا غاب أي عنصر، اجتهد بالتخمين وغالبًا لا يُوافق هواك. تقديم المتطلبات لـ Codex هو تسليمه هذه الوثيقة.
ما الذي يعنيه كل عنصر وماذا يحدث إن غاب:
| العنصر | السؤال الذي يُجيب عنه | كيف تعطيه | ما يحدث إن غاب |
|---|---|---|---|
| الهدف (Goal) | ماذا تريد إنجازه | "اجعل القائمة الفارغة تُعيد 0" "حوّل التصدير إلى JSON" | يخمّن ما تريد، والاتجاه محض حظ |
| النطاق (Scope) | ماذا يُعدَّل وماذا لا | اذكر الملف/الدالة بالاسم: "عدّل average في stats.py فقط" | يبحث في المشروع كله ويُعدّل أشياء لا تريدها |
| القيود (Constraint) | ما الذي لا يمكن المساس به | "لا تستورد مكتبات جديدة" "حافظ على التوافق مع الإصدارات السابقة" "لا تلمس migrations/" | يتبع تفضيلاته، وربما لا يناسبك ذلك |
| التحقق (Verification) | ما معيار النجاح | "اكتب اختبارين وشغّلهما" "رمز خروج البناء صفر" | "يبدو مكتملًا" هو إشارته الوحيدة للتوقف، والأخطاء تظل عليك |
من بين الأربعة، "التحقق" هو ما يُغفله المبتدئون أكثر، وهو الأهم للإضافة — الوثائق الرسمية تُنبّه إليه صراحةً:
Codex ينتج جودة أعلى حين يستطيع التحقق من عمله. أرفق خطوات إعادة إنتاج المشكلة، وطريقة التحقق من الوظيفة، وأوامر الـ lint وفحوصات ما قبل الإيداع التي يجب تشغيلها.
لماذا التحقق بالغ الأهمية هكذا؟ لأنه بدون فحص قابل للتشغيل، "يبدو مكتملًا" هو الإشارة الوحيدة لـ Codex للتوقف. بدون معيار، يتوقف حين "يشعر" بالاكتمال، وتتولى أنت مهمة التحقق وتبحث عن كل ثغرة بنفسك. لكن حين تُعطيه فحصًا يُخرج "نجح / فشل" — مجموعة اختبارات، أمر lint، رمز خروج البناء — تنغلق الحلقة من تلقاء نفسها: ينتهي → يُشغّل الفحص → يرى النتيجة → يواصل التعديل إن لم تنجح، دون أن تحتاج للبقاء مشاهدًا.
03 النطاق والقيود: أعطِ المواد مباشرةً بدلًا من وصفها
من الأربعة الأساسية، النطاق والقيود كثيرًا ما لا تحتاج إلى شرح مطوّل، بل تعطيها مباشرةً — هذا القسم يشرح كيف تُعطيها، لأنه أبسط حيلة عملية وأكثرها فائدة.
الفكرة الجوهرية: ما يمكن "إرفاقه"، لا تصفه بكلمات. Codex يقرأ المواد الأصلية دائمًا بدقة أكبر مما يقرأ وصفك الثانوي لها.
أولًا: أدرج الملفات ذات الصلة مباشرةً في السياق. تقول الوثائق الرسمية صراحةً في قسم Prompting: أرفق المتطلب بـالسياق الذي يمكن لـ Codex استخدامه، كمراجع الملفات والصور. أبسط طريقة هي ذكر مسار الملف في متطلبك:
استنادًا إلى تعريفات النوع في src/types/user.ts، أضف تعليقات الأنواع لـ UserServiceهذا أفضل بكثير من "يوجد في المشروع ملف لأنواع المستخدم، ابحث عنه". امتداد IDE (IDE extension) يمنحك ميزة مجانية: تنص الوثائق الرسمية على أن امتداد IDE يُدرج تلقائيًا قائمة الملفات المفتوحة والنص المحدد في السياق. بمعنى: في VS Code، ما تُحدّده بالمؤشر، يعرفه Codex بلا حاجة لوصف.
ثانيًا: الصق رسائل الخطأ كاملةً، لا تلخّصها. هذه عادة تستحق أن تصبح انعكاسًا تلقائيًا — عند مواجهة traceback، لا تقل "يُعطي خطأ null pointer"، بل الصق المكدس كاملًا:
يظهر هذا الخطأ أثناء تشغيل الاختبارات، ساعدني في تحديد السبب:
TypeError: Cannot read properties of null (reading 'userId')
at getUserProfile (src/services/user.ts:42:18)
at async ProfileController.getProfile (src/controllers/profile.ts:15:20)لماذا نلصق المكدس كاملًا؟ لأن المكدس يحتوي على اسم الملف، رقم السطر، سلسلة الاستدعاء، فيستطيع Codex الوصول مباشرةً إلى user.ts:42. حين تلخّص، تحذف هذه الإحداثيات الحيوية، ويعود للتخمين من الصفر.
ثالثًا: مشاكل UI/البصريات، أعطِ صورة. Codex يدعم إدخال الصور — الصق الصورة أو اسحبها مباشرةً إلى منطقة المحادثة؛ يمكن تمرير صور في CLI أيضًا (ارجع للوثائق الرسمية للمعاملات الدقيقة). تصميم مُقترح أو لقطة خطأ أو مخطط بنية، إعطاء صورة دائمًا أدق من وصف "اجعل الزر يتحرك يسارًا قليلًا".
| ما تريد إعطاءه | ❌ الوصف بكلمات | ✅ الإرفاق المباشر |
|---|---|---|
| محتوى ملف | "في المشروع ملف يتعامل مع المصادقة" | اذكر src/auth/session.ts في المتطلب |
| الكود الذي تراه الآن | "تلك المنطقة" | حدّده في IDE، الامتداد يُدرجه تلقائيًا |
| رسالة خطأ | "يُعطي خطأ undefined" | الصق الـ traceback كاملًا |
| مشكلة بصرية | "موضع الزر غير صحيح" | الصق لقطة الشاشة / التصميم |
💡 خلاصة بجملة واحدة: النطاق والقيود في أغلب الأحيان لا تحتاج وصفًا مطوّلًا — اذكر الملف، حدّد في IDE، الصق الخطأ كاملًا، أرفق الصورة، ما يمكن "إرفاقه" لا "تصفه"، Codex يقرأ المواد الأصلية دائمًا بدقة أكبر.
04 المهام الكبيرة: كيف تُقسّمها لتجعلها قابلة للإنجاز والمراجعة
الأربعة الأساسية تحلّ مشكلة "كيف تصوغ متطلبًا واحدًا". لكن بعض الأعمال كبيرة بطبيعتها — "نفّذ نظام مصادقة المستخدم الكامل" أو "ارحّل المشروع كله من JavaScript إلى TypeScript" — إذا ألقيتها دفعةً واحدة، سيبتلعها Codex ثم ينحرف في مكان ما لا تراه، وحين تكتشف فقد عدّل الكثير.
الوثائق الرسمية واضحة في هذا:
Codex يُنجز عملًا أفضل حين تُقسّم العمل المعقد إلى خطوات أصغر وأكثر تركيزًا. الخطوات الصغيرة أسهل اختبارًا لـ Codex وأسهل مراجعةً لك. إذا لم تكن متأكدًا كيف تُقسّم، اطلب من Codex مباشرةً أن يقترح خطة (plan).
هذا الكلام يحمل طبقتين، كلتاهما مهمتان. الطبقة الأولى: التقسيم لا يُفيد فقط Codex بل يُفيدك أنت أيضًا — الخطوات الصغيرة أسهل اختبارًا وأسهل مراجعةً لـ diff؛ تغيير يمسّ عشرين سطرًا تنتهي منه بلمحة، أما تغيير يمسّ مئات الأسطر في ثمانية ملفات فلا تستطيع مراجعته فعلًا. الطبقة الثانية: لا تعرف كيف تُقسّم؟ اطلب من Codex أن يُقترح الخطة أولًا — وهذا يتصل بما قلناه في 06: "للعمل الكبير، اطلب الخطة أولًا، لا تبدأ بالتنفيذ مباشرةً".
إليك تقسيم عملي لـ "نظام المصادقة" تستشعر منه الحجم المناسب لكل خطوة:
المهمة الكبيرة: تنفيذ نظام مصادقة مستخدم كامل
تُقسَّم إلى خطوات، كل خطوة تُسلَّم بشكل مستقل:
الخطوة 1: صمّم بنية البيانات (جدول المستخدمين + جدول الرموز)، قدّم خطة للمراجعة أولًا
الخطوة 2: نفّذ التسجيل (تشفير كلمة المرور بـ bcrypt)، مع اختبارات مكتملة
الخطوة 3: نفّذ تسجيل الدخول (إصدار JWT)، مع اختبارات مكتملة
الخطوة 4: نفّذ middleware التحقق من الرمز، مع اختبارات مكتملة
الخطوة 5: نفّذ تسجيل الخروج، مع اختبارات مكتملةلاحظ تفصيلتين في هذا التقسيم: أولًا: كل خطوة تحمل "تحققًا" ذاتيًا (اختبارات مكتملة) — وهذا تطبيق لـ"التحقق" من الأربعة الأساسية على كل خطوة؛ ثانيًا: الخطوة الأولى تطلب الخطة قبل التنفيذ — البنية هي الأساس الذي يتأثر منه كل شيء، إذا أُخطئت فيه أضعت كل ما بعدها، لذا دعه يرسم المخطط أولًا وراجعه قبل أن يبدأ.
05 تثبيت معيار القبول: وضع /goal
قال القسم 02 إن "التحقق" أهم ما يُضاف، لكن التحقق في المتطلب العادي له قيد: يُغطي هذه الجولة فقط — Codex يُشغّل الفحص مرةً وربما يُعيد التحكم إليك. إذا أردت أن "لا يتوقف حتى تتحقق المعايير، يُعدّل جولةً بعد جولة تلقائيًا"، لدى Codex وضع مخصص — وضع الهدف (Goal mode).
الفرق بين المتطلب العادي والوضع الهدف: في المتطلب العادي تكتب معيار القبول كـ "شغّله ولاحظ"؛ /goal يُثبّت المعيار كـهدف للمهمة بأكملها. تقول الوثائق الرسمية بوضوح:
عند تعيين هدف، يعمل نص الهدف كمحفّز البداية ومعيار الاكتمال في آنٍ واحد. يستخدمه Codex لتحديد الخطوة التالية وما إذا كانت المهمة قد اكتملت.
بمعنى: الجملة التي تكتبها هي "ماذا تفعل" و"متى تعتبر اكتملت" في آنٍ — يُقارن بها Codex بعد كل جولة، ويواصل إن لم يتحقق، ويتوقف إن تحقق. هذا يناسب الأعمال الطويلة التي تحتاج تعريفًا واضحًا للاكتمال.
كيف تستخدمه؟ اكتب /goal ثم هدفك. المفتاح أن يُكتب الهدف بحيث يستطيع Codex بنفسه الحكم على إنجازه — تطلب الوثائق الرسمية أن يتضمن نواتج محددة، أو مقاييس قابلة للقياس، أو معايير قابلة للاختبار. مثالان رسميان:
/goal ارحّل هذا المستودع من JavaScript إلى TypeScript، بحيث يُجمَّع في وضع strict دون أي نوع any صريح/goal اخفض وقت التفاعل (TTI) للصفحة الرئيسية إلى ما دون ثانية واحدة"يُجمَّع في وضع strict بلا any"، "TTI أقل من ثانية" — هذه معايير يمكن إنتاج "نعم / لا" واضح لها. أما "جودة الكود عالية" أو "تجربة أفضل"، فلا يمكن الحكم عليها موضوعيًا، ولن يستطيع وضع الهدف المساعدة في إنهائها.
بعض التفاصيل العملية عند استخدام /goal:
/goalلا تظهر؟ تحتاج إلى تفعيل الميزة أولًا. اكتب في~/.codex/config.tomlتحت قسم[features]السطرgoals = true، أو شغّلcodex features enable goals.
# ~/.codex/config.toml
[features]
goals = true- لا تعرف كيف تُحدد الهدف من البداية؟ تقترح الوثائق الرسمية: إذا لم يكن الهدف واضحًا في البداية، استخدم
/planليساعدك Codex على إيضاحه، ثم حوّله إلى هدف؛ بل يمكنك طلب أن يُجري "مقابلة" معك لصياغة هدف بمعيار نجاح واضح. - الهدف ليس مُقيِّدًا بعد تفعيله. يمكنك إضافة قيود في منتصف الطريق؛ وإذا أردت معرفة التقدم دون مقاطعة الخط الرئيسي، استخدم المحادثة الجانبية (side chat).
- تخشى انقطاع الاتصال في الأعمال الطويلة؟ تُذكّر الوثائق الرسمية بـإيقاف مؤقت قبل انقطاع الشبكة، ثم الاستئناف أو التعديل لاحقًا.
💡 خلاصة بجملة واحدة: لمن يريد "عدم التوقف حتى الاكتمال، والتعديل جولةً بعد جولة"، استخدم
/goal— اكتب الهدف كمعيار "نعم / لا" قابل للقياس؛ إذا لم تعرف كيف تُعرّفه، استخدم/planأولًا، وتذكر تفعيلfeatures.goals.
06 تطبيق عملي: نفس المتطلب بطريقتين
الشرح النظري وحده لا يكفي، إليك تجربة صغيرة ترى فيها الفرق بأم عينيك. تحتاج فقط ملفًا لعبةً من ثلاثة أسطر، بلا اعتماد على أي مشروع موجود.
تنبيه للمنصات: أمر
mkdirيعمل مباشرةً على Mac / Linux؛ على Windows يعملmkdir/cdبالطبع، وأنشئstats.pyبالمفكرة والصق فيه السطرين المطلوبين.
الخطوة الأولى: أنشئ ملفًا لعبةً يحتوي على "ثغرة" (Mac / Linux)
mkdir prompt-demo
cd prompt-demo
echo 'def average(nums):
return sum(nums) / len(nums)' > stats.pyهذه الدالة تحتوي على ثغرة: حين تُمرَّر قائمة فارغة []، يكون len(nums) صفرًا، مما يتسبب في انهيار "القسمة على صفر". سنستخدمها في تجربتنا.
الخطوة الثانية: شغّل Codex في مجلد المشروع
codexالخطوة الثالثة: جرّب السؤال السيئ أولًا، وانظر كيف يتخمن
@stats.py ساعدني في تعديل هذه الدالةالمتوقع: Codex على الأرجح "سيخمّن" ما تريد — ربما يضيف تعليقات توضيحية للأنواع أو docstring، لكنه لا يعرف أن المشكلة هي الانهيار عند القائمة الفارغة، والاتجاه محض حظ. هذه هي تكلفة غياب "الهدف / التحقق".
الخطوة الرابعة: جرّب السؤال الجيد — الأربعة الأساسية كلها
دالة average في @stats.py تحتوي على خطأ: تنهار عند تمرير قائمة فارغة بسبب القسمة على صفر.
السلوك المتوقع أن تُعيد القائمة الفارغة 0 (الهدف).
عدّل هذه الدالة فقط، لا تلمس شيئًا آخر (النطاق)؛ استخدم Python النقي دون استيراد مكتبات (القيود).
أصلح الخطأ وأضف اختبارًا: average([]) يجب أن يُعيد 0، وaverage([2, 4]) يجب أن يُعيد 3،
ثم شغّل الاختبارات وتأكد من نجاحها (التحقق).المتوقع: هذه المرة سلسلة أفعال Codex واضحة تمامًا — يحدد فرع القائمة الفارغة → يضيف شرط الإعادة بـ 0 → يكتب الاختبارين المذكورين → يُشغّل الاختبارات فعلًا → يعرض نتيجة النجاح. لا يحتاج للتخمين في أي شيء، لأنك حددت "الهدف، النطاق، القيود، وطريقة الحكم على النجاح" كلها.
الخطوة الخامسة: اخرج وتأكد من تطبيق التغييرات
cat stats.py(في Windows PowerShell: type stats.py)
المتوقع: يظهر في stats.py شرط للتعامل مع القائمة الفارغة (مثل if not nums: return 0). تطابقه مع ما طلبته في الخطوة الرابعة = أتقنت "قول الكلام الصحيح".
| الخطوة الثالثة ❌ سؤال سيئ | الخطوة الرابعة ✅ سؤال جيد | |
|---|---|---|
| الهدف | غائب، يتصرف هو | القائمة الفارغة تُعيد 0، محدد |
| النطاق | غائب، يبحث في الملف كله | الدالة average بالاسم |
| القيود | غائب، قد يستورد مكتبات | Python نقي، بلا مكتبات |
| التحقق | بلا معيار، يتوقف "حين يشعر" | اختباران + تشغيلهما |
| تجربتك | تتساءل "هذا ليس ما أريد" | يُنفّذ خطتك، مرة واحدة |
💡 خلاصة بجملة واحدة: نفس الملف ونفس الخطأ، السؤال السيئ يجعل Codex يتخذ القرارات عنك، والسؤال الجيد يُحدد "الهدف / النطاق / القيود / التحقق" كلها — جرّب الخطوتين بنفسك، الفرق أوضح من قراءة عشر صفحات نظرية.
07 مخطط يجمع كل شيء: من المتطلب إلى التسليم
مخطط يجمع منطق هذا الجزء في صورة — مسار المتطلب من فمك حتى إنجاز Codex له:
أهم نقطتين في هذا المخطط: الأولى "هل المهمة كبيرة؟" — الكبيرة تُقسَّم وتستخدم /plan، لا تُعطى دفعةً واحدة؛ الثانية "هل يوجد تحقق قابل للتشغيل؟" — إن كان موجودًا تنغلق الحلقة من تلقاء نفسها، وإن غاب يتوقف Codex حين "يشعر"، ويعود عبء التحقق إليك.
08 الخلاصة
هذا الجزء كله يشرح شيئًا واحدًا: كيف تقول جملتك بطريقة يستطيع Codex الإمساك بها بدقة.
ملخص سريع:
| الأسلوب | بجملة واحدة | كيف تطبّقه |
|---|---|---|
| الأربعة الأساسية | الهدف / النطاق / القيود / التحقق، ما يغيب يقرر عنك | "عدّل average (النطاق)، أعد 0 للفارغة (الهدف)، لا مكتبات (القيود)، اختباران وتشغيل (التحقق)" |
| إرفاق لا وصف | أعطِ المواد مباشرةً | اذكر الملف، حدّد في IDE، الصق الخطأ كاملًا، أرفق الصورة |
| قسّم الكبير | لا تُعطِ المهام الكبيرة دفعةً واحدة | إذا لم تعرف كيف تُقسّم استخدم /plan، ثم نفّذ خطوةً خطوة |
| ثبّت المعيار | اجعله لا يتوقف حتى الإنجاز | /goal + هدف قابل للقياس بـ "نعم / لا" (فعّل features.goals أولًا) |
ما تستطيع فعله الآن: ترجمة أي طلب ضبابي "ساعدني في التعديل" إلى متطلب يستطيع Codex الإمساك به فعلًا — الأربعة الأساسية واضحة، المواد ترفقها مباشرةً، المعقد يُقسَّم أو يستخدم /plan، والعمل الجدي يستخدم /goal لتثبيت المعيار. هذه القواعد في الصياغة هي "المهارة الداخلية" لكل ما ستفعله مع Codex — مهما تطورت الميزات، إذا كان الإدخال ضعيفًا، لن يكون الناتج جيدًا.
فكّر في هذا السؤال: بما أن "قول الكلام الصحيح" بالغ الأهمية، هل يعني ذلك أن قواعد مثل "لا تستورد مكتبات جديدة في هذا المشروع" أو "الاختبارات دائمًا في مجلد
tests/" يجب إعادة ذكرها في كل مرة؟ هل هناك طريقة لجعل Codex "يتذكرها" بحيث لا تحتاج لتكرارها؟ (تلميح: 11 · AGENTS.md يحمل الإجابة.)
الجزء التالي 14 · سير العمل اليومي — هذا الجزء علّمك "كيف تقول" كقاعدة عامة، الجزء التالي ينزل بها إلى أكثر الأعمال تكرارًا في اليومي: استكشاف مستودع غريب، إصلاح خطأ، إعادة الهيكلة، كتابة الاختبارات... كل نوع بأسلوب قياسي يمكن نسخه ولصقه. القواعد موجودة، حان وقت الأساليب.