العنوان الأصلي: دليل إلى /goal
الكاتب الأصلي: @dkundel، عضو فريق علاقات المطورين في OpenAI
الترجمة: بيجي

ملاحظة المحرر: تستعرض هذه المقالة تجربة استخدام وظيفة Codex «وضع الهدف / /goal» من قبل عضو علاقات المطورين في OpenAI، دومينيك كونديل. فهي لا تتحدث عن تقنية prompt عادية، بل عن تحول في دور أدوات البرمجة بالذكاء الاصطناعي: إذ لم تعد Codex مجرد مساعد برمجي يرد على أوامر ذات جولة واحدة، بل بدأت تتحول إلى وكيل تنفيذي يمكنه الاستمرار في التقدم حول هدف واضح ومحدد.

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

تذكر المقالة بشكل خاص أن المهام البصرية هي الأكثر عرضة لأن تقع Codex في فخ التفاصيل الدقيقة. بدلاً من طلب «إعادة بناء بكسل-ببكسل بنسبة 100%»، من الأفضل تقسيم الهدف البصري إلى قائمة وظائف، ومعايير تصميم النظام، ومؤشرات تقييم. وللمهام طويلة الأمد التي تستغرق ساعات أو أيام، من الضروري أيضًا تتبع التقدم باستمرار عبر الالتزامات، وطلبات السحب Draft PR، ووثائق التقدم، وتحديثات Slack، أو الدردشات الجانبية، لتجنب الحصول في النهاية على مجموعة من التعديلات غير قابلة للتتبع.

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

وفيما يلي النص الأصلي:

لقد أطلقنا وضع الهدف (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 أن يضع خطة مبدئية (plan mode) ويقوم بإنشاء ملف خطة لتوثيق الحلول المحتملة. ثم، يمكنك أن تربط هدفك بهذه الخطة.

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

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

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

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

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

الصورة: لقطة شاشة من Codex، تُظهر أداة لمقارنة صورتين بصريًا.

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

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

هذه ليست الطرق التي تريدها بالضرورة.

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

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

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

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

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

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

حذر عند تحديد الأهداف البصرية

إعطاء Codex هدفًا بصريًا، مثل «إعادة بناء هذا الواجهة بنسبة 100% بكسل-ببكسل»، قد يكون مغريًا جدًا. لكن، اعتمادًا على الإعداد، قد يسبب ذلك مشاكل.

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

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

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

متابعة التقدم

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

اعتمد على بعض الطرق المفيدة، مثل:

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

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

· أن تضع تعليمات لـ Codex لنشر تحديثات التقدم بشكل تلقائي، عبر Slack أو أدوات أخرى.

· استخدام دردشة جانبية /side لطرح أسئلة سريعة عن الحالة، حيث تنشئ محادثة فرعية من سياقها الحالي، وتكون قصيرة المدة.

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

نظف وحقق النتائج النهائية

رائع، لقد أنجزت الهدف أخيرًا! هل يمكن الآن أن تسلم النتائج للفريق وتختتم العمل؟

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

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

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

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

ماذا جربت من /goal حتى الآن؟

[رابط النص الأصلي]

انقر لمعرفة المزيد عن فرص العمل في BlockBeats

انضم إلى المجتمع الرسمي ل BlockBeats:

قناة Telegram: https://t.me/theblockbeats

مجموعة Telegram: https://t.me/BlockBeats_App

حساب Twitter الرسمي: https://twitter.com/BlockBeatsAsia