كيف تراجع تغييرًا أجراه مساعد ذكاء اصطناعي على لعبتك قبل أن تحتفظ به؟

قارن الملفات المتغيّرة بمهمتك، واقرأ الـ diff بدءًا من المحذوف، وشغّل الفحوص بنفسك، والعب الجزء المتغيّر، وبعد ذلك فقط احفظه في commit.

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

لماذا لا تكفي كلمة «تمّ»؟

لأنها ادّعاء، والدليل هو التغيير نفسه. قد يقول المساعد إن ميزة ما تعمل وهو لم يتحقق إلا من أن الشيفرة تُبنى، أو إنه لمس ملفًا واحدًا بينما أعاد أمرٌ شغّله كتابة ثلاثة.

وبعض ذلك لا يظهر في المحرّر أصلًا. تقول صفحة Visual Studio Code عن مراجعة التعديلات التي يجريها الذكاء الاصطناعي إن التعديلات المعلّقة محفوظة على القرص بالفعل، وإن التغييرات التي تتم عبر أوامر الطرفية أو السكربتات لا تظهر في قائمة التعديلات لديه، وإن نقاط الاستعادة فيه لا تتراجع عن أوامر الطرفية ولا عن عمليات النشر. هكذا كانت الصفحة في 29 أكتوبر 2026، وآخر تحديث لها في 21 أكتوبر. أيًّا كانت أداتك، فالرؤية الموثوقة هي التي يعطيها نظام التحكم بالإصدارات: كل ملف يختلف عن آخر commit لديك.

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

إلامَ تنظر أولًا؟

إلى قائمة الملفات المتغيّرة. يعطيكها أمران:

git status
git diff --stat

يسمّي git status كل ملف متغيّر وكل ملف جديد. ويضيف git diff --stat عدد الأسطر التي كسبها كل ملف والتي خسرها. لاحظ أن git diff وحده لا يعرض الملفات الجديدة التي لم تُضَف إلى Git بعد، أما git status فيعرضها، فاقرأ الاثنين.

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

لا شيء من هذا خطأ في حد ذاته. لكن كل بند منها شيء لم تخطط لمراجعته، لذلك يأتي أولًا.

كيف تقرأ الـ diff إن لم تكن مبرمجًا؟

اقرأه كقائمة من الأسطر المحذوفة (بالأحمر، وعليها -) والأسطر المضافة (بالأخضر، وعليها +)، وابدأ بالمحذوفة. السطر الذي يختفي هو أسهل تغيير يفوتك وأصعب ما تلاحظه أثناء اللعب: فحص كان يمنع اللاعب من عبور الجدران، أو تصفير النقاط، أو حماية من حفظ فارغ.

ثم ابحث عن بعض العلامات التي يسهل رؤيتها من دون معرفة اللغة:

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

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

أيّ الفحوص تشغّلها بنفسك؟

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

الاختبار الأخضر لا يثبت إلا ما يختبره. إن تغيّر ملف اختبارات في الـ diff نفسه، فاقرأ ذلك الجزء: الاختبار الذي كان ينتظر نقاطًا تساوي 0 بعد إعادة البدء، وصار ينتظر أيّ قيمة تُرجعها الشيفرة، لم يعد يفحص شيئًا.

ماذا تلعب قبل أن تحتفظ بالتغيير؟

أولًا التغيير نفسه، كما وصفته مهمتك. ثم جولة قصيرة في بقية اللعبة، هي نفسها في كل مرة، لأن التغيير في مكان كثيرًا ما يكسر مكانًا آخر:

1. ابدأ اللعبة من صفحة جديدة؛
2. استعمل كل أداة تحكم مرة واحدة، على لوحة المفاتيح وعلى الهاتف إن كانت للعبة أدوات تحكم باللمس؛
3. إيقاف مؤقت، خسارة، إعادة بدء؛
4. احفظ، أعد تحميل الصفحة، حمّل الحفظ.

تستغرق الجولة بضع دقائق وتلتقط ما نادرًا ما تغطيه الاختبارات: زرًّا لم يعد يستجيب، أو شاشة لا يمكن الخروج منها، أو حفظًا لا يعود. وإن أضاف التغيير مفتاحًا أو شاشة، فتأكد أنهما يعملان باللمس أيضًا؛ هذه هي القاعدة التي نتبعها في KittenGalaxy منذ أن أضفنا إليها أدوات التحكم باللمس.

كيف تحتفظ بالتغيير، أو تتخلص منه؟

لتحتفظ به، احفظه في commit برسالة تقول ما الذي تغيّر بكلمات اللاعب: «كل موجة أسرع بنسبة 10% من سابقتها، حتى ضعف سرعة البداية». مهمة واحدة، commit واحد. لاحقًا، حين ينكسر شيء، يمكنك أن تعرف أيّ تغيير سبّبه وتتراجع عن ذلك التغيير بالضبط.

لتتخلص منه، عد إلى آخر commit. في Git، يعيد git restore . الملفات التي يتتبعها Git بالفعل إلى ما كانت عليه في آخر commit، ما لم تكن التغييرات قد جُهّزت بـ git add؛ أما الملفات التي أنشأها المساعد فلا يحذفها هذا الأمر، فانظر في git status مرة أخرى واحذفها بيدك. والمحرّرات التي لديها تراجع خاص بها أو نقاط استعادة تستطيع فعل الشيء نفسه، في الحدود التي تصفها. ثم اكتب مهمة أفضل: قل ما الذي سار على نحو خاطئ، وأضف فحصًا كان سيلتقطه.

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

هل يستطيع ذكاء اصطناعي آخر إجراء المراجعة؟

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

أسئلة شائعة

كم يجب أن تستغرق المراجعة؟ بقدر صِغَر التغيير تقريبًا. إن استغرقت قراءة الـ diff وقتًا أطول من كتابة المهمة، فالمهمة على الأرجح كانت أكبر من اللازم؛ قسّم التالية.

هل أحتاج إلى Git لهذا؟ تحتاج إلى طريقة ما لترى ما الذي تغيّر وتعود إلى الوراء. Git هو الطريقة المعتادة وهو مجاني، ومعظم المحرّرات والمساعدين يعملون معه.

ماذا لو كان التغيير صحيحًا لكن الشيفرة تبدو فوضوية؟ احتفظ به إن كان يعمل وأنت تفهمه، واكتب مهمة منفصلة للترتيب، بالفحوص نفسها. لا تخلط الترتيب بتغيير يضيف ميزة.

هل أراجع تغييرات الرسومات والأصوات وملفات المراحل؟ نعم، بالنظر واللعب بدل قراءة الـ diff. وقائمة الملفات المتغيّرة ما زالت تخبرك أيّها تنظر فيه.

متى يستطيع الآخرون لعبها؟ حين تنجح الجولة أعلاه على صفحة جديدة، ويستطيع شخص غريب إنهاء اللعبة من دون مساعدتك. عندها يمكنك إرسالها إلى HeapPlay.