وكلاء الذكاء الاصطناعي للمصممين: كيف تصمم وتبني مسارات عمل الوكلاء

الفرق بين روبوت المحادثة والوكيل هو الفرق بين مساعد مبتدئ ينتظر رسالتك التالية، ومساعد مبتدئ يذهب وينهي العمل كاملاً.

هذا النوع الثاني هو ما ظهر في أدواتك في الأشهر الثمانية عشر الماضية، ومعظم المصممين لم يلاحظوا ذلك بعد. ما زالوا يكتبون أوامر في نافذة دردشة، ينسخون الإجابة، يلصقونها في Figma، ويتساءلون لماذا يبدو سير عملهم نسخة أسرع قليلاً من عام 2023. التحول نحو الوكلاء ليس "ChatGPT أفضل." إنه تغيير في الفئة بأكملها.

الوكيل يحصل على هدف. يقرر أي الأدوات يستدعي. يستدعيها بالترتيب، يقرأ النتائج، يصحح المسار، ويسلمك شيئاً منتهياً. لم تعد تكتب في دردشة. أنت تعطي إحاطة لفريق صغير وتراجع المُنتَج.

روبوت المحادثة، المساعد، الوكيل، ولماذا يهم الفرق

ثلاث كلمات تُستخدم كأنها تعني الشيء نفسه. لا تعني.

روبوت المحادثة يعمل بالتناوب. تسأل، يجيب، تسأل مجدداً. ChatGPT بلا أدوات، Claude في نافذة دردشة بسيطة، Gemini في التطبيق. السياق هو ما تلصقه. الناتج نص.

المساعد (copilot) مساعدة مدمجة. GitHub Copilot، ميزات AI في Figma، Notion AI. يعيش داخل أداة أخرى ويقترح الخطوة التالية بينما تعمل. لا يخرج من المسار الذي أنت فيه. لا يخطط لعمل متعدد الخطوات.

الوكيل موجَّه نحو هدف. تعطيه نتيجة، لا خطوة تالية. يختار أدواته بنفسه، يستدعيها في حلقة، يفحص تقدمه، ويتوقف حين يتحقق الهدف أو يحتاج مدخلاً منك. المثال الأكثر وضوحاً الآن هو Claude Code يعمل في طرفيتك مع خوادم MCP موصولة، وإن كانت وضعية الوكيل في ChatGPT، ولوحة وكيل Cursor، وComputer Use من Anthropic تتصرف بالطريقة نفسها.

الخلاصة: روبوتات المحادثة تستجيب، المساعدون يُعينون، الوكلاء يُنجزون.

الوكيل حلقة، لا أمر واحد

كل وكيل ستستخدمه يشغّل نفس الدورة الرباعية الخطوات. تعلم هذا الشكل وستستطيع التنبؤ بسلوك أي أداة وكيلة.

1. التخطيط. الوكيل يقرأ الهدف ويقرر الخطوة الأولى.
2. التصرف. يستدعي أداة. يقرأ ملفاً، يستعلم عن API، يشغّل أمراً، يجلب URL.
3. المراقبة. يقرأ ناتج الأداة ويقرر إن كان اقترب من الهدف.
4. التكرار. إن لم ينته، يخطط للخطوة التالية. إن انتهى، يُبلغ.

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

مجموعة أدوات الوكيل للمصمم في 2026

لا تحتاج أن تبني وكيلاً من الصفر. في أبريل 2026، السطح الوكيلي المفيد للمصممين يبدو هكذا.

Claude Code. يعيش في طرفيتك أو داخل VS Code. يقرأ مستودعك كاملاً. يستدعي ملفات، يشغّل أوامر، يتحدث إلى خوادم MCP. الأفضل لكل ما يمس الكود أو الـ tokens أو مستودع نظام التصميم.

Claude Desktop وChatGPT مع MCP. كلاهما يدعم اتصالات MCP الآن. يمكنك وصلهما بـ Figma وGoogle Drive وNotion وLinear ونظام ملفاتك. أفضل للبحث وكتابة الإحاطات والمواصفات والمحتوى، لا للبرمجة.

وضعية وكيل Cursor. وكيل مدمج في المحرر لبناء مشاريع React وVue وSvelte. أقرب إلى Claude Code في ما يفعل، مع واجهة بصرية بدلاً من الطرفية.

Figma MCP. ليس وكيلاً بحد ذاته. موصّل أدوات. يحول Figma إلى مصدر بيانات يمكن لوكيل قراءته. اضبطه مرة واحدة، وكل وكيل يدرك MCP يمكنه الآن رؤية إطاراتك. الإعداد مغطى في Figma MCP: ربط Figma بـ Claude Code ووكلاء الذكاء الاصطناعي.

n8n وZapier agents والسكريبتات المخصصة. إن أردت وكيلاً يعمل بجدول أو يستجيب لـ webhook (تعليق جديد في Figma، إرسال جديد في Google Form، بريد إلكتروني جديد في صندوق مشترك)، هذه هي منصات الاستضافة. المصممون يستخدمونها للوكلاء "اللاصقة"، تلك التي تعمل في الخلفية بينما تنام.

لمعظم المصممين، المجموعة المبدئية الصحيحة هي Claude Code مع Figma MCP واتصال واحد بـ Google Drive أو Notion. هذا يكفي لتغطية تسعين بالمئة من عمل التصميم الوكيلي.

كيف تصمم وكيلاً (ما زال إحاطة)

تصميم وكيل ليس مهمة برمجة. إنه مهمة إحاطة. نفس ما تفعله كل مرة تسلم عملاً لمستقل أو مساعد مبتدئ.

أربعة أسئلة تجيب عليها، بالترتيب، قبل أن تبني أي شيء.

1. ما الهدف؟ جملة واحدة. "إنتاج لوحة مزاج وإحاطة إبداعية قصيرة من نص استكشاف مع عميل."
2. ما الأدوات التي يحتاجها الوكيل؟ اذكرها. "قراءة مستند Google، البحث في الويب، جلب صور، الكتابة في ملف Figma، الحفظ في مجلد Google Drive."
3. ما القواعد التي تقيّده؟ "استخدم فقط صوراً من مصادر تحريرية، لا من التصوير الفوتوغرافي المخزون. لا تخترع علامة تجارية أبداً. اذكر كل مصدر. أنتج الإحاطة دائماً بصيغتنا الداخلية."
4. متى يتوقف؟ "حين يحتوي ملف Figma على إطار لوحة مزاج بـ 12 مرجعاً على الأقل وتُحفظ الإحاطة كـ PDF في Drive المشترك."

افتقد الهدف والوكيل يتشتت. افتقد الأدوات ويرتجل بأدوات خاطئة. افتقد القواعد ويشحن لك متوسط بيانات تدريبه، وهو عادة مخزون وركام AI. افتقد شرط التوقف ويدور إلى الأبد أو يتوقف مبكراً.

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

الوصفة 1: وكيل البحث إلى لوحة المزاج

أول وكيل يجب على كل استوديو تصميم بناؤه. يستهلك نص استكشاف مع عميل وينتج لوحة مزاج أولية وإحاطة إبداعية قصيرة.

الهدف. من نص استكشاف، إنتاج لوحة مزاج في Figma وإحاطة إبداعية في Google Drive.

الأدوات المطلوبة. Google Drive MCP (قراءة النص، كتابة الإحاطة)، بحث الويب، جلب الصور، Figma MCP (الكتابة في إطار لوحة مزاج).

شكل موجّه النظام. هذا هو التعليم الذي تعطيه للوكيل مرة واحدة في بداية الجلسة.

You are a senior brand strategist at Brainy, a design studio with 2M+
community followers. Your job: turn a discovery call transcript into
a first-pass creative direction.

Goal:
- Read the transcript at the Google Drive URL I give you.
- Extract: client name, industry, audience, brand adjectives (3-5),
  competitors mentioned, any visual references they named.
- Produce two deliverables:
  1. A creative brief, saved as a Google Doc in /Brainy/Briefs/
     using our template at /Brainy/Templates/brief.docx.
  2. A Figma moodboard in the file I specify, populated with at
     least 12 editorial image references (no stock photography).

Rules:
- Use only editorial sources: Are.na, It's Nice That, Brand New,
  museum archives, design studio portfolios. Never Shutterstock,
  Getty, or Unsplash generic.
- Every image needs a source URL captioned on the Figma frame.
- Voice for the brief: Brainy house voice. Opinionated on craft,
  neutral on facts. No corporate filler.
- If the transcript is unclear on an adjective, flag it as "needs
  confirmation" in the brief instead of inventing one.

Stop when:
- Brief is saved, moodboard has 12+ captioned references, and you
  have posted the two URLs back to me.

هذه إحاطة وكيل صالحة للعمل. الصقها في Claude Desktop مع اتصالات MCP بـ Drive وFigma، أشِر إليها في نص، وراجع الناتج.

ما تراجعه. هل الصفات صحيحة؟ هل المراجع تناسب العلامة التجارية ولا تميل نحو الواضح؟ هل ضبط كل صورة بمصدرها فعلاً؟ هل الإحاطة بصوت الدار أم عادت إلى الإنجليزية الرسمية؟

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

الوصفة 2: وكيل المواصفة إلى التسليم

هذا الوكيل يُغلق الفجوة بين "صُودق على التصميم" و"المطوّر لديه كل ما يحتاجه." يقرأ ملف Figma ويكتب مستند تسليم الهندسة.

الهدف. بناءً على رابط ملف Figma، إنتاج مستند تسليم مطوّر يحتوي على مخزون المكونات، قائمة الـ tokens، قيم التباعد، والأسئلة المفتوحة.

الأدوات المطلوبة. Figma MCP، مكان لكتابة الناتج (Notion، مشكلة GitHub، Google Doc، اختيارك).

شكل موجّه النظام.

You are a senior design systems engineer acting as the bridge
between a design team and a front-end team.

Goal:
- Read the Figma file at the URL I give you.
- Produce a handoff document containing:
  1. Component inventory: every component instance used, counted,
     with Figma component name and closest existing code component
     name from our /components/ directory.
  2. Token usage: every color, spacing, and typography variable
     referenced, compared against /design/tokens.css.
  3. Layout specs: breakpoints used, any auto-layout frames that
     might be ambiguous at edge cases.
  4. Open questions: a bulleted list of anything in the Figma file
     that cannot be resolved from the file alone (missing states,
     unclear interactions, content placeholders).
- Write the output as a Notion page in /Engineering/Handoffs/.

Rules:
- Never invent a component. If a Figma element does not map to an
  existing code component, list it under "new components required"
  with a one-line description.
- Flag every free-form (non auto-layout) frame as a risk.
- Include the Figma node ID for every item so devs can jump to it.
- Do not assume interactions that are not explicitly in the file.

Stop when:
- Notion page is written and you have posted the URL back to me.

لماذا هذه الوصفة مهمة. مشكلة "ظن المصمم أن التسليم تم، المطوّر لم يجد الـ tokens" كلاسيكية. هذا الوكيل يُزيلها في تسعين ثانية تقريباً لكل ميزة.

أين يخفق. في ملفات Figma الفوضوية. إطارات بلا auto-layout، استخدام متغيرات متضارب، مكونات فردية عشوائية. الوكيل يُظهر الفوضى، وهو إما هدية (الآن تعرف) أو مشكلة (الآن يجب عليك إصلاحها).

الوصفة 3: وكيل ضمان جودة التصميم

الوكيل الذي يعمل بعد النشر ويخبرك بما شُحن بشكل خاطئ.

الهدف. مقارنة رابط staging منشور بملف Figma المرجعي والإبلاغ عن الانحراف البصري.

الأدوات المطلوبة. Figma MCP، Playwright (لالتقاط لقطات شاشة لصفحة الـ staging)، مقارنة الصور (Claude يمكنه مقارنة الصور بشكل طبيعي في وضع الرؤية).

شكل موجّه النظام.

You are a senior product designer doing a pre-release visual QA pass.

Goal:
- Visit the staging URL I give you at three breakpoints: 1440px,
  768px, 375px.
- For each breakpoint, take a full-page screenshot using Playwright.
- Compare each screenshot to the corresponding Figma frame at the
  URL I provide.
- Produce a QA report listing every visual difference, categorized:
  - BLOCKING: wrong components, wrong colors, broken layouts
  - NON-BLOCKING: spacing off by less than 4px, minor type weight
    mismatches, image crops slightly different
  - INFORMATIONAL: intentional differences between design and code
    worth noting

Rules:
- Do not flag differences that are within 2px of intended spacing
  unless they visibly break alignment.
- Include a screenshot-with-annotation for every BLOCKING item.
- Link every item back to the Figma node ID.
- Output as a Markdown file in /qa/reports/ with timestamp.

Stop when:
- Report is saved and you have posted the path back to me.

لماذا هذه الوصفة مهمة. معظم الفرق تُجري ضمان جودة التصميم يدوياً أو لا تُجريه على الإطلاق. وكيل ضمان الجودة يعمل في كل نشر قبل الإنتاج. يُمسك 80% من الانحراف الذي تفوت العيون في الصفحة الثالثة.

كيف يستخدمه المصممون. اربطه بـ CI ليعمل تلقائياً على نشرات staging. أو اتركه يدوياً وشغّله قبل شحن أي شيء مرئي. في كلتا الحالتين، تتوقف عن كونك العائق على "هل شُحن هذا بشكل صحيح."

ما لا يستطيع الوكلاء فعله (بعد)

كن صريحاً مع نفسك. هنا يُخفق الوكلاء في أبريل 2026.

قرارات الذوق. الوكيل سيشحن لك لوحة مزاج كفؤة. لا يستطيع إخبارك أن لوحة المزاج مسطحة عاطفياً أو أن العلامة التجارية يجب أن تذهب أكثر نحو التحفظ. هذا لا يزال أنت.

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

الاستراتيجية الجديدة. الوكلاء ممتازون في تنفيذ استراتيجية حددتها أنت. هم ضعفاء في اختراع واحدة من صفحة بيضاء. التموضع وهندسة العلامة التجارية وقرارات المنتج من المبادئ الأولى هذه لا تزال عمل بشري.

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

أي شيء يحتاج ثقة مع عميل أو شريك. استراتيجي يواجه العملاء، مدير فني يعطي تغذية راجعة لمستقل، مدير إبداعي يعرض فكرة. الوكلاء يُعينون هؤلاء البشر. لا يحلون محلهم.

القاعدة: الوكلاء يتولون التنفيذ. البشر يتولون الذوق والاستراتيجية والثقة.

كيف تُفكر كمصمم وكلاء، لا كمستخدم وكلاء

هناك فرق بين استخدام الوكلاء وتصميمهم. معظم المصممين سينتهي بهم الأمر يفعلان الأمرين.

استخدام الوكيل عمل أوامر. كتابة إحاطة، مراجعة الناتج، التكرار.

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

ثلاثة عادات تُفرق بين من يصمم وكلاء جيدة ومن يتصارع مع وكلاء معطوبة.

أولاً، يكتبون الإحاطة قبل فتح الأداة. لا كتابة حتى يكون الهدف والأدوات والقواعد وشرط التوقف على الورق. يوفر ساعة من التخبط.

ثانياً، يُصدّرون موجّه النظام كالكود. يحفظونه في ملف. يُدرجونه في git إن أمكن. كل مرة يُخفق الوكيل بطريقة جديدة، يضيفون قاعدة. الأمر يصبح أذكى بمرور الوقت، لا أكثر ضجيجاً.

ثالثاً، يراجعون كل تشغيل في العشرة الأولى. لا ثقة بالافتراض. كل ناتج يُقرأ ويُقيَّم ويُستخدم لتحديث الأمر. بعد عشرة تشغيلات الوكيل يصبح موثوقاً بما يكفي للعمل في الخلفية. قبل عشرة تشغيلات لا.

إن أردت المزيد من تحليلات سير عمل AI، تصفح بقية أوراق Brainy. وإن أردت مسارات عمل وكيلة مدمجة في فريقك دون أول ثلاثة أشهر من التعثر، وظّف Brainy وسنشحن المجموعة كاملة.

خطة بدء الوكيل للمصمم

أسبوع واحد، وكيل واحد، حلقة عمل واحدة.

• اختر سير عمل تكرره. ليس سير عمل خيالي. سير عمل حقيقي فعلته هذا الشهر.
• اكتب الهدف بجملة واحدة، قائمة الأدوات، القواعد، وشرط التوقف على الورق.
• أعدّ Claude Code أو Claude Desktop مع اتصال MCP واحد (Figma أو Drive أو نظام الملفات).
• الصق الإحاطة كموجّه نظام. شغّل الوكيل على مدخل حقيقي.
• اقرأ الناتج بنظرة نقدية. قيّمه مقابل ما كنت ستشحنه.
• حدّث الأمر بما أخفق. شغّل مجدداً.
• كرر ثلاث إلى خمس مرات. لاحظ كم يستغرق كل تشغيل مقارنة بفعله بنفسك.
• احفظ موجّه النظام النهائي. هذا أول وكيل إنتاجي لك.

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

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

هل أحتاج إلى برمجة لبناء وكيل ذكاء اصطناعي؟

لا. كل وصفة أعلاه تُهيَّأ من خلال موجّه نظام واتصالات MCP، كلاهما يُعدّ عبر واجهة مستخدم أو أمر واحد. أنت تكتب إحاطات وتوصّل أدوات، لا تكتب كود إنتاجي. إن استطعت تهيئة Zapier، تستطيع تهيئة وكيل.

ما الفرق بين Claude Code ووكيل Claude؟

Claude Code وكيل محدد واحد، ذلك الذي يعيش في طرفيتك ومبني للعمل مع قواعد الكود. "وكيل Claude" هو أي وكيل مدعوم بنموذج Claude، وقد يكون Claude Code أو Claude Desktop مع أدوات أو وكيل مخصص مبني من خلال Anthropic API أو وكيل بأسلوب ChatGPT يستخدم Claude تحت الغطاء. Claude Code هو الوكيل الرئيسي لعمل المصمم المطوّر في 2026.

كم تكلّف تشغيل وكيل؟

للمصممين الأفراد، اشتراك Claude Max أو ChatGPT Plus يغطي Claude Code ووضعية الوكيل على التوالي. يجري هذا في المئات المنخفضة من الدولارات شهرياً ويتضمن معظم الأدوات التي تحتاجها. للفرق، استخدام API يتناسب مع مقدار عمل الوكلاء. الميزانية تبدأ من 50 إلى 200 دولار لكل مصمم شهرياً للاستخدام المكثف. رخيص مقارنة بالوقت الذي يوفره.

أنت تُدير فريقاً صغيراً الآن

كنت مصمماً. تُعطى إحاطات وتُنتج عملاً. هذا لا يزال جزءاً من الوظيفة.

الآن هناك جزء ثانٍ. تكتب إحاطات لفرق صغيرة من الوكلاء تُنتج عملاً بينما تفعل الجزء الأول. تراجع ناتجهم. تصحح لهم حين يتشتتون. تتقاعد الوكلاء الذين لا يثبتون قيمتهم وترقي الذين يفعلون.

المصممون الذين يفهمون هذا التحول أولاً سيمتلكون العقد. ليس لأن الوكلاء يحلون محل المصممين، بل لأن المصممين الذين يُديرون وكلاء يحلون محل المصممين الذين لا يفعلون.

اختر سير عملاً. اكتب الإحاطة. اشحن الوكيل الأول. راجع الناتج. كرر يوم الاثنين.