غالبًا ما يكون شكل الاستجابة في الدردشة غير مناسب لمهمة منتج حقيقية.
إذا طلب مستخدم تفصيل محفظة، أو جدول زمني، أو جدول مقارنة، فإن أفضل إجابة غالبًا ما تكون مكونًا، وليس فقرة. هذه هي الفكرة وراء واجهة المستخدم التوليدية: دع النموذج يشارك في اختيار أو تكوين عناصر الواجهة، وليس فقط في توليد النص.
الجزء المهم هو السيطرة. يجب أن لا يخترع النموذج واجهة مستخدم عشوائية. يجب أن يختار من مجموعة موثوق بها من المكونات التي يعرف نظامك بالفعل كيفية عرضها بأمان.
نمط أفضل
بدلاً من طلب من نموذج اللغة الكبيرة إنتاج ترميز واجهة أمامية بشكل حر، أعطه مفردات مقيدة:
type UiIntent =
| { type: "chart"; metric: string; period: "7d" | "30d" | "90d" }
| { type: "table"; entity: "orders" | "users"; limit: number }
| { type: "summary"; topic: string };
ثم تقوم التطبيق بربط هذا الناتج بمكونات حقيقية:
function RenderIntent({ intent }: { intent: UiIntent }) {
switch (intent.type) {
case "chart":
return <RevenueChart metric={intent.metric} period={intent.period} />;
case "table":
return <EntityTable entity={intent.entity} limit={intent.limit} />;
case "summary":
return <SummaryCard topic={intent.topic} />;
}
}
هذا يمنحك أفضل جزء من واجهة المستخدم التوليدية دون تسليم السيطرة على التخطيط لنظام عشوائي.
كيف تساعد مكونات الخادم
تجعل مكونات خادم ريأكت هذا النمط أكثر طبيعية لأنه يمكن للخادم:
- استرداد البيانات الخاصة
- تشكيل النتيجة
- عرض شجرة المكونات الصحيحة
دون شحن كل اعتمادية داخلية إلى المتصفح.
التبادل هو أنك لا تزال بحاجة إلى حد واضح بين ما يقرره النموذج وما تراه التطبيق مقبولاً.
المساومات
تكون واجهة المستخدم التوليدية مفيدة عندما:
- يعتمد شكل الواجهة على نية المستخدم
- تكون مجموعة المكونات المدعومة معروفة
- تستفيد التطبيق من التركيب الديناميكي
تكون أقل فائدة عندما يجب أن تكون واجهة المستخدم ثابتة، مدفوعة بسير العمل بصورة مشددة، أو تخضع لمراجعة صارمة.
قراءة إضافية