يشرح هذا الفيديو الأمر الذي ستستخدمونه في المختبر لإرسال prompts إلى النماذج من الـ shell. سنشرحه أولًا على Claude Code، وفي النهاية سنعرض الأمر المقابل في Codex.
هكذا كنتم تشغّلون Claude Code حتى الآن. تكتبون claude، فتُفتح جلسة، تطرحون سؤالًا وتحصلون على إجابة، ثم ينتظر سطر الإدخال رسالتكم التالية. تحتفظ الجلسة بالمحادثة وبنتائج الأدوات، وتمرّرها سياقًا للرسالة التالية.
هناك طريقة ثانية لتشغيله. أضيفوا الخيار -p، وضعوا الـ prompt مباشرةً في سطر الأوامر. يعالج Claude Code الطلب، ويطبع الإجابة، ثم يعيدكم إلى الـ shell. لا تدخلون إلى سطر الإدخال التفاعلي. نسمّي هذا وضع one-shot.
بدون خيار continue أو resume، يبدأ كل تشغيل محادثة جديدة. في الجلسة التفاعلية، يمكن لسؤال المتابعة أن يشير إلى سؤال سابق. أما في تشغيل one-shot جديد، فالسؤال السابق غير موجود. قد يجيب النموذج عن سؤال المتابعة رغم ذلك، لكن عليه أن يجيب دون أن يعرف ما الذي دار في التفاعل السابق.
عبارة one-shot تصف ما يحدث من جهتكم أنتم. أما الـ harness فقد يشغّل حلقة الوكيل عدة مرات، ويعالج استدعاءات الأدوات قبل أن يطبع الإجابة النهائية. فالـ prompt الواحد لا يعني طلبًا واحدًا للنموذج.
لا يلزم أن يكون الـ prompt وسيطًا بين علامتي تنصيص في سطر الأوامر. يمكن أن يصل بدلًا من ذلك عبر الإدخال القياسي. هنا يكتب echo الـ prompt، والـ pipe يمرّره إلى claude -p. فيصل الـ prompt نفسه كما لو كُتب بين علامتي تنصيص.
الإدخال القياسي مفيد عندما يكون الـ prompt محفوظًا في ملف أو ناتجًا عن برنامج آخر. يمكنكم تمرير المحتوى مباشرةً، بدل وضع الـ prompt كله داخل أمر shell. عند استخدام متغيّر، أبقوه بين علامتي تنصيص كما في المثال.
هنا الـ prompt محفوظ في متغيّر shell، وحلقة تكرار ترسله خمس مرات، وتبدأ محادثة جديدة في كل مرة. سؤال الـ mutex مجرد مثال على صيغة الأمر. ولأن النموذج يسحب عيّنات عند التوليد، قد تنتج الـ prompts المتطابقة إجابات مختلفة. والتشغيلات المتكرّرة تخبرنا كم مرة تكون الإجابة صحيحة في الظروف نفسها.
يعرض هذا الشريط نافذة السياق، أي كل ما يتلقّاه النموذج في طلب واحد. يظلّ وضع one-shot يضيف أجزاء الـ harness افتراضيًا. وهي تعليماته، وتعريفات أدواته، وأي ملفات تعليمات سارية. الـ prompt الذي تكتبونه ليس إلا جزءًا صغيرًا مما يتلقّاه النموذج. لكي نقارن بين النماذج والـ prompts في المختبر، علينا أن نتحكّم فيما يضيفه الـ harness. ثلاثة إعدادات تزيل هذه الأجزاء، واحدًا تلو الآخر.
الإعداد الأول هو --system-prompt. وهو يستبدل تعليمات الـ harness بسلسلة نصية تحدّدونها أنتم. التعليمات المعتادة تشرح للنموذج كيف يؤدّي دور وكيل برمجة. هنا نستبدلها بتعليمة قصيرة واحدة: «أنت مساعد مفيد».
الإعداد الثاني هو --tools. وهو يحدّد الأدوات المدمجة المسموح للنموذج باستخدامها. مرّروا له سلسلة نصية فارغة، فلا تبقى أي أداة مدمجة متاحة. وعطّلوا أيضًا أي أدوات MCP خارجية. عند تعطيل الأدوات، لا يستطيع النموذج استخدام الـ harness لقراءة ملف أو تشغيل كود. عليه أن يولّد إجابته من السياق المُعطى ومما تعلّمه أثناء التدريب.
الإعداد الثالث هو المجلد الذي تشغّلون فيه الأمر. إذا استخدمتم مجلدًا فارغًا، فلن يُحمَّل أي ملف تعليمات للمشروع. لكن قد تظلّ تعليمات المجلدات الأعلى والمستخدم والذاكرة المحفوظة محمّلة. لذا تحقّقوا مما يحمّله إعدادكم، وأبقوه ثابتًا في كل ظروف التجربة إن أجريتم تجارب بهذه الطريقة.
خيار النموذج يحدّد أي نموذج يتلقّى الـ prompt. يبدأ المختبر بـ Haiku، الخيار السريع والأقل تكلفة بين النماذج المعروضة هنا.
الخياران الآخران المعروضان هما Sonnet و Opus. وتوازن النماذج الثلاثة بشكل مختلف بين القدرة والسرعة والتكلفة. صُمّم Haiku لعمل أسرع وأقل تكلفة، بينما صُمّم Opus للمهام الأصعب.
الخيار --model بالقيمة haiku يوجّه هذا الطلب إلى Haiku. للمقارنة مع Sonnet أو Opus، غيّروا هذه القيمة وأرسلوا الـ prompts نفسها. سجّلوا إصدار النموذج الذي عالج كل مجموعة من التشغيلات.
يسأل المختبر: إذا طلبنا من النموذج أن يكتب أفكاره ويعمل خطوة بخطوة، هل تتغيّر نسبة إجاباته الصحيحة؟ لتفسير هذه المقارنة، علينا أن نميّز بين خطوات مكتوبة في الردّ المرئي وبين tokens التفكير المنفصلة. تستطيع نماذج التفكير أن تولّد tokens تفكير قبل إجابتها النهائية. وهذه الـ tokens منفصلة عن الإجابة التي تقرؤونها عادةً.
تُولَّد tokens التفكير كالإجابة تمامًا، بالتنبّؤ بالـ token التالي، وكل token يعتمد على السياق الذي يسبقه. وهذا يتيح للنموذج أن يجرّب طريقة ما ويتحقّق من نتائج وسيطة قبل أن يجيب. قد يساعد ذلك في المسائل الصعبة، لكن توليد هذه الـ tokens الإضافية يستهلك أيضًا وقتًا وموارد حوسبة.
هناك وسيلتا تحكّم مرتبطتان. مستوى الجهد يحدّد مقدار التفكير الذي نطلبه. في الجلسة تكتبون /effort، وفي سطر الأوامر تضيفون الخيار --effort. وهو ليس عددًا دقيقًا من الـ tokens. في النماذج ذات ميزانية التفكير الثابتة، يحدّد MAX_THINKING_TOKENS هذه الميزانية بعدد محدّد. يستخدم المختبر القيمة 0 لتعطيل التفكير المنفصل.
عند تعطيل التفكير المنفصل، يبدأ التوليد بالردّ المرئي مباشرةً، لا بقسم تفكير منفصل. يبقى لدى النموذج ما تعلّمه في التدريب، ويبقى يولّد token واحدًا في كل مرة. ويمكنه أيضًا أن يكتب خطوات وسيطة في الردّ المرئي إذا طلبتم منه ذلك.
في سلسلة الأوامر هذه، الإسناد قبل أمر ما يضبط متغيّر بيئة لذلك الأمر. ضعوه على جانب الـ pipe الذي يحتاج إليه. في هذا السطر يأتي بعد الـ pipe ومباشرةً قبل كلمة claude، فيكون claude هو من يتلقّاه.
انقلوا الإسناد إلى ما قبل echo، فيسري على echo. لا تتلقّى عملية claude هذا الإسناد، فتستخدم إعداد التفكير الذي كان سيسري عليها على أي حال. إذا بدت مقارنة ما مفاجئة، تحقّقوا من أن الإعداد وصل إلى العملية التي قصدتم اختبارها.
هذا هو أمر البداية في ورقة تعليمات المختبر 2، مع الإعدادات التي شرحناها للتو. اضبطوا المتغيّر PROMPT على أي prompt تحتاجونه، ثم شغّلوا الأمر من المجلد الفارغ الذي أعددتموه.
غيّروا شيئًا واحدًا في كل مرة. مثلًا، لاختبار ما إذا كان طلب خطوات الحل يساعد، ثبّتوا النموذج والمسألة، وغيّروا تلك التعليمة وحدها في الـ prompt. عطّلوا الأدوات والتفكير المنفصل طوال المختبر، وأبقوا الـ system prompt والذاكرة المحمّلة كما هي.
كرّروا كل مُدخَل عدة مرات في كل إعداد، مع محادثة جديدة في كل مرة، وسجّلوا كم مرة تكون الإجابة صحيحة. استخدموا الوكيل لبناء برنامج اختبار يشغّل هذا الأمر. قرّروا كيف ستتحقّقون من الإجابات قبل تشغيله، ثم افحصوا بعض الردود لتتأكّدوا أن البرنامج يقيّمها بشكل صحيح.
إذا ثبّتم Codex بدلًا من Claude Code، فالأمر المقابل موجود في ورقة تعليمات المختبر. ها هو، وكل الخيارات مضبوطة مسبقًا. codex exec هو وضع one-shot فيه، وبقية السطر تختار النموذج، وتوقف التفكير المنفصل، وتستبدل التعليمات الافتراضية، وتعطّل الأدوات. لا داعي لأن تحفظوا هذه الخيارات عن ظهر قلب. الأمر جاهز للنسخ في ورقة تعليمات المختبر، وهي تشرح ما يفعله كل خيار.
في Codex، النماذج التي يمكنكم اختيارها هي Sol و Terra و Luna، وكذلك Astra. هناك فرق واحد يجب أن تنتبهوا إليه. لا يوجد في Astra إعداد يوقف التفكير. أدنى مستوى جهد فيه هو low، لذلك يفكّر دائمًا قليلًا. إذا اختبرتموه، فاذكروا ذلك في تقريركم. أصبحت لديكم الآن طريقة لتحويل أسئلتكم عن النموذج إلى تجارب. يمكن لبرنامج الاختبار أن يجمع الإجابات، ومن النتائج تعرفون أي التغييرات تساعد في المسألة التي اخترتموها.