ملاحظة المحرر: هذه المقالة مقدمة من دومينيك كونديل، عضو في فريق علاقات المطورين في OpenAI، وتلخص تجربته في استخدام ميزة Codex "goal mode / /goal". فهي لا تناقش مجرد تقنية موجهة، بل تناقش تغييرًا في دور أداة البرمجة بالذكاء الاصطناعي: لم يعد Codex مجرد مساعد كود يستجيب لتعليمات فردية، بل بدأ يصبح وكيلًا تنفيذيًا قادرًا على المضي قدمًا نحو هدف محدد.

في وضع /goal، ما يهم حقًا ليس كتابة المتطلبات بشكل أطول وأكثر تفصيلًا، بل تحديد معايير خروج واضحة وقابلة للتحقق لـ Codex. على سبيل المثال: "خفض وقت النشر بنسبة 30٪" أو "تحقيق تغطية اختبار بنسبة 100٪ parity" أو "خفض LCP إلى أقل من 2.5 ثانية". هذه المؤشرات تمكن Codex من تحديد ما إذا كان المهمة قد اكتملت، وتمنعه من التجربة والخطأ اللانهائية في أهداف غامضة. في الوقت نفسه، يحتاج المستخدم إلى توفير الاتجاه الكافي والأدوات والبيئة الحقيقية التي تمكن Codex من قياس التقدم والتحقق من النتائج، وليس فقط إكمال حل يبدو قابلاً للتطبيق في بيئة محلية أو افتراضية.

تشير المقالة بشكل خاص إلى أن المهام البصرية هي الأكثر عرضة لجعل Codex يغرق في التفاصيل. بدلاً من طلب "استنساخ بدقة 100% على مستوى البكسل"، يُفضل تقسيم الأهداف البصرية إلى قائمة وظيفية، ومواصفات نظام تصميم، ومقاييس قابلة للتقييم. كما أنه بالنسبة للمهام الطويلة التي تستغرق ساعات أو حتى أيام، يجب تتبع التقدم باستمرار من خلال التزامات commit، وطلبات سحب draft PR، ووثائق التقدم، وتحديثات Slack، أو المحادثات الجانبية، لتجنب الحصول في النهاية على مجموعة من التغييرات غير القابلة للتتبع.

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

Below is the original text:

لقد أطلقنا وضع الهدف (goal mode، أو /goal) لمساعدتك على جعل Codex يتحرك باستمرار نحو نتيجة محددة. بمجرد تحديدك لهدف، سيستمر Codex في العمل حتى تحقيق الهدف — سواء استغرق ذلك ساعات أو أيام. لقد قام بعض المستخدمين بتشغيل Codex لعمل نفس الهدف بشكل متواصل لأكثر من 120 ساعة.

النمط الهدف قوي جدًا. لاستغلاله بأقصى قدر، هناك 7 أشياء يجب الانتباه إليها عند استخدام /goal.

تحديد معايير واضحة وقابلة للتحقق

عند تفعيل وضع الهدف، فإن الكلمات التوجيهية التي تدخلها تُستخدم كمُحفّز أولي، ولكن الأهم أنها تصبح معيار الخروج لهذا الهدف. سيتحقق Codex بعد كل جولة عمل: هل تم إكمال هذا الهدف؟

لذلك، لا ينبغي أن يكون توجيه هدفك طويلًا جدًا، بل يجب أن يركز على معيار واضح: متى يُعتبر أن هذا الهدف قد تم تحقيقه؟

في معظم الحالات، يُفضَّل أن يتضمن الهدف الجيد مؤشرًا رقميًا واضحًا لتمكين النموذج من تحديد ما إذا كان قد أُنجز أم لا. على سبيل المثال:

تقليل وقت البناء والنشر بنسبة 30%.

قم بنقل هذه الميزة من TypeScript إلى Rust وتحقق من توافق اختبارات بنسبة 100%.

تحسين هيكل التطبيق لجعل مؤشر الرسم الأكبر للمحتوى (Largest Contentful Paint)، الذي يقيس سرعة تحميل المحتوى الرئيسي للصفحة، أقل من 2.5 ثانية في بيئة الإنتاج.

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

إذا كنت لا تزال غير متأكد من كيفية تحديد الهدف، أو ترغب في بدء مناقشة هذا المشروع مع Codex من خلال جلسة عصف ذهني، فلا داعي لبدء المحادثة باستخدام نمط الهدف.

يمكن لـ Codex تحديد أهدافه بنفسه. يمكنك بدء محادثة طبيعية أولاً، ثم عندما تكون جاهزاً لجعل Codex يبدأ التنفيذ، تطلب منه تحديد الهدف بناءً على ما تم مناقشته سابقاً.

يمكنك أيضًا تحرير الهدف في أي وقت: انقر على زر التحرير في تطبيق Codex، أو استخدم /goal مرة أخرى في CLI.

قدم الإرشادات قدر الإمكان

الإشارات مثل "تقليل وقت البناء والنشر بنسبة 30%" تبدو رائعة وقد تساعد Codex على إيجاد حلول إبداعية. لكن إذا كنت تعرف بالفعل تقريبًا أين قد تكمن المشكلة، فقد تؤدي هذه الإشارات إلى إرباك Codex.

لذلك، من الأفضل في حالات ممكنة إخبار Codex من أين يجب أن يبدأ التحقيق، وأي أدوات يمكن استخدامها لتحقيق الهدف، أو تقديم تلميحات أخرى لتجنب انحرافه في الاتجاه الخاطئ.

على سبيل المثال، قام زميلي @reach_vb بذلك في تجربة واحدة: أخبر Codex أنه يمكن استخدام متصفح Chrome للوصول إلى Google Colab، وحدد بعض القيود المقبولة، مثل السماح لـ Codex بإنشاء مجموعة البيانات بنفسه أثناء تدريب النموذج.

وبالمثل، إذا كنت ترغب في تقليل وقت البناء، وعرفت بالفعل أن معظم الوقت يُهدر في أي مرحلة، فمن الأفضل أن توجه Codex أولًا إلى تلك المنطقة في نص التحفيز.

طريقة أخرى هي أن تسمح لـ Codex أولاً بالقيام ببعض الأبحاث الأولية في وضع التخطيط (plan mode) وإنشاء ملف خطة يسجل الحلول المحتملة، ثم تستخدم هدفك للإشارة إلى هذا الملف.

اجعل التقدم قابلاً للقياس

إذا كان هدفك طموحًا أو كان هناك العديد من الطرق التي يمكن لـ Codex أن تتبعها للوصول تدريجيًا إلى الهدف، فمن المهم أن تزود Codex بأدوات لقياس التقدم.

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

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

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

حسب المهمة، قد تحتاج أيضًا إلى التفكير في ما إذا كانت هناك معايير إضافية تحتاج إلى القياس أو التحقق منها. وإلا، فقد يظن Codex أن المهمة اكتملت، بينما ترى أنت أنها غير مكتملة.

على سبيل المثال، قد يقوم Codex بقص صورة المرجع التصميمية ودمجها مباشرة في الصفحة لتحقيق "إعادة إنتاج بدقة بكسلية" لواجهة المستخدم؛ أو قد يقلل من نطاق التغطية الاختبارية لتحقيق نسبة نجاح اختبارات تصل إلى 100٪. هذه ليست الطرق الحقيقية التي ترغب في تحقيق الإنجاز بها.

أنشئ بيئة حقيقية

إذا كنت ترغب في أن يحقق Codex تقدمًا فعالًا نحو هدفه، فإنه يحتاج إلى التشغيل في بيئة كافية الواقعية.

في التطبيق العملي، هذا يعني أنه إذا كنت ترغب في تحسين وقت النشر أو مشاكل التأخير، يجب أن يكون لدى Codex وصول إلى بيئات النشر والاختبار، وأن تكون هذه البيئات محاكية قدر الإمكان لبيئة الإنتاج. أي استخدام نفس مجموعة التقنيات، ونفس مفاتيح التكوين، وقواعد بيانات مشابهة.

على سبيل المثال، كنا نقوم بتحسين وقت البناء والنشر لـ developers.openai.com. في ذلك الوقت، كنا نستخدم معاينات النشر بالفعل، لذا كان يمكن لـ Codex الاستفادة من بيئات المعاينة هذه للنشر ومراجعة السجلات ذات الصلة. لكن المشكلة كانت أن معاينات النشر الخاصة بنا كانت تعطّل بعض مسارات البناء مقارنة ببيئة الإنتاج الكاملة.

لذلك، اضطر Codex في النهاية إلى إجراء نشر يدوي، ونشر الكود في بيئة أقرب إلى التكوين الإنتاجي لتحديد المشكلة بدقة.

بالمثل، يمكنك أيضًا السماح لـ Codex باستخدام استخدام الحاسوب (قدرة النموذج على التحكم في واجهات التطبيقات الحقيقية) لاختبار التطبيقات العملية. ولتحسين بعض مشكلات الأداء على iOS، استخدم @dimillian أجهزة فعلية للحصول على بيئة اختبار الأكثر دقة.

حدد أهدافك البصرية بحذر

إعطاء كودكس هدفًا بصريًا، مثل "أعد إنشاء هذا الواجهة بدقة 100% من هذه الصورة"، يبدو أمرًا جذابًا. لكن حسب الإعدادات المحددة، قد يؤدي ذلك إلى مشاكل.

إذا لم تقدم إرشادات وقيود مناسبة، قد يغرق Codex في تفاصيل معينة وينسى الهدف العام. على سبيل المثال، إذا احتوت الصورة المرجعية على عناصر رسومية، وترغب في أن ينشئ Codex هذه العناصر—سواء كانت أيقونات SVG أو صورًا—فربما يُضيع جهدًا كبيرًا في "كيفية إعادة إنتاج هذه المواد بدقة" بدلاً من تفكيك المشكلة بشكل صحيح.

بالإضافة إلى ذلك، يحتاج Codex إلى أدوات لإجراء مقارنات بصرية بشكل صحيح. وهذا يعني مزيدًا من مدخلات الصور واستهلاكًا أعلى للـ token بشكل عام، لكنه لا يوفر بالضرورة طريقة بسيطة لـ Codex لتحديد فرص التحسين الحقيقية ذات القيمة.

لذلك، عادةً ما تكون الصور أكثر ملاءمة كمقياس للسياق المستهدف، وليس كمقياس وحيد للإكمال. يجب أن تبحث عن طرق أخرى لتمكين Codex من تقييم ما إذا كان الهدف قد تم تحقيقه، مثل قائمة الوظائف، أو المواصفات التنفيذية، أو التوافق مع نظام التصميم.

Track progress

إذا عمل Codex في الخلفية لساعات أو حتى أيام، وحتى على جهاز آخر، فمن السهل أن تنسى إلى أين وصل بالضبط وما هي المهام التي أكملها.

وفقًا للأهداف المختلفة، وجدت أن الطرق التالية مفيدة جدًا:

· اجعل Codex يُقدّم الكود في النقاط الرئيسية ويرفعه إلى PR تجريبي. هذا مفيد جدًا خاصةً عندما تعمل على موقع ويب ولديك نشر تجريبي.

· اطلب من Codex تحديث مخرج موجه للإدارة. يمكن أن يكون ملف HTML يمكنك فتحه دائمًا في متصفح التطبيق؛ أو صفحة مُنشرة عبر Sites لعرضها من قبل الفريق؛ أو رسم بياني مُرسَم للتقدم؛ أو حتى ملف Markdown عادي.

أرشد Codex لنشر تحديثات تقدمه تلقائيًا. يمكنك أيضًا تضمين هذا كهدف: جعل Codex يرسل التحديثات إلى قناة Slack أو أي مكان آخر ترغب في تسجيل التقدم فيه عند تحقيق تقدم مهم.

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

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

تنظيف والتأكيد النهائي للنتائج

رائع، تم تحقيق الهدف أخيرًا! هل يمكن الآن توجيه النتائج مباشرة إلى الفريق ثم إنهاء العمل؟

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

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

ضع هدفًا للمهمة التالية أيضًا

الوظيفة المستهدفة لـ Codex هي أداة قوية للغاية يمكنها مساعدتك في حل بعض التحديات الهندسية الأكثر أهمية. لكنها فقط ستصل إلى هدفها بكفاءة أكبر عندما تقدم لها البيئة والتعليمات الصحيحة.

ماذا فعلت باستخدام /goal؟