منهج عملي

منهج بناء مشاريع Vibe Coding بأقل مشكلات أمنية ومعمارية

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

آخر تحديث: 2 أكتوبر 2026

افحص مشروعك الآن اطلب مراجعة من مختص

لماذا تظهر الثغرات والهلوسة؟

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

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

المرحلة 1: ملف قواعد ثابت قبل أول سطر

أنشئ ملف قواعد في جذر المشروع (AGENTS.md أو ما تدعمه أداتك مثل Knowledge في Lovable أو .cursorrules في Cursor أو CLAUDE.md). الأداة تقرؤه في كل جلسة، فلا تعيد شرح الأساسيات ولا تتغير القرارات. ستجد نموذجاً جاهزاً للنسخ أسفل هذه الصفحة.

المرحلة 2: خطط قبل أن تبني

01اكتب وصفاً قصيراً: من المستخدم، ما المشكلة، ما الصفحات، ما البيانات.
02اطلب من الأداة خطة فقط دون كود: الجداول وعلاقاتها، الأدوار والصلاحيات، الصفحات، ما هو عام وما يحتاج دخولاً.
03راجع الخطة واسأل: من يستطيع قراءة كل جدول؟ من يستطيع تعديله؟ ثم وافق.

المرحلة 3: قاعدة البيانات والصلاحيات أولاً

01فعّل RLS على كل جدول منذ إنشائه، واكتب سياسة لكل عملية (قراءة، إضافة، تعديل، حذف).
02الأدوار في جدول مستقل (user_roles) وليس في جدول المستخدمين.
03أي عملية حساسة تتحقق من الهوية والصلاحية على الخادم، لا يكفي إخفاء الزر.
04المفاتيح السرية تُحفظ كأسرار على الخادم فقط؛ المفتاح العام (publishable) وحده يجوز في الواجهة.

المرحلة 4: ابنِ بخطوات صغيرة قابلة للتحقق

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

المرحلة 5: امنع الهلوسة بطلب الدليل

01اطلب من الأداة ذكر الملفات التي عدّلتها والسبب، وليس «تم» فقط.
02اطلب أن تقرأ الكود الحالي قبل التعديل، ولا تفترض وجود دوال أو جداول.
03لأي مكتبة أو API: «تأكد من الوثائق الرسمية ولا تخترع خيارات».
04إذا قالت الأداة إن شيئاً يعمل، اطلب طريقة التحقق: سجل، اختبار، أو خطوات تجربة.

المرحلة 6: مراجعة أمنية ومعمارية دورية

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

المرحلة 7: افحص قبل الإطلاق

01شغّل فحص VibeQuality على الرابط المنشور، وأضف مستودع GitHub إن كان متاحاً لفحص الكود.
02سجّل الدخول بحسابين مختلفين وتأكد أن كل حساب يرى بياناته فقط.
03جرّب النماذج بمدخلات خاطئة وطويلة وفارغة.
04راجع قائمة «تحقق بنفسك» في التقرير ونفّذ برومبت المراجعة.

تصنيف المشكلات التي يغطيها المنهج

المحور	أمثلة	كيف تُكتشف
الأمان	مفاتيح مكشوفة، جداول بلا RLS، صلاحيات في الواجهة، ملفات حساسة منشورة	الفحص الخارجي + فحص المستودع + المراجعة اليدوية
قاعدة البيانات	سياسات مفتوحة، أدوار في جدول المستخدمين، غياب التحقق من المدخلات	فحص ملفات الترحيل + برومبت المراجعة
المعمارية	منطق مكرر، ملفات ضخمة، قرارات متضاربة	مراجعة دورية بملف القواعد
الهلوسة	دوال أو مكتبات غير موجودة، ادعاء إصلاح دون تنفيذ	طلب الدليل والتجربة اليدوية
الإطلاق والظهور	noindex، غياب Sitemap، محتوى لا يظهر دون JavaScript	الفحص الخارجي
وضوح المنتج	عنوان غامض، دعوة غير واضحة لاتخاذ إجراء	تقييم ذكي مقيّد باقتباس حرفي من الصفحة

برومبتات جاهزة لكل مرحلة

برومبت التخطيط

قبل البناء

لا تكتب أي كود الآن. اقرأ ملف القواعد ثم اقترح خطة للمشروع التالي: [الوصف].
أريد: الجداول وأعمدتها وعلاقاتها، الأدوار وصلاحية كل دور على كل جدول (قراءة/إضافة/تعديل/حذف)، الصفحات العامة والصفحات التي تحتاج دخولاً، والعمليات التي يجب أن تتم على الخادم.
اذكر أي افتراض تضطر إليه بوضوح بدل تنفيذه بصمت.

برومبت ميزة بنطاق محدد

أثناء البناء

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

برومبت تشخيص قبل الإصلاح

عند تكرار الخطأ

لا تعدّل أي شيء الآن. شخّص سبب المشكلة التالية: [الوصف والخطأ].
اقرأ السجلات والملفات المعنية، واذكر السبب الجذري المحتمل مع الدليل (ملف وسطر أو رسالة خطأ).
إذا لم تكن متأكداً قل ذلك واقترح طريقة للتأكد. بعد موافقتي فقط نفّذ الإصلاح.

برومبت مراجعة أمنية ومعمارية

كل عدة ميزات وقبل الإطلاق

راجع المشروع دون تعديل وأعطني تقريراً بالدليل لكل بند:
1. كل جدول: هل RLS مفعّلة؟ ما السياسات؟ هل توجد سياسة كتابة مفتوحة (true)؟
2. أين تُخزن الأدوار؟ هل يستطيع المستخدم تعديل دوره؟
3. هل يوجد أي مفتاح سري في كود الواجهة؟
4. أي عملية حساسة تعتمد على إخفاء الواجهة بدل التحقق على الخادم؟
5. أي مدخلات لا يتم التحقق منها على الخادم؟
6. ملفات كبيرة جداً أو منطق مكرر يجب فصله.
لا تفترض ما لم تره في الكود. رتّب النتائج: حرج، مهم، تحسين.

ملف القواعد: انسخه إلى مشروعك

ضعه في Knowledge في Lovable، أو كملف AGENTS.md / CLAUDE.md / ‎.cursorrules في جذر المشروع. عدّل قسم المعمارية بقرارات مشروعك.

# قواعد المشروع (اقرأها قبل أي تعديل)

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

## الأمان وقاعدة البيانات
- كل جدول جديد: فعّل RLS واكتب سياسة لكل عملية، مقيدة بصاحب البيانات أو الدور.
- لا سياسات كتابة مفتوحة (USING true / WITH CHECK true) إلا بقرار مكتوب.
- الأدوار في جدول مستقل (user_roles) مع دالة تحقق آمنة، وليس في جدول المستخدمين.
- أي عملية حساسة (دفع، حذف، صلاحيات، بيانات مستخدمين آخرين) تتحقق على الخادم.
- المفاتيح السرية أسرار على الخادم فقط. المفتاح العام وحده مسموح في الواجهة.
- تحقق من كل المدخلات على الخادم (النوع، الطول، القيم المسموحة).
- لا تكشف تفاصيل داخلية في رسائل الخطأ.

## المعمارية
- مكوّنات صغيرة بمسؤولية واحدة. افصل المنطق عن العرض.
- لا تكرر المنطق؛ أعد استخدام الموجود.
- سجّل كل قرار معماري هنا كقاعدة من سطر واحد مع سببه.

## المحتوى
- لا تختلق أرقاماً أو شهادات عملاء أو شعارات شركات أو أسعاراً.
- لا محتوى مؤقت (Lorem ipsum) في أي صفحة منشورة.

الحدود والقيود

01لا يوجد منهج يضمن صفر ثغرات؛ الهدف تقليلها واكتشاف الباقي قبل المستخدمين.
02الفحص الخارجي لا يرى قاعدة البيانات؛ لذلك تبقى المراجعة اليدوية أو فحص المستودع ضرورية.
03المشاريع التي تتعامل مع مدفوعات أو بيانات حساسة تحتاج مراجعة مختص قبل الإطلاق.

أسئلة شائعة

هل يكفي أن أطلب من الأداة «اجعل المشروع آمناً»؟

لا. الطلب العام ينتج تعديلات عامة. اطلب بنوداً محددة قابلة للتحقق مثل: فعّل RLS على كل جدول واذكر السياسات، وانقل أي مفتاح سري إلى الخادم.

هل يعمل المنهج مع أي أداة؟

نعم. المبادئ واحدة؛ يختلف فقط مكان ملف القواعد: Knowledge في Lovable، وCLAUDE.md في Claude Code، و.cursorrules أو AGENTS.md في Cursor وCodex.