Mistral Vibe CLI للتصميم.

ماهية Mistral Vibe CLI فعليًا

Mistral Vibe CLI وكيل برمجة مفتوح المصدر (Apache-2.0) تطرحه Mistral AI للطرفية. يوفّر واجهة محادثة تفاعلية بأدوات للتعامل مع الملفات والبحث في الشيفرة والتحكّم بالإصدارات وتنفيذ الأوامر، ويمسح تلقائيًا بنية ملفات مشروعك وحالة Git ليمنح الوكيل سياقًا ذا صلة. وهو مدعوم بنماذج Devstral البرمجية من Mistral — مخطّطًا للعمل ومتحقّقًا منه انطلاقًا من مهام بلغة طبيعية بدلًا من إكمال الأسطر فحسب.

في العمل التصميمي، تبرز خاصيتان. فهو يعمل على عائلة Devstral مفتوحة الأوزان من Mistral (Devstral 2 وDevstral Small 2 الأصغر)، فيمكنك تشغيل الوكيل مقابل واجهة Mistral البرمجية في السحابة أو مقابل نماذج محلية — وهو مفيد للعمل التصميمي الحسّاس للخصوصية أو دون اتصال. وهو يتحدّث بروتوكول عميل الوكيل، فيستطيع الوكيل نفسه قيادة المحرّرات والأدوات، لا جلسة طرفية واحدة فحسب.

• ملفات الإعدادات: يُهيَّأ Vibe CLI عبر ملف config.toml (على مستوى المشروع ./.vibe/config.toml، مع بديل احتياطي في ~/.vibe/config.toml). وهو موضع عملي لتدوين مزوّديك واختيار النموذج وإعدادات المشروع.
• الأدوات المدمجة + MCP: يأتي بأدوات للملفات والبحث والتحكّم بالإصدارات وتنفيذ الأوامر، ويدعم خوادم MCP (المُهيَّأة ضمن قسم [[mcp_servers]]) لإضافة سياق خارجي مثل ملف Figma حيّ.
• BYOK أو محليًا: صادِق بمفتاح API من Mistral عبر وحدة تحكّم Mistral، أو وجّهه إلى نماذج محلية/متوافقة كي يعمل دون اتصال بالكامل.

• المُورّد: Mistral AI
• بيانات الاعتماد: مفتاح API من Mistral (BYOK) من وحدة تحكّم Mistral، أو نماذج محلية/متوافقة
• الترخيص: Apache-2.0، مفتوح المصدر

لماذا يناسب التصميمَ وكيلُ برمجة مفتوح الأوزان

تأتي ميزة Vibe CLI التصميمية من عائلة نماذجه مفتوحة الأوزان ومدى بروتوكوله — لكن، كما هي الحال مع كل وكيل، يبقى الذوق أمرًا يجب توفيره.

• نماذج Devstral البرمجية: يعمل Vibe على عائلة Devstral من Mistral، وهي نماذج مضبوطة للبرمجة ومبنية للعمل القائم على الوكيل عبر ملفات متعدّدة — فيحرّر الوكيل عبر قاعدة شيفرة واجهات أمامية حقيقية بدلًا من إصدار مقتطفات معزولة.
• مفتوح الأوزان وملائم للتشغيل المحلي: Devstral Small 2 صغير بما يكفي للتشغيل على عتاد المستهلك، فيمكن للعمل التصميمي أن يبقى محليًا ودون اتصال بالكامل — فلا يضطرّ المراجع والشيفرة إلى مغادرة جهازك أبدًا.
• الأعراف في config.toml + السياق: توجّه إعدادات المشروع وتعليماتك الخاصة الوكيلَ إلى رموزك التصميمية ومكوّناتك ومواصفاتك الحقيقية، فيعمل وفق هوية بصرية بدلًا من مظهر افتراضي.

الدرس نفسه الذي يعلّمه كل وكيل: لا يمتلك Vibe CLI ذوقًا افتراضيًا. فهو ينتج تصميمًا جيدًا حين تمدّه بالقيود — نظام تصميم ومهارة جمالية ومراجع ملموسة. ويحزم Open Design هذه المدخلات بالضبط، ولهذا يتلاءم الاثنان معًا (المزيد أدناه).

إعداد Vibe CLI للعمل التصميمي، من الصفر

إليك المسار الكامل من جهاز نظيف إلى Vibe CLI قادر على بناء الواجهات والتحقّق منها.

# 1. Install Mistral Vibe CLI
uv tool install mistral-vibe
# or: pip install mistral-vibe

# 2. Run the setup wizard to register your API key
vibe --setup     # saves config to ~/.vibe/config.toml and ~/.vibe/.env
#    or set it directly:  export MISTRAL_API_KEY=...

# 3. Start Vibe in your project
cd your-project
vibe

# 4. Wire the Figma MCP server (optional, for design handoff)
#    add an [[mcp_servers]] entry in your config.toml

• دوّن قواعد تصميمك: احتفظ برموزك التصميمية وعناصرك الأساسية وأعرافك حيث يقرؤها الوكيل ووجّه Vibe إليها، كي تطابق المخرجات الهوية البصرية بدلًا من اللجوء افتراضيًا إلى مظهر عام.
• أضِف التحقّق عبر المتصفّح: اربط Playwright أو متصفّحًا عبر MCP كي يعرض Vibe في متصفّح حقيقي ويفحص مخرجاته عبر نقاط التوقّف بدلًا من مجرّد التأكّد من نجاح البناء.

سير عمل التحويل من المرجع إلى الواجهة

أكثر حلقات التصميم تأثيرًا مع Vibe CLI هي تحويل مرجع واضح إلى واجهة عاملة ومتجاوبة والتكرار حتى تتطابق — بالاعتماد على أدوات الوكيل للعرض والفحص وتصحيح مخرجاته بنفسه.

1. ابدأ من أوضح المراجع لديك — وصِف حالات متعدّدة (سطح المكتب والجوال، والتمرير فوق العنصر، والحالة الفارغة، وحالة التحميل)، لا لقطة رئيسية واحدة فحسب.
2. كن محدّدًا في المُوجّه؛ فالمُوجّهات الغامضة تنتج واجهات عامة حتى مع نموذج قوي.
3. احتفظ بنظام تصميمك وأعرافك حيث يقرؤها Vibe، وأخبِره بمواضع الرموز التصميمية والعناصر الأساسية المرجعية.
4. شغّل خادم تطوير واجعل Vibe يعرض في متصفّح حقيقي، مع تغيير الحجم إلى نقاط التوقّف للتحقّق من النتيجة.
5. كرّر العمل بأن تجعل Vibe يقارن تنفيذه بالمراجع — لا أن يكتفي بالتأكّد من نجاح البناء.

أشِر إلى الملفات بـ @ (يكمل Vibe مسارات الملفات تلقائيًا) واستخدم أوامر الشَّرطة المائلة بـ /، ثم قدّم قيودًا ملموسة:

vibe
# in the prompt:
> @design-spec.md @tokens.css
  Implement this design in React + Vite + Tailwind + TypeScript.
  Reuse my existing design-system components and tokens.
  Match spacing, layout, and hierarchy; make it responsive.
  Run the dev server, render it in the browser, and iterate until
  it matches the references across breakpoints.

أبقِ المُوجّهات صغيرة ومركّزة، وأودِع التكرارات الجيدة وتراجع عن السيّئة (مع إخبار Vibe عند تراجعك)، كي تبني كل مرحلة على أساس نظيف.

config.toml وMCP وACP

ثلاث نقاط توسّع تجعل Vibe CLI عمليًا للعمل التصميمي المستمر، وتنطبق الثلاث جميعها بسلاسة على سير عمل تصميمي مفتوح.

• config.toml: تقيم قواعد المشروع وإعدادات المزوّد/النموذج في ملف config.toml (على مستوى المشروع، مع بديل احتياطي في ~/.vibe). وهو الموطن المتين لكيفية ربط الوكيل في مشروعك، يُقرأ في كل تشغيل.
• خوادم MCP: هيّئ خوادم MCP في ملف config.toml الخاص بك ([[mcp_servers]]، مع نقل عبر HTTP وHTTP القابل للبثّ وstdio) — وهي الطريقة القابلة للنقل لإدخال السياق التصميمي والأدوات الخارجية، وأكثرها صلةً خادم Figma عبر MCP، التي تعمل عبر الوكلاء، لا مع Vibe فحسب.
• بروتوكول عميل الوكيل: يتحدّث Vibe بروتوكول ACP، فيمكن قيادة الوكيل نفسه من المحرّرات وعملاء ACP الآخرين. وهذا بالضبط كيف يدمجه Open Design — عبر ACP من خلال الملف التنفيذي vibe-acp.

هذه قدرات قابلة للنقل ومتعدّدة الوكلاء — وهي بالضبط ما بُني Open Design لتنسيقه، بدلًا من إعادة إنشائه لكل مشروع.

Vibe CLI مقابل Codex وClaude Code وCursor وGemini CLI في التصميم

لا يوجد فائز واحد في العمل التصميمي — فلكل وكيل نقطة قوة مختلفة، والفِرق المتمرّسة تجمع بينها. وفيما يلي ملخّص منصف:

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

العثرات وكيفية تجنّب مظهر «ركاكة الذكاء الاصطناعي»

أكثر الشكاوى شيوعًا بشأن التصميم المُولَّد بالذكاء الاصطناعي أنه يبدو عامًا — تدرّجات لونية ناعمة، ولوحات طافية، وزوايا دائرية مفرطة الحجم، وظلال مبالَغ فيها، وطابع «خط Inter واللون الأرجواني» الذي «يصرخ بأن ذكاءً اصطناعيًا صنع هذا». ومن المشكلات المُبلَّغ عنها أيضًا تكسّر تخطيطات الجوال وتسرّب التعليمات إلى نصوص الواجهة. ولا يقتصر أيٌّ من هذا على Vibe CLI؛ بل هو ما يحدث حين يعمل أي وكيل دون سياق تصميمي منسّق.

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

لاحظ أن كل إجراء تخفيفي يدور حول منح الوكيل سياقًا تصميميًا منسّقًا. والحفاظ على هذا السياق يدويًا، ولكل مشروع، هو العناء الذي يزيله Open Design.

التصميم باستخدام Vibe CLI داخل Open Design

Open Design هو طبقة التصميم مفتوحة المصدر التي يطلبها سير العمل أعلاه باستمرار. فهو يتعامل مع Mistral Vibe CLI بوصفه مُحوّلًا أصيلًا — يقوده عبر ACP من خلال الملف التنفيذي vibe-acp — ويغلّفه بمكتبة منسّقة من المهارات وأنظمة التصميم، وخط معالجة عرض منظّم، وواجهة سطح مكتب محلية. وهكذا يكون السياق التصميمي الذي يجعل Vibe جيدًا حاضرًا منذ التشغيل الأول، لا مُجمَّعًا يدويًا في كل مرة. وكلاهما مفتوح المصدر ويعمل محليًا أولًا، ما يجعل اقترانهما ملائمًا بطبيعته.

1. ثبّت Open Design واختر Mistral Vibe CLI وكيلًا لك.
2. صادِق بمفتاح API الخاص بك من Mistral (BYOK) أو وجّه Vibe إلى نماذج محلية — تبقى بيانات الاعتماد على جهازك ولا تُمرَّر عبرنا أبدًا.
3. اختر نظام تصميم ومهارة، ثم أنشئ العروض التقديمية والنماذج الأولية وصفحات الهبوط بذوق متّسق.
4. كل ناتج وملف DESIGN.md يبقى في مستودعك الخاص، لا في سحابة مستضافة.

وكيل Vibe CLI نفسه، والمفتاح نفسه — مع سير عمل تصميمي حقيقي وقابل للنقل ومفتوح المصدر من حوله. وهو يعمل محليًا أولًا ومرخّص بـ Apache-2.0، فلا يغادر جهازك أيُّ شيء من عملك أو بيانات اعتمادك.

الأسئلة الشائعة

1. 01 هل يستطيع Mistral Vibe CLI فعلًا أداء العمل التصميمي؟ +

   نعم — فمع مهارة جمالية ونظام تصميم ومراجع حقيقية في السياق، ينتج Vibe CLI واجهات متجاوبة بجودة الإنتاج، وتحرّر نماذجه من Devstral عبر قاعدة شيفرة واجهات أمامية حقيقية. ودون ذلك السياق يميل إلى اللجوء افتراضيًا إلى مظهر عام، وهي الفجوة التي يسدّها Open Design.

2. 02 كيف أصادِق على Vibe CLI؟ +

   شغّل معالج الإعداد عبر vibe --setup لتسجيل مفتاح API من Mistral (من وحدة تحكّم Mistral)، أو اضبط MISTRAL_API_KEY في بيئتك. ويمكنه أيضًا العمل مقابل نماذج محلية أو متوافقة، دون اتصال بالكامل. ولا يمرّر Open Design بيانات اعتمادك في كل الأحوال.

3. 03 ما الذي يجعل Vibe CLI جيدًا للتصميم تحديدًا؟ +

   هو وكيل مرخّص بـ Apache-2.0 وأصيل في ACP ومدعوم بنماذج Devstral البرمجية مفتوحة الأوزان من Mistral — فيمكنك تشغيله محليًا للعمل الحسّاس للخصوصية والتحرير عبر قاعدة شيفرة حقيقية. لكن الذوق يبقى نابعًا من نظام التصميم والمهارة والمراجع التي توفّرها.

4. 04 Vibe CLI أم Claude Code لتصميم الواجهات الأمامية؟ +

   كلاهما قوي. يُعرَف Claude Code بقراراته التصميمية المحدّدة والمدرِكة لقاعدة الشيفرة؛ أما ميزة Vibe CLI فهي منظومة Devstral مفتوحة الأوزان التي يمكنك تشغيلها محليًا وترخيص Apache-2.0. وتستخدم فِرق كثيرة كليهما — ويتيح لك Open Design تبديل الوكلاء دون تغيير سير عملك التصميمي.

5. 05 كيف أربط Vibe CLI بـ Figma؟ +

   أضِف خادم Figma عبر MCP بوصفه مُدخَل [[mcp_servers]] في ملف config.toml الخاص بك. عندئذٍ يستطيع Vibe سحب سياق تصميمي حقيقي — المكوّنات والمتغيّرات وبيانات التخطيط — فتطابق الشيفرة المُولَّدة المصدرَ بدلًا من تقريبه.

6. 06 هل Open Design تابع لـ Mistral AI؟ +

   لا. Mistral Vibe CLI منتج تابع لـ Mistral AI؛ وOpen Design مشروع مستقل مفتوح المصدر يدعمه بوصفه مُحوّلًا أصيلًا، يُقاد عبر ACP. وMistral علامة تجارية لـ Mistral AI.

7. 07 هل ملفّاتي وبيانات اعتمادي آمنة؟ +

   نعم — فـ Open Design يعمل محليًا أولًا ومرخّص بـ Apache-2.0. تبقى ملفّاتك ونواتجك وملف DESIGN.md في مستودعك الخاص، وتُستخدَم بيانات اعتماد Mistral مباشرةً من قِبل وكيلك، ولا تُمرَّر عبر خوادم Open Design أبدًا.