يمكن لوكيل برمجة أن يسلّمك تطبيقًا يعمل، بينما تبقى أنت غير قادر على شرح سبب اختيار قاعدة البيانات، أو ما يحدث عند حذف سجل، أو أين تُفحص صلاحيات المستخدم. سرعة إنتاج الكود لا تعني أنك تعلمت كيف يُبنى النظام.
هذه هي المشكلة التي يحاول VibeWise معالجتها. الإضافة تجعل Claude Code أو Codex يطلب منك التفكير في الحل قبل تنفيذه، ويساعدك على فهم المفاهيم والمفاضلات، ثم يكتب الكود الذي اتفقتما عليه ويشرح ما تغيّر.
قد تكون هذه الطريقة أبطأ من طلب "ابنِ التطبيق كاملًا". لكنها تناسب من يريد أن يخرج من الجلسة بفهم يستطيع استخدامه في المهمة التالية، لا بمجرد ملفات تعمل الآن.
هذه قراءة للوثائق وتعليمات الإضافة المنشورة، وليست تجربة استخدام شخصية أو قياسًا لتحسّن التعلم. لم نثبّت VibeWise ونختبر جلسة تعليمية أثناء إعداد هذا المقال؛ لذلك نفصل بين ما تصفه الوثائق وما يحتاج إلى تجربة فعلية.
ما VibeWise، وما الذي يغيّره؟
VibeWise إضافة لـClaude Code وCodex تضع التعلم وملكية المستخدم للقرار قبل سرعة البناء. هي ليست نموذجًا جديدًا، ولا دورة برمجة، ولا أداة تضمن صحة الكود. إنها مهارات وتعليمات وسياق محفوظ يغيّر أسلوب المحادثة مع وكيل البرمجة.
في وضع التعلم، يطلب الوكيل منك وصف طريقة العمل التي تتصورها. يمكنك الإجابة بكلمات عادية، أو رسم، أو pseudocode. لا يشترط أن تكتب التنفيذ يدويًا؛ الوكيل يتولى ذلك بعد الاتفاق على الخطوة.
المقصود أن تقود أنت التصميم. وإذا لم تفهم مفهومًا، يشرحه الوكيل. وإذا طلبت اقتراحات أو كنت عالقًا، يمكنه عرض خيارات تساعدك على متابعة التفكير، بدل أن يقدّم خطة كاملة ثم يسألك فقط إن كنت موافقًا.
هذه نقطة تستحق الانتباه: الموافقة على خطة كتبها الذكاء الاصطناعي لا تثبت أنك فهمتها. التعليمات المنشورة تحاول إبقاء تفكيرك ظاهرًا في المحادثة، حتى يستطيع الوكيل مناقشة افتراضاتك والأخطاء المحتملة.
المشكلة ليست أنك تستخدم AI، بل أنك قد تتجاوز التفكير
في أسلوب البناء السريع، قد تصف الواجهة والميزات ثم تترك بقية القرارات للوكيل: تمثيل البيانات، والعلاقات، ومكان التحقق، وسياسة الحذف، وطريقة النشر.
هذا قد يناسب نموذجًا أوليًا مؤقتًا، لكنه يترك فجوة عندما تحتاج إلى تعديل المشروع لاحقًا. لا يكفي أن تعرف أسماء الملفات؛ تحتاج إلى فهم العلاقة بين الأجزاء، ولماذا اختيرت هذه البنية، وأين يمكن أن تفشل.
VibeWise يحاول إدخال هذا النقاش داخل مهمة البناء نفسها. تتعلم العلاقات وأنت تصمم ميزة تحتاجها، بدل قراءة شرح عام لا تعرف أين ستستخدمه. ويطلب من الوكيل توضيح المخاطر وحدود الثقة ومراجعة الاقتراح مقابل الكود الموجود.
لا يعني ذلك أن كل قرار يجب أن يتحول إلى درس طويل. الإضافة تسمح بتعديل كثافة نقاط التوقف، وتكييف الشرح حسب خبرتك بالموضوع، وتجاوز خطوة تعليمية عندما تطلب ذلك صراحة.
كيف تسير الجلسة؟
تصف الوثائق ثلاثة أنواع من نقاط التوقف. ليست سلسلة إجبارية يجب تكرارها كاملة لكل تغيير، بل أدوات تستخدم حسب الخطوة التالية.
Build checkpoint: فكّر في طريقة الحل
يسألك الوكيل كيف ستتعامل مع المشكلة، وينتظر إجابتك. الهدف هنا رؤية فهمك للعلاقات والسلوك، لا اختبار حفظك لمصطلح تقني.
إذا قلت "أريد الملاحظات داخل مجلدات"، فهذا مطلب. أما توضيح ما إذا كانت الملاحظة تنتمي إلى مجلد واحد أو عدة مجلدات، وما الذي يحدث عند حذف أحدها، فهو جزء من تصميم السلوك.
Design checkpoint: اعتمد التصميم دون بدء التعديل
يلخّص الوكيل التصميم المقترح ومفاضلاته، ويمكنك اختيار Confirm and continue لتسجيل القرار ومتابعة التخطيط، أو Discuss لمناقشته.
هذه الموافقة، حسب تعليمات الإضافة، لا تأذن بعد بتغيير الكود. فصل القرار عن التنفيذ مفيد عندما تحتاج إلى فهم جزء من النظام قبل الانتقال إلى بقية الخيارات.
Implementation checkpoint: وافق على نطاق التغيير
عندما تصبح الخطوة جاهزة، يشرح الوكيل التعديلات المحددة التي سيجريها. اختيار Implement this step يأذن بتنفيذ ذلك النطاق، بينما يتيح Discuss مراجعة التفاصيل قبل التعديل.
قد تجمع هذه النقطة اعتماد التصميم والتنفيذ معًا، فلا تحتاج إلى نقطة تصميم منفصلة عندما يكون النقاش مكتملًا بالفعل.
بعد التنفيذ، يفترض أن يوضح الوكيل الملفات التي تغيّرت، وكيف يعمل الكود الأساسي، وما الاختبارات المضافة أو المعدّلة، والفحوص التي شغّلها فعلًا ونتائجها. كتابة اختبار وتشغيله أمران مختلفان، ويجب أن يظهر الفرق في التقرير.
مثال يوضح الفكرة: حذف مجلد لا يعني حذف كل ملاحظاته
يعرض README مثالًا لتطبيق ملاحظات يسمح بوضع الملاحظة في أكثر من مجلد. تبدأ الفكرة بأن حذف المجلد يحذف ملاحظاته، ثم يسأل الوكيل عن ملاحظة موجودة في مجلدين: ماذا يحدث لنسختها الظاهرة في المجلد الآخر؟
يقود النقاش إلى فصل حذف المجلد عن حذف الملاحظة، وتمثيل العضوية بجدول روابط يحمل note_id وfolder_id. حذف المجلد يزيل روابطه ويحافظ على الملاحظات وعضويتها في المجلدات الأخرى.
هذا المثال من توثيق المشروع، وليس جلسة أجريناها نحن. ويذكر صاحبه أن بعض خطوات التنفيذ اللاحقة توضيحية. لذلك لا نعرض نتائج الاختبارات الموجودة فيه كاختبار مستقل للإضافة.
ما يستحق التعلم من المثال هو ترتيب النقاش: تحديد السلوك أولًا، ثم اختيار تمثيل البيانات، ثم اختبار أن عملية الحذف لا تمس شيئًا لم يطلب المستخدم حذفه.
وقد يكون مشروعك مختلفًا. إذا كان حذف المجلد يجب أن يحذف المحتوى فعلًا، فهذه سياسة تحتاج إلى تعريفها وتوضيح عواقبها، لا إلى تبنّي جدول الروابط لأن المثال استخدمه.
لمن يمكن أن تكون مفيدة؟
للمبتدئ، توفر طريقة للسؤال عن المفاهيم أثناء استخدامها. لا تحتاج إلى معرفة جواب كل سؤال مسبقًا، لكنك تشارك في الوصول إليه.
للمطور المتوسط، يمكن أن تكون مناسبة عند التفكير في التفاعلات بين الأجزاء: كيف ينتقل الطلب من الواجهة إلى API، وما الذي يحدث إذا فشل أحدهما، ومن المسؤول عن التحقق.
وللمطور الخبير، تقترح الوثائق التركيز على القيود الصعبة، وحالات الفشل، وافتراضات التصميم، خصوصًا في تقنية أو مستودع لا يعرفه جيدًا.
أما إذا كنت تحتاج إلى إصلاح محسوم بسرعة أو تنفّذ مهمة تعرف تفاصيلها، فقد تكون كثرة التوقفات عبئًا. تستطيع تقليلها أو طلب التنفيذ المباشر لخطوة محددة. قيمة الإضافة تعتمد على ما تريد تعلمه، لا على إبقاء وضع التعلم نشطًا في كل موقف.
المتطلبات قبل التثبيت
بحسب README، تحتاج إلى نسخة حديثة من Claude Code أو Codex، وإلى Python 3. لا يحتاج الجزء الخاص بالإضافة إلى حزم Python إضافية.
في Claude Code، يستخدم Python لاستعادة سياق التعلم وإعادة ضبط الملاحظات. وفي Codex، يحتاجه مسار إعادة الضبط، بينما استئناف التعلم يتم باستدعاء المهارة.
راجع المصدر والمهارات والـhooks قبل التثبيت، واختر نطاقًا مناسبًا، مثل تجربة الإضافة على مشروع تدريبي أولًا. قدرة الإضافة على طلب موافقة ليست بديلًا عن إعداد صلاحيات وكيل البرمجة نفسه.
تثبيت VibeWise على Claude Code
يوصي README بالتثبيت من Anthropic Directory إذا كان متاحًا في نسختك. داخل Claude Code:
/plugin install vibe-wise@anthropic-plugin-directory
اختر نطاق التثبيت ووافق، ثم أعد تشغيل Claude Code داخل المشروع الذي تريد العمل عليه. بعد ذلك:
/vibe-wise:learn
يبدأ الإعداد بأسئلة عن تفضيلاتك، ويمكن اختيار Use defaults لتجاوز تخصيصها. إذا كان المستودع موجودًا بالفعل، تصف الوثائق أن الوكيل يفحص الكود ويضع خريطة صغيرة للنظام قبل متابعة التعلم.
إذا لم يكن المسار السابق متاحًا، يوفر المشروع بديلًا عبر GitHub marketplace. أرسل الأمر الأول، وانتظر اكتماله:
/plugin marketplace add nykooi1/vibe-wise
ثم أرسل الأمر الثاني بصورة منفصلة:
/plugin install vibe-wise@vibe-wise
اختر طريقة واحدة؛ لا تحتاج إلى التثبيت من المصدرين معًا. أعد التشغيل ثم فعّل /vibe-wise:learn في مشروعك. هذه أوامر من الوثائق الحالية، وليست نتيجة تثبيت أعدنا تنفيذه أثناء الكتابة.
تثبيته على Codex
من الطرفية، نفّذ الأمر الأول ثم الثاني بعد اكتماله:
codex plugin marketplace add nykooi1/vibe-wise
codex plugin add vibe-wise@vibe-wise
ابدأ Codex داخل المشروع، ثم استدعِ المهارة:
$vibe-wise:learn
الفرق في صيغة الاستدعاء مهم: تستخدم أوامر Claude Code هنا /، بينما تستخدم مهارات Codex $.
كذلك، تكامل Codex المنشور لا يملك hook جلسة خاصًا بـVibeWise، ويعرض ملف الإضافة hooks: {}. لذلك يطلب الدليل استدعاء $vibe-wise:learn في بداية كل جلسة Codex، وعندما يبدو أنه فقد سياق وضع التعلم. يقرأ الملاحظات المحفوظة ليستأنف دون تكرار الإعداد المكتمل.
في Claude Code، توجد آلية SessionStart لاستعادة السياق عند بداية الجلسة وبعض حالات الاستئناف وضغط السياق. لا تعمم هذه الآلية على Codex لمجرد أن الأداتين تشتركان في ملفات التعلم.
أول مهمة مناسبة للتجربة
اختر ميزة صغيرة لها قرار يمكنك مناقشته: حفظ مسودة، أو علاقة بين كيانين، أو صلاحية قراءة سجل. تجنب بدء التجربة بمشروع كبير لا تستطيع تقييم صحة مخرجاته.
بعد تفعيل التعلم، يمكن أن تطلب:
أريد إضافة مجلدات للملاحظات في هذا المشروع.
ساعدني على فهم الخيارات قبل كتابة الكود.
ابدأ بسؤالي عن علاقة الملاحظة بالمجلد وسياسة الحذف.
ناقش حدود الصلاحيات، ثم اتفق معي على خطوة صغيرة يمكن اختبارها.
هذا طلب توضيحي مقترح للقارئ، وليس نص جلسة حدثت معنا. يمكنك الإجابة بالعربية أو وصف فكرتك ببساطة، وطلب شرح مفهوم غير مألوف قبل اتخاذ القرار.
عند قراءة تقرير التنفيذ، اسأل عن مكان تطبيق القرار وعن الحالات التي لم تُختبر. ثم افتح الفرق في الملفات وشغّل الفحوص المناسبة. لا تجعل شرح الوكيل هو دليلك الوحيد على أن التطبيق يفعل ما اتفقتما عليه.
تخصيص الشرح وإيقاف التعلم مؤقتًا
تفرق الإضافة بين مستوى الخبرة وكثافة نقاط التوقف. قد تكون خبيرًا في الواجهات ومبتدئًا في قواعد البيانات، ولذلك يفترض أن يتكيف الشرح حسب الموضوع والفهم الظاهر، لا حسب لقب تختاره مرة واحدة.
يمكن طلب شرح أقل تمهيدًا، أو التركيز على backend architecture، أو استخدام أسئلة متعددة الخيارات حيث يناسب ذلك. ويمكن تقليل نقاط التوقف أو زيادتها.
من العبارات التي يوثقها المشروع:
Use fewer checkpoints.
Focus on backend architecture.
Just implement this one.
Pause learning.
بعد إيقاف التعلم مؤقتًا، استأنفه بـ/vibe-wise:learn في Claude Code، أو $vibe-wise:learn في Codex.
التمييز بين وصف ميزة وبين اعتماد تصميمها يظل مهمًا. في وضع التعلم، طلب بناء عادي لا يفترض تلقائيًا أنك تريد تجاوز النقاش؛ اطلب ذلك صراحة عندما يكون هو قصدك.
أين يحفظ ما تتعلمه؟
يحفظ المشروع التفضيلات وملاحظات التعلم وخريطة النظام داخل .vibe-wise/. تتضمن تعليمات المهارة ملفات مثل profile.md وprogress.md وproject-map.md، لتسجيل التفضيلات والتقدم والقرارات المتعلقة بالمشروع.
في مستودع Git، تتجه الملاحظات إلى جذر المستودع ويمكن العثور عليها من المجلدات الفرعية. دون Git، يعتمد التحديد على المجلد الذي بدأت فيه؛ ابدأ من مجلد المشروع الأساسي ولا تتوقع أن يبحث في كل المجلدات الأعلى.
أضف هذا السطر إلى .gitignore إذا أردت إبقاء الملاحظات خارج Git:
.vibe-wise/
حسب الوثائق، الإضافة لا تعدّل .gitignore بصمت. ووجود الملاحظات على جهازك لا يعني أنها لا تصل إلى مزود النموذج: تدخل هذه الملفات ضمن سياق Claude Code أو Codex، ولذلك تبقى إعدادات البيانات والخصوصية الخاصة بالأداة مطبقة.
README يذكر عدم الحاجة إلى حساب إضافي أو backend أو telemetry خاص بالمشروع. هذا وصف للمشروع، وليس تدقيقًا أمنيًا أجريناه، ولا ضمانًا بأن كل البيانات تبقى محلية أثناء استخدام النموذج.
لا تحفظ مفاتيح أو بيانات عملاء أو معلومات داخلية حساسة في ملاحظات التعلم. ويمكنك مراجعة حدود الوكيل الآمنة قبل منحه صلاحية الكتابة أو تشغيل أوامر على مشروع فعلي.
إعادة الضبط والتحديث
للبدء من جديد في Claude Code:
/vibe-wise:reset
وفي Codex:
$vibe-wise:reset
تصف الوثائق شاشة تأكيد تعرض المشروع وخياري الإلغاء أو إعادة التعلم. بعد الموافقة، تنسخ ملفات ملفك التعليمي والتقدم والخريطة إلى backups/ داخل مجلد الملاحظات ثم تعيد الإعداد. هذا المسار خاص بملاحظات التعلم، وليس أمرًا لإعادة الكود إلى نسخة سابقة.
إذا كان هدفك تغيير مستوى الخبرة أو التفضيلات، أخبر الوكيل بذلك بدل إعادة الضبط دون حاجة. ولا تعتبر النسخة الاحتياطية لملاحظات التعلم بديلًا عن Git أو نسخ بيانات المشروع.
للتحديث في Claude Code، افتح /plugin ثم قسم الإضافات المثبتة واختر VibeWise والتحديث. أما Codex فيوثق README تحديث marketplace ثم إعادة إضافة النسخة الحالية:
codex plugin marketplace upgrade vibe-wise
codex plugin add vibe-wise@vibe-wise
ابدأ جلسة جديدة بعد التحديث. تحقق من الأوامر التي توفرها نسختك قبل التنفيذ، لأن دعم الإضافات يتغير مع الإصدارات.
هل يمكن استخدامها على Hermes؟
المستودع الذي راجعناه يوثق Claude Code وCodex. لم نجد فيه تكاملًا أصليًا موثقًا لـHermes، ولذلك لا نقدّم أمر تثبيت أو نعد بتشغيل hooks نفسها عليه.
يمكن تطبيق فكرة الحوار التعليمي في أدوات أخرى، لكن هذا يختلف عن توافق الإضافة. نقل مهارة أو تعليمات يحتاج مراجعة أسماء الأدوات ومسارات الملفات وآلية استعادة السياق والموافقات. لا يكفي نسخ النص والافتراض أن كل سلوكه سيعمل تلقائيًا.
VibeWise وPonytail يعالجان سؤالين مختلفين
في مراجعة Ponytail، كان التركيز على تقليل البناء الزائد وإعادة استخدام الموجود قبل إضافة كود. سؤال Ponytail هو: ما أصغر تغيير ينجز المهمة كاملة؟
أما VibeWise فيركز على فهم المستخدم وملكيته للتصميم: هل شاركت في اتخاذ القرار، وهل تعرف لماذا سيعمل هذا النظام؟
قد يرغب شخص في الأمرين، لكننا لم نختبر تشغيل الإضافتين معًا. وقد تظهر مفاضلة بين رغبة أداة في التنفيذ المختصر ورغبة الأخرى في التوقف للنقاش. لا نفترض توافقًا كاملًا أو تحسنًا مركبًا دون تجربة.
إذا كانت مشكلتك الأساسية كودًا زائدًا، فراجع Ponytail. وإذا كنت تحصل على كود يعمل لكنك لا تستطيع تفسيره، ففكرة VibeWise أقرب إلى حاجتك.
ما الذي لا تضمنه الإضافة؟
لا يثبت وجود نقطة موافقة أن التصميم صحيح، ولا يثبت شرح مفهوم أنك اكتسبت القدرة على استخدامه دون مساعدة. وقد يعطي النموذج تفسيرًا خاطئًا أو تقييمًا غير دقيق لفهمك.
كذلك، لا نملك من هذه القراءة دليلًا على نسبة محددة لتحسّن التعلم أو توفير التكلفة. الأسئلة والسياق المحفوظ قد يزيدان زمن الجلسة واستهلاكها؛ المشروع يضع التعلم قبل السرعة أصلًا.
للتقييم، جرّب مهمة صغيرة ثم اختبر نفسك خارج الحوار: اشرح العلاقة بين الأجزاء، وحدد حالة فشل، واقترح تغييرًا وكيف ستختبره. راجع الكود الناتج واختباراته بصورة مستقلة. هذه طريقة مقترحة لتقييم الفائدة، وليست دراسة نفذناها.
البداية التي تستحق التجربة
إذا أردت التعلم أثناء بناء مشروع، جرّب VibeWise على مهمة صغيرة في فرع تجريبي. فعّل الوضع المناسب لأداتك، وناقش التصميم بكلماتك، ثم وافق على خطوة تنفيذ تستطيع مراجعتها.
لا تحتاج إلى ترك الذكاء الاصطناعي كي تتعلم البرمجة. لكنك تحتاج إلى إبقاء بعض العمل لنفسك: فهم المشكلة، ومراجعة الافتراضات، وتفسير النتيجة. هذا هو الاستخدام الذي تحاول الإضافة دعمه، ويستحق تجربة من يريد أن يبني ويفهم ما يبنيه.
المصادر
راجَعنا المصادر لإعداد المقال في 10 أكتوبر 2026. الغلاف تصميم تحريري يستخدم الأيقونة الرسمية من مستودع VibeWise، ولا يمثل واجهة تطبيق أو نتيجة تجربة. المشروع منشور بترخيص MIT، حقوق النشر © 2026 Noah Kim. المقال مستقل عن المشروع.

لا تعليقات بعد. شارك سؤالك أو تجربتك مع هذا الدليل.