توجيه عمال الخلفية

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

ما الذي يتغيّر حين تكتب /vibe

أمران، والأول وحده ما تفرضه الآلية:

1. أدوات الجلسة نفسها تنحصر في القراءة فقط، ويبقى معها خمسة أفعال لتشغيل العمال. لا سبيل للجلسة إلى التأثير في المستودع إلا عبر عامل، ولا سبيل لها إلى معرفة ما حدث إلا بقراءة الملفات التي لمسها عامل.
2. تُؤمَر الجلسة بالتحقق بالقراءة لا بالتصديق. تقرير العامل ادّعاء عمّا فعله، لا دليل على أن العمل نجح.

الأول هو الذي يقوم عليه الأمر. الموجّه الذي يبقى قادرًا على البحث والتعديل سينجز العمل بنفسه تحت الضغط، وهذا نمط الفشل الذي وُجد هذا الوضع لمنعه.

/vibe migrate the auth module to the new session API

العمال يبدؤون من الصفر

العامل لم يرَ محادثتك قط، ولن يراها. التكليف هو سياقه كله.

هذا ما يبقي النمط رخيصًا: عشرون عاملًا، لكل منهم تاريخ الموجّه الكامل، يكلّفون عشرين ضعف سياق الموجّه. وهو أيضًا ما يصعّب كتابة التكليف. «والآن افعل الأخرى أيضًا» تُقرأ في عين الموجّه تعليمات مكتملة، ولا تعني لجلسة جديدة شيئًا على الإطلاق.

التكليف الجيد يسمّي الملفات والأوامر وتعريف الإنجاز:

في lib/features/auth/، ضع SessionStore.get(key) محل كل استدعاء لـ SessionStore.read(key). يعيد الأسلوب الجديد Future<String?> حيث كان القديم يعيد String?، لذلك يحتاج المستدعون إلى await. شغّل fvm flutter analyze lib/features/auth حين تنتهي، وأبلغ عن أي أخطاء عجزت عن إصلاحها.

الأفعال الخمسة

الفعل	ما يفعله
vibe_spawn	يبدأ عاملًا بتكليف. يعيد فورًا.
vibe_list	المستوى والحالة والوقت المنقضي وآخر نتيجة لكل عامل
vibe_send	جولة متابعة لعامل أنهى جولته
vibe_wait	يتوقف حتى يستقر عامل واحد
vibe_kill	يوقف واحدًا

الإطلاق غير متزامن عمدًا. الموجّه الذي يتوقف عند كل إطلاق يشغّل العمال واحدًا واحدًا، وهذا أبطأ مما كان ينجزه بنفسه أصلًا. لا تستخدم vibe_wait إلا حين تعجز حقًا عن المتابعة من غير جواب بعينه.

مستويان

المستوى	الغرض
fast	عمل روتيني بمواصفة واضحة — تعديلات، وإعادة تسمية، ومسودات، وتشغيل أوامر
good	التصميم، أو التقدير، أو مراجعة ما أنتجه عامل fast

الشكل الشائع أن تفرّع عمال fast على ملفات مستقلة، ثم تطلق عامل good واحدًا يراجع ما فعلوه مجتمعين.

التحقق

هذا الجزء هو الذي يقرّر ألهذا النمط قيمة.

vibe_list
→ w1 [fast] auth-migrate — done (48s): Edited lib/features/auth/session.dart …
  w2 [fast] tests — running (12s)

ثم اقرأ الملفات التي سمّاها. يملك الموجّه read وsearch وlsp وast_grep، وهذا كل المغزى من إبقائها. الموجّه الذي يصدّق التقرير على ظاهره ليس إلا ملخّصًا لتفاؤل وكلاء سواه.

lsp(action: "diagnostics", file: "*") بعد دفعة من العمال هو في العادة أسرع فحص منفرد.

حين يضيع الخيط على العامل

أوقفه وأعد التكليف. تكليف جديد مصحَّح أرخص من جدال، وvibe_send لا يعمل إلا على عامل أنهى جولته أصلًا.

vibe_kill(worker_id: "w2")
vibe_spawn(brief: "…corrected…", label: "tests", tier: "fast")

الحدود

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

متى لا تستخدمه

وضع vibe للعمل الذي يتفكك إلى تكليفات مستقلة. إن كانت الخطوة التالية تعتمد على مخرج الخطوة السابقة، فأنت تصف خط أنابيب أو تنسيقًا، وكلاهما يعبّر عن التبعيات على وجهها بدل أن تجعل الموجّه يحاكيها بـ vibe_wait.

ذات صلة

• تشغيل الوكلاء بالتوازي — الطرق الأخرى لتوزيع العمل
• التنسيق — حين يكون للعمل شكل
• أدوات الوكيل المضمّنة — الأفعال ووسائطها