Beyond Components: The Future of AI UI | Ruben Casas at Agent Conf 2026

Watch on YouTube

Now Playing

Transcript

726 segments

0:22

حسناً، مرحباً

0:23

بالجميع. أنا سعيد

0:25

لأنكم لا تزالون هنا.

0:27

أعلم أننا قضينا يومين

0:28

رائعين من المحادثات،

0:29

لكن المحادثات

0:30

الأخيرة تكون صعبة

0:31

حقاً. لكن آمل أن يكون

0:33

هذا العرض مثيراً

0:34

للاهتمام. سأتحدث عن

0:36

المستقبل. وقبل أن

0:37

نتحدث عن المستقبل،

0:39

وهذا العرض بعنوان "ما

0:41

وراء المكونات"، يجب

0:43

أن نتحدث عن الماضي

0:44

والحاضر. سابقاً،

0:46

عندما بدأ كل هذا، كنا

0:48

نستخدم ChatGPT، وأول شيء

0:51

فعلته عندما صدر هو: "

0:53

يا ChatGPT، أنشئ لي مكون

0:55

React". وقد أنشأ هذا

0:57

المكون. أخذته، وكان

0:59

علي أن أطلب منه

1:00

تحديداً: "أعطني نصاً".

1:02

"لا تعطني نصاً، فقط

1:03

أعطني شيئاً يمكنني

1:05

نسخه ولصقه". وهذا ما

1:06

فعله بالضبط. نسخت،

1:07

ولصقت، وعمل الأمر

1:09

بنجاح. حسناً، في بعض

1:10

الأحيان لم يكن يعمل.

1:11

وكان ذلك أمراً مذهلاً

1:13

حقاً. نحن نتحدث عن قبل

1:14

3 سنوات، تعلمون، هذا

1:15

النمط من النسخ واللصق

1:17

، الإصلاح، والتكرار.

1:18

لم يمضِ وقت طويل على

1:19

ذلك، وهذا ما أسميه "

1:21

برمجة الفقراء". كانت

1:23

هذه هي برمجتنا في ذلك

1:25

الوقت. وكان الأمر

1:26

مثيراً للغاية. والآن

1:27

عندما ننظر إلى ذلك،

1:28

نقول: "ماذا؟ هل كنتم

1:30

تفعلون ذلك حقاً؟" نعم.

1:32

وقد نجح الأمر نوعاً

1:33

ما. كان بدائياً. كان

1:35

مثيراً. بالتأكيد، لم

1:39

نعتقد حينها أن

1:40

النماذج اللغوية

1:41

الكبيرة ستكتب كوداً

1:43

أفضل منا أو تبني

1:45

واجهات مستخدم أفضل.

1:48

لكن الأمور تحسنت،

1:50

وتحسنت بسرعة كبيرة

1:53

جداً. لقد مر الآن ما

1:56

يقرب من عام على ما

1:58

أعتقد أنه الوقت الذي

2:00

تغير فيه كل شيء.

2:02

بالعودة إلى عام 2025،

2:03

في الشهر الأخير من 2025

2:05

، أعتقد أن كل شيء تغير

2:08

تماماً في مجالنا.

2:09

عندما أدركنا جميعاً: "

2:11

أوه، كل شيء أصبح

2:12

مختلفاً الآن". هذا هو

2:13

الوقت الذي توقف فيه

2:14

معظمنا عن كتابة الكود

2:16

. أعني، كم منكم يكتب

2:17

الكود يدوياً الآن؟ هل

2:18

هناك من يكتب الكود؟

2:20

لا؟ هل هناك من يقرأ

2:22

الكود؟ آه، حسناً.

2:24

حسناً، بعضكم لا يزال

2:25

يقرأ الكود، لكنكم لم

2:27

تعودوا تكتبونه. لأن

2:28

ما حدث في عام 2025 كان

2:30

يعود جزئياً إلى إطلاق

2:33

نموذجين مهمين للغاية.

2:35

ChatGPT 5.2 و Opus 4.5. أعني،

2:39

هذه نماذج قديمة جداً

2:40

الآن. شخص ما قال لي: "

2:42

أنا ما زلت أستخدم Opus

2:43

4.5". فقلت له: "واو، هذا

2:45

نموذج عتيق جداً". لم

2:46

يمر عليها سوى عام

2:47

واحد. لكنها كانت جيدة

2:48

حقاً. هذان النموذجان

2:50

ينشئان واجهات مستخدم

2:51

عالية الدقة. كانت

2:52

بارعة حقاً في إنشاء

2:54

واجهات جميلة ومدروسة

2:56

أحياناً. وكان الأمر

2:58

سريعاً جداً. تجربتي

3:00

عندما استخدمت أحد هذه

3:02

النماذج قبل عام وطلبت

3:04

منها: "مهلاً، أنشئ لي

3:06

شيئاً ما". أنشأت أمراً

3:08

مباشراً لمدونتي وقلت:

3:10

"مهلاً، أعد صياغة هذه

3:12

المدونة لي". كانت جملة

3:14

واحدة فقط، دون أي

3:15

هندسة للأوامر أو غير

3:17

ذلك. وقد قدمت واجهة

3:19

مستخدم جميلة حقاً مع

3:20

تفاعلات وإمكانية

3:21

وصول. أعني، نحن ننظر

3:23

إلى هذا الآن ولا يبدو

3:24

مبهراً جداً، لكننا

3:25

نتحدث عن قبل عام أو

3:26

عام ونصف. حينها أدركت:

3:28

"حسناً، هذه النماذج

3:29

بارعة حقاً في إنشاء

3:31

واجهات المستخدم".

3:32

وهكذا، في غضون ثلاث

3:34

سنوات، انتقلنا من

3:36

مجرد بضعة أسطر برمجية

3:38

من ChatGPT ننسخها

3:40

ونلصقها لتعمل. لقد

3:42

أصبح الأمر تطبيقاً

3:43

كاملاً متكاملاً،

3:44

والآن من يدري ما هو

3:46

القادم، وهذا ما

3:47

سنتحدث عنه اليوم. لذا

3:49

، السؤال المطروح

3:51

عليكم هو: إذا كانت هذه

3:52

النماذج بارعة جداً في

3:54

إنشاء واجهات مستخدم،

3:56

واجهات جيدة جداً، وهي

3:58

أفضل منا أو من معظمنا

4:00

في برمجة الواجهات

4:02

الأمامية، وأنا

4:03

شخصياً لا أمانع، فلم

4:05

أعد أهتم بكتابة

4:06

الأكواد. فلماذا لا

4:09

نزال عالقين في هذه

4:11

الطريقة التقليدية

4:12

الساكنة لعرض واجهات

4:14

المستخدم؟ لماذا لا

4:17

نزال عالقين في عصر

4:19

المكونات المحددة

4:20

مسبقاً حيث كل شيء

4:22

ثابت وليس مولداً

4:23

برمجياً؟ أين هي لحظة "

4:25

جارفيس" التي ننتظرها

4:27

جميعاً؟ هذه الميم (

4:29

الصورة الساخرة) لم

4:30

تعد ممتعة بعد الآن

4:31

لأن الجميع يستخدم هذا

4:32

التشبيه، لكن سأوضح

4:33

لكم في النهاية لماذا

4:35

لا أعتقد أنه تشبيه

4:36

جيد. على أية حال، اسمي

4:38

روبن. لقد كنت أعمل على

4:39

تطبيقات MCP. أنا أحد

4:41

الرواد في مجال

4:42

تطبيقات MCP. أعمل في

4:43

شركة بوستمان. وقد كنت

4:45

أبحث في موضوع

4:45

الواجهات المولدة

4:46

برمجياً وتوليد

4:47

الواجهات باستخدام

4:48

النماذج اللغوية

4:49

الكبيرة طوال العام

4:50

الماضي. وإليكم القصة.

4:52

لدينا حاسوب جديد.

4:54

أعتقد أن النماذج

4:55

اللغوية الكبيرة هي

4:56

وسيلة جديدة للتفاعل

4:57

مع الآلات، وهي بمثابة

4:59

حاسوب جديد. وقد قال

5:00

أندريه كارباثي هذا

5:02

أيضاً. قال إن التحدث

5:04

إلى نموذج لغوي كبير

5:06

اليوم أو التفاعل معه

5:08

يشبه كثيراً التفاعل

5:10

مع الطرفية (Terminal) في

5:12

السبعينيات. كما

5:13

تعلمون، عندما ظهر

5:14

الحاسوب، كنا نعتاد

5:16

على التعامل بالنصوص

5:17

فقط. مجرد نصوص في

5:19

الواجهات. لم تكن هناك

5:20

واجهات رسومية. لم يكن

5:22

هناك أنظمة تشغيل مثل

5:23

ويندوز بأشياء يمكنك

5:25

التفاعل معها. كان

5:26

الأمر مجرد نص. وهذا

5:28

مشابه جداً لما لدينا

5:30

اليوم. الواجهة

5:32

الرسومية للمستخدم لم

5:33

تكن قد اخترعت بعد.

5:35

كأننا لا نزال في

5:37

السبعينيات، نتفاعل

5:38

مع النماذج اللغوية

5:40

الكبيرة بالنصوص فقط.

5:42

الآن، لا نزال نحاول

5:44

معرفة ما هي الواجهة

5:45

المناسبة. إذن، إذا لم

5:47

تكن نصوصاً، فما هي

5:49

الواجهة للنماذج

5:50

اللغوية الكبيرة؟ ما

5:52

هي واجهة هذا الحاسوب

5:53

الجديد؟ وما يفعله

5:56

الجميع الآن هو

5:57

الدردشة. ويتم إضافة

5:59

الدردشة إلى معظم

6:01

المنتجات. وبعض الناس

6:03

لا يحبون ذلك. بعض

6:04

الناس، كما تعلم، يرون

6:06

صفحة هبوط وأول شيء

6:08

يواجههم الآن بدلاً من

6:09

المنتج هو واجهة دردشة

6:11

. وكل شركة تحاول إضافة

6:12

الدردشة إلى واجهة

6:14

المستخدم الخاصة بها.

6:15

ها هي واجهة الدردشة.

6:17

لكنني أعتقد أن

6:18

الدردشة ليست الشكل

6:19

الأكثر كفاءة أو الشكل

6:21

النهائي. هل هي أفضل

6:23

شيء لدينا الآن؟ لكن

6:24

الناس يتساءلون أيضاً:

6:26

"حسناً، إذا لم تكن

6:27

دردشة، فماذا تكون؟""

6:29

إذاً ما هي؟" ومؤخراً

6:31

بدأ الناس يقولون: "أوه

6:32

، لا تجعلوني أتحدث

6:33

إلى نموذجكم اللغوي.""

6:35

فقط دعوا الوكيل الخاص

6:36

بي يتحدث إلى منتجكم.""

6:38

فقط لا تعطوني واجهات

6:40

الدردشة هذه." خيار آخر

6:42

مما رأيناه مؤخراً

6:44

وخلال المؤتمر كنا

6:45

نبحث فيه، هو مفهوم

6:47

التطبيق الواحد أو

6:49

التطبيق الشامل الذي

6:50

يمكنه التحكم في

6:52

واجهات المستخدم. مثل

6:54

وكيلك الخاص أو في هذه

6:56

الحالة "ChatGPT" أو "Claude"،

6:58

حيث تتفاعل معهم وهم

6:59

يتفاعلون مع كل شيء

7:01

آخر. هذا هو مفهوم

7:03

التطبيق الشامل حيث لا

7:04

تتفاعل مع المنتجات

7:06

مباشرة بنفسك. أنت

7:07

تتفاعل مع ذلك التطبيق

7:09

الشامل وهو يتصل بكل

7:11

شيء آخر. وهذا يستخدم

7:13

من خلال شيء يسمى

7:14

تطبيقات "MCP" التي تم

7:16

الحديث عنها. إذا

7:17

فاتتك محاضرة "تيجاس"

7:19

بالأمس، فقد قدم عرضاً

7:21

لكيفية عمل تطبيقات "MCP

7:24

"، وهي الآلية لربط كل

7:26

هؤلاء الوكلاء أو

7:27

التطبيقات الشاملة أو

7:29

التكاملات بجميع

7:31

خدمات الطرف الثالث

7:33

عبر "MCP". تطبيقات "MCP"

7:35

مفهوم مثير للاهتمام

7:37

لأنها تمنحك الفرصة

7:39

للحفاظ على تلك

7:40

الواجهة الغنية

7:41

للمستخدم بدلاً من

7:43

مجرد كونها نصوصاً،

7:44

وهو ما كنا نناقشه.

7:46

فالنصوص وحدها ليست

7:47

كافية. لذا، نحن نعرض

7:49

واجهات المستخدم

7:51

الرسومية هذه عبر

7:52

تطبيقات "MCP". سواء كان

7:54

الأمر يتعلق بالدردشة

7:55

أو بتطبيقات MCP، ففي

7:57

الوقت الحالي، نحن لا

7:58

نعرف. كلا الخيارين قد

8:00

يكونان صالحين. قد

8:01

يكون هذان الخياران

8:03

هما المتاحان أمامنا

8:04

لواجهة المستخدم. نحن

8:05

نحاول فقط معرفة ماهية

8:07

هذا الحاسوب الجديد.

8:09

ما هي واجهة المستخدم

8:10

هذه التي تتفاعل مع

8:12

حاسوب جديد؟ هذا

8:13

السؤال مثير للاهتمام

8:14

، لكنه يتضمن أمرين

8:16

مختلفين. الأول هو: أين

8:17

تعمل واجهة المستخدم

8:19

هذه؟ هل تعمل داخل

8:20

الوكيل الخاص بي؟ هل

8:21

تعمل على موقعك

8:22

الإلكتروني؟ كيف يتم

8:24

عرض واجهة المستخدم

8:25

هذه؟ لكن السؤال

8:27

الأكثر إثارة

8:28

للاهتمام هو: كيف يتم

8:29

إنشاء واجهة المستخدم

8:31

هذه فعلياً؟ وهذا ما

8:32

سأناقشه بعد قليل، وهو

8:35

كيفية توليد هذه

8:36

الواجهة. بمجرد أن

8:38

يكون لديك وكيل وواجهة

8:40

مستخدم، كيف يتم

8:41

إنشاؤها؟ سنستعرض

8:43

الخيارات المختلفة،

8:44

بدءاً من الواجهات

8:45

الثابتة والتصريحية،

8:47

وصولاً إلى الواجهات

8:48

التوليدية بالكامل

8:49

ومستقبل واجهات

8:50

المستخدم. لنبدأ

8:52

بالمكونات الثابتة.

8:53

تُعد المكونات

8:54

الثابتة الطريقة

8:55

التقليدية التي

8:56

نستخدمها لعرض واجهات

8:57

المستخدم في الذكاء

8:58

الاصطناعي في معظم

8:59

الأوقات. إنها طريقة

9:01

بسيطة للغاية. يقوم

9:03

الوكيل ببساطة بإجراء

9:04

استدعاء لأداة ما.

9:05

يحصل هذا الاستدعاء

9:07

على بعض المعلمات

9:08

والبيانات والخصائص،

9:10

ثم يتم تجميع هذه

9:12

الخصائص وعرضها

9:13

بواسطة العميل. إذا

9:15

فكرت في الأمر، ستجد

9:16

أنه يشبه إلى حد كبير

9:18

نموذج العرض التقليدي

9:19

لتطبيقات الصفحة

9:20

الواحدة البسيطة. إنه

9:22

مشابه تماماً لما كان

9:23

يفعله الخادم سابقاً،

9:25

حيث يحصل الخادم على

9:26

البيانات، ويرسل

9:27

الخصائص، ثم يقوم

9:29

العميل بالعرض

9:30

والتجميع وتقديمها

9:31

للمستخدم. لذا، هذا

9:32

ليس جديداً تماماً.

9:34

هذا مشابه جداً للنمط

9:36

التقليدي. ومن أمثلة

9:39

ذلك بروتوكول AGUI، حيث

9:41

يوفر طريقة لتسجيل

9:43

مكونات React التي ترتبط

9:45

باستدعاء أداة أو

9:47

وظيفة في الذكاء

9:48

الاصطناعي، ومن ثم

9:50

يمكنك عرض مكونات

9:51

محددة مسبقاً بناها

9:53

المطور وسجلها في

9:55

البروتوكول. مثال آخر

9:59

أود توضيحه هو Goose.

10:01

أعني أن هذا قديم

10:03

نوعاً ما أيضاً. لقد مر

10:04

عام تقريباً منذ طرحهم

10:07

لفكرة "Goose Visualizer". Goose

10:09

هو عميل MCP يمكنك

10:10

تزويده بأي بيانات

10:12

يجمعها وكيلك، ثم تطلب

10:14

منه تقديم تمثيل مرئي

10:17

لتلك البيانات.

10:19

المكونات التي يتم

10:21

عرضها في هذه الحالة

10:23

عبر Goose هي مكونات

10:24

محددة مسبقاً من قبل

10:26

فريق Goose. على سبيل

10:29

المثال، إذا أردت عرض

10:31

خريطة أو ما شابه، فإن

10:33

استخدام تطبيقات MCP

10:34

يعتمد فقط على أخذ تلك

10:36

القوالب المحددة

10:38

مسبقًا وتجميعها

10:39

واستخدام البيانات

10:41

لعرضها. إذن، هذه هي

10:43

الطريقة الثابتة، وهي

10:45

الأبسط وما يفعله معظم

10:47

الناس. لكن هناك طريقة

10:48

جديدة ومثيرة للغاية

10:50

تسمى طريقة واجهة

10:51

المستخدم التصريحية.

10:53

في هذه الحالة، تستخدم

10:55

واجهة المستخدم

10:56

التصريحية واصفًا مثل

10:58

JSON لتعيين هذه

10:59

المكونات. وهذا لا

11:01

يزال عبارة عن مجموعة

11:02

من المكونات المحددة

11:03

مسبقًا. لذا، لا تزال

11:05

هذه المكونات مبنية

11:06

بواسطة فريقك، ومصممة

11:07

بنظام التصميم الخاص

11:08

بك، مع مراعاة إمكانية

11:09

الوصول وكل شيء آخر.

11:10

مجرد تطبيق عادي تم

11:12

نشره بمكوناته. لكن JSON

11:14

يرتبط بهذه المكونات،

11:16

ثم هناك محرك ترجمة أو

11:18

عرض للتخطيط يأخذ ملف

11:20

JSON هذا ويقوم بعرض

11:21

واجهة المستخدم. إذن،

11:23

الوكيل لا يقوم بكتابة

11:25

واجهة المستخدم.

11:27

الوكيل يكتب ملف JSON

11:28

الذي سيتم تحويله إلى

11:30

واجهة المستخدم

11:31

النهائية. لكن انتظر

11:32

لحظة، هذا يبدو

11:34

متشابهًا جدًا. هذا

11:35

ليس جديدًا أيضًا. هذا

11:37

شيء تفعله نتفليكس منذ

11:38

فترة طويلة من خلال

11:40

أسلوب التخصيص وواجهة

11:42

المستخدم التي يحركها

11:43

الخادم. لذا، عندما

11:45

تذهب إلى صفحة نتفليكس

11:47

الرئيسية، تحصل على

11:49

عرض مخصص بناءً على

11:51

تفضيلاتك وعروضك

11:52

المختلفة، وهو يختلف

11:54

تمامًا عن صفحتي أو

11:56

صفحتك الرئيسية. وهم

11:58

يستخدمون هذا النهج

11:59

المشابه للواجهة

12:01

الثابتة مع واجهة

12:02

المستخدم التصريحية،

12:04

حيث يسمحون للخادم

12:05

بتخصيص ملفات JSON

12:06

المختلفة ثم تقديمها

12:08

للمكونات. مثال آخر هو

12:10

JSON render. JSON render هي

12:12

مكتبة رائعة حقًا

12:14

يمكنك من خلالها، كما

12:15

ناقشنا، ربط تلك

12:17

المكونات بـ JSON ثم

12:18

ببساطة تعليم الوكيل

12:20

كيف يبدو JSON، حتى

12:21

يتمكن الوكيل من إنشاء

12:23

JSON وتقديم واجهة

12:25

مستخدم جيدة حقًا.

12:27

الآن، حتى JSON render،

12:28

التي تبدو مثيرة

12:30

للإعجاب، يقولون

12:32

أيضًا إنهم مقيدون

12:33

بكتالوج الخاص بك.

12:35

مكوناتك مقيدة

12:37

بالأشياء التي تحددها

12:39

أنت. لذا، في الأساس،

12:42

لا تزال مكونات ثابتة.

12:44

لا تزال مكونات نكتبها

12:45

يدويًا، حسنًا ليس

12:47

يدويًا تمامًا، لكننا

12:48

نسمح لوكلائنا

12:49

بكتابتها وربطها بـ JSON

12:51

، والوكيل يقوم فقط

12:53

بكتابة ملف JSON. في هذه

12:54

المرحلة، أعتقد أن

12:56

واجهة المستخدم

12:57

التصريحية هي التوازن

12:59

الأمثل بين الأنواع

13:00

المختلفة، فهي توفر

13:02

الاستقرار وتحافظ على

13:03

نظام التصميم

13:04

وإمكانية الوصول،

13:06

بينما يمتلك الوكيل

13:07

حرية إبداعية في إنشاء

13:09

ملفات JSON وتوليد

13:10

الواجهة، مما يجعلها

13:11

أكثر ديناميكية من

13:13

مجرد استدعاء أداة

13:14

يعيد مكونات ثابتة.

13:17

الآن ننتقل إلى الخيار

13:18

الأخير، وهو المكونات

13:19

التوليدية، أو واجهة

13:21

المستخدم التوليدية

13:22

بالكامل. هذا يقع في

13:24

الطرف الآخر من الطيف،

13:25

حيث تتميز النماذج،

13:27

كما ذكرت سابقًا،

13:28

ببراعتها في كتابة كود

13:30

React، أو جافا سكريبت، و

13:32

HTML، و CSS. لذا، في هذه

13:34

الحالة، نترك للنماذج

13:36

مهمة كتابة كود HTML

13:38

نفسه. وقد قدمت هذا

13:39

العرض العام الماضي

13:41

عندما كنا نبتكر مفهوم

13:43

تطبيقات MCP، حيث

13:44

أعطيتها واجهة برمجة

13:46

تطبيقات للحصول على

13:47

حالة الطقس ودمج بعض

13:49

العناصر، ثم طلبت منها

13:51

ببساطة توليد HTML من

13:53

تلك الواجهة، وهذا ما

13:54

توصلت إليه، نكتة و..

13:58

حالة الطقس لمدن

13:59

مختلفة. في هذه

14:02

الطريقة، يقوم

14:04

النموذج باستدعاء

14:06

أداة إلى خادم، ولكن

14:08

بدلاً من أن يعيد

14:10

الخادم ملف JSON، كنت

14:12

أقوم بتوليد HTML

14:13

وإعادته وعرضه داخل

14:16

عميل MCP في حالة

14:17

تطبيقات MCP. الآن، HTML

14:21

هو HTML. وهذا كل ما

14:24

تحتاجه. هذا الأمر ظهر

14:27

في وقت سابق من هذا

14:29

العام عندما نشر فريق

14:31

Anthropic تدوينة ذكروا

14:33

فيها أن HTML خيار ممتاز

14:36

، ولنكن صادقين، لقد

14:38

سئمنا من قراءة كميات

14:40

هائلة من نصوص

14:41

ماركداون، وأدركنا

14:43

أنه يمكننا ببساطة

14:45

إخبار الوكيل بإنشاء

14:47

HTML بشكل فوري لنتمكن

14:49

من استهلاكه بطريقة

14:51

أفضل وأكثر مرئية. لذا

14:55

، هذا هو الاستخدام

14:56

الأكثر شيوعاً لواجهة

14:58

المستخدم التوليدية

15:00

اليوم. وهو ببساطة: "

15:02

أريد رؤية شيء ما". "

15:03

أريد استهلاكه بطريقة

15:05

أفضل، اذهب وقم

15:07

بتوليده". لكنها مصممة

15:09

للاستخدام المؤقت،

15:10

يمكنك حفظ بعضها كـ "

15:12

أدوات"(artifacts)، لكنها

15:14

في الغالب مخصصة للعرض

15:17

البصري. واجهة

15:18

المستخدم التوليدية

15:19

بالكامل لها أيضاً بعض

15:21

السلبيات. على سبيل

15:23

المثال، التكلفة. أعني

15:25

أن Anthropic لديها رموز

15:26

غير محدودة، ولا

15:27

يمكنهم ببساطة

15:28

استخدام ما يشاؤون

15:29

لتوليد عدد لا نهائي

15:30

من واجهات HTML التي

15:31

سيتم التخلص منها

15:32

لاحقاً. لكن توليد

15:33

واجهات المستخدم هذه

15:35

بشكل لحظي في كل مرة

15:37

سيكون مكلفاً. لدينا

15:38

أيضاً مشكلات تتعلق

15:40

بالاتساق، فما لم

15:41

تتمكن من تدريب نموذجك

15:42

الخاص بنظام التصميم

15:44

الخاص بك مع مراعاة

15:45

إمكانية الوصول وكل

15:46

شيء، ستحصل على نتائج

15:47

غير متسقة. أيضاً

15:49

الألفة. لا أعرف عنكم،

15:51

لكنني أحب أن أعرف

15:52

مكان الأشياء. أعني،

15:54

إذا كان لديك أي

15:55

مستخدمين، فأنت تعلم

15:56

أنه عندما تنقل زراً

15:57

أو شيئاً ما إلى مكان

15:58

آخر، سيشتكي أحدهم

15:59

دائماً قائلاً: "إلى

16:00

أين ذهب هذا؟" أين زري؟

16:02

أين قائمتي؟ "إلخ. لذا،

16:04

نحن كبشر نحب الاتساق.

16:06

نحب الأشياء المألوفة.

16:08

لذا، هذه مشكلة في

16:09

واجهة المستخدم

16:10

التوليدية. إنها غير

16:11

حتمية، لذا سينتهي بك

16:13

الأمر بشيء ليس متسقاً

16:15

تماماً. والأخيرة هي

16:18

الأمان. أعني، مع

16:19

تطبيقات MCB يمكننا

16:21

الحصول على بيئة

16:22

معزولة (Sandbox)، لذا فهي

16:24

ليست مشكلة كبيرة،

16:26

ولكن إذا كنت تولد كود

16:28

JavaScript وتسمح للنموذج

16:29

بتشغيله، فمن الأفضل

16:31

عزله وتقييده. لذا،

16:33

لكي أختتم، اليوم ربما

16:35

ليس الشكل النهائي.

16:37

هذه ليست الوجهة

16:39

النهائية. وكما سألت

16:42

في البداية، أين

16:43

جارفيس؟ أين تلك

16:45

النوافذ التي تطفو

16:46

وتظهر؟ أعتقد أن هذا

16:49

واضح جداً. لم أعد أحب

16:51

هذا لأن الأمر يبدو

16:52

وكأنه، نعم بالتأكيد،

16:54

مثل توني ستارك يمكنه

16:55

فعل هذا، لكن هذا شيء

16:56

بديهي قد يبدو عليه

16:58

الأمر، لكن أتذكر هذا

16:59

التشبيه الذي أخبرني

17:01

به أحدهم عندما ظهر

17:02

التلفزيون في

17:03

الثلاثينيات. لقد كان

17:04

جديداً كلياً،

17:05

تكنولوجيا جديدة،

17:07

التلفزيون. واو، مذهل.

17:09

لكن برامج التلفزيون

17:10

المبكرة كانت تبدو

17:12

أشبه ببرامج الراديو.

17:14

مجرد شخصين يجلسان

17:15

ويتحدثان لأنه لم يكن

17:17

هناك خيال. لم يكن

17:19

بإمكاننا تخيل ما

17:20

يمكننا القيام به بهذه

17:21

التكنولوجيا. لم نستطع

17:22

تخيل كل هذه البرامج

17:23

التلفزيونية الرائعة

17:25

والأشياء التي يمكننا

17:26

القيام بها لأنها كانت

17:27

تكنولوجيا جديدة

17:28

تماماً. لكن اليوم،

17:29

هناك أشياء رائعة حقاً

17:31

تظهر. على سبيل المثال

17:33

، فيما يتعلق بالصوت،

17:35

مشابه لما يفعله توني

17:37

ستارك، إصدار" أسترا "

17:39

قبل أسبوعين، حيث

17:41

عرضوا هذا العرض

17:42

التوضيحي المثير لشخص

17:44

يتحدث إلى التلفزيون

17:46

بصوته، ثم تبدأ

17:48

الأشياء بالتغير على

17:50

الشاشة. لذا، الأمر

17:53

قريب جداً من حيث

17:54

التعرف على الصوت.

17:57

هناك أيضاً نماذج

17:59

لبناء العوالم، وهي

18:01

مذهلة، حيث يمكنك

18:02

ببساطة إنشاء عالم

18:04

متكامل يمكنك التفاعل

18:06

معه والتحرك فيه

18:08

وتوليده. بعض النماذج

18:10

يمكنها توليد أشياء

18:12

كهذه، وهي جديدة كلياً

18:14

. وهناك مشروع آخر أحب

18:16

استعراضه يوضح ما قد

18:18

يكون ممكناً. أعتقد أن

18:20

شركة فيجما استحوذت

18:21

عليه مؤخراً، لكنه

18:23

يسمى فليب كارت. كان

18:24

الأمر أشبه بإعادة

18:26

تصور للمتصفح. ماذا لو

18:28

كان المتصفح يولد

18:29

المحتوى بنفسه، ويقوم

18:31

بإنشائه عند الطلب

18:32

بواسطة النموذج

18:33

اللغوي أثناء تصفحك؟

18:35

إذاً، هذه ليست صفحة

18:37

ويب تقليدية. هذه يتم

18:38

توليدها وبثها مباشرة

18:40

بواسطة النماذج. لذا،

18:42

هذه كلها أشياء يمكنك

18:43

تخيل أنها قد تصبح

18:45

ممكنة. لكن بالعودة

18:46

إلى الواقع، رأيي هو

18:48

أن شيئاً أكثر قيمة

18:49

اليوم في مجال واجهة

18:51

المستخدم التوليدية

18:52

هو التعاون. أريد أن

18:53

أكون قادراً على

18:54

التعاون مع وكلائي

18:55

الذكاء الاصطناعي.

18:56

أعني، واجهة المستخدم

18:57

التوليدية رائعة.

18:59

يمكنك إنشاء عروض

19:00

توضيحية مذهلة حقاً.

19:01

ولكن، يوجد تطبيق" MCP "

19:03

يسمى Excalidraw. هذا هو

19:05

العرض التوضيحي له.

19:07

وهذا هو ما يعجبني.

19:08

وهذا ما أريد أن أرى

19:10

استثماراً أكبر فيه

19:11

فيما يتعلق بتفاعل

19:12

المستخدم مع النماذج

19:14

اللغوية. الأمر لا

19:15

يقتصر على المخرجات

19:16

فقط. ليست مجرد صفحة

19:18

ثابتة، بل هي تصور

19:20

مرئي. إنها أداة

19:21

يمكنني مشاركتها مع

19:23

وكيلي، و ChatGPT يقوم

19:24

بهذا أيضاً عندما

19:25

تتوفر لديك لوحة يمكنك

19:27

التعاون من خلالها.

19:29

ولديك هذا المفهوم

19:30

للتعاون بين الإنسان

19:32

والوكيل. لذا نعم،

19:33

بالتأكيد هي تولد

19:34

الواجهة، وبكل تأكيد

19:36

تبدو رائعة، ولكن في

19:37

الوقت نفسه يمكنني

19:39

النقر على أحد تلك

19:40

العناصر وتحريكه

19:41

وإخبار الوكيل:" لقد

19:42

حركت هذا "، أو" هل

19:43

يمكنك تحريك ذاك؟ "،

19:45

وهكذا نتعاون على هذه

19:47

اللوحة. لذا، ما زلنا

19:48

في البداية. من يدري؟

19:52

أعني، الأمور تتغير

19:54

بسرعة كبيرة. من يدري

19:56

إلى أين نتجه قريباً،

19:57

ولكن لنقم بإنشاء هذه

19:59

الواجهة الجديدة. لنقم

20:00

بإنشاء هذه الواجهة

20:01

الجديدة للكمبيوتر

20:02

الجديد. شكراً جزيلاً

20:04

لكم.

20:30

>> هممم.

Interactive Summary

Ask follow-up questions or revisit key timestamps.

يتناول العرض تطور واجهات المستخدم في عصر الذكاء الاصطناعي، بدءاً من البدايات التي اعتمدت على النسخ واللصق وصولاً إلى نماذج متقدمة قادرة على إنشاء واجهات برمجية ديناميكية. يستعرض المتحدث طرقاً مختلفة لإنشاء هذه الواجهات، مثل المكونات الثابتة، والنهج التصريحي، والواجهات التوليدية بالكامل، مع التركيز على أهمية بروتوكول MCP (Model Context Protocol). كما يناقش كيف أننا لا نزال في مرحلة مبكرة من فهم "الحاسوب الجديد" الذي يمثله الذكاء الاصطناعي، مؤكداً أن مستقبل التفاعل يكمن في التعاون الفعال بين الإنسان والوكلاء الأذكياء وليس فقط في توليد المخرجات.