كيف تطوّر تطبيقًا بُني بالذكاء الاصطناعي دون أن تكسره

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

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

حلقة التطوير

1. اختر تغييرًا واحدًا. ميزة واحدة، أو خطأ واحد، أو صفحة واحدة.
2. صفه بما يراه المستخدم ويفعله.
3. للتغييرات الكبيرة، خطط أولًا. اطلب خطة، واقرأها، ثم ابنِ.
4. تحقق من النتيجة في المعاينة: التغيير والتدفقات القريبة منه.
5. احفظ نقطة استعادة أو commit.
6. كرر.

كل خطوة موجودة لإبقاء التغييرات صغيرة وقابلة للتراجع.

الخطوة 1: احتفظ بقائمة قصيرة

قبل الطلب، اكتب ما تريد تغييره، مرتبًا حسب الأهمية. يمنعك ذلك من إرسال فقرة فيها عشر أمنيات في رسالة واحدة، ويمنحك طريقة لقول «ليس الآن» للأفكار التي تخطر لك في منتصف العمل.

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

الخطوة 2: صف ما تراه

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

في صفحة الأسعار على الهاتف، زر بطاقة Pro مقطوع من الحافة اليمنى. أبقِ تخطيط سطح المكتب كما هو؛ وعلى الشاشات أقل من 640 بكسل، اجعل البطاقات تتكدس عموديًا واجعل الأزرار بعرض الشاشة كاملًا.

قارن ذلك بـ«صفحة الأسعار تبدو سيئة على الجوال». الأول يمكن تنفيذه والتحقق منه في خطوة واحدة؛ أما الثاني فيدعو إلى إعادة تصميم لم تطلبها.

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

الخطوة 3: خطط قبل التغييرات الكبيرة

لأي شيء يمس عدة أجزاء من التطبيق، كنموذج بيانات جديد، أو المدفوعات، أو أدوار المستخدمين، اطلب خطة قبل أي تغيير في الكود:

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

اقرأ الخطة. إذا كانت خاطئة، فتصحيح الخطة أرخص بكثير من التراجع عن بناء كامل.

الخطوة 4: قل ما يجب ألا يتغير

أدوات الذكاء الاصطناعي تميل أحيانًا إلى «ترتيب» أشياء لم تطلب تغييرها. احمِ ما يعمل:

أضف فلتر تاريخ إلى جدول الطلبات. لا تغيّر أعمدة الجدول أو تنسيقه أو زر التصدير.

بالنسبة للقواعد التي تنطبق في كل مكان، مثل ألوان العلامة التجارية، ونبرة الكلام، و«لا تحذف البيانات أبدًا دون تأكيد»، ضعها في ملف ملاحظات للمشروع أو إعداد معرفة يقرؤه الذكاء الاصطناعي في كل مرة، بدل تكرارها.

الخطوة 5: تحقق من أكثر من التغيير نفسه

بعد كل طلب، اختبر:

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

إذا لاحظت خللًا، فصفه بدقة. راجع كيف تكتب تقرير خطأ جيدًا.

الخطوة 6: ارجع إلى الوراء بدل تكديس الإصلاحات

عندما يكسر تغيير شيئًا، ولا ينجح الإصلاح الأول، توقف. كل «إصلاح» إضافي يُبنى على حالة مكسورة، والمشاكل تتراكم.

بدلًا من ذلك:

1. ارجع إلى آخر نسخة كانت تعمل (نقطة استعادة أو commit في Git).
2. حدد ما الذي كان غامضًا في الطلب.
3. جرّب مرة أخرى بطلب أصغر أو أوضح.

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

الخطوة 7: اعرف متى تكون إعادة البناء هي الصحيحة

إعادة البناء من الصفر تتخلص من كثير من التفاصيل التي تعمل. وتستحق ذلك فقط عندما:

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

وعندما تعيد البناء، اكتب ما يجب الإبقاء عليه: الاسم، والألوان، والنصوص، والأجزاء التي أحبها المستخدمون.

أمثلة على طلبات

قبل أن نكمل، لخّص كيف يعمل التطبيق حاليًا: الصفحات، والبيانات التي يخزنها، وأي شيء تراه هشًا.

أريد إضافة حجوزات متكررة. ما أصغر نسخة مفيدة؟ اقترح ثلاثة تغييرات منفصلة نقوم بها واحدًا تلو الآخر.

راجع التغييرات الثلاثة الأخيرة لأي شيء قد يكون كسر تدفق الدفع. لا تعدّل شيئًا الآن.

أخطاء شائعة

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

قائمة التحقق

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

التطوير على Mythex

يقوم Mythex على هذه الحلقة:

• أوضاع التخطيط والبناء والسؤال. وضع التخطيط يناقش الأسلوب قبل التحرير؛ ووضع السؤال يجيب دون تغيير الكود؛ ووضع البناء يطبق التغيير. انظر المحادثة.
• نقاط الاستعادة. بعد كل دورة ناجحة، يحفظ Mythex نقطة استعادة في git، والعودة إلى هذه النقطة تتراجع عن التغييرات. كما يمكنك تعديل رسالة سابقة والتجاهل وإعادة الإرسال لتجربة طلب مختلف من تلك النقطة. انظر التطوير دون إعادة البناء.
• المعرفة. في إعدادات المشروع ← المعرفة، توجد ملاحظات دائمة يتبعها الوكيل في كل رسالة.
• /test يجعل الوكيل ينقر في المعاينة كما يفعل المستخدم بعد تغيير كبير.

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

الأسئلة