التطبيق العملي: خطوة بخطوة لتعليمك كيفية استخدام 7 وكلاء لترقية Vibe Coding إلى عملية تطوير احترافية

المؤلف @sairahul1 حلل ثورة تدفق العمل من «Vibe Coding» إلى «مصنع البرمجيات»: تقسيم الحوار الواحد مع الذكاء الاصطناعي إلى 7 وكلاء متخصصين: الباحث، كاتب القصص، كاتب المواصفات، منشئ الواجهة الخلفية، منشئ الواجهة الأمامية، مختبر الاختبار، مدقق التنفيذ، كل واحد مسؤول عن مهمة واحدة، وسياق نظيف وحدود صارمة.
(ملخص سابق: هل يمكن لـ MCP المربوط بكل شيء و Web3 أن يكونوا نواة السرد المئة مرة في الموجة القادمة من الذكاء الاصطناعي؟)
(معلومات إضافية: أعظم خبراء الاستثمار يساعدونك في العمل! يجمعون بين باريت و وارن وCathie Wood… 19 وكيل AI لتحليل السوق)

فهرس المقالة

Toggle

• المشكلة التي لا يتحدث عنها أحد
• التحول: من Vibe Coding إلى مصنع البرمجيات
• السبعة وكلاء
  • الوكيل 1: باحث الكود (Codebase Researcher)
  • الوكيل 2: كاتب القصص (Story Writer)
  • الوكيل 3: كاتب المواصفات (Spec Writer)
  • الوكيل 4: منشئ الواجهة الخلفية (Backend Builder)
  • الوكيل 5: منشئ الواجهة الأمامية (Frontend Builder)
  • الوكيل 6: مختبر الاختبار (Test Verifier)
  • الوكيل 7: مدقق التنفيذ (Implementation Validator)
• كيف يعمل السلسلة كاملة
• الأساس: قبل أن يعمل الوكيل، تحتاج إلى هذا
  • CLAUDE.md — ذاكرة كل حوار
  • انحراف السياق — القاتل الصامت
• النتائج: ما الذي يتغير حقًا
  • قبل المصنع:
  • بعد المصنع:
  • التغيير الحقيقي:
• اصنع نسختك الخاصة هذا الأسبوع
  • قائمة إعداد من 8 خطوات:
• السبعة وكلاء — مرجع سريع

كنت أظن أنني أستخدم AI لكتابة الكود. في الواقع، أنا فقط أكتب بسرعة أكبر.

هذه المقالة تتحدث عن الفرق بين الاثنين — وعن «نظام الوكلاء السبعة» الذي يغير كل شيء بشكل جذري.

احفظ هذه المقالة. ستوفر عليك شهورًا من العمل.

المشكلة التي لا يتحدث عنها أحد

دورة الإنتاج التي تبدو فعالة، لكنها ليست كذلك:

→ اطلب من Claude أن ينشئ لك وظيفة → يخرج الكود → شيء ما يتعطل → تلصق رسالة الخطأ → يصلحها → يتعطل مكان آخر → تسأل مرة أخرى

اليوم الأول: هذا يبدو سحريًا.

اليوم الثلاثون: تقضي وقتًا أكثر في مراقبة AI من أن تكتب بنفسك سابقًا.

نفس المنطق يظهر في ثلاثة أماكن مختلفة. Claude ينسى القواعد التي وضعتها قبل أسبوعين. وظيفة جديدة تفسد الوظائف القديمة. الاختبار إما غير موجود أو سطحي جدًا.

وفي يوم من الأيام، تدرك أن: الفشل ليس في AI، بل في تدفق عملك.

جوهر المشكلة هو هيكلي.

عندما تدخل أمر «ساعدني في عمل هذه الوظيفة» في Claude Code، أنت تطلب من حوار AI أن يلعب أدوارًا متعددة:

→ محلل المنتج → المهندس المعماري → مطور الواجهة الخلفية → مطور الواجهة الأمامية → مهندس الاختبار → مدقق الكود

كل ذلك مرة واحدة، في حوار واحد فوضوي.

الافتراضات الخاطئة في خطة العمل ستتحول إلى نماذج قاعدة بيانات خاطئة. النماذج الخاطئة ستنتج API خاطئ. API الخاطئ سيؤدي إلى UI خاطئ.

وعندما تكتشف ذلك، يكون الضرر قد انتشر في كل مكان.

وهذا هو ما يُسمى Vibe Coding (البرمجة بناءً على الشعور).

هناك سقف صلب لهذا الأسلوب.

التحول: من Vibe Coding إلى مصنع البرمجيات

السر الحقيقي الذي يغير كل شيء:

الفرق الحقيقي هو أن الفرق الهندسية لا تعمل في حوار واحد كبير.

كل شخص لديه مهمة مختلفة:

→ شخص يوضح مشكلة المستخدم → شخص يفكر في الهيكل → شخص يكتب API → شخص يكتب UI → شخص يفكر في الحالات الحدية → شخص يراجع

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

الحل هو تقسيم العمل إلى وكلاء متخصصين.

كل وكيل يتلقى:

→ مهمة مركزة → سياق نظيف خاص به → أدوات يحتاجها فقط → قواعد صارمة حول «ما لا يمكنه التعدي عليه»

النتيجة: مصنع برمجيات.

مطور واحد + سبعة وكلاء مركزين = فريق منسق.

وفيما يلي السبعة وكلاء الذين يجعلون هذا يعمل.

السبعة وكلاء

الوكيل 1: باحث الكود (Codebase Researcher)

أكبر خطأ يرتكبه المطورون عند استخدام AI هو؟

اعتقاد أن «الحاجة للكود» هي الخطوة الأولى.

عند طلب وظيفة، AI يأخذ الأمر، ويخمن ويملأ الفراغ، ويبدأ في التوليد. التصميم السيء هو أن هذا يحدث في تلك اللحظة.

الباحث يصحح هذا.

وظيفته الوحيدة:** فحص قاعدة الكود وشرح الحالة الحالية — قبل كتابة سطر واحد من الكود.**

ماذا يفعل:

• يحدد الملفات ذات الصلة ودورها
• يسجل الأنماط الموجودة التي يجب اتباعها
• يجد وظائف مشابهة تم إنشاؤها سابقًا
• يحدد المخاطر (مثل المناطق الزمنية، متعدد المستأجرين، منطق إعادة المحاولة)
• يذكر أي اختبارات تحتاج إلى تحديث

ماذا لا يستطيع أن يفعل:

• تحرير الملفات (فقط قراءة)
• تنفيذ أوامر تغير الحالة
• افتراض أشياء — يجب أن يطرح أسئلة

الأدوات: Read، Grep، Glob، فقط.

القواعد: قبل أن يبدأ، يجب أن يستكشف دائمًا.

الباحث دائمًا يبدأ.

الوكيل 2: كاتب القصص (Story Writer)

معظم فشل الوظائف ليس بسبب خطأ في الكود.

بل لأن المشكلة لم تُعرف بوضوح.

كاتب القصص يحول فكرة عامة إلى قصة مستخدم حقيقية — قبل اتخاذ أي قرار تقني.

المدخلات:

• وصفك العام للوظيفة
• نتائج التحقيق من الباحث

المخرجات:

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

ماذا لا يستطيع أن يفعل:

• اختراع قواعد تجارية
• كتابة كود أو تصميم تقني
• الاستمرار في التقدم عندما يكون غير واضح تمامًا

الأدوات: Read، فقط.

القواعد: يجب أن تقرأ وتوافق على القصة قبل أن تتقدم.

هذه هي النقطة الحاسمة لضمان عدم حدوث أخطاء لاحقًا — نقطة مراجعة الإنسان 1.

الوكيل 3: كاتب المواصفات (Spec Writer)

بعد الموافقة على القصة، يحولها كاتب المواصفات إلى عرض تقني.

هذا العرض هو المخطط الذي سيتبعه وكلاء البناء.

المدخلات:

• القصة التي وافقت عليها
• نتائج التحقيق من الباحث
• قواعد CLAUDE.md الخاصة بمشروعك

المخرجات:

• تغييرات النموذج البيانات (الحقول، الأنواع، الترحيل)
• سير العمليات / سير المعالجة
• تغييرات API (نقاط النهاية، تنسيق الطلب/الاستجابة)
• تغييرات الواجهة الأمامية (المكونات، الصفحات، hooks)
• الاختبارات المطلوبة (نجاح، فشل، حالات حدية)
• المخاطر والمشاكل غير المحسومة
• كل ملف سيتم تغييره

ماذا لا يستطيع أن يفعل:

• تحرير أي ملف
• اختراع بنية تحتية جديدة — يجب أن يوضح بشكل صريح
• تخطي عزل المستأجرين أو اعتبارات المناطق الزمنية
• ترك أسئلة بدون إجابة

الأدوات: Read، Grep، Glob، فقط.

القواعد: هذا هو نقطة مراجعة الإنسان 2.

يجب أن تقرأ وتوافق، كي يتم تعديل أي ملف.

إذا رأيت «تخزين المعرف في الذاكرة» — فهذه إشارة حمراء.

الآن، استخرجها. لا تنتظر حتى يتم تعديل 10 ملفات.

الوكيل 4: منشئ الواجهة الخلفية (Backend Builder)

الآن يبدأ البناء.

منفذ الوظائف للواجهة الخلفية — مسؤول فقط عن الجزء الخلفي.

المدخلات:

• العرض التقني الموافق عليه
• نتائج التحقيق من الباحث
• قواعد CLAUDE.md الخاصة بمشروعك

يقوم ببناء:

• مسارات API
• الخدمات والمنطق التجاري
• الوصول إلى قاعدة البيانات وترحيلها
• المهام الخلفية
• الاختبارات الوحدوية التي يكتبها

ماذا لا يستطيع أن يفعل:

• التعامل مع مكونات React، الصفحات، أو hooks على الجانب العميل (هذه مهمة الوكيل 5)
• اختراع تبعيات جديدة بدون توجيه
• تعديل ملفات خارج النطاق
• التوقف بدون تشغيل typecheck، lint، أو اختبارات

عند الانتهاء، يعيد ملخصًا: الملفات التي تم إنشاؤها أو تعديلها، الأنماط المعاد استخدامها، الملاحظات حول قواعد CLAUDE.md.

الأدوات: Read، Edit، Write، Bash — فقط داخل مجلد الواجهة الخلفية.

التركيز على الفصل بين الأدوار.

الوكيل 4 دائمًا لا يفسد الواجهة الأمامية.

الوكيل 5: منشئ الواجهة الأمامية (Frontend Builder)

الواجهة الأمامية تنفذ واجهة المستخدم — مسؤول فقط عن الجزء الخاص بالواجهة.

يقرأ ملخص الوكيل 4 أولاً.

وهذا مهم جدًا.

يستخدم API وفقًا للمواصفات التي خرج بها الوكيل 4. لا يختلق نقاط نهاية جديدة.

إذا كانت بنية API غير متوافقة مع UI،سيبلغ عن عدم التوافق — بدلاً من إصلاحها بنفسه.

المدخلات:

• العرض التقني الموافق عليه
• نتائج التحقيق من الباحث
• ملخص API من الوكيل 4 (عقد API)

يقوم ببناء:

• مكونات React والصفحات
• hooks الحالة على الجانب العميل
• حالات التحميل والخطأ
• اختبارات الوحدة والمكونات التي يكتبها

ماذا لا يستطيع أن يفعل:

• التعامل مع خدمات، مسارات API، عمال، أو ترحيلات (هذه مهمة الوكيل 4)
• اختلاق نقاط نهاية أو تنسيقات استجابة
• إضافة تبعيات بدون توجيه
• التوقف بدون تشغيل typecheck، lint، أو اختبارات

الأدوات: Read، Edit، Write، Bash — فقط داخل مجلد الواجهة الأمامية.

الوكيلان يعملان بشكل مستقل، مع سياقات نظيفة، بدون احتمالية أن يفسد أحدهما الآخر.

الوكيل 6: مختبر الاختبار (Test Verifier)

كل من الوكيل 4 و 5 يكتبان اختبارات وحدوية.

لكن هذا غير كافٍ.

مختبر الاختبار يقوم بشيء واحد فقط:** إثبات أن الوظيفة فعلاً تنفذ ما تقول قصة المستخدم.**

يكتب اختبارات قبول (Acceptance Tests)، وليست اختبارات وحدوية.

الاختبارات القبول تختبر الوظيفة من الخارج — كما لو كان مستخدم حقيقي يتفاعل معها.

المدخلات:

• قصة المستخدم الموافق عليها (بجميع معايير القبول)
• العرض التقني الموافق عليه
• ملخصات الوكيل 4 و 5

المخرجات:

• ملف اختبار قبول يغطي كل معيار
• تقرير: من نجح، من فشل، من لم يُغطَ بشكل نظيف

ماذا لا يستطيع أن يفعل:

• تعديل الكود الخلفي أو الأمامي
• اختراع حلول ملتوية للمعايير غير القابلة للاختبار
• اعتبار المعايير غير المغطاة بأنها مغطاة

إذا فشل اختبار: الوظيفة لا تلبي القصة.

سيبلغ عن «أي معيار فشل».** لن يصلح الكود.**

سيُعاد الإصلاح إلى الوكيل الصحيح.

الأدوات: Read، Edit، Write (ملف الاختبار فقط)، Bash.

القواعد: قبل أن تمر الاختبارات، لن يكون لديك الوظيفة.

الوكيل 7: مدقق التنفيذ (Implementation Validator)

هذا هو الوكيل الذي يكتشف ما تم نسيانه.

يقارن التنفيذ الحالي مع القصة والمستندات المعتمدة،** ويبلغ عن الفجوات**.

لا يقوم بأي تعديل. هو فقط يقول الحقيقة.

الفحوصات التي يجريها:

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

الإبلاغ حسب الأهمية:

• Critical — ضروري قبل الدمج
• Important — يجب إصلاحه قبل الدمج
• Minor — رأي شخصي، يقرره المراجع

كل اكتشاف يُذكر بمسار الملف ورقم السطر.

إذا لم توجد مشكلة، يقول ببساطة: لا توجد مشاكل.** لا يخترع مشاكل ليبدو جادًا.**

الأدوات: Read، Grep، Glob، فقط.

هذا الوكيل هو سبب ثقة المصنع كله.

تقرير التقييم الذاتي لا قيمة له. الوكيل الصادق هو الذي لا يكتفي برؤية «ما على القرص»، بل ينظر إلى «كيف كُتب».