كيف تصلح تطبيقاً مبنياً بالذكاء الاصطناعي: تشخيص في 30 دقيقة

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

لا عرض بيع حتى النهاية. شغّل الفحوصات أولاً، فمعظم ما ستجده يمكنك إصلاحه بنفسك.

لماذا تنهار هذه التطبيقات في الإنتاج

البناء بالذكاء الاصطناعي يعني أن تصف ما تريد لأداة مثل Lovable أو Bolt أو Cursor أو Replit أو v0 وتُطلق ما تعيده. وهو ممتاز فعلاً في أول سبعين بالمئة. الخطأ هو افتراض أن الثلاثين بالمئة الأخيرة غير موجودة لأن العرض التجريبي بدا مكتملاً.

أدوات البرمجة الذكية تُحسِّن للكود الذي يعمل، لا للكود الذي يصمد. اختبر تقرير Veracode لأمن الكود المولَّد لعام 2025 أكثر من 100 نموذج عبر 80 مهمة برمجية، ووجد أن نحو 45% من الكود المولَّد يحتوي على ثغرة من قائمة OWASP العشر. وتشير تحليلات القطاع خلال 2025 و2026 إلى الاتجاه نفسه: الفرق التي تستخدم الذكاء الاصطناعي تُطلق أسرع بأضعاف، وتتراكم لديها الملاحظات الأمنية أسرع من ذلك.

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

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

لا أحد يطلب هذه الأمور في الـ prompt، لأن لا أحد يعرضها في العرض التجريبي.

التشخيص في 30 دقيقة: ستة فحوصات

نفّذها بالترتيب، وسجّل نجاحاً أو فشلاً لكل فحص، فستحتاج المحصلة في النهاية. لست بحاجة لأن تكون مطوّراً، لكنك تحتاج وصولاً إلى الطرفية (terminal) وإلى بيئة النشر.

الفحص 1: هل مفاتيحك مكشوفة؟

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

افحص الملفات الحالية:

npx secretlint "**/*"

ثم افحص السجل، وهناك تكمن المفاجآت الحقيقية:

git log -p | grep -Ei "sk-|AKIA|BEGIN (RSA |EC )?PRIVATE KEY|password\s*="

وأخيراً، تحقق مما تُرسله إلى المتصفح. أي متغير ببادئة مرئية للعميل يعتبر عاماً لكل زائر مهما كان اسمه:

grep -rE "^(NEXT_PUBLIC|VITE|REACT_APP)_.*(KEY|SECRET|TOKEN|PASSWORD)" .env*

فشل إذا: ظهر أي مفتاح حقيقي في أي من الثلاثة. مفتاح قاعدة بيانات بصلاحيات كاملة ببادئة عامة يعني اختراقاً كاملاً، لا تحذيراً.

الفحص 2: هل واجهة API محمية فعلاً؟

هذا أكثر عطل خطير شيوعاً وأسرعها اختباراً. خذ أي مسار API يعيد بيانات خاصة واستدعِه بلا أي بيانات اعتماد:

curl -s -o /dev/null -w "%{http_code}\n" https://yourapp.com/api/orders

الرد المطلوب هو 401 أو 403. أما 200 فيعني أن أي شخص على الإنترنت يستطيع قراءة هذا المسار، وأن شاشة تسجيل الدخول أمامه مجرد ديكور.

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

إن كنت تستخدم Supabase، وهو الافتراضي في Lovable وBolt، فافتح محرر الجداول وتأكد أن أمان مستوى الصفوف (RLS) مفعّل على كل جدول يحمل بيانات مستخدمين، وأن لا سياسة منها مفتوحة للجميع. تعطيل RLS هو النسخة الخاصة بـSupabase من العطل نفسه.

فشل إذا: أجاب أي مسار خاص بلا بيانات اعتماد، أو استطاع أي مستخدم قراءة سجلات مستخدم آخر.

الفحص 3: ماذا يوجد في اعتمادياتك؟

الأدوات الذكية تثبّت النسخة التي كانت في بيانات تدريبها، وغالباً ليست النسخة التي تريدها.

npm audit --audit-level=high

لمشاريع بايثون:

pip-audit

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

الفحص 4: ماذا يجد التحليل الثابت؟

التحليل الثابت يكشف الأنماط التي يولّدها الذكاء الاصطناعي بانتظام: استعلامات SQL مبنية بدمج النصوص، وغياب التحقق من المدخلات، وعرض غير آمن لمحتوى المستخدم. ثبّت Semgrep عبر pip install semgrep أو brew install semgrep، ثم شغّل قواعد OWASP على مشروعك:

semgrep --config=p/owasp-top-ten .

فشل إذا: وُجدت نتائج بدرجة ERROR في كود يمس المصادقة أو مدخلات المستخدم أو قاعدة البيانات. تجاهل ضجيج الملفات المولَّدة والاعتماديات حالياً.

الفحص 5: هل لديك أي شبكة أمان؟

أمران وقائمة مجلد واحدة:

npm test و ls .github/workflows

إذا طبع الأول «no test specified» ولم يوجد الثاني، فكل إطلاق تقوم به تجربة حية على مستخدميك. لست بحاجة لتغطية عالية، بل لاختبارات على المسارات الثلاثة إلى الخمسة التي تجلب المال أو تفقد العملاء: التسجيل، وتسجيل الدخول، والإجراء الأساسي، والدفع.

فشل إذا: لا يوجد أي فحص آلي بين لوحة مفاتيحك والإنتاج.

الفحص 6: هل نموذج البيانات سليم؟

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

1. هل تستطيع تسمية كل جدول وقول ما يحتويه في جملة واحدة؟ الجداول التي لا يستطيع أحد شرحها هي جداول نمت بالصدفة.
2. هل تُخزَّن أي معلومة واحدة في أكثر من مكان؟ ازدواج الحقيقة يعني أن كل ميزة قادمة ستكون أيضاً عطل مزامنة.
3. هل العلاقات موجودة كمفاتيح مرتبطة فعلية، أم مجرد نصوص متطابقة يأمل الكود أن تتوافق؟

فشل إذا: كانت الإجابة «لا» على اثنين أو أكثر. احتفظ بهذه النتيجة منفصلة عن البقية، فهي وحدها تحدد القرار التالي.

كيف تقرأ نتائجك

اجمع نتائج الفحوصات الستة:

• فشل الفحص 1 أو 2: أوقف التسجيلات أو المدفوعات الجديدة حتى الإصلاح. هذان هما اللذان يكشفان بيانات العملاء، ولا يستغرق أي منهما أكثر من يوم.
• فشل 3 أو 4 أو 5 مع نجاح 1 و2: لست في خطر، أنت في دَين تقني. هذا أسبوع عمل مركّز تقريباً، ويمكن إنجازه داخلياً بالكامل.
• فشل الفحص 6: اقرأ القسم التالي بعناية. هذا هو العطل الوحيد الذي قد يجعل الإصلاح خياراً خاطئاً.
• نجحت الفحوصات الستة: أحسنت فعلاً، فهذا أندر مما يوحي به الإنترنت. أضف المراقبة وواصل البناء.

إصلاح أم إعادة بناء؟ اجعل نموذج البيانات هو الفيصل

كل نقاش إنقاذ ينتهي بسؤال «ألا نبدأ من الصفر؟»، ويُجاب عليه عادةً بالمزاج لا بالدليل. وهناك قاعدة أوضح:

إذا صمد المخطط، أصلح. وإذا وجب تغيير المخطط، أعد بناء الطبقات فوقه.

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

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

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

أصلح بهذا الترتيب، لا بالترتيب الذي تشتهيه

أكثر خطأ شائع هنا هو البدء بإعادة الهيكلة، لأن الترتيب ممتع والأمان ليس كذلك. لكن الكود المرتب الذي يسرّب بيانات العملاء ما زال يسرّبها. اعمل من الأعلى للأسفل:

1. استبدل كل مفتاح مكشوف. الاستبدال أولاً وتنظيف سجل Git ثانياً. الاستبدال هو ما يوقف التسريب فعلاً، وتنظيف السجل يمنع تكراره.
2. افرض الصلاحيات على الخادم. كل مسار، وفي كل مرة، مقابل المستخدم الموثّق لا مقابل معطى أرسله العميل.
3. حصّن مسارات المال. المدفوعات والأرصدة والحصص وكل ما يرسل بريداً للعميل. تحقق في الخادم، ولا تثق أبداً بسعر أو كمية وصلا من المتصفح.
4. أضف معالجة أخطاء حقيقية وتتبعاً. استبدل كتل المعالجة الفارغة، ثم ثبّت Sentry أو ما يعادله. يستغرق ذلك نحو عشرين دقيقة، وتتحول «قال مستخدم إنه تعطل» إلى أثر خطأ كامل.
5. أضف تكاملاً مستمراً واختبارات للمسارات الحرجة. خط يعمل مع كل دفعة، واختبارات شاملة لمسارات المال الثلاثة إلى الخمسة.
6. أضف مراقبة التشغيل والسجلات. يجب أن تعرف بتعطل تطبيقك من إشعار، لا من عميل.
7. ثم الأداء والتكلفة. فهارس قاعدة البيانات، والتخزين المؤقت، وحدود الاستخدام، وسقف لاستدعاءات النماذج اللغوية. الاستدعاءات بلا حدود هي سبب فاتورة بخمسة أرقام بعد أسبوع انتشار.
8. وأعد الهيكلة أخيراً، ولما تلمسه فقط. البنية تتحسن تلقائياً أثناء تنفيذ ما سبق. أما إعادة كتابة شاملة لكود يعمل فلا تعطي المستخدم شيئاً يراه.

ما الذي تخطئ فيه كل أداة عادةً

تختلف أنماط الأعطال بحسب مصدر الكود، وهذا اختصار مفيد حين تعرف أداتك ولا تعرف كودك.

• Lovable وBolt: تعتمدان Supabase افتراضياً، فالمشكلة المتكررة هي أمان مستوى الصفوف. إما معطّل تماماً، أو سياسة مفتوحة بما يكفي ليقرأ المفتاح العام كل الصفوف. افحص RLS جدولاً جدولاً قبل أي شيء.
• Replit: إدارة المفاتيح جيدة على المنصة، فالثغرة المعتادة في إعدادات النشر. إعدادات تطوير، أو CORS مفتوح، أو أوضاع تنقيح تُنقل إلى البيئة الحية.
• Cursor وClaude Code وWindsurf: أنت في مستودع حقيقي وبكود أفضل عموماً، والعطل هنا انحراف معماري بدلاً من ذلك. كل جلسة تضيف نمطاً جديداً، فتنتهي بأربع طرق لفعل الشيء نفسه وبلا مرجع واحد.
• v0: واجهة أولاً، وبارع فيها. الفجوة خلف الشاشات، حيث تكون الخدمات الخلفية وهمية أو ناقصة، فما يبدو مكتملاً غير موصول فعلياً.
• ChatGPT أو Claude بالنسخ واللصق: ملفات منطقية منفردة بلا معمارية مشتركة، لأن أي prompt واحد لم يرَ النظام كاملاً.

متى تستعين بمهندس خبير

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

• فشل الفحص 2 ولست واثقاً أنك وجدت كل المسارات المتأثرة.
• تتعامل مع مدفوعات أو بيانات صحية أو أي مجال خاضع لجهة تنظيمية.
• فشل الفحص 6 وقرار الإصلاح مقابل إعادة البناء يستحق أكثر من كلفة رأي ثانٍ.
• لديك عملاء يدفعون الآن، وتكلفة التوقف اليومية أعلى من تكلفة الإصلاح.
• حاولت الإصلاح بالأداة نفسها مرتين فانتقل العطل بدل أن يزول.

النقطة الأخيرة تستحق التأمل. الأدوات الذكية بارعة في إضافة الكود وضعيفة في تقرير ما لا ينبغي أن يوجد. وحين يُنتج الإصلاح عطلاً جديداً في ملف آخر، تكون قد بلغت حد ما يمكن أن يحله المزيد من الـ prompts.

الخلاصة

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

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

وإن فضّلت أن ينفّذها غيرك، فإن خدمة إنقاذ الكود لدينا تشغّل التشخيص نفسه باحتراف وتمنحك تقريراً مكتوباً خلال ثلاثة أيام عمل بسعر ثابت 1,500 دولار، يُحتسب بالكامل من قيمة الإصلاح إن تابعت. وإن لم تكن قد بنيت المنتج بعد، فإن سباق المنتج الأولي في 30 يوماً يوصلك إلى هناك بلا فاتورة تنظيف لاحقة. أو احجز مكالمة تقييم مجانية 20 دقيقة وسنخبرك أي الخيارات الثلاثة تحتاج فعلاً.