“القمامة تدخل، والكنوز تخرج”: كبير مصممي أنثروبيك يتحدث عن فلسفة منتج Cowork وحقيقة إطلاقه خلال 10 أيام

整理 & 编译：深潮TechFlow

嘉宾：Jenny Wen，Cowork 设计负责人

主持人：Peter Yang

播客源：Peter Yang

原标题：Claude Cowork Tutorial from Cowork s Design Lead (40 Min) | Jenny Wen

播出日期：2026年3月29日

要点总结

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

精彩观点摘要

حول طريقة العمل اليومية

معظم الأشياء التي أقضي وقتًا في القيام بها، هي طرح المنتج إلى السوق. لكني أعتقد أن هذا قد لا يبدو مثل ما كان عليه قبل سنة أو سنتين. وفي جزء كبير منه، يتمثل الأمر في أننا نجتمع معًا مع المهندسين وأفراد المنتجات، بطريقة غير رسمية إلى حد ما للـ jam (التعاون الارتجالي). عادةً يشاهد الجميع نموذجًا أوليًا واحدًا، ثم يشيرون إليه ويفكرون في كيفية تطوره.

حول فلسفة “قم بإدخال القمامة وإخراج الكنوز”

أكثر ما يدهشني في Cowork هو قدرتها على تنظيم المعلومات. أحب أن أسميها “قم بإدخال القمامة وإخراج الكنوز”. فهي تجمع المعلومات من مصادر مختلفة، ثم تجد بسرعة النقاط الرئيسية فيها، وتستخلص المحتوى ذي القيمة، وتحوله إلى نتائج ذات إنتاجية فعلية.

حول الفرق بين Cowork و Claude Code

بالإضافة إلى العمل الدقيق للغاية في كود الإنتاج (production code)، فإن كل شيء تقريبًا الآن يتم إنجازه باستخدام Cowork. إذا كان هناك موقف يتطلب التركيز على بعض تفاصيل الكود، فأنا ما زلت أستخدم Claude Code. لكن بالنسبة للتواصل والتعاون اليومي، فأنا الآن أعتمد بالكامل على Cowork.

حول قصة نشأة Cowork

تلك المقولة “لقد أنجزوه في 10 أيام” تم اقتطافها في الواقع من مقابلة أو تقرير إعلامي. لكن الحقيقة هي أنه فيما يتعلق بهذا الاتجاه الخاص بـ Cowork، كنا قد بدأنا بالفعل في التفكير منذ أن انضممت إلى Anthropic قبل عام. كنا نفكر باستمرار في كيفية بناء “شريك تفكير” (thinking partner) يمكنه مساعدة جميع العاملين في المعرفة بشكل عام.

على الرغم من أن Claude Code كان قادرًا بالفعل على التعامل بشكل جيد مع المهام المتعلقة بالكود، فإن هدفنا كان تغطية كل سيناريوهات العمل المعرفي. أعتقد أن التحدي الحقيقي كان: كيف سننفذ هذه الفكرة؟ وما نوع البنية المعمارية (architecture) الأنسب؟ وما نوع تجربة المستخدم (UX) التي ستكون الصحيحة؟

حول تطور سير عمل التصميم

ما زلت أستخدم Figma. لكننا لا نقوم بوثائق مواصفات (specifications) بشكل متكرر الآن، وغالبًا أيضًا ليست مفصلة جدًا. ما زلنا نقوم بترتيب الأولويات، وتبقى كوثيقة موجودة، لكن في الغالب تكون مجرد بضع نقاط bullet points، وليست تلك الجداول الجميلة ذات الإفراط في التصميم.

حول التخطيط والرؤية

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

حول مستقبل المصممين

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

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

بداية الحلقة

Peter Yang: مرحبًا بالجميع، أنا متحمس جدًا اليوم لترحيب Jenny، مسؤولة التصميم في Anthropic. ستعرض لنا كيف تستخدم Claude Cowork و Claude Code لتصميم المنتجات وإطلاقها، كما ستشاركنا القصة الداخلية لـ Cowork، وربما تتحدث أيضًا عن الخطوة التالية لمنتجاتها.

Jenny، كيف تبدو يومك النموذجي في العمل؟ ما المهام التي تستحوذ على معظم وقتك؟

Jenny:

لا أعرف إن كان هناك شيء مثل يوم نموذجي، لكن معظم الوقت الذي أقضيه في العمل هو طرح المنتج. ومع ذلك، أعتقد أن هذا قد لا يكون مثل ما كان يبدو عليه قبل سنة أو سنتين. جزء كبير منه—في الحقيقة—هو أننا نتعاون مع المهندسين وأفراد فريق المنتج، بطريقة غير رسمية نوعًا ما للـ jam (التعاون الارتجالي). عادةً يشاهد الجميع نموذجًا أوليًا معًا، ثم يشيرون ويلاحظون ويفكرون في كيفية تطوره. أحيانًا يكون ذلك مجرد مناقشة أداء الميزات، وأحيانًا أعمل أنا على تنفيذ بعض الأشياء. أعتقد أن جزءًا كبيرًا من الوقت ما زال مخصصًا لي في التصميم وصنع النماذج الأولية وما إلى ذلك، لكنني أشعر أن طريقة العمل في التصميم أصبحت أكثر مرونة الآن.

Peter Yang: بشكل أساسي، ستقوم بإنشاء حزمة من النماذج الأولية عبر Claude أو ما شابه، ثم تتعاون مع المهندسين للـ jam، وتقدم ملاحظات، ثم تستخدم الأوامر/الـ prompts لتحسينه من خلال الذكاء الاصطناعي، أليس كذلك؟

Jenny:

في الحقيقة، غالبًا حتى ليست نماذج أولية—بل تكون نماذج أولية عاملة يتم بناؤها داخلنا وتشغيلها عبر بيئات Claude أو Cowork. أنا عادةً أقضي وقتًا باستخدام هذه الوظيفة، ودفعها للأمام، ورؤية قدراتها، وتكوين الآراء. والخطوة التالية غالبًا تكون أن أجلس وأقول للمهندسين: “مرحبًا، هذا ما أفكر فيه. هذه هي الأشياء التي أعتقد أنه ينبغي تعديلها”.

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

Peter Yang: أعتقد أن هذا هو أكثر جزء أستمتع به كمدير منتج أو كمصمم—أن أجمع المصممين والمهندسين معًا، وأرى المنتج يتطور عبر التكرار. لذا أنتم الآن لا تفعلون كثيرًا وثائق تخطيط مثل مواصفات (specs) أو ملفات Figma، أليس كذلك؟ أم أنكم ببساطة تقومون بالتكرار عبر الكود وتبنون النماذج الأولية داخله؟

Jenny:

ما زلت أعمل على Figma. لكننا لا نقوم بوثائق المواصفات بشكل متكرر الآن، وغالبًا أيضًا ليست مفصلة جدًا. نعم. ما زلنا نعمل على ترتيب الأولويات، وتظل كوثيقة موجودة. لكن في الحقيقة هذا يساعدنا عندما نقوم بتسليم الأمور لفريق الأمن أو الشؤون القانونية، حتى يفهموا ما الذي سيتم نشره. لكن غالبًا تكون مجرد نقاط bullet points قليلة. وليست تلك الجداول الجميلة ذات الإفراط في التصميم. وأعتقد أن ملفات Figma لدينا تكون كذلك أيضًا.

عرض عملي لـ Cowork

Peter Yang: هل يمكنك أن تعرض لنا كيف تستخدم هذه المنتجات، أو ماذا تستخدم كل منتج على حدة لإنجازه؟

Jenny:

بالطبع. سأشرح كيف أستخدم Cowork. في الحقيقة، لدي سر صغير: بصرف النظر عن العمل الدقيق للغاية في كود الإنتاج (production code)، فإن كل شيء تقريبًا في الوقت الحالي يتم إنجازه باستخدام Cowork. إذا كانت هناك حالات تتطلب التركيز على تفاصيل كود معينة، فما زلت أستخدم Claude Code. لكن بالنسبة للتواصل والتعاون اليومي، فأنا الآن أعتمد بالكامل على Cowork.

أعتقد أن أكثر ما يدهشني في Cowork هو قدرتها على تنظيم المعلومات. أحب أن أسميها “قم بإدخال القمامة وإخراج الكنوز”. فهي تجمع المعلومات من مصادر مختلفة، ثم تجد بسرعة النقاط الرئيسية، وتستخلص المحتوى القيم، وتحوله إلى نتائج ذات إنتاجية فعلية.

خذ مثالًا: أنا الآن متصل بمجلد يحتوي على بعض ملفات مقابلات المستخدمين. فريق Cowork يهتم جدًا بالحفاظ على علاقة وثيقة مع المستخدمين، وهذه أيضًا واحدة من مفاتيح نجاحنا. نحن نجري بحثًا تقليديًا لتجربة المستخدم (UXR)، ونتحدث مباشرة مع المستخدمين. كما نفعل ذلك بطريقة داخلية للاستخدام الذاتي، مثل أن لدينا قناة Slack مخصصة لجمع الملاحظات. بالإضافة إلى ذلك، نهتم أيضًا بالمناقشات على وسائل التواصل الاجتماعي ونستمع لآراء المستخدمين المتحمسين. وبسبب أننا نحافظ دائمًا على علاقة وثيقة مع المستخدمين، وبسبب قدرتنا على التكرار بسرعة على المنتج، استطعنا تحسينه باستمرار وتحقيق ما نراه اليوم.

لذا ما أفعله الآن هو أنني أخبر Claude: “مرحبًا، لدي هذا المجلد من المقابلات”. لكنني أيضًا أجعل Claude ينظر إلى وسائل التواصل الاجتماعي وReddit وتقييمات عملاء Cowork الأخرى، ويخبرني بما هي أكبر الرؤى. قد يحتاج ذلك إلى بعض الوقت، لأنه يحتاج حقًا إلى معالجة هذا الكم من البيانات وتقطيرها. لكن بإمكانه فعل أشياء مثل أن يطلق أحيانًا وكلاء فرعيين للعمل بالتوازي، وأن يقضي وقتًا في البحث على الويب.

Peter Yang: في عملك الفعلي، هل لديكم شيء مثل تقرير رؤى أسبوعي؟ أي أن يتم تجميع كل شيء تلقائيًا ثم إرساله إليك وفريقك؟

Jenny:

بصراحة، يمكننا القيام بذلك مباشرة عبر Cowork. لدي اعتقاد أن الباحثين لدينا سيكون لديهم واحد يتم إصداره، ولديهم كذلك نسخة يتم ping لي بها على Slack. كما أننا نستمع أيضًا مباشرةً إلى قنوات Slack الداخلية. نحن نعتمد بشكل كبير على المستخدمين الأقوى داخل الشركة لتزويدنا بذلك النوع من الملاحظات المتقدمة. لأن الأشخاص داخل الشركة يرغبون حقًا في أن يكونوا صريحين معك؛ فهم يدفعون الميزات إلى أقصى مدى، وغالبًا ما يكونون أيضًا الأكثر استعدادًا لمواكبتها.

Peter Yang: أعتقد أن هذا بالضبط ما يجب أن يحدث. وأشعر أن معظم الشركات تكون فرقها متباعدة فيما بينها كثيرًا، لكن Anthropic لا يبدو كذلك على الإطلاق.

Jenny:

أعتقد أن هذا جزء مهم من نجاح Claude Code—الإنصات إلى المستخدمين على أرض الواقع. كما أننا نقوم بالكثير من ذلك أثناء استخدام Figma، والكثير من dogfooding الداخلي. لأنه عند التعامل مع أشياء مثل تصميم التفاعل وصقل التجربة، يقوم الأشخاص داخل الشركة فعلاً بالبحث عن تلك التفاصيل. أما المستخدمون الخارجيون، فعادة تكون ملاحظاتهم أكثر حول: “هل هذا مناسب لخط سير المستخدمين لدي؟” لذا يوفر ذلك مستوى مختلفًا تمامًا من الملاحظات.

حدود المستخدمين بين Cowork و Claude Code

Peter Yang: أعرف أن التسويق وإدارة المنتج في Anthropic يستخدمان الآن بشكل أساسي Claude Code للقيام بالعمل، خاصة بعد توفر Claude Cowork داخل Cowork. كيف ترى سيناريوهات الاستخدام المختلفة؟ أو كيف يستخدم الناس Cowork و Claude Code؟

Jenny:

لقد لاحظنا أن النطاق الكلي لتطبيق Cowork يتم توسيعه تدريجيًا، وأنه بدأ يُستخدم في سيناريوهات مشابهة لما كان يُجرّب فيه العملاء المتقدمون الذين سبقوا في استخدام Claude Code. هل تتذكرون عندما كنا نبدأ بتطوير Cowork؟ كانت فرق المبيعات الداخلية هي مصدرنا الرئيسي للمعلومات. بعض هؤلاء كانوا من المستخدمين المتعمقين لـ Claude Code، ويستخدمونه لإنشاء قوائم العملاء المحتملين وكتابة نصوص المكالمات الهاتفية وغيرها. عندما رأيت هذه الاستخدامات لأول مرة، شعرت بالدهشة لأنني لم أكن أتوقع حتى أن Claude Code يمكن أن يُستخدم لإنجاز هذه المهام.

لكن الآن، هؤلاء المستخدمون تحولوا تقريبًا بالكامل إلى Cowork، وحتى زملاؤهم بدأوا باستخدام Cowork بشكل متكرر.

والسبب هو أن لديه واجهة UI جميلة، وهذا ما أعتقد أنه يحتاجه حقًا. وهناك أيضًا سبب آخر: أنه قريب جدًا من العمل الآخر الذي يقومون به. فهم أصلًا يستخدمون ميزة الدردشة، ومن تطبيق سطح المكتب يمكنهم أيضًا الاستمرار باستخدام Claude Code، لذا أشعر أنه أكثر مواءمة لسير عملهم الحالي من مجرد فتح سطر الأوامر.

من الرؤى إلى Artifact قابل للتنفيذ: التدفق الكامل

Jenny:

لدي هنا سبع موضوعات مختلفة، وكل أسبوع تكون مختلفة. يمكنني في الأساس أن أخبره مباشرة: “ساعدني في إنشاء هذه الوثيقة X”، وأنها ستكون موجودة تلقائيًا ضمن مجلد على جهاز الكمبيوتر الخاص بي. ويمكنني أيضًا تشغيل مهمتين متوازيتين في الوقت نفسه. على سبيل المثال: “هذه الرؤى رائعة، لكن بناءً على هذه، ما هي ميزات المنتج التي يجب أن أبدأ فعلاً في بنائها؟” ثم يمكنني أيضًا بالتوازي القيام بشيء آخر: تحويل محتوى وثيقة الرؤى التي ساعدتني بها إلى عرض تقديمي يمكنني مشاركته مع الفريق خلال kickoff هذا الأسبوع.

لكن في النهاية، من هنا أبدأ في تصميم التدفق—ستعطيني خيارات لميزات مختلفة. ومن هناك يمكنني حتى أن أجعل Claude يساعدني في إنشاء بعض الـ wireframe لهذه الميزات. قد يمنحني كمية كبيرة من الخيارات المختلفة، ويمكنني نقلها إلى Figma لتفصيلها فعليًا، أو إلى Claude Code بحيث نستخدم مكونات نظام التصميم (design system) الخاصة بنا لبناء شيء حقيقي، ومن ثم أبدأ من تلك النقطة.

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

Peter Yang: كل شيء يتعلق بالتكرار، كل شيء يتعلق بالتكرار. الآن صرت أتكاسل أكثر، وأنا أطلب من الذكاء الاصطناعي أن يفعل النسخة الأولى أولًا، ثم أنا أعود لأتفاعل معه.

Jenny:

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

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

المهارات وقاعدة المعرفة الشخصية

Peter Yang: ما المهارات (skills) التي تستخدمها؟ أو هل لديك مهارات مخصصة لك شخصيًا لإنشاء هذه الوثائق والعروض الشرائح؟

Jenny:

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

Peter Yang: مثلًا، لدي skill للكتابة يقول للذكاء الاصطناعي ألا يستخدم تلك الكلمات العشوائية/المزيفة للذكاء الاصطناعي (AI slop words).

Jenny:

لكن في الحقيقة، اكتشفت الآن أن استخدام مجلدات Cowork—حيث وضعت فيها كل ملاحظاتي الشخصية—يفهم طريقتي في العمل من خلال هذه المجلدات، وبالنسبة لي أصبحت مفيدة جدًا. بل أشعر أنني لا أحتاج إلى memory وskills أكثر فأكثر، لأن لديه أساسًا قاعدة معرفة عني. بالطبع ما زلت أرى أن skills لديها حالات استخدام مناسبة، لكن بالنسبة لحالات الاستخدام التي لدي حاليًا، أشعر أن الحاجة إلى ذلك أقل بكثير.

Peter Yang: هل لأن ذلك يحدث تحديثًا للذاكرة تلقائيًا كل يوم بناءً على محادثاتك؟

Jenny:

نعم. في الأساس إنه memory أحافظ عليه أنا بنفسي، لأنني طوال الوقت أدون الملاحظات بداخله.

عقد تعاون الفريق

Peter Yang: إذًا في أي مرحلة من العملية تجلب الفريق إلى الصورة؟ أو أنك تقوم أنت وAI بالتكرار أولًا ثم تبدّلان ذهابًا وإيابًا مع الفريق، أم كيف يتم ذلك؟

Jenny:

قصدي هو أن أشياء مثل مقابلات UXR الحقيقية—أنا لا أقوم بها وحدي. إما أن مدير المنتج هو من يفعلها، أو باحث داخل الفريق، أو شخص آخر داخل الفريق. وبعد ذلك، من خلال ذلك، يمكنك مشاركة الـ artifact مباشرة، وهذا يجعله يصبح بالفعل مرجعًا لتشغيل الفريق.

فريقنا—على الأقل—يميل لأن يكون bottom-up للغاية وديمقراطيًا. لذلك طريقة عملنا هي: نضع الرؤى والأهداف أمام الجميع، ثم يقوم كل شخص ببناء نماذج أولية وتجربة أشياء، وتأتي الأفكار من كل الاتجاهات. ليست المسألة أنني كمصممة يجب أن أفكر في كل الحلول. بل: “مرحبًا، هذه رؤى. وهذا هو الهدف الذي سنحاول الوصول إليه هذا الشهر. كيف يمكننا جميعًا أن نصل إليه معًا؟”

أعتقد أنه مع ذلك، لن نُسلم كل شيء مباشرة إلى Claude. ما زلنا نعتمد على أنفسنا لاتخاذ الكثير من القرارات، ونعتمد على قدرتنا على إدارة ما يجب بناؤه حقًا والقيام به.

Peter Yang: عندما يتحدث الناس على الإنترنت عن الذوق وقدرة الحكم، فأعتقد أن طرق تدريب هذه القدرات هي—في الواقع—من خلال الحصول باستمرار على كمية كبيرة من ملاحظات المنتج من الداخل والخارج. في هذه العملية، ستتكون لديك تدريجيًا نوع من الحدس الذي يتيح لك التقاط أين توجد المشكلات وما يحتاج إلى إصلاح. لأنك تستمع كل يوم وتعالج هذه الملاحظات، ومع مرور الوقت، تتطور لديك حساسية قوية تجاه المشكلات.

Jenny:

بالنسبة للتصميم، إحدى وظائف Claude هي أنه يمكنه توليد رسومات أولية تشبه wireframe، وتقديم عدة خيارات تصميم. كـممصممة، أحب هذا الأسلوب. حتى لو لم تكن هذه الرسومات دقيقة جدًا، فهي تجعلني أرى الاحتمالات المختلفة بشكل بديهي دون أن أعتمد كليًا على خيالي. يساعدني هذا على اتخاذ قرار أسرع حول اتجاه التصميم التالي.

لذلك أعتقد أن السماح لـ Claude بتوليد هذه الخيارات الأولية مباشرة يمكن أن يوفر علي وقتًا وجهدًا في صنع الـ wireframe يدويًا. من بين هذه الخيارات، سأختار اتجاهًا، ثم أبدأ بتكرار محدود حوله. بعدها، قد أستخدم الكود لتحويل هذا الاتجاه إلى نموذج أولي أولي، ثم أواصل تحسين التصميم وتدقيقه بناءً على ذلك.

القصة الحقيقية وراء نشأة Cowork

Peter Yang: دعنا نتحدث عن كيف نشأ Cowork. هناك الكثير من القصص في الخارج حول أنه تم إنجازه خلال 10 أيام، لكن في الحقيقة، ألا تكون قد مررت به بالفعل العديد من التكرارات قبل ذلك؟

Jenny:

في الحقيقة، المقولة “لقد أنجزوه في 10 أيام” تم اقتطافها من مقابلة أو تقرير إعلامي، واستمر الجميع في النقاش حول هذه النقطة. لكن الحقيقة هي أنه فيما يتعلق باتجاه Cowork، فقد بدأنا بالفعل التفكير في ذلك منذ أن انضممت إلى Anthropic قبل عام. كنا نناقش دائمًا كيفية بناء “شريك تفكير” (thinking partner) يمكنه مساعدة جميع العاملين في المعرفة بشكل عام.

على الرغم من أن Claude Code كان قادرًا بالفعل على معالجة المهام المتعلقة بالكود بشكل جيد، فإن هدفنا كان تغطية كل سيناريوهات العمل المعرفي. أعتقد أن التحدي الحقيقي كان: كيف ننفذ هذه الفكرة؟ وما هي البنية المعمارية الأكثر ملاءمة؟ وما هي تجربة المستخدم (UX) الصحيحة؟

على مدار العام الماضي، حاولنا العديد من تصاميم النماذج الأولية، وكانت بعض الأفكار أكبر طموحًا حتى من أهدافنا الحالية. أجرينا أيضًا الكثير من التجارب التقنية، وقمنا باختبار إطار عمل AI وكلاء (AI agent frameworks) مختلفة. لكن بعض هذه المحاولات لم تنجح. في النهاية، حددنا تدريجيًا الاتجاه الذي نعمل عليه الآن. لم نكتفِ بالاستفادة من النماذج الأولية التي طورتها فرق المختبر، بل درسنا أيضًا النماذج الأولية التي بنيناها داخل فرق المنتج. في النهاية، كانت التوقيت والقدرة على التنفيذ هما العاملان الحاسمان—مثلما أصابت البرق الهدف تمامًا.

عندما قررنا إصدار هذا المنتج، كانت العملية سريعة جدًا. من “يجب أن نصدره” إلى “المنتج تم تشغيله”، استغرق الأمر 10 أيام فقط. يعود ذلك أساسًا لأننا رأينا إمكاناته خلال إجازات Claude Code. خلال الإجازة، وجد كثيرون أخيرًا وقتًا لتجربة Claude Code، بل حتى بعض المستخدمين غير التقنيين بدأوا باستخدامه. على سبيل المثال، يستخدمونه لتحليل تفريغ/نص بودكاست، أو لإجراء تحليلات بيانات معقدة، وغيرها. لقد اكتشفنا أن إطار عمل وكلاء Claude Code بدأ يظهر توافقًا مبكرًا بين المنتج والسوق حتى لدى غير المتخصصين تقنيًا.

في الواقع، كان لدينا نموذج أولي يعمل داخل الشركة، وكان مخططًا لإصداره لاحقًا قليلًا. لكن هذه الملاحظات جعلتنا ندرك: “الآن هو الوقت الأفضل”. لذلك قررنا اغتنام الفرصة، وانتهى بنا الأمر إلى تلك الـ 10 أيام الجنونية.

Peter Yang: إذا لم أكن قد فهمت خطأ، ففي العام الماضي شاركتم الكثير من النماذج الأولية داخل Slack الداخلي، وجمعتم كمًا كبيرًا من الملاحظات، ثم حددتم نموذجًا أوليًا قابلاً للتنفيذ. وبعد ذلك، لأنكم رأيتم الطلب من السوق عليه، قمتم بسرعة بإنجاز sprint واحد وأطلقتم المنتج.

Jenny:

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

التكرار المبكر للتصميم: من أداة workflow إلى Chat بسيط جدًا

Peter Yang: هل يمكنك مشاركة بعض خبرات حول التكرارات المبكرة، أو عرض شيء كان قيد التطوير؟

Jenny:

بالطبع. لقد رتبت خصيصًا مجموعة من لقطات الشاشة المبكرة لأعرض فكرة تصميمنا في ذلك الوقت وعملية التكرار.

في وقت مبكر من هذا العام، كان لدينا نموذج أولي مبكر أنجزته أنا مع مصمم آخر. في ذلك الوقت، حاولنا جعل هذه الأداة أكثر توجّهًا للمهام (task-oriented) أو أكثر توجّهًا لسير العمل (workflow-oriented). لأننا كنا قلقين كثيرًا بشأن ما إذا كان المستخدمون سيستوعبون كيفية استخدام منتج مثل Cowork لإنجاز مهام معينة أو تحقيق نتائج واضحة (outcome). مثلًا إنشاء لوحة معلومات (dashboard)، أو دمج بيانات قادمة من مصادر مختلفة. لذلك، في ذلك الوقت، صممنا واجهة المستخدم بشكل هيكلي جدًا، شبه أداة سير عمل. مثلًا: “أضف هذه المحتويات—هذه هي المدخلات (inputs)، وهذه هي المخرجات (outputs)”. وكانت وظيفة الدردشة موجودة في موضع ثانوي.

لكن بدا الأمر وكأنك تحتاج القيام بعدد كبير من الخطوات لإنجاز شيء. وفي عصر 2025—لماذا يجب علينا تعقيدها إلى هذا الحد؟ ألا يمكن أن يقوم Claude بكل ذلك مباشرة؟

كانت هذه واحدة من اتجاهات تصميمنا المبكرة، لكن في النهاية قررنا تغيير الفكرة ليصبح الأمر أبسط، مثل صندوق دردشة (chat box). حاولنا توجيه المستخدمين لتحقيق أهداف أكثر تحديدًا، مثل تحليل أو توليد وثائق. كما صممنا نموذجًا أوليًا وظيفيًا: عندما ينقر المستخدم، يرى مجموعة خيارات، وكل خيار به زر لضبط شيء ما—مثل طول الوثيقة، أو اختيار نوع الوثيقة مثل ملاحظات أو عرض تقديمي. لكن التصميم النهائي جعل المستخدمين يشعرون بأنه معقد جدًا ومُرهق.

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

في النهاية، النسخة التي أطلقناها قبل بضعة أسابيع هي تقريبًا كما تراها الآن. لقد حاولنا تجربة مستخدم تشبه “وضع المعالج” (wizard-like)، حيث ينقر المستخدم ويرى تلميحات مثل: “أنشئ وثيقة، طولها ثلاث إلى خمس صفحات” وما إلى ذلك.

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

الآن، الواجهة التي تراها مبسطة بشكل كبير. أزلنا الأشرطة الجانبية الثقيلة (sidebars)، وجعلناها أقرب إلى صندوق دردشة تقليدي. لكن على الصفحة الرئيسية، أجرينا بعض التغييرات بحيث تبدو أكثر كـ “قائمة مهام” (to-do list) يشترك في مشاركتها كل من أنا وClaude، بدل أن تكون أداة دردشة مليئة باقتراحات وتوجيهات معقدة.

Peter Yang: ربما يمكنها في المستقبل دعم عدة وكلاء (agent)، ويمكنك سحب المهام عليها لإدارة سير العمل.

Jenny:

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

التموضع المختلف بين Cowork و Claude Code

Peter Yang: أثناء استخدام Claude Code، كنت كثيرًا ما أشارك ملاحظات عبر تويتر. لديه العديد من الأوامر عبر السلاش (slash commands) المدمجة التي يحتاج المستخدم إلى تعلمها خطوة بخطوة. هذه التجربة تشبه نوعًا من “صيد الكنوز” (treasure hunt) عندما تذهب للتسوق في Costco. أنت لا تعرف أبدًا ما هي الوظائف الجديدة التي ستجدها.

لكن بالنسبة للمبتدئين، هذا الأسلوب ليس لطيفًا/مناسبًا لهم. إنه يشبه لعبة، ومع مرور وقت الاستخدام ستبدأ في فهمه والتعود عليه. أشعر أن Cowork ربما كان يحاول استكشاف منطقة وسط بين أدوات الدردشة العادية وClaude Code. فهو لا يخفي كل الميزات خلف الكواليس، وفي الوقت نفسه يمكنه—بطريقة ما—توجيه المستخدمين لاستخدامه بشكل أفضل.

Jenny:

نعم. Cowork تدعم أيضًا استخدام الأوامر عبر السلاش (slash commands)، لكنها ليست طريقة التفاعل الأساسية. من وجهة نظري الشخصية، Cowork على الأقل أداة موجهة للمحترفين. لقد لاحظنا أن العديد من المستخدمين يستخدمونها بالفعل بطريقة مستخدمي خبراء (power users). كما ظهرت في المجتمع بالفعل مجموعة من مستخدمي الخبراء. هؤلاء عادةً مستعدون لاستثمار الوقت لتعلم الوظائف الأكثر تعقيدًا—مثل إنشاء skills بأنفسهم، ومشاركتها مع الفريق، أو استخدام الأوامر المختصرة (shorthand commands).

لكن هدفنا هو أن تصبح هذه الوظائف طريقة تفاعل ثانوية وليست محتوى تعليميًا إلزاميًا. أي أنه حتى لو لم يكن المستخدمون يعرفون كل الأوامر، يمكنهم استخدام Cowork بسهولة. نريد أن يكون تفاعل المستخدم مع Claude طبيعيًا وبديهيًا، وليس شيئًا يتطلب تذكر سلسلة كاملة من الأوامر للقيام بالأشياء.

عملية التخطيط والرؤية

Peter Yang: كيف تبدو عملية التخطيط في Anthropic؟ هل تقومون بإجراء تخطيط سنوي وتحديد أهداف؟ أم تعتمدون أكثر على تطوير النماذج الأولية والتجربة المستمرة؟

Jenny:

أسلوبنا في التخطيط يختلف في كل مرة. في الفريق الذي أعمل فيه، نقوم بخطط شهرية. لدينا جدول بيانات (electronic spreadsheet). وعلى الأقل في جزء Cowork، ندرج عادةً حوالي 12 مهمة بحد أقصى، وكلها مهام ذات أعلى أولوية (P0). لكل مهمة يوجد شخص مسؤول مباشر (DRI). ونراجع أسبوعيًا: هل ما زلنا على المسار الصحيح؟ كما نقوم أيضًا ببعض التخطيط ربع سنوي أو نصف سنوي. غالبًا ما يقوم شخص ما بتحديد اتجاه مثل: “أعتقد أننا ينبغي أن نتجه بهذا الاتجاه. وهذه هي الأشياء التي نحتاج للتركيز عليها”. لكن هذه التخطيطات ليست صارمة لدرجة أنه يجب تنفيذ مشاريع محددة. فهي أكثر لتوفير اتجاه عام للفريق، لذا تكون مرنة نسبيًا.

Peter Yang: مرنة نسبيًا، صحيح؟ ومن المثير للاهتمام أنني وجدت أن أكثر الشركات ابتكارًا غالبًا ما تقوم بقدر أقل من التخطيط السنوي، وتقوم أكثر بالتكرار المستمر والتعلم من المستخدمين. هل قمت بشيء مشابه لـ North Star vision deck في حياتك المهنية؟ وهل تعتقد أن هذا مفيد؟

Jenny:

لقد فعلت ذلك بالفعل. العام الماضي قمت بإعداد North Star vision deck. أعتقد أن للرؤية قيمة فعلية. فهي توجه الفريق وتساعدنا على البقاء واضحين فيما سنقوم به في العمل القادم. لكن لأن مجالنا التقني يتغير بسرعة شديدة، وتظهر نماذج جديدة باستمرار، وتزداد سرعة التحديث كذلك، فإن وضع رؤية لسنة واحدة غير واقعي بالنسبة لنا، ناهيك عن رؤية لمدة سنتين إلى خمس سنوات بسبب وجود الكثير جدًا من العوامل غير المعروفة.

ومع ذلك، تكمن القيمة الحقيقية للرؤية في توجيه الجميع للمضي في اتجاه واحد، خصوصًا في بيئة يمكن للجميع فيها بناء مشاريع مختلفة بحرية. لذلك، أعتقد أن مدة الرؤية الأكثر منطقية بالنسبة لنا هي من 3 إلى 6 أشهر، ويمكن عرضها على شكل وثيقة. أشعر أن الرؤية تكون أكثر تأثيرًا عندما تكون قابلة للتصور/المرئية. وهذه هي القيمة الكبيرة للتصميم أيضًا—أن يكون قادرًا على تجميع عناصر مختلفة معًا، والسرد بقصة متماسكة خلال فترة زمنية محددة. بالطبع يمكن أن تكون الرؤية أيضًا نموذجًا أوليًا، وليس مجرد deck ثابت. يمكن أن تساعدنا في تنسيق العمل بين الفرق، خاصة عندما يكون لدينا خمسة فرق تتعامل مع مشاريع متشابهة جدًا أو قد تكون متعارضة. يمكن للتصميم أن يساعد عبر “القيادة/التنسيق” (curation) في توحيد الأفكار وتوضيح طريق نحو تجربة مستخدم مثالية بدل أن تظل التجربة مشتتة.

Peter Yang: إذًا هل لديكم مراجعات من مديرين للمنتج؟ أو مراجعات للأشخاص المعنيين؟ هل هذه المراجعات رسمية؟ أم أنهم يشاركون أيضًا في تصميم النماذج الأولية؟

Jenny:

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

نصيحة للمصممين: كيف تجد مكانك في عصر الذكاء الاصطناعي

Peter Yang: إذًا، بالنسبة لأولئك المصممين الذين يشعرون بأن بيئة عملهم تتغير بسرعة، ما نصيحتك لهم؟ هل عليهم البدء في تعلم تقديم كود (PR)؟ أم أن المصممين عليهم اتباع طرق أخرى للتكيف؟

Jenny:

إذا شعرت أن الأرض تحت قدميك تتحرك، فهذا لأن الأمر يتغير بالفعل. علينا أن نعترف بذلك، ونتعلم التكيف، وفي الوقت نفسه نعود ننظر لطريقتنا الحالية في العمل بروح منفتحة. أعتقد أن التغيير يؤثر على المصممين الآن بشكل كبير، خصوصًا لأننا في “الموجة الثانية” من هذا المدّ. أدوار مهنية أخرى مرّت بتحول مشابه من قبل، والآن جاء دورنا. بالتوازي، أدوات التصميم لدينا تتطور باستمرار.

في كل مرة أشعر أن مسيرتي المهنية تواجه تحديًا، أشعر بقلق خفيف. مثل: “يا إلهي، عملي يتغير بشكل ضخم، وربما لن يعود الناس ينظرون إليه بنفس القيمة كما كانوا يفعلون سابقًا”. لكن في تلك اللحظات، أتذكر زملائي المهندسين. لقد مر عملهم بتغييرات هائلة منذ وقت طويل، لكنهم لم يتكيفوا فقط مع هذه التغييرات؛ بل واجهوا التحديات بالشجاعة الكبيرة والتواضع، وفي النهاية حققوا نتائج عمل أكثر كفاءة وتميزًا. هؤلاء هم مصدر إلهامي—وأقول لنفسي: إذا كان بإمكان هؤلاء الزملاء الذين أحترمهم كثيرًا أن يفعلوا ذلك، فأنا أيضًا يمكنني فعل ذلك. إنهم نموذج يحتذى به للتكيف مع التغيير.

Peter Yang: من نوع ما، هذه التغييرات تخلص المصممين من جزء كبير من العمل المتكرر الممل، مثل عدم الاضطرار لقضاء الوقت في ضبط كل تلك الإطارات والأطر، أليس كذلك؟ وبهذا يمكنك تخصيص المزيد من وقتك للتفكير على مستويات أعلى والعمل الإبداعي.

Jenny:

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