رابط‌های کاربری زاینده: انتقال کنترل صفحه از برنامه‌نویس به مدل

تصور کنید به جای گشتن در منوهای پیچیده برای برنامه‌ریزی سفر، صفحه نمایش شما دقیقاً در همان لحظه به نقشه، ویجت آب‌وهوا و تخمین قیمت پرواز تبدیل شود. این دیگر یک رویای طراحی نیست، بلکه تغییر بنیادین در نحوه تعامل انسان و نرم‌افزار است.

در نرم‌افزارهای سنتی، هر صفحه و هر جریان کاربر (User Flow) در زمان توسعه توسط برنامه‌نویس قفل می‌شود. در این محصولات، تیم توسعه تمام صفحات، جریان‌ها، اجزا (Components)، حالت‌های خطا و قوانین ناوبری را در زمان توسعه تعریف می‌کند. برای مثال، وقتی کاربر در یک اپلیکیشن استاندارد درخواست برنامه‌ای برای آخر هفته می‌کند، برنامه احتمالاً صرفاً لیستی از نتایج جست‌وجو را نمایش می‌دهد. اما در یک سامانه رابط کاربری زاینده (Generative UI)، نویسندگی رابط کاربری به زمان اجرا (Runtime) منتقل می‌شود؛ یعنی صفحه به جای تکیه بر منوهای موجود، خود را با هدف کاربر تطبیق می‌دهد. این سیستم صرفاً کد HTML تولید نمی‌کند، بلکه تصمیم می‌گیرد کدام بخش از تجربه کاربری باید منعطف باشد و کدام بخش باید تحت کنترل صریح برنامه بماند.

این گذار صرفاً یک تغییر ظاهری یا تزئینی نیست؛ بلکه نحوه گردش داده‌ها، قوانین و حالت‌ها (States) را در کل سیستم به‌طور بنیادین تغییر می‌دهد. به گزارش وب‌سایت Boda در مقاله‌ای با عنوان Generative UI، هدف اصلی این رویکرد، حذف «دیوارهای متنی» است که در پاسخ‌های معمول هوش مصنوعی دیده می‌شود و تبدیل قصد کاربر به عناصر رابط کاربری موقت است. برای مثال، در حالی که یک چت‌بات ساده ممکن است صرفاً بگوید «سه رستوران پیدا کردم»، یک رابط زاینده می‌تواند آن سه مورد را روی یک نقشه نشان دهد، فیلترهای اعمال‌شده را توضیح دهد، مشخص کند کدام یک در حال حاضر باز هستند، مسیرهای دسترسی را پیشنهاد دهد و به کاربر اجازه دهد بدون نیاز به شروع مجدد گفتگو، جست‌وجوی خود را اصلاح کند.

همان‌طور که در تحلیل‌های قبلی ما درباره‌ی عامل‌های هوشمند اشاره کردیم، انتقال از پاسخ‌های متنی به اقدامات عملی، گام بعدی تکامل مدل‌هاست. در اینجا، رابط کاربری دیگر یک پوسته ثابت نیست، بلکه ابزاری است که بر اساس قصد کاربر ساخته می‌شود.

چالش‌های مهندسی و حاکمیت

طبق راهنمای فنی منتشر شده در dev.to در تاریخ ۷ اوت ۲۰۲۶، بزرگ‌ترین چالش مهندسی، حفظ حاکمیت (Authority) بر رابط کاربری است. وقتی ورودی کاربر باز است — مثلاً جمله‌ای مثل «برنامه‌هایی که با بودجه من سازگارند را مقایسه کن» یا «تغییرات رخ داده در این حادثه را نشان بده» — برنامه باید بتواند این قصد را به چیزی تبدیل کند که هم قابل مشاهده باشد و هم قابل اجرا.

بدون مرزهای سخت‌گیرانه، رابط‌های تولیدشده توسط هوش مصنوعی می‌توانند ناسازگار، غیرقابل دسترس، دشوار برای تست یا حتی آسیب‌پذیر در برابر اجرای کدهای مخرب و دلخواه باشند. طبق این مستندات، پرسش کلیدی این نیست که آیا هوش مصنوعی «می‌تواند» صفحه بسازد یا خیر، بلکه این است که چه کسی کنترل و حاکمیت بر موارد زیر را در دست دارد:

• کدام داده‌ها مجاز به استعلام و نمایش هستند.
• چه اقداماتی (Actions) از طریق آن صفحه توسط کاربر قابل اجراست.
• کدام اجزا (Components) مجاز به نمایش در صفحه هستند.
• ورودی‌ها و خروجی‌ها چگونه اعتبارسنجی می‌شوند.
• در صورت شکست مدل، تأخیر در پاسخ یا عدم توانایی در پاسخ‌دهی، چه اتفاقی می‌افتد.

یک معماری بالغ در این حوزه، تصمیمات حیاتی را به مدل واگذار نمی‌کند، بلکه یک «حوزه تصمیم‌گیری» مشخص برای مدل تعریف کرده و قراردادهای سخت‌گیرانه‌ای دور آن می‌سازد. هدف این است که حداقل درجه آزادی لازم برای حل مشکل کاربر پیدا شود، بدون اینکه سطح جدیدی برای شکست سیستم ایجاد گردد.

سه سطح آزادی در رابط کاربری

معماران نرم‌افزار می‌توانند این سیستم را در سه سطح مختلف از آزادی پیاده‌سازی کنند. این سطوح mutually exclusive یا متقابل نیستند و بسته به میزان پیش‌بینی‌پذیری مورد نیاز، می‌توانند در یک محصول واحد در کنار هم coexist کنند.

• رابط کنترل‌شده (Controlled UI) - مدل می‌پرسد، برنامه می‌سازد: این مستقیم‌ترین مسیر برای اکثر تیم‌ها است. کاربر نیاز خود را به زبان طبیعی توصیف می‌کند؛ مدل درخواست را تفسیر کرده و آرگومان‌های لازم را برای ابزارهای تایپ‌شده (Typed Tools) انتخاب می‌کند؛ برنامه قوانین دامنه (Domain Rules) را اجرا می‌کند و در نهایت فرانت-اند اجزای موجود را رندر می‌کند.

  • مثال: در جست‌وجوی مکان، مدل نقشه یا دکمه را تولید نمی‌کند. بلکه ابزاری مانند recommendPlaces را با فیلترهای ساختاریافته (مکان، بودجه، زمان، دسته‌بندی و اولویت‌ها) فراخوانی می‌کند.
  • مزیت: ابزار از منابع قابل اعتماد استعلام می‌گیرد و محدودیت‌های قطعی (Deterministic) را اعمال می‌کند. سپس فرانت-اند تصمیم می‌گیرد که از کارت‌ها، نقشه، لیست یا حالت خالی (Empty State) استفاده کند. این کار سیستم طراحی، معیارهای دسترسی‌پذیری و رفتارهای تست‌شده را حفظ می‌کند در حالی که ورودی باز را می‌پذیرد.
  • قابلیت مشاهده (Observability): این رویکرد به تیم‌ها اجازه می‌دهد تا قصد تفسیرشده، آرگومان‌های انتخاب‌شده، ابزار فراخوانی‌شده، فیلترهای اعمال‌شده و جزء نهایی رندر شده را لاگ کنند.

• رابط توصیفی (Declarative UI) - مدل ترکیب می‌کند، کاتالوگ تضمین می‌کند: زمانی استفاده می‌شود که انتخاب یک جزء آماده کافی نیست. برای مثال، یک برنامه‌ریز سفر ممکن است نیاز داشته باشد یک مقدمه، پیش‌بینی آب‌وهوا، تخمین پرواز، دستور کار روزانه و لیست وسایل مورد نیاز را با ترتیبی متغیر کنار هم قرار دهد.

  • مکانیسم: مدل به جای تولید کد قابل اجرا، یک توصیف ساختاریافته (درختی از اجزای مجاز، ویژگی‌ها و روابط) تولید می‌کند.
  • کاتالوگ: یک کاتالوگ این توصیف را تفسیر می‌کند. هر آیتم دارای یک طرحواره (Schema) است که تعریف می‌کند چه ورودی‌هایی می‌پذیرد و یک رندرر دارد که توسط تیم توسعه کنترل می‌شود.
  • پروتکل‌ها: برای جلوگیری از سردرگمی، سیستم انتقال رویداد (Event Transport) را از توصیف رابط جدا می‌کند. پروتکل‌هایی مانند AG-UI سیگنال‌های اجرا، متن، ابزارها، حالت و فعالیت‌ها را مدیریت می‌کنند، در حالی که مشخصاتی مانند A2UI اجزا و نحوه ترکیب آن‌ها را توصیف می‌کنند.
  • بهای پذیرش (Trade-off): این روش انعطاف‌پذیری را با قابلیت جابه‌جایی (Portability) ترکیب می‌کند، اما نیازمند نگهداری طرحواره‌ها، کاتالوگ‌ها، رندررها، سیاست‌های استفاده و نسخه‌بندی است.

• رابط باز (Open UI) - مدل کد می‌سازد، سندباکس محدود می‌کند: مدل مستقیماً کد خام HTML، CSS و JavaScript تولید می‌کند. این روش وسوسه‌انگیز است چون نیاز به کاتالوگ را از بین می‌برد؛ اگر درخواست کاربر جدید باشد، هوش مصنوعی چیزی کاملاً جدید خلق می‌کند.

  • ریسک‌ها: این کار می‌تواند منجر به کدهایی شود که داده‌های غیرمجاز را می‌خوانند، رفتارهای غیرمنتظره دارند، در مرورگرهای مختلف می‌شکنند یا استانداردهای دسترسی‌پذیری را نادیده می‌گیرند.
  • کاهش ریسک: به دلیل اینکه اجرای کدهای دلخواه در مرورگر یک ریسک امنیتی بزرگ است، این رابط‌ها معمولاً در ای‌فریم‌های ایزوله (Sandboxed iframes) قرار می‌گیرند.
  • حاکمیت: حتی با ایزوله‌سازی، تیم‌ها باید مجوزها، ارتباطات میزبان، کش، تأخیر و محدودیت‌های منابع را مدیریت کنند. این روش برای ویجت‌های موقت، پروتوتایپ‌های داخلی یا سطوح مصرفی یک‌بارہ مناسب است.

نقشه راه پیاده‌سازی

برای تیم‌هایی که قصد پذیرش این معماری را دارند، مسیر پیشنهادی از میان‌برهای شکننده اجتناب می‌کند و توالی پیچیدگی را به این صورت دنبال می‌کند:

۱. شناسایی قصدهای تکراری: شروع از نقاطی که کاربران در حال حاضر با فیلترهای پیچیده دست‌وپنجه نرم می‌کنند، مانند اکتشاف داده‌ها، پشتیبانی عملیاتی، برنامه‌ریزی یا مقایسه.
۲. مدل‌سازی ابزارها پیش از رابط: ایجاد اعتماد از طریق ابزارهایی با ورودی/خروجی‌های تایپ‌شده و قوانین دامنه که خارج از پرامپت (Prompt) نگه داشته شده‌اند.
۳. استفاده مجدد از اجزای موجود: اجازه دهید مدل داده‌ها و گونه‌ها (Variations) را انتخاب کند، به جای اینکه سعی کند سیستم طراحی را از نو خلق کند.
۴. اندازه‌گیری بهبود تسک: تأیید اینکه آیا تفسیر هوش مصنوعی واقعاً توانایی کاربر برای تکمیل تسک را بهبود بخشیده است یا خیر.
۵. ثبت کامل ردپای تصمیمات: ثبت قصد، فراخوانی ابزار، نتیجه اعتبارسنجی شده و جزء نمایش‌داده‌شده. این روش برای عیب‌یابی بسیار برتر از ذخیره ساده متن چت است.
۶. ساخت کاتالوگ برای تکرار: سرمایه‌گذاری روی لایه توصیفی تنها زمانی که قصدهای مختلف شروع به درخواست بلوک‌های مشابه در چیدمان‌های متفاوت کنند.
۷. ایزوله‌سازی کدهای باز: اگر تولید کد اجتناب‌ناپذیر است، از روز اول با اجرای آن به عنوان محتوای غیرقابل اعتماد برخورد کنید.

موازنه آزادی و ریسک

هیچ محصولی نباید ۱۰۰٪ در حالت کنترل‌شده، توصیفی یا باز باشد. در عوض، باید از ترکیبی بر اساس پروفایل ریسک جریان (Flow) استفاده کرد:

• کنترل‌شده: برای پرداخت‌ها، مجوزها، اقدامات تخریبی، داده‌های تحت نظارت و وظایف تکراری.
• توصیفی: برای تجربه‌هایی که چیدمان اطلاعات بر اساس قصد کاربر تغییر می‌کند، اما بلوک‌های سازنده همچنان در مالکیت محصول هستند.
• باز/ایزوله: برای نیازهای موقت، خاص یا آزمایشی که هنوز ساخت یک جزء اختصاصی برای آن‌ها توجیه نشده است.

در این چرخش معماری، مدل لایه چیدمان را پیشنهاد می‌دهد، اما محصول همچنان مسئول دسترسی به داده‌ها، انتقال حالت‌ها (State Transitions)، اعتبارسنجی، دسترسی‌پذیری، تله‌متری و حالت‌های جایگزین (Fallbacks) است. با ایجاد قراردادهای شفاف، توسعه‌دهندگان می‌توانند از تبدیل شدن انعطاف‌پذیری به یک ریسک سیستماتیک جلوگیری کنند. آینده نرم‌افزار، یک رابط ایستا نیست، بلکه مجموعه‌ای سیال از اجزاست که در لحظه بر اساس قراردادی که مانع از تبدیل انعطاف به یک نقطه ضعف می‌شود، خود را سازماندهی می‌کنند.

گام بعدی شما

• اگر توسعه‌دهنده هستید، ابتدا نقاطی از محصول خود را که دارای فیلترهای پیچیده است شناسایی کنید و سعی کنید آن‌ها را به مدل‌های استنتاج (Inference) — لحظه‌ای که مدل واقعاً جواب تولید می‌کند — متصل کنید.
• برای شروع، از رویکرد رابط کنترل‌شده استفاده کنید تا ریسک شکست سیستم در محیط عملیاتی به حداقل برسد.
• مستندات پروتکل‌های AG-UI و A2UI را برای درک نحوه جداسازی توصیف رابط از اجرای آن مطالعه کنید.

اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است؛ برای درک اینکه چگونه تراشه‌های جدید سرعت رندرینگ این رابط‌ها را بالا می‌برند، به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.