هل سبق أن طلبت من الذكاء الاصطناعي كتابة برنامج صغير، فحصلت على كود يعمل في البداية، لكنه أصبح صعب الفهم عندما حاولت تعديله؟ هذه مشكلة قد تواجه المبتدئين وحتى أصحاب الخبرة عند الاعتماد على أدوات توليد الأكواد دون تقديم تعليمات واضحة. فقد ينتج النموذج عشرات الأسطر دفعة واحدة، أو يستخدم أسماء متغيرات غامضة، أو يضيف وظائف لم تطلبها، مما يجعل صيانة المشروع أكثر تعقيدًا لاحقًا.
المشكلة ليست دائمًا في قدرة النموذج على البرمجة، بل في طريقة وصف المهمة ومعايير الجودة التي تحددها قبل توليد الكود. فهناك فرق بين طلب برنامج يؤدي وظيفة معينة، وطلب برنامج يمكن فهمه واختباره وتطويره دون إعادة بنائه من الصفر. ويتطلب الوصول إلى النتيجة الثانية معرفة كيفية تقسيم المهمة، وتحديد القيود التقنية، ومراجعة الناتج بصورة منهجية.
لكي تطلب من الذكاء الاصطناعي كتابة كود نظيف وقابل للتعديل، حدد وظيفة البرنامج ولغة البرمجة وبيئة التشغيل، واشترط تقسيم الكود إلى وظائف واضحة، واستخدام أسماء مفهومة، وتقليل التكرار، وإضافة اختبارات، ثم اطلب مراجعة الناتج وتحسينه قبل اعتماده.
قبل أن تبدأ
- حدد المشكلة التي تريد حلها بجملة واضحة.
- اختر لغة البرمجة أو اطلب اقتراح لغة مناسبة مع توضيح السبب.
- اكتب المدخلات والمخرجات المتوقعة للبرنامج.
- حدد إن كنت تريد إنشاء مشروع جديد أو تعديل كود موجود.
- جهز أمثلة لحالات الاستخدام والأخطاء المحتملة.
- لا تشارك كلمات المرور أو مفاتيح الخدمات أو البيانات السرية مع أدوات غير موثوقة.
ما الذي ستحتاجه قبل البدء؟
لا تحتاج إلى إتقان البرمجة للاستفادة من الذكاء الاصطناعي، لكنك تحتاج إلى تصور واضح لما تريد تنفيذه. ابدأ بوصف المهمة بلغة بسيطة: ما الذي سيفعله البرنامج؟ ومن سيستخدمه؟ وما النتيجة المطلوبة عندما يستقبل بيانات صحيحة أو خاطئة؟
إذا كنت تريد أداة لتنظيم المصروفات مثلًا، فحدد هل ستجمع المبالغ فقط، أم تصنفها، أم تحفظها في ملف. هذه التفاصيل تؤثر في بنية الكود أكثر من مجرد تحديد لغة البرمجة.
من المفيد أيضًا معرفة ثلاثة مصطلحات أساسية: الدالة هي جزء مستقل من الكود ينفذ مهمة محددة، والوحدة البرمجية هي ملف أو مكون يجمع وظائف مرتبطة، وإعادة الهيكلة (Refactoring) تعني تحسين تنظيم الكود دون تغيير سلوكه المقصود.
إذا كان لديك مشروع قائم، جهز الملفات ذات الصلة وأسماء الدوال المستخدمة وإصدارات الأدوات الأساسية. ولا ترسل المشروع كاملًا عندما تكفي أجزاء محددة لفهم المشكلة.
الفكرة العملية: اكتب وصفًا قصيرًا للمهمة يتضمن الهدف والمدخلات والمخرجات والقيود قبل إرسال أول طلب.
ما الخطوات بالترتيب الصحيح؟
أفضل طريقة للحصول على كود منظم هي التعامل مع توليده كعملية تطوير متدرجة، لا كإجابة واحدة نهائية. اتبع الخطوات التالية، واختبر نتيجة كل مرحلة قبل الانتقال إلى التي تليها.
-
حدد مهمة واحدة قابلة للتنفيذ.
بدلًا من كتابة «أنشئ نظام إدارة كاملًا»، اطلب وظيفة محددة مثل حساب إجمالي المصروفات من قائمة أرقام. المهام الصغيرة تجعل مراجعة النتائج واكتشاف الأخطاء أسهل.
-
حدد لغة البرمجة وبيئة التشغيل.
اذكر مثلًا أنك تريد Python 3 أو JavaScript يعمل في المتصفح. وإذا كان المشروع يعتمد على إطار عمل، فحدد اسمه وإصداره. اطلب عدم استخدام مكتبات إضافية إلا عند الضرورة، مع توضيح طريقة تثبيتها.
-
ضع معايير واضحة لنظافة الكود.
اطلب أسماء دوال ومتغيرات معبرة، وتجنب التكرار، وفصل العمليات المختلفة إلى دوال مستقلة، وعدم إضافة تعقيد غير مطلوب. وفي Python يمكن الاسترشاد بتوصيات توثيق Python الرسمي المتعلقة بأسلوب كتابة الكود وسهولة قراءته.
-
اطلب خطة مختصرة قبل كتابة البرنامج.
يمكنك كتابة: «اشرح تقسيم الحل إلى وظائف قبل توليد الكود، واذكر أي افتراض يحتاج إلى تأكيد». تساعد هذه الخطوة على اكتشاف سوء الفهم قبل تحويله إلى عشرات الأسطر.
-
اطلب توليد الوظيفة الأساسية أولًا.
ابدأ بأصغر جزء يحقق الهدف. مثلًا، اطلب دالة تستقبل قائمة مصروفات وتعيد مجموع القيم الصحيحة. بعد اختبارها يمكن إضافة التصنيف أو الحفظ أو واجهة الاستخدام.
-
حدد طريقة التعامل مع الأخطاء.
اشترط سلوكًا واضحًا عند إدخال قيمة غير صالحة أو غياب البيانات. هل يعيد البرنامج رسالة خطأ؟ أم يرفض العملية؟ تجنب الطلبات العامة مثل «اجعل الكود يعالج جميع الأخطاء» دون تحديد الحالات المهمة.
-
اطلب اختبارات عملية.
الاختبار الآلي هو كود يتحقق من أن وظيفة أخرى تعطي النتيجة المتوقعة. اطلب اختبار القيم العادية والقائمة الفارغة والمدخلات غير الصحيحة. وتوضح وثائق GitHub كيفية الاستفادة من مساعد البرمجة في إنشاء اختبارات الوحدات والتكامل.
-
اطلب مراجعة مستقلة للكود.
بعد التوليد، استخدم طلبًا جديدًا مثل: «راجع الكود بحثًا عن التكرار، والوظائف الطويلة، والأسماء غير الواضحة، والأخطاء المحتملة. لا تغير السلوك دون توضيح السبب». تعامل مع نتائج المراجعة باعتبارها مقترحات تحتاج إلى تحقق.
-
اطلب نسخة محسنة مع شرح التعديلات.
عندما يعمل البرنامج بصورة صحيحة، اطلب إعادة تنظيم الأجزاء المعقدة مع الحفاظ على المدخلات والمخرجات. ويُفضل أن يوضح النموذج ما الذي تغير، ولماذا، وما الاختبارات التي ينبغي إعادة تشغيلها.
-
احفظ النسخة واختبرها بنفسك.
انسخ الكود إلى بيئة تشغيل مناسبة، ونفذ الاختبارات فعليًا، وقارن النتائج بالمطلوب. إذا ظهر خطأ، احتفظ برسالة الخطأ وسياقها بدل إعادة توليد المشروع بالكامل.
مثال على طلب احترافي جاهز للنسخ
«تصرف كمطور برمجيات يهتم بسهولة الصيانة. اكتب برنامجًا بلغة Python 3 لحساب إجمالي المصروفات من قائمة أرقام. استخدم دوال قصيرة بأسماء واضحة، وافصل التحقق من المدخلات عن عملية الحساب، وتجنب التكرار والمكتبات الخارجية. وضح سلوك البرنامج عند إدخال قائمة فارغة أو قيمة غير رقمية. أضف اختبارات للحالات الأساسية والخاطئة، واشرح طريقة التشغيل. لا تضف وظائف غير مطلوبة، ولا تدّعِ تشغيل الاختبارات إن لم تنفذها فعلًا».
يمكن إعادة استخدام هذا الطلب بعد استبدال اللغة والمهمة والمدخلات. الأهم هو الاحتفاظ بمعايير التنظيم والتحقق وعدم ترك القرارات الأساسية للتخمين.
الفكرة العملية: اطلب التخطيط ثم التنفيذ ثم الاختبار ثم التحسين، مع فصل كل مرحلة عن الأخرى.
ما الأخطاء الشائعة التي يجب تجنبها؟
الخطأ الأول هو استخدام تعليمات فضفاضة مثل «اكتب أفضل كود ممكن». كلمة «أفضل» لا تحدد هل الأولوية للسرعة أم البساطة أم سهولة الصيانة. استبدلها بمعايير يمكن مراجعتها، مثل تجنب تكرار المنطق واستخدام دوال مستقلة.
الخطأ الثاني هو طلب مشروع كبير دفعة واحدة؛ فقد ينتج النموذج مكونات مترابطة بطريقة تجعل تعديل أحدها يؤثر في البقية. قسم العمل إلى وظائف صغيرة وحدد العلاقة بينها قبل دمجها.
الخطأ الثالث هو اعتبار التعليقات الكثيرة دليلًا على الجودة. التعليق المفيد يشرح سبب قرار غير واضح، بينما ينبغي أن يكون عمل الدالة مفهومًا من اسمها وبنيتها قدر الإمكان.
ومن الأخطاء المهمة قبول أكواد تتعامل مع المدخلات دون تحقق أو تضع بيانات الدخول مباشرة داخل الملفات. تؤكد مؤسسة OWASP أهمية التحقق من المدخلات وحماية البيانات وتطبيق ممارسات البرمجة الآمنة.
كذلك لا تفترض أن الكود صحيح لمجرد أن النموذج أكد ذلك؛ فقد يقترح مكتبة غير مناسبة أو يستخدم واجهة برمجية تغيرت طريقة عملها.
الفكرة العملية: لا تعتمد الكود بسبب مظهره المنظم؛ تحقق من السلوك والأمان وقابلية الصيانة.
كيف تتحقق من نجاح كل خطوة؟
التحقق يبدأ بمقارنة الناتج بالمتطلبات الأصلية. تأكد أولًا من أن الدوال تنفذ الوظائف المطلوبة فقط، وأن أسماءها تصف مسؤولياتها، وأن تعديل قاعدة حسابية لا يتطلب تغيير مواضع متعددة دون مبرر.
بعد ذلك شغل البرنامج بمدخلات معروفة النتائج، ثم اختبر الحالات الطرفية، وهي الظروف التي تقع على حدود الاستخدام المعتاد، مثل البيانات الفارغة أو القيم الكبيرة أو الأنواع غير المتوقعة. نجاح الحالة العادية وحدها لا يكفي.
راجع أيضًا تحذيرات محرر الكود وأدوات التحليل الثابت التي تفحص الشيفرة دون تشغيلها. ويمكن استخدام تنسيق آلي متوافق مع اللغة لتوحيد المسافات وترتيب الأسطر، لكن التنسيق وحده لا يثبت صحة المنطق.
في المشاريع المشتركة، تفيد مراجعة التغييرات قبل دمجها. وتشرح وثائق GitHub لمراجعة طلبات الدمج كيفية فحص الملفات والتعديلات ومناقشة الأخطاء قبل اعتمادها.
وأخيرًا، جرب تعديل شرط صغير في البرنامج. إذا استطعت تحديد موضع التعديل واختبار أثره دون فهم المشروع كاملًا، فهذه علامة مفيدة على وضوح بنيته، وليست ضمانًا مطلقًا لجودته.
الفكرة العملية: اجمع بين التشغيل الفعلي والاختبارات ومراجعة التنظيم، ولا تعتمد على تقييم النموذج لنفسه وحده.
ماذا تفعل إذا فشلت خطوة معينة؟
إذا لم يعمل الكود، لا تبدأ فورًا بطلب كتابته من جديد. حدد أولًا نوع الفشل: هل توجد رسالة خطأ؟ هل يعمل البرنامج لكنه يعطي نتيجة خاطئة؟ أم أن المشكلة في صعوبة تعديل بنيته؟ لكل حالة طريقة معالجة مختلفة.
عند ظهور رسالة خطأ، قدم للنموذج نصها الكامل والجزء المرتبط بها وإصدار بيئة التشغيل، مع حذف أي بيانات سرية. ثم اطلب تفسير السبب واقتراح أصغر تعديل ممكن، دون تغيير بقية الوظائف.
أما إذا كانت النتائج غير صحيحة، فأرسل مثالًا يتضمن المدخلات والنتيجة المتوقعة والنتيجة الفعلية. هذه المعلومات أدق من عبارة «الكود لا يعمل»، وتساعد على تحديد الخلل المنطقي.
إذا أصبحت البنية معقدة، فاطلب خطة لإعادة الهيكلة قبل تطبيقها. ابدأ بإضافة اختبارات للسلوك الحالي، ثم نفذ تغييرًا محدودًا في كل مرة. ويمكنك استخدام نظام التحكم بالإصدارات مثل Git للعودة إلى نسخة سابقة إذا ظهرت مشكلة جديدة.
عندما يكون الخلل مرتبطًا بمكتبة أو خدمة خارجية، راجع التوثيق الرسمي لإصدارها المستخدم. ولا تعتمد على اقتراح النموذج بوصفه دليلًا على أن الدالة أو الخاصية ما زالت مدعومة.
الفكرة العملية: قدم دليلًا محددًا على الفشل، واطلب إصلاح الجزء المتأثر مع إعادة تشغيل الاختبارات.
نصائح متقدمة لتحسين النتيجة
بعد إتقان الخطوات الأساسية، يمكنك جعل الطلبات أكثر دقة بإضافة معايير قبول واضحة. مثلًا: «يجب أن تقبل الدالة قائمة فارغة، وألا تعدل البيانات الأصلية، وأن تعيد نتيجة من النوع المحدد». هذه الشروط تحول التوقعات العامة إلى سلوك قابل للاختبار.
اطلب أيضًا توضيح الافتراضات والبدائل عندما توجد قرارات تصميمية مؤثرة. وإذا اقترح النموذج مكتبة جديدة، فليوضح فائدتها وتكلفة إضافتها وإمكانية تنفيذ الوظيفة دونها.
في المشاريع الأكبر، استخدم ملفًا مرجعيًا يحتوي على قواعد تسمية الدوال، وهيكل المجلدات، وإصدارات الأدوات، وطريقة كتابة الاختبارات. أرفق هذه القواعد مع كل مهمة ذات صلة لتقليل الاختلاف بين الأجزاء المولدة.
من المفيد كذلك طلب عرض التعديلات فقط بدل إعادة إرسال جميع الملفات. وتساعد آلية الفروع وحفظ التغييرات الموضحة في إرشادات GitHub لإدارة الكود على عزل التجارب والرجوع إلى النسخ السابقة.
ولتحسين الأمان، اطلب مراجعة معالجة المدخلات والصلاحيات والأخطاء الحساسة، ثم تحقق من النتائج باستخدام أدوات مناسبة. فالكود القابل للصيانة ينبغي ألا يصبح أقل أمانًا بسبب التبسيط أو إعادة التنظيم.
الفكرة العملية: اجعل معايير القبول وقواعد المشروع ثابتة، واطلب تغييرات صغيرة يمكن تتبع أثرها واختبارها.
مواضيع قد تهمك:
- كيف تحسّن سيرتك الذاتية بالذكاء الاصطناعي لتجاوز ATS؟
- ما الذي يحدد جودة إجابة الذكاء الاصطناعي قبل سؤالك؟
- كيف تكتشف أن رد الذكاء الاصطناعي يعتمد على بيانات قديمة؟
- كيف تتحقق من صحة إحصائية ذكرها الذكاء الاصطناعي؟
أسئلة متكررة
هل يستطيع الذكاء الاصطناعي كتابة كود نظيف من أول محاولة؟
نعم، قد ينتج كودًا منظمًا من المحاولة الأولى، لكن ذلك لا يضمن خلوه من الأخطاء. تظل المراجعة والاختبارات ضرورية قبل الاستخدام الفعلي.
هل يجب أن أعرف البرمجة قبل طلب كتابة الكود؟
ليس بالضرورة لبدء التجربة، لكن فهم المفاهيم الأساسية يساعد على تقييم النتائج واكتشاف الأخطاء واتخاذ قرارات التعديل.
ما الفرق بين الكود النظيف والكود الذي يعمل فقط؟
الكود الذي يعمل يحقق وظيفة معينة، أما الكود النظيف فيسعى أيضًا إلى الوضوح وتقليل التعقيد والتكرار وتسهيل الاختبار والصيانة.
هل أطلب الكود كاملًا أم أقسم المشروع إلى أجزاء؟
يفضل تقسيم المشاريع المتوسطة والكبيرة إلى مهام واضحة، مع تحديد كيفية اتصال الأجزاء واختبارها قبل دمجها.
كيف أطلب تعديل الكود دون تغيير وظائفه؟
اطلب إعادة الهيكلة مع الحفاظ على السلوك الحالي وواجهات الدوال، وحدد الملفات المسموح تعديلها، ثم أعد تشغيل الاختبارات للتحقق من عدم حدوث تغييرات غير مقصودة.
هل الكود الذي يولده الذكاء الاصطناعي آمن للاستخدام مباشرة؟
لا يمكن افتراض ذلك. يجب فحص المدخلات والصلاحيات والمكتبات والبيانات الحساسة، وإجراء الاختبارات والمراجعات المناسبة قبل استخدامه في بيئة إنتاج حقيقية.
ماذا تفعل الآن
- اختر وظيفة برمجية صغيرة وحدد مدخلاتها ومخرجاتها بدقة.
- استخدم نموذج الطلب الجاهز مع تحديد اللغة ومعايير التنظيم والاختبارات.
- شغل الكود، واختبر الحالات المختلفة، ثم اطلب تحسين بنيته مع الحفاظ على سلوكه.
كتابة كود نظيف بالذكاء الاصطناعي ليست نتيجة أمر سحري، بل ثمرة تعليمات واضحة ومراجعة مستمرة وقرارات تقنية قابلة للتحقق. وكلما تعلمت وصف المشكلة وتحديد القيود وتقييم النتائج، أصبحت قدرتك على تطوير البرنامج لاحقًا أفضل. ابدأ اليوم بدالة بسيطة، واختبرها بنفسك، ثم اطلب تحسين تنظيمها دون تغيير وظيفتها.
الفكرة العملية: اعتمد الكود بعد أن تثبت صحته وتفهم طريقة تعديله، وليس بمجرد انتهاء النموذج من كتابته.