هل اكتشفت يومًا أثناء عملية تطوير Vibe Coding أن الكود الذي ينتجه الذكاء الاصطناعي مليء بالفجوات المنطقية، مما يجعلك تشك في حياتك أثناء إصلاحه؟
في التطوير التقليدي، المواصفات (Spec) هي العدالة. لكن عند التعاون مع الذكاء الاصطناعي، نكون أشبه بـ “المخرجين”.
لجعل ذلك الممثل الذكي ولكن “المجنون” أحيانًا يقدم عرضًا جيدًا، تحتاج إلى أداتين قويتين: EARS (منطق النص) و BDD (لقطات القبول).
EARS: تحويل المتطلبات إلى “كتل منطقية”
لا بد أنك قابلت هذا النوع من مديري المشاريع، يكتبون متطلبات مثل: “يجب أن يكون النظام أسهل في الاستخدام”، “يجب أن تكون سرعة المعالجة سريعة”. هذه كارثة عند كتابة الكود.
EARS (Easy Approach to Requirements Syntax) ببساطة هو تحويل هذه “الصفات الغامضة” إلى “تعليمات دقيقة”.
EARS تشبه هندسة الأوامر (Prompt Engineering) من الدرجة الأولى، تجبرك على التحدث بمنطق مغلق. تتيح لك أنماط الجمل الخمسة الرئيسية “قفل” حدود المتطلبات في أي وقت:
| النوع | الوصف |
|---|---|
| Ubiquitous (شامل) | يجب أن يقوم النظام بـ... (مثل التنفس، يجب الالتزام به في جميع الأوقات). |
| Event-driven (مبني على الحدث) | عندما [يحدث حدث]، يجب أن يقوم النظام بـ.... |
| Unwanted Behavior (سلوك غير مرغوب فيه) | إذا [حدث شيء سيء]، يجب أن يقوم النظام بـ... (هذه هي روح معالجة الأخطاء). |
| State-driven (مبني على الحالة) | بينما [في حالة معينة]، يجب أن يقوم النظام بـ.... |
| Optional Feature (ميزة اختيارية) | حيث [يتم تضمين الميزة]، يجب أن يقوم النظام بـ.... |
تساعدك EARS على وضع قواعد صارمة
مما يجعل من المستحيل منطقيًا على الذكاء الاصطناعي “التحدث بهراء بوجه جاد”.
BDD: تحويل الاختبارات إلى “نصوص أفلام”
إذا كانت EARS عقدًا صارمًا، فإن BDD (Behavior Driven Development) هي “قصة من لحم ودم”. إنها لا تختبر a == b، بل تختبر “ما يشعر المستخدم أنه قد حدث”.
تسمى الصيغة المستخدمة بواسطة BDD بـ Gherkin (مخلل، يجب أن يكون مقرمشًا ومنعشًا!)، والثلاثية الأساسية هي كما يلي:
| الصيغة | الوصف |
|---|---|
| 🎬 Given (الخلفية) | إعداد المشهد قبل التصوير (مثال: وجود 100 دولار في الجيب). |
| ⚡ When (الحركة) | اللحظة التي يصرخ فيها المخرج Action (مثال: طلب حبار حار). |
| ✅ Then (النتيجة) | النهاية التي يراها الجمهور (مثال: استلام حبار عطري، المحفظة بها 60 دولارًا أقل). |
من خلال طريقة “سرد القصص” هذه، حتى غير المهندسين يمكنهم التواصل معنا، ويمكن للذكاء الاصطناعي أيضًا فهم نيتك الحقيقية من خلال هذه “الأمثلة الحقيقية”.
ما هو الفرق بين EARS مقابل BDD؟
كلاهما يؤدي واجباته الخاصة، والجمع بينهما يجعلهما “لا يقهران” حقًا.
| الميزة | EARS (صيغة المتطلبات) | BDD (مبني على السلوك) |
|---|---|---|
| الروح الأساسية | تعريف دقيق (إزالة الغموض) | التوافق والتحقق (سرد القصص) |
| مثل كتابة… | بنود قانونية | نصوص أفلام |
| الجمهور الرئيسي | مدير المشروع، المهندس المعماري، واضع القواعد | المهندس، ضمان الجودة، مساعد الذكاء الاصطناعي |
| نقطة الألم التي تم حلها | “ما فعلته ليس ما كنت أفكر فيه!” | “المنطق صحيح، لكنه غير قابل للاستخدام!” |
ببساطة: تساعدك EARS على وضع القواعد، وتساعدك BDD على التحقق من النتائج.
تطبيق EARS المتقدم: Vibe Coding في العمل
نقوم بحشو قواعد EARS ونصوص BDD مباشرة في الـ Prompt ليقوم الذكاء الاصطناعي بالتطوير.
يمكنك محاولة إعطاء تعليمات مثل هذه عند تطوير “خصم المحفظة الإلكترونية”:
# المهمة: يرجى مساعدتي في تنفيذ API الخصم
## منطق EARS (يرجى الالتزام بصرامة):
- [Event-driven]: عند استلام طلب، يجب التحقق من الرصيد.
- [Unwanted]: إذا كان الرصيد غير كافٍ، قم بإرجاع رمز الخطأ 400 'INSUFFICIENT_FUNDS'.
- [State-driven]: بينما المحفظة في حالة 'Frozen'، ارفض جميع الخصومات.
## نص قبول BDD (لاختبارات Jest):
Scenario: فشل الخصم بسبب عدم كفاية الأموال
Given رصيد المستخدم هو 50 دولارًا
When تم استلام طلب لخصم 100 دولار
Then يجب أن يرجع API الرمز HTTP 400
And يجب أن يكون رمز الخطأ 'INSUFFICIENT_FUNDS'
حاول رمي هذا للذكاء الاصطناعي، ولن ينحرف الكود الناتج كثيرًا عن الهدف!
الخاتمة
سواء في التطوير اليومي أو Vibe Coding، فإن EARS و BDD هي أدوات لتحسين الكفاءة.
تساعدك EARS على وضع قواعد صارمة، وتساعدك BDD على تأكيد نتائج الأداء.