كيف تكتب مهمة لمساعد ذكاء اصطناعي بحيث تستطيع مراجعة نتيجتها؟
اطلب تغييرًا واحدًا، وقل أين يوضع وما الذي يجب ألا يتغير، وأعطِ فحصًا ينجح أو يفشل، واطلب تقريرًا بما جرى.
اطلب تغييرًا واحدًا، صغيرًا بما يكفي لتجربه في دقائق. قل أين يوضع، وما الذي يجب أن يبقى كما هو، وكيف يُفحص أنه يعمل، وماذا تريد أن تسمع في الرد. المهمة المكتوبة بهذه الطريقة تعود إليك بشيء تستطيع الحكم عليه: قائمة قصيرة بالملفات التي تغيرت، وفحص نجح أو فشل، ولعبة تستطيع أن تلعبها لتتأكد. أما المهمة الغامضة فتعود تغييرًا كبيرًا «يبدو منتهيًا»، ويبقى الفحص كله عليك.
ما الذي يجعل المهمة قابلة للمراجعة؟
خمسة أجزاء. معظم المهام تحتاج إليها كلها، وكل جزء يكفيه سطر أو سطران.
| الجزء | ماذا تكتب | لماذا يساعد في المراجعة |
|---|---|---|
| 1. التغيير | شيء واحد يجب أن تفعله اللعبة بشكل مختلف | ترى هل حدث أم لا |
| 2. المكان | الملف أو الشاشة أو الدالة التي ينتمي إليها | يبقى التغيير في مكان واحد |
| 3. ما يجب ألا يتغير | التحكم، وحفظ التقدم، والشاشات الأخرى، والمكتبات | أي شيء خارج القائمة يلفت النظر |
| 4. الفحص | اختبار، أو أمر، أو خطوات تلعبها | يعطي نجاحًا أو فشلًا، لا انطباعًا |
| 5. التقرير | الملفات التي تغيرت، والفحوص التي شُغّلت، وما لم يُختبر | تقرأ أدلة بدل أن تعيد العمل |
لا جديد في شيء من هذا. دليل GitHub لكتابة الطلبات إلى Copilot يطلب طلبًا بسيطًا ومحددًا، مقسمًا إلى خطوات، مع مثال أو مثالين لما تتوقعه. وأفضل الممارسات في Claude Code تضع أولًا فحصًا يستطيع المساعد تشغيله بنفسه، لأنه بدونه تكون عبارة «يبدو منتهيًا» الإشارة الوحيدة التي لديه. هكذا كانت الصفحتان في 25 أكتوبر 2026. وما يلي يطبق ذلك على لعبة صغيرة.
ما حجم المهمة الواحدة؟
صغيرة بما يكفي لتصف التغيير في جملة واحدة وتجربه في دقائق. «أضف شاشة إيقاف مؤقت» مهمة واحدة. «أضف شاشة إيقاف مؤقت وقائمة إعدادات وصوتًا» ثلاث مهام، وعندما يتعطل شيء لن تعرف أيها السبب.
إذا احتاجت المهمة إلى وصف أطول، فاطلب خطة أولًا واترك الشيفرة لما بعد. صفحة Claude Code تقترح هذا بالضبط: دع المساعد يقرأ الشيفرة ويقترح الملفات التي ستتغير، واقرأ الخطة بنفسك، ثم دعه يكتب بعد ذلك فقط. الخطة التي تمس نصف المشروع علامة على أن المهمة يجب أن تُقسم.
إنها القاعدة نفسها التي تجعل لعبتك الأولى صغيرة: كل ميزة يجب أن تعمل مع كل ميزة أخرى، فالمهمة التي تضيف ثلاثًا منها تضاعف الفحص.
كيف تبدو مهمة غامضة بجانب مهمة قابلة للمراجعة؟
هذا طلب واحد للعبة إطلاق نار صغيرة، مكتوب مرتين.
| غامضة | قابلة للمراجعة |
|---|---|
| «اجعل اللعبة أصعب.» | «في شيفرة الموجات، اجعل كل موجة جديدة أسرع من السابقة بنسبة 10%، حتى ضعف السرعة الأولى. لا تغير سرعة اللاعب ولا عدد الأرواح ولا التحكم.» |
| «أصلح خطأ النقاط.» | «بعد إعادة البدء تبدأ النقاط من القيمة القديمة بدل 0. ابحث عن المكان الذي تعيد فيه إعادة البدء ضبط اللعبة، واجعلها تعيد ضبط النقاط أيضًا، وأضف اختبارًا يعيد البدء مرتين ويتوقع 0.» |
| «أضف تحكمًا للهاتف.» | «على الشاشات اللمسية، اعرض أزرار يسار ويمين وإطلاق ترسل أحداث المفاتيح نفسها التي ترسلها لوحة المفاتيح. اللعب بلوحة المفاتيح يجب ألا يتغير. أخبرني بالشاشات التي ليس فيها تحكم باللمس بعد.» |
العمود الأيسر أطول، لكن كل سطر فيه يمكن فحصه. والسطر الثالث قريب مما فعلناه عندما أضفنا التحكم باللمس إلى KittenGalaxy: الأزرار ترسل أحداث المفاتيح التي كانت لوحة المفاتيح سترسلها، فلم تحتج اللعبة نفسها إلى تغيير.
كيف تخبر المساعد بطريقة فحص عمله؟
أعطه شيئًا يجيب بنعم أو لا.
- اختبار يستطيع المساعد تشغيله، مع الحالات مكتوبة: «إعادة البدء تجعل النقاط 0».
- أمر يمكن قراءة نتيجته: البناء يكتمل، والصفحة تُحمَّل بلا أخطاء في وحدة التحكم.
- خطوات ستلعبها بنفسك، مكتوبة قبل التغيير: «ابدأ، اخسر كل الأرواح، اضغط إعادة البدء، النقاط تظهر 0».
اطلب من المساعد أن يشغّل الفحص ويعرض المخرجات، لا أن يقول إنه نجح. نتيجة اختبار ملصوقة أو سجل وحدة تحكم بلا أخطاء يُقرأ في ثوانٍ؛ أما جملة «كل شيء يعمل» فلا تثبت شيئًا.
بعض الأشياء لا يحكم عليها إلا إنسان: هل القفزة مريحة، وهل المرحلة عادلة. لهذه الأشياء، اكتب ما ستنظر إليه والعب بنفسك. لا تدع تقرير المساعد يحل محل ذلك.
ماذا يجب أن يخبرك المساعد عندما ينتهي؟
اطلب في المهمة نفسها تقريرًا قصيرًا بهذا الترتيب:
- أي الملفات تغيرت، ولماذا، في سطر لكل ملف؛
- أي الفحوص شغّلها وماذا أعادت؛
- ما الذي لم يختبره، ولماذا؛
- أي شيء غيّره دون أن تطلبه.
البند الأخير هو الأهم. التغيير الذي يتجاوز الطلب ليس خطأً دائمًا، لكنه دائمًا شيء لم تكن تنوي مراجعته. قارن قائمة الملفات بالجزء 3 من مهمتك: الملف الذي ما كان يجب أن يتغير هو أول مكان تنظر فيه.
ما الذي يوضع في ملف المشروع بدل كل مهمة؟
كل ما كنت ستكرره لولا ذلك: كيف تُشغّل اللعبة والاختبارات، وما المجلدات التي لا تُمس، وقواعد الشيفرة. معظم المساعدين يقرؤون ملفًا كهذا في بداية الجلسة (يسميه Claude Code باسم CLAUDE.md). اجعله قصيرًا؛ فصفحة Claude Code تحذر من أن القواعد المهمة تضيع في الملف الطويل.
تستحق القاعدة مكانها هناك عندما يؤدي نسيانها إلى تعطيل اللعبة. الملاحظات التي نحتفظ بها للعبة KittenGalaxy تقول إنه كلما أُضيف مفتاح أو شاشة أو حالة من حالات اللعبة، يُضاف التحكم باللمس الخاص بها في التغيير نفسه، وإلا فلن يستطيع من يلعب على الهاتف الوصول إليها. وعندها لا تحتاج المهمة إلا إلى قول ما هو جديد.
ماذا تفعل عندما تكون النتيجة خاطئة؟
ارجع، ثم اطلب مرة أخرى بمهمة أفضل.
احفظ نسخة تعمل قبل كل مهمة، على شكل commit في نظام التحكم بالإصدارات، حتى يمكن التراجع عن التغيير السيئ بخطوة واحدة. عندما يفشل فحص، يمكنك أن تطلب إصلاحًا مرة أو مرتين. وإذا فشل تصحيحان، تقترح صفحة Claude Code بدء جلسة جديدة بطلب أول أفضل بدل التصحيح مرة بعد مرة، لأن المحاولات الفاشلة تبقى في المحادثة. تراجع عن التغيير، وأضف إلى المهمة ما تعلمته، وأرسلها من جديد.
أسئلة شائعة
هل أحتاج إلى أن أكون مبرمجًا لأكتب مهام كهذه؟ لا. الأجزاء 1 و3 و5 تتحدث عما تفعله اللعبة، بكلمات بسيطة. أما الجزء 2، فاسأل المساعد أين يوضع التغيير قبل أن تطلب منه إجراءه.
هل المهمة الطويلة أفضل من القصيرة؟ ليس في ذاتها. المهمة الطويلة التي تطلب تغييرات كثيرة أصعب في المراجعة من قصيرة تطلب تغييرًا واحدًا. الطول يفيد عندما يضيف فحصًا أو حدًا.
هل أطلب اختبارات في لعبة صغيرة؟ للقواعد التي يمكن قولها بدقة (النقاط، والأرواح، والمؤقت، وحفظ التقدم)، نعم. تشغيلها رخيص بعد كل تغيير لاحق. أما الإحساس والمتعة فما زالا يحتاجان إلى اللعب.
ماذا لو طرح عليّ المساعد أسئلة؟ أجب عنها في المهمة قبل أن يبدأ الكتابة. السؤال المبكر أرخص من تغيير خاطئ.
متى تصبح اللعبة جاهزة لعرضها على الناس؟ عندما يستطيع شخص غريب أن يبدأها من رابط وينهيها دون مساعدتك. عندها يمكنك إرسالها إلى HeapPlay، ويستطيع المطورون الموثَّقون تسجيل كل إصدار جديد وما تغيّر فيه.
ai-assistants workflow testing
هل تبني لعبة؟ أرسلها إلى HeapPlay وتعرّف على ما يحصل عليه المطورون.