19 ديسمبر 2025·6 دقيقة
شرح Vibe Coding: سير العمل وثلاثة أمثلة عملية للبناء
تعرف على مفهوم vibe coding، كيف يعمل سير العمل بخطوات بسيطة، وشاهد 3 أمثلة عملية (تطبيق ويب، API، وتطبيق موبايل) يمكنك تكرارها.
تعرف على مفهوم vibe coding، كيف يعمل سير العمل بخطوات بسيطة، وشاهد 3 أمثلة عملية (تطبيق ويب، API، وتطبيق موبايل) يمكنك تكرارها.
vibe coding هو بناء البرمجيات بوصف ما تريده للذكاء الاصطناعي بلغة عادية، ثم التكرار على النتيجة حتى تعمل بالشكل الذي تتوقعه.
الهدف بسيط: الوصول إلى شاشات وواجهات API وميزات تعمل بشكل أسرع عن طريق وصف النية بدلاً من البدء من ملف شيفرة فارغ. تصف ما يجب أن يفعله التطبيق، وما البيانات التي يستخدمها، ومعنى "الانتهاء". يحول الذكاء الاصطناعي ذلك إلى شيفرة وبنية مشروع، وأنت توجهه بملاحظات مثل "اجعل تسجيل الدخول أبسط" أو "خزن الطلبات مع حالة وطوابع زمنية".
فكّر فيه كأنك تُخرِج توجيهات لمطور مبتدئ سريع للغاية. يمكنه كتابة الكثير من الشيفرة بسرعة، لكنه لا يزال بحاجة لتعليمات واضحة وتصحيحات عرضية. على منصة مثل Koder.ai، الدردشة هي واجهة العمل الرئيسية: تصف التطبيق، فيولّد واجهة React، وواجهة خلفية Go، وإعداد PostgreSQL عند الحاجة. بعد ذلك يمكنك مراجعة التغييرات، التراجع إذا حدث خطأ، وتصدير الشيفرة المصدرية عندما تريد التحكم الكامل.
بعض القواعد البسيطة تساعد على ضبط التوقعات:
vibe coding يساعد عادة نوعين من الناس أكثر: البناة غير التقنيين الذين لديهم فكرة واضحة ولا يريدون تعلم حزمة تطوير كاملة أولًا، والفرق المشغولة التي تريد مسارًا أسرع من الفكرة إلى نموذج عملي أو أداة داخلية. إذا استطعت شرح ما تريده بجمل بسيطة، يمكنك البدء.
vibe coding حلقة. تصف ما تريد، يولّد النظام المشروع والشيفرة، تشغّله لترى ما حدث، ثم تعدّل الطلب حتى يطابق فكرتك. يتحوّل العمل من كتابة كل سطر إلى اتخاذ قرارات واضحة وإعطاء ملاحظات جيدة.
ابدأ بأصغر شريحة مفيدة، لا بالمنتج الحلمي كاملًا. قل ما هو الغرض من التطبيق، من يستخدمه، وما معنى "الانتهاء".
طريقة بسيطة للصياغة: "ابنِ X لـ Y، يجب أن يفعل A وB، ولا يجب أن يفعل C." البشر يقودون هذه الخطوة. أنت تختار الميزات، القواعد، وما يهم أولًا.
النظام ينشئ الأجزاء المملة نيابةً عنك: إعداد المشروع، التوجيهات (routing)، ربط قاعدة البيانات، واجهة المستخدم الأساسية، وأول نسخة من المنطق.
مع أداة vibe-coding مثل Koder.ai، قد يبدو الأمر كأنك تدردش عبر خطوات كانت تستغرق ساعات من الإعداد والـboilerplate.
اطلب البنية بكلمات عادية: "أنشئ ثلاث شاشات"، "أضف تسجيل دخول"، "خزن العناصر في جدول PostgreSQL"، أو "عرض نقطة نهاية تُرجع JSON". لا تلاحق الشيفرة المثالية في المحاولة الأولى. هدفك مسودة عاملة يمكنك لمسها.
لا تقرأ مخرجات الدردشة فحسب. شغّل التطبيق وابحث عن إشارات حقيقية.
ابدأ بما يلاحظه المستخدمون أولًا (هل تبدو الشاشات صحيحة وتتصرف بشكل مناسب؟)، ثم تحقق من الأجزاء الأقل وضوحًا (هل تُحفظ البيانات وتُحمَّل بشكل صحيح؟). بعد ذلك، جرّب بعض حالات الحافة: المدخلات الفارغة، المكررات، والقيم السيئة بوضوح.
إذا كان لديك وقت، أضف بضعة اختبارات بسيطة للقواعد التي تهتم بها أكثر حتى لا تنهار بهدوء لاحقًا.
الآن رد كما لو كنت مالك منتج ومراجع. قل ما الخطأ، ما الذي يجب تغييره، وما الذي يجب الاحتفاظ به. كن محددًا: "احتفظ بالتخطيط، لكن انقل الزر إلى الرأس"، أو "ارفض المبالغ السالبة بخطأ 400."
بعد عدة دورات، ستحصل على شيء يطابق نيتك، وليس مجرد كومة من الشيفرة المولّدة. السرعة هي "vibe"، لكن الجودة تأتي من اختياراتك ومراجعتك.
vibe coding ينجح عندما يكون الهدف واضحًا بما يكفي ليُوصَف بلغة بسيطة، وتكون تكلفة أن تكون "قريبًا من الصحيح" منخفضة. تريد تغذية راجعة سريعة، وليس نظامًا مثاليًا من المحاولة الأولى. إذا استطعت أن تشير إلى النتيجة وتقول "نعم، هذا هو" أو "غيّر هذا الجزء"، فأنت في المنطقة المناسبة.
الملاءمة الجيدة هي أي شيء حيث تهم السرعة أكثر من التخطيط الطويل. على سبيل المثال، قد يحتاج فريق صغير إلى لوحة داخلية لمراجعة مكالمات المبيعات. يمكنك وصف الشاشات، الحقول، وبعض القواعد، ثم التكرار حتى تتطابق مع طريقة عمل الفريق.
غالبًا ما يتألق في النماذج الأولية، الأدوات الداخلية (لوحات، لوحات إدارة، أتمتة بسيطة)، وMVPs ضيقة النطاق بتدفقات معيارية مثل تسجيل الدخول وCRUD. يمكن أن يعمل جيدًا أيضًا لتطبيقات "الربط" التي توصل بين بعض الخدمات، لأنك تستطيع تعريف المدخلات والمخرجات والتحقق منها بسرعة.
يصبح أصعب عندما تكون المتطلبات صارمة، عميقة، أو مليئة بالاستثناءات. ذلك يشمل قواعد الامتثال المعقدة، تحسين الأداء الشديد، والأنظمة القديمة الكبيرة. لا يزال بإمكانك استخدام vibe coding هناك، لكن العمل يتحول إلى مواصفات دقيقة، مراجعات شديدة، واختبارات، وليس مجرد دردشة.
طريقة عملية للقرار: ابدأ صغيرًا وتوسّع فقط إذا ظل الناتج متوقعًا. ابنِ شريحة رفيعة واحدة من البداية للنهاية (شاشة واحدة، مسار API واحد، جدول بيانات واحد). إذا اجتمعت تلك الشريحة بسلاسة، أضف الشريحة التالية.
علامات تدل على أنه يجب التمهّل وتوضيح الخطة:
إذا رأيت هذه العلامات، توقف واكتب قواعد أوضح، أمثلة مدخلات/مخرجات، وبضعة اختبارات "يجب أن تجتاز". على منصات مثل Koder.ai، وضع التخطيط واللقطات يساعدانك على التكرار دون فقدان نسخة عاملة.
vibe coding الجيد يبدأ قبل كتابة رسالتك الأولى. إذا كانت مطالبتك غامضة، سيكون البناء غامضًا. إذا كانت مطالبك محددة، يمكن للذكاء الاصطناعي أن يتخذ خيارات صلبة وتقضي وقتك في المراجعة بدل إعادة الكتابة.
ابدأ بموجز مشروع قصير تلصقه في الدردشة. اجعله ملموسًا: الهدف (جملة واحدة)، من المستخدمون، الشاشات القليلة التي تتوقعها، البيانات الرئيسية التي تخزنها (والحقول المهمة)، وأي قيود صارمة (ملاءمة للموبايل، تواريخ UTC، الوضع الداكن، إلخ).
بعدها وصف الميزات بأمثلة، لا بشعارات. "يمكن للمستخدمين إدارة المهام" غامض. "يمكن للمستخدم إنشاء مهمة بعنوان، تاريخ استحقاق، وأولوية؛ وضع علامة منجزة؛ وفرز حسب الحالة" يعطي الذكاء الاصطناعي شيئًا يمكن اختباره.
إذا أردت شيفرة قابلة للصيانة، اطلب بنية بسيطة من البداية: ما الصفحات، ما الجداول، وما نقاط الـAPI التي تربطها. لست بحاجة لأن تكون تقنيًا لتطلب هذا. الكلمات العادية تكفي.
إليك مطالبة يمكنك تكييفها (تعمل جيدًا في أدوات مثل منصة Koder.ai):
Build a small web app called “Team Tasks”.
Users: Admin, Member.
Goal: track tasks for a small team.
Screens:
1) Login
2) Task list (filter: All, Open, Done)
3) Task details
4) Admin: Users list
Data:
Task(id, title, description, status, due_date, created_by, assigned_to)
User(id, name, email, role)
Rules:
- Members can only edit tasks they created.
- Admin can view and edit everything.
Please propose:
- Pages/components
- Database tables
- API endpoints (CRUD)
Then generate the first working version.
للحفاظ على نطاق الإصدار الأول تحت السيطرة، حدّده بقائمة ميزات قصيرة. سطر مفيد لإضافته: "إذا كان هناك أي غموض، اسأل حتى 5 أسئلة قبل البناء." هذا يقلل التخمين ويمنع ميزات مفاجئة لم تطلبها.
إيقاع بسيط يعمل في معظم البنايات:
ابدأ بموجز فقرة واحدة: لمن، العمل الأساسي الذي يؤديه، وما معنى "الانتهاء". أضف اثنين أو ثلاثة من الضروريات واثنين أو ثلاثة من الرفاهيات، ثم توقف. الكثير من التفاصيل مبكرًا يخلق عادةً ارتباكًا.
بعد ذلك، اطلب أصغر نسخة قابلة للتشغيل: تدفق أساسي واحد من البداية للنهاية، حتى لو بدا بسيطًا. لتطبيق حجز، قد تكون صفحة قائمة الخدمات، صفحة اختيار وقت، وشاشة تأكيد مع حفظ الحجز.
اختبر مسار السعيد أولًا، ثم وسّع ببطء. املأ المسار الرئيسي ثم صحّح ما يحجبه فقط. بعد ذلك، أضف حالة حافة واحدة في كل مرة: منع الحجز المزدوج، التعامل مع المناطق الزمنية، الحقول المفقودة، الأيام المغلقة.
عندما يعمل شيء، احفظ نقطة تفتيش (لقطة، علامة، أو أي ما يدعمه أداتك) حتى تتمكن من التراجع إذا كسر التغيير التالي الأمور. هنا حيث تصبح أدوات مثل Koder.ai مفيدة عمليًا: اللقطات والتراجع تجعل التجربة منخفضة المخاطر.
أخيرًا، قم بالتلميع قبل إضافة ميزات بكثرة. رسائل التحقق الواضحة، حالات التحميل، أخطاء لطيفة، وتعيينات افتراضية منطقية هي ما يجعل التطبيق يبدو حقيقيًا.
تخيل متتبع مهام صغير تستخدمه على الحاسوب المحمول: تسجّل الدخول، ترى قائمتك، تضيف مهمة، تعدّلها، وتحذفها عند الانتهاء. في vibe coding، تبدأ بوصف هذا التدفق بجمل بسيطة، ثم تطلب من البنّاء تحويله إلى شاشات وبيانات عاملة.
ابدأ بالصفحات والإجراءات، لا بالتقنية. على سبيل المثال: صفحة تسجيل الدخول (بريد إلكتروني + كلمة مرور، تسجيل خروج)، صفحة المهام (عرض المهام، إنشاء، تعديل، حذف)، وربما عرض تفاصيل المهمة (ملاحظات، تاريخ استحقاق، حالة) وشاشة إعدادات أساسية.
بعدها، صف البيانات بمصطلحات بشرية. بدل "صمّم مخططًا"، قل ما يجب أن يخزنه العنصر: عنوان، ملاحظات اختيارية، حالة (todo/doing/done)، تاريخ استحقاق اختياري، وطوابع زمنية للإنشاء والتحديث. كذلك أشر إلى أن المهام تابعة لمستخدم.
إذا كنت تستخدم منصة vibe-coding مثل Koder.ai، اطلب نسخة أولى صغيرة تعمل من البداية للنهاية: شاشات React، واجهة خلفية Go، وقاعدة بيانات PostgreSQL بالحقول التي وصفتها. اجعل المحاولة الأولى ضيقة: تسجيل دخول، عرض المهام، إضافة مهمة. عندما يعمل ذلك، كرّر.
إيقاع عملي هو "اجعله يعمل، ثم اجعله أجمل." تسلسل واقعي:
كل جولة هي طلب دردشة آخر يبني على الموجود. المفتاح أن تكون محددًا بشأن التغيير وما يجب ألا ينكسر.
حتى لتطبيق ويب صغير، بعض التفاصيل تقرر ما إذا كان يبدو متينًا:
طلب تكرار جيد يبدو هكذا: "أضف فلتر حالة بعلامات تبويب (الكل، ToDo، Doing، Done). احتفظ بقاعدة البيانات كما هي. حدّث الـAPI حتى يدعم الفلترة حسب الحالة، وأظهر حالة تحميل عند تبديل التبويبات." قصير، قابل للاختبار، وصعب الفهم خطأ.
الـAPI من أسهل الأماكن لاستخدام vibe coding لأن العمل فيه في الأساس قواعد: ما البيانات التي تخزنها، ما الأفعال المسموح بها، وما الشكل الذي تُعاد به الاستجابات.
تخيل نظام متجر صغير به عنصران: العملاء والطلبات. جملتك يمكن أن تكون بسيطة مثل: "العملاء لديهم الاسم والبريد الإلكتروني. الطلبات تنتمي إلى عميل، وتحتوي عناصر، والسعر الإجمالي، وحالة مثل draft -> paid -> shipped." هذا يكفي للبدء.
اجعله ملموسًا: ما الذي يمكنك فعله، ما الذي يجب إرساله، وما الذي تحصل عليه بالرد.
يمكنك رسم الأساسيات (إنشاء، قائمة، استرجاع واحد، تحديث، حذف) للعملاء والطلبات، ثم إضافة بعض الفلاتر التي ستحتاجها (مثلاً: قائمة الطلبات حسب customer_id وstatus). بعد ذلك، عرّف كيف يجب أن تتعامل الأخطاء "غير موجود"، "مدخلات سيئة"، و"غير مسموح"، وأي نقاط تتطلب تسجيل دخول.
ثم أضف قواعد المدخلات واستجابات الأخطاء. أمثلة قواعد: يجب أن يكون البريد الإلكتروني صالحًا وفريدًا؛ عناصر الطلب يجب أن تكون على الأقل 1؛ يجب أن يطابق الإجمالي مجموع العناصر؛ يمكن للحالة أن تنتقل فقط للأمام (draft -> paid -> shipped).
إذا اهتممت بالأمان الأساسي مبكرًا، اطلب توكن توثيق (Bearer token)، أدوار بسيطة (admin مقابل support)، وحدود معدل (مثلاً 60 طلبًا في الدقيقة لكل توكن). إذا كنت تستخدم Koder.ai، وضع التخطيط يمكن أن يساعدك على الاتفاق على هذه القواعد قبل توليد أي شيفرة.
لا تهدف للاختبار الشامل في البداية. تريد إثباتًا أن الـAPI يتصرف كما حددت.
# Create customer
curl -X POST http://localhost:8080/customers \\
-H "Authorization: Bearer <token>" \\
-H "Content-Type: application/json" \\
-d '{"name":"Mina Lee","email":"[email protected]"}'
# Expected: 201 + JSON with id, name, email
# Create order
curl -X POST http://localhost:8080/orders \\
-H "Authorization: Bearer <token>" \\
-H "Content-Type: application/json" \\
-d '{"customer_id":1,"items":[{"sku":"A1","qty":2,"price":12.50}]}'
# Expected: 201 + status "draft" + computed total 25.00
# Bad input example (invalid email)
# Expected: 400 + {"error":"invalid_email"}
إذا أعادت هذه الطلبات رموز الحالة والحقول الصحيحة، فلديك أساس يعمل. من هناك، كرّر: أضف ترقيم صفحات، فلترة أفضل، ورسائل خطأ أوضح قبل إضافة مزيد من الميزات.
مثال موبايل جيد هو متتبع عادات بسيط. التطبيقات المحمولة تبدو "صعبة" بسبب الشاشات الصغيرة، العمل دون اتصال، وميزات الجهاز. ستحصل على نتائج أفضل عندما تحدد تلك القيود قبل البناء الأول، وليس بعد ظهور الأخطاء.
ابدأ بتسمية التطبيق والشيء الوحيد الذي يجب أن يفعله في اليوم الأول: "تتبع العادات اليومية مع تسجيل سريع." ثم اذكر الشاشات التي تتوقعها. إبقاء القائمة صغيرة يساعد الذكاء الاصطناعي على اختيار بنية تنقل نظيفة.
نسخة أولى صلبة:
بعد ذلك، كن واضحًا حول العمل دون اتصال والمزامنة. العديد من التطبيقات تُستخدم بشبكة ضعيفة. إذا كنت تهتم بالعمل دون اتصال أولًا، قل ذلك: "يجب أن يعمل كل شيء دون اتصال. إذا سجّل المستخدم الدخول لاحقًا، قم بالمزامنة في الخلفية وحل التعارضات بالاحتفاظ بآخر تغيير." إذا لم تكن بحاجة للمزامنة بعد، اذكر ذلك أيضًا. إصدار محلي فقط غالبًا أسرع وأقل مخاطرة.
ثم أشر إلى ميزات الجهاز حتى لو لم تكن متأكدًا من استخدامها، لأن ذلك يغيّر بنية التطبيق: الإشعارات (تذكيرات يومية، معالجة المناطق الزمنية)، الكاميرا (مرفقات صور اختيارية)، الموقع (غالبًا غير مطلوب)، والقياسات الحيوية (إذا كانت الملاحظات حساسة).
للحفاظ على البساطة، اختر منصة واحدة أولًا ووسع لاحقًا. مثال: "ابنِ Android أولًا مع إشعارات أساسية. iOS لاحقًا." إذا كنت تستخدم Koder.ai، طلب تطبيق Flutter عملي لأنه يحافظ على قاعدة شيفرة واحدة أثناء استكشاف الفكرة.
مطالبة عملية تعمل عادةً بشكل جيد:
“Build a Flutter habit tracker app with 4 screens: Onboarding, Daily List, Add Habit, Stats. Offline first using local storage. No login for v1. Daily reminder notification at a user-chosen time. Keep the UI clean with a bottom nav. Generate sample data for testing.”
من هناك، كرّر بخطوات صغيرة: تحقق من التنقل، تحقق من سلوك العمل دون اتصال، أضف التذكيرات، ثم قم بتلميع الإحصاءات. الحلقات الصغيرة تغلب على إعادة الكتابة الكبيرة.
أسرع طريقة للحصول على قيمة من vibe coding هي معاملته كسلسلة من رهانات صغيرة قابلة للاختبار. معظم المشاكل تحدث عندما تقفز مباشرة إلى "منتج نهائي" دون تحديد ما يعنيه "عامِل".
سيناريو سريع: تبني تطبيق حجز. تطلب "تقويم ومدفوعات"، وتنتج الأداة شاشات، قاعدة بيانات، وموصل مدفوعات تجريبي. يبدو مكتملًا، لكنك لم تحدد ماذا يحدث عندما يمتلئ اليوم، متى تفشل البطاقة، أو إذا حاول المستخدم الحجز في الماضي. هذه الثغرات الصغيرة تصبح أخطاء كبيرة.
Vibe coding هو بناء البرمجيات بوصف ما تريده بلغة عادية، وترك الذكاء الاصطناعي ليولّد الشيفرة والبنية، ثم التكرار مع ملاحظات واضحة حتى يعمل بالشكل المطلوب.
أنت لا تزال مسؤولاً عن اتخاذ القرارات والمراجعة — الـ"vibe" هي السرعة، وليست التشغيل الآلي الكامل.
حلقة بسيطة تعمل بأفضل شكل:
هدفك نسخة "مسودة عاملة" أولاً، ثم التنقيح.
ابدأ بموجز صغير تضمنه في الدردشة:
لا تبدأ بالمنتج الكامل. ابدأ بشريحة رفيعة واحدة تعمل من البداية للنهاية:
مثال: "تسجيل دخول → عرض عناصر → إضافة عنصر." إذا كانت هذه الشريحة مستقرة، أضف الشريحة التالية. هذا يحافظ على التغييرات مفهومة ويقلل العِقد المتكررة.
قم بفحوصات سريعة وحقيقية بالترتيب التالي:
إذا كان شيء مهمًا، اطلب اختبارًا صغيرًا حتى لا يتراجع لاحقًا.
استخدم ملاحظات دقيقة وقابلة للاختبار. أمثلة جيدة:
تجنّب طلبات غامضة مثل "اجعلها عصرية" ما لم تضف أمثلة محددة (تباعد، ألوان، نصوص الأخطاء).
بطئ واكتب خطة أوضح إذا لاحظت أمورًا مثل:
في تلك الحالة، اكتب مواصفات قصيرة: أمثلة مدخلات/مخرجات، قواعد "يجب أن تجتاز"، و2–3 اختبارات رئيسية. ثم قم بتغيير واحد في كل مرة.
وضع التخطيط مفيد عندما تريد اتفاقًا قبل تغيّر الكود. اطلب:
عندما يتطابق هذا المخطط مع نيتك، ولّد النسخة الأولى القابلة للتشغيل وابدأ التكرار منها.
استخدم اللقطات كنقاط تفتيش بعد أن يعمل شيء ما (مثلاً بعد أن يكون تسجيل الدخول + القائمة + الإضافة ثابتًا). إذا كسر تغيير جديد شيئًا، ارجع إلى آخر لقطة جيدة وأعد تطبيق التغيير بشكل أضيق.
هذا يسمح لك بالتجربة دون فقدان نسخة عاملة.
صدّر عندما تريد التحكم الكامل في المشروع: تخصيص أعمق، أدوات مخصصة، مراجعات صارمة، أو الانتقال إلى خط تجريبي خاص بك.
نهج عملي: ابنِ وكرر بسرعة على المنصة، ثم صدّر عندما تصبح البنية والتدفقات الأساسية مستقرة.
ثم أضف: "إذا كان هناك أي غموض، اسأل حتى 5 أسئلة قبل البناء."