يبدأ شرح AI2sql بالعربي من مهمة واضحة: تحويل سؤال عن بياناتك إلى استعلام SQL تستطيع فهمه والتحقق من نتيجته. بدل كتابة «اعرض أفضل العملاء» فقط، تحتاج إلى تحديد معنى الأفضل، وحالة الطلبات، والفترة الزمنية، والجداول التي تحتوي المعلومات. الأداة تساعدك في الصياغة والشرح والإصلاح، لكن تعريف المقياس ومراجعة الرقم يظلان مسؤوليتك. ولتحديد الأداة الأنسب لمهمتك، راجع مقارنة AI2sql وSQLAI.ai وBlazeSQL لكتابة SQL بالذكاء الاصطناعي.
سنستخدم مثالًا تدريبيًا لعرض أعلى ثلاثة عملاء بحسب قيمة الطلبات المدفوعة في أكتوبر، ثم نراجع الكود والحالات التي قد تعطي نتيجة مضللة. يعتمد وصف وظائف المنتج على صفحاته الرسمية، وليس على تجربة شخصية لحساب مدفوع. الكود والبيانات الصغيرة في الدليل أمثلة تعليمية من إعدادنا، وقد تختلف تسميات الواجهة وفق تحديث الخدمة.
ما هي AI2sql وما الفرق بينها وبين محرر SQL؟
تعرض AI2sql أدوات لكتابة الاستعلامات من وصف بلغة طبيعية، وشرح SQL الموجود، وإصلاح الأخطاء، واقتراح تحسينات. ويمكن أن تستفيد من مخطط قاعدة البيانات حتى تستخدم أسماء جداولك وأعمدتك. أما محرر SQL التقليدي فهو المكان الذي تكتب فيه الكود وتشغله؛ وجود مساعد ذكي لا يلغي الحاجة إلى فهم ما سيُنفذ.
قد تستخدم الخدمة لمراجعة استعلام تنسخه إلى بيئتك، أو تتعامل مع اتصال حي تدعمه الخطة. هذان مساران مختلفان. الأول لا يحتاج بالضرورة إلى تسليم بيانات دخول القاعدة، والثاني يضيف أسئلة عن الصلاحيات والشبكة ونوع المحرك ومكان معالجة النتائج. اختر المسار الأبسط الذي يحقق المهمة.
هل تحتاج إلى معرفة SQL قبل البدء؟
تستطيع تجربة الطلب باللغة العربية أو الإنجليزية، لكن من المفيد أن تفهم SELECT لاختيار الأعمدة، وWHERE للتصفية، وGROUP BY للتجميع، وJOIN للربط. لا تحتاج إلى حفظ الصياغة كاملة حتى تبدأ، إلا أنك تحتاج إلى التمييز بين عدد الصفوف وعدد العملاء، وبين المبيعات المسجلة والأرباح.
المبتدئ يستفيد أكثر عندما يسأل «لماذا استخدمت هذا الشرط؟» بعد كل استعلام. إذا لم تستطع شرح كيف حُسب الرقم، استخدم المثال كتمرين تعليم لا كتقرير ترسله إلى عميل. الجواب الواثق لغويًا لا يثبت أن البيانات أو الافتراضات صحيحة.
قبل فتح الأداة: جهّز وصف القاعدة
اكتب اسم محركك وإصداره إن كان معروفًا، ثم أسماء الجداول والأعمدة وأنواعها. في مثالنا نستخدم جدول orders، ويضم id لمعرف الطلب، وcustomer_id لمعرف العميل، وstatus للحالة، وtotal لقيمة الطلب، وcreated_at لتاريخ الإنشاء. جميع المبالغ بعملة واحدة، وكل صف يمثل طلبًا كاملًا.
حدد كذلك قيم الحالات كما هي داخل القاعدة، لا كما تظهر في الواجهة العربية للمتجر. قد تعني «مكتمل» delivered في نظام وpaid في آخر، وقد يوجد تاريخ مستقل للدفع. في التمرين نعتمد created_at كما هو معرف، ولا نزعم أنه يمثل تاريخ التحصيل في أي متجر حقيقي.
| العنصر | ما نعتمده في التدريب | سبب تحديده |
|---|---|---|
| المحرك | PostgreSQL للاستعلام المعروض | منع خلط الصياغة بين المحركات |
| مستوى الصف | طلب واحد في كل صف | تجنب جمع قيمة الطلب عدة مرات |
| الحالة المقبولة | paid فقط | استبعاد pending وcancelled |
| الفترة | أكتوبر: من 1 أكتوبر إلى ما قبل 1 نوفمبر | إظهار حدود التاريخ بوضوح |
| المقياس | مجموع total وعدد الطلبات لكل عميل | عدم الخلط مع الربح أو عدد بنود السلة |
الخطوة الأولى: الحساب والخطة المناسبة
افتح الموقع الرسمي وانتقل إلى بدء الاستخدام أو تسجيل الدخول، ثم راجع الخطة المعروضة في حسابك. لا يلزمك ربط قاعدة الإنتاج لتقييم جودة صياغة طلب بسيط؛ ابدأ بقاعدة العرض أو مخطط تدريبي وفق الخيارات المتاحة. تجنب إدخال كلمة مرور قاعدة البيانات داخل خانة السؤال.
تعرض صفحة خطط AI2sql اشتراكات Start وPro وTeam، مع فصل بين المساعدة في الكتابة وبعض وظائف الاتصال والتنفيذ والعمل الجماعي. وتعرض تجربة للخطط المدفوعة تتطلب بطاقة. وجود بداية مجانية لا يعني أن كل المزايا متاحة دون اشتراك، ولا أن الضغط على تجربة لا يتبعه تجديد.
توجد فروق في بعض حدود الاستخدام بين صفحة الخطط وتوثيق التكامل؛ لذلك لا نبني الدليل على رقم ثابت لعدد الطلبات المجانية. اقرأ الرصيد ونوع الاتصال والتجديد داخل حسابك قبل الاشتراك. إذا كنت تحتاج توليد SQL فقط، فلا تدفع مقابل مسار فريق أو تنفيذ حي دون حاجة فعلية إليه.
الخطوة الثانية: اختر المحرك والمخطط
حدد PostgreSQL إذا كنت ستطبق الاستعلام التالي على هذا المحرك. ثم أرفق مخطط جدول التدريب بالطريقة التي يتيحها حسابك، أو استخدم الاتصال التجريبي المناسب. إن كانت الخدمة تعرض جداول كثيرة، احصر سياق السؤال في الجدول اللازم بدل مطالبتها بتخمين جدول المبيعات الصحيح بين نسخ قديمة ونسخ أرشيفية.
إذا أردت اتصالًا حقيقيًا، اجعل مسؤول القاعدة ينشئ مستخدمًا للقراءة فقط بحدود واضحة، وحدد الجداول المسموح بها. لا تعالج فشل الاتصال بفتح الخادم لجميع العناوين أو استخدام حساب المدير. الاختبار الأول هدفه التأكد من المخطط والصلاحية، لا توسيع الوصول حتى يختفي الخطأ.
الخطوة الثالثة: اكتب طلبًا يمنع التخمين
اكتب استعلام PostgreSQL من جدول orders. أريد أعلى 3 عملاء بحسب مجموع total للطلبات التي status فيها paid فقط. الفترة من 2026-10-01 شاملًا إلى 2026-11-01 غير شامل وفق created_at. أعرض customer_id وعدد الطلبات والمجموع، ورتب تنازليًا حسب المجموع ثم تصاعديًا حسب customer_id عند التعادل. لا تضف جداول أو خصومات أو تحويل عملات. أعطني الاستعلام واشرح افتراضاته.
هذا الطلب أفضل من «أفضل العملاء هذا الشهر» لأنه يثبت الفترة ومعنى الأفضل والتعامل مع التعادل. لا تحتاج إلى إطالة كل سؤال بهذا الشكل دائمًا؛ لكنك تحتاج إلى التعريفات نفسها في مصدر موثوق يمكن للمساعد الرجوع إليه، خصوصًا في التقارير المتكررة.
عندما تكون أسماء الأعمدة بالإنجليزية، أبقها مطابقة للمخطط داخل طلبك العربي. إذا احتجت إلى اسم مقروء في التقرير، اطلب تسمية عرض واضحة بعد تثبيت الحساب. لا تجعل الأداة تستبدل اسم عمود حقيقي بترجمة عربية لا توجد في القاعدة.
مثال SQL يمكن مراجعته
الاستعلام التالي نموذج تعليمي يحقق تعريف التمرين، وليس لقطة من حساب AI2sql أو ضمانًا بأن الخدمة ستنتج النص نفسه. يفترض أن created_at تاريخ أو طابع زمني مناسب، وأن total قيمة رقمية معروفة وغير فارغة للطلبات المدفوعة، وأن الأعمدة بالأسماء المذكورة:
SELECT
customer_id,
COUNT(*) AS paid_order_count,
SUM(total) AS paid_total
FROM orders
WHERE status = 'paid'
AND created_at >= '2026-10-01'
AND created_at < '2026-11-01'
GROUP BY customer_id
ORDER BY paid_total DESC, customer_id
LIMIT 3;يختار WHERE الطلبات المدفوعة داخل الفترة قبل التجميع. ثم يجمع GROUP BY طلبات كل عميل، ويحسب COUNT(*) عدد الطلبات وSUM(total) قيمتها. يحدد ORDER BY ترتيب العملاء، ثم يعرض LIMIT ثلاثة صفوف فقط. الشرط الأخير على customer_id يجعل ترتيب المتعادلين ثابتًا في هذا المثال.
استخدام الحد الأدنى الشامل والحد الأعلى المستبعد يساعد على تمثيل الشهر دون تخمين آخر ثانية منه. لكنه لا يحل وحده اختلاف المناطق الزمنية. إذا كان العمود يخزن UTC والتقرير يعتمد توقيتًا محليًا، حدد حدود الفترة المناسبة مع مسؤول البيانات قبل المقارنة.
الخطوة الرابعة: تحقق من الناتج على بيانات معروفة
استخدم سبعة طلبات تدريبية: للعميل 1 طلبان مدفوعان بقيمتي 100 و60 في أكتوبر؛ وللعميل 2 طلب مدفوع بقيمة 90 وآخر ملغى بقيمة 200 في أكتوبر؛ وللعميل 3 طلب مدفوع بقيمة 50 وآخر معلق بقيمة 70 في أكتوبر، وطلب مدفوع بقيمة 40 يوم 1 نوفمبر.
| customer_id | عدد الطلبات المقبولة | المجموع المتوقع |
|---|---|---|
| 1 | 2 | 160 |
| 2 | 1 | 90 |
| 3 | 1 | 50 |
يجب أن يكون مجموع القيم المعروضة 300 وعدد الطلبات أربعة. لا تدخل قيمة 40 لأنها خارج الفترة، ولا 200 أو70 لأن حالتهما غير مقبولة. إن اختلفت النتيجة، افتح الصفوف الأصلية التي دخلت الحساب بدل مطالبة المساعد بإعادة الشرح بصياغة أكثر ثقة.
أضف حالة اختبار عند أول لحظة من نوفمبر، وحالة عند بداية أكتوبر، وتأكد من دخول الثانية واستبعاد الأولى. جرّب عميلين متساويين في المجموع لتفحص ترتيب التعادل. هذه الحالات الصغيرة تكشف أخطاء قد تخفيها عينة عشوائية كبيرة يصعب جمعها يدويًا.
ماذا تفعل إذا ظهر خطأ؟
العمود أو الجدول غير موجود
قارن الاسم بالمخطط أولًا، بما في ذلك المخطط الفرعي وحالة الحروف عند استعمال أسماء مقتبسة. أرسل رسالة الخطأ بعد إزالة أي أسرار، وأرفق تعريف الأعمدة اللازمة. لا تطلب من الأداة اختراع عمود بديل لمجرد جعل الاستعلام يعمل؛ قد يكون مصدر البيانات الصحيح مختلفًا.
الاستعلام يعمل والمجموع خاطئ
راجع الحالة والفترة ومستوى الصف. إذا ربطت الطلبات بجدول order_items لاحقًا، فقد تتكرر قيمة الطلب مرة لكل بند. ولا تصلح المشكلة باستخدام SUM(DISTINCT total) تلقائيًا، لأن طلبين صحيحين قد يحملان القيمة نفسها. المطلوب تصميم تجميع يحافظ على هوية الطلب.
الاستعلام بطيء أو يخرج نتائج ناقصة
اطلب تفسيرًا للاستعلام أولًا، ثم راجع حجم البيانات وخطة التنفيذ مع شخص يعرف القاعدة. لا تعتبر LIMIT ضمانًا بأن المحرك لن يفحص بيانات كثيرة، خصوصًا مع التجميع والترتيب. وإذا كانت واجهة التنفيذ تقطع الصفوف عند حد معين، فلا تستخدم مجموع الصفوف المعروضة بديلًا عن تجميع كامل داخل القاعدة.
الشرح والإصلاح والتحسين: ثلاث مراجعات مختلفة
في الشرح، اطلب وظيفة كل شرط وما الذي سيحدث عند حذفه. وفي الإصلاح، أرسل الكود ورسالة الخطأ والمحرك. وفي التحسين، حافظ على تعريف النتيجة واطلب توضيح ما تغير. إعادة كتابة أسرع ظاهريًا قد تغيّر تعامل NULL أو العملاء بلا طلبات، فتنتج تقريرًا مختلفًا.
قبل اقتراح فهرس أو تغيير بنية قاعدة حقيقية، راجع أثره على القراءة والكتابة ومساحة التخزين. التعلم على قاعدة صغيرة لا يثبت أداء الاستعلام على ملايين الصفوف. احفظ الكود الأصلي ونتائجه المرجعية، ثم قارن أي نسخة معدلة بنفس الشروط والبيانات.
ماذا عن ربط AI2sql بمساعد عبر MCP؟
يوضح توثيق AI2sql للتكامل عبر MCP مسارًا يتيح للمساعد التعرف إلى الاتصالات والمخطط وتوليد SQL، مع تنفيذ للقراءة على اتصالات مدعومة وفق الخطة. وهذا مختلف عن نسخ نص استعلام بين نافذتين، لأن المساعد قد يستقبل نتائج من قاعدة مرتبطة.
إذا كان عملك داخل محرر، يمكن الرجوع إلى شرح Cursor للمبتدئين لفهم مراجعة المشروع والتغييرات. أما إعداد عميل MCP نفسه وصلاحياته فيعتمدان على التطبيق الذي تستخدمه؛ لا تفترض أن إضافة الخادم تمنح تلقائيًا وصولًا مناسبًا لجميع قواعدك.
ابدأ باتصال تدريبي واطلب وصف جدول واحد قبل سؤال تحليلي. راجع ما يستطيع المساعد رؤيته، وكيفية فصل الاتصال، وما إذا كانت الخطة تشمل إخفاء القيم الحساسة. وجود حارس للقراءة لا يعالج وحده حقولًا لا ينبغي أن تدخل المحادثة أصلًا.
هل تستحق AI2sql الاستخدام في مشروعك؟
تستحق التقييم إذا كنت تكرر كتابة SQL وتحتاج مساعدة في الانتقال من السؤال إلى كود قابل للفهم. وقد لا تحتاج إلى اشتراك إضافي إذا كانت استعلاماتك قليلة ومخططك بسيطًا ومساعدك الحالي يفي بالغرض. احسب الوقت الذي توفره بعد المراجعة، لا وقت ظهور أول إجابة فقط.
ابدأ بطلب تدريبي تعرف مجموعه، وتأكد من فهم الحالة والفترة والتجميع، ثم وسّع المثال تدريجيًا. عندما يصبح الاستعلام جزءًا من تطبيق، ضعه ضمن مراجعة الكود واختباراته المناسبة. بهذه الطريقة تستخدم AI2sql لتسريع العمل دون تحويل إجابة مولّدة إلى مصدر حقيقة غير قابل للتدقيق.
