ما هذا المنشور. مثال تطبيقي توضيحي، وليس نتيجة عميل. فريق التقنية المالية ومنتجه وكل رقم افتراضات. يبيّن ما يلزم لتحويل نموذج AI أولي يعرض جيدًا إلى ميزة يمكنك وضعها أمام كل المستخدمين.
افترض فريق منتج في شركة تقنية مالية من السلسلة ب. بنى مدير منتج نموذجًا أوليًا لميزة AI في lovable خلال عطلة نهاية أسبوع. يبدو حقيقيًا وعُرض جيدًا في الاجتماع العام. ثم يبقى مكانه، لأن أن تبدو حقيقيًا وأن تكون موثوقًا مهمتان مختلفتان.
عن هذا المثال: الفريق عام ولا يقف خلفه عميل. لا شيء هنا نتيجة مُسلَّمة أو توقع. التصميم هو الموضوع، لا الشعار.
لماذا يتعثر النموذج الأولي الجيد قبل الإنتاج؟
لأن النموذج الأولي يجيب عن سؤال مختلف عن سؤال الإنتاج. النموذج الأولي يثبت أن الفكرة يمكن أن تعمل مرة واحدة، على مُدخل نظيف، بقيادة المؤسس. الإنتاج يجب أن يعمل على المُدخل الفوضوي، في الساعة الثانية صباحًا، دون أن يراقبه أحد، وأن يكون قابلًا للدفاع عنه حين ينازع عميل ما قالته له الميزة. هذه الفجوة هي حيث تموت معظم مشاريع v0 وlovable. ليس لأن الفكرة كانت خاطئة. بل لأنه لم يكن هناك مسار من العرض التجريبي إلى الشيء الذي يمكنك وضع اسمك عليه.
كيف تنقل نموذج AI أوليًا إلى الإنتاج؟
ابدأ من المشكلة الحقيقية لا من واجهة العرض. أعد بناء الميزة داخل منتجك مع استجابات متدفقة ومجموعة اختبارات تقارن الإجابات بحالات سليمة معروفة وتسجيل تدقيق ومراجعة بشرية حيث يلزم. ثم قِس تذاكر الدعم على الميزة قبل الإطلاق وبعده.
ماذا يتضمن تصميم الإنتاج؟
لا تبدأ من مربع الدردشة في النموذج الأولي. ابدأ من قائمة الدعم. افترض أن أعلى ثلاث تذاكر حجمًا على هذه الميزة تشير كلها إلى الأمر نفسه: لا يستطيع المستخدمون الحصول على إجابة واضحة دون مراسلة الدعم. ابنِ الميزة لتجيب عن هذه الأسئلة الثلاثة أولًا، داخل منتج الفريق ونظام تصميمه، لا كأداة ملصقة.
- ردود متدفقة (streaming) بحيث تبدو الميزة فورية بدلًا من مؤشر تحميل دوّار. تظهر الإجابة أثناء تكوّنها.
- مجموعة اختبارات تشغّل الميزة مقابل إجابات معروفة الصحة عند كل تغيير، بحيث لا يستطيع تعديل بسيط في أحد الأوامر أن يكسر حالة أخرى بصمت.
- تسجيل تدقيق لكل رد، بحيث حين ينازع عميل ما قالته الميزة، يمكن للدعم استخراج المُدخل والمُخرج الدقيقين.
- تجربة مستخدم داخل المنتج مبنية ضمن نظام تصميمهم، بحيث تبدو جزءًا من المنتج، لا نافذة محادثة ألصقها أحدهم لاحقًا.
We are
نعيد بناء نموذج أولي متعثر إلى ميزة مُطلَقة مع استجابات متدفقة ومجموعة اختبارات وتسجيل تدقيق وتجربة أصيلة داخل المنتج.
We aren't
لا نضع مربع دردشة عامًا فوق المنتج ونسميه ميزة AI.
كيف تعرف أن الميزة تقلل تذاكر الدعم؟
ابنِ الميزة انطلاقًا من التذاكر. الأسئلة التي تولّد أكبر حجم دعم هي التي تجيب عنها الميزة داخل المنتج، قبل أن يضطر المستخدم إلى مراسلة أحد. يبيّن سجل التدقيق الأسئلة التي تعالجها الميزة والتي ما زالت تصل إلى إنسان. ويساعد السجل نفسه الفريق على التمييز بين انخفاض حقيقي وتراجع موسمي: قارن الحجم لكل نوع تذكرة بفترة أساس من قبل الإطلاق.
مجموعة الاختبارات هي ما يجعل أي تحسّن يصمد. قبل الإطلاق، يُشغَّل كل تغيير على الإجابات السليمة المعروفة. تعديل موجّه يصلح حالة ويكسر اثنتين يُلتقط قبل أن يصل إلى مستخدم. هذا هو الفرق بين عرض يعمل مرة وميزة تعمل في كل مرة. تسمّي فرق المنتج هذا الإطلاق، ونحن نتفق. المزيد عن نهجنا في عمل المنتج هنا.
بأي ترتيب تبنيها؟
سجل التدقيق ومجموعة الاختبارات أولًا، لأنك لا تستطيع تحسين ما لا تستطيع قياسه. ثم أعد بناء إجابات أعلى التذاكر داخل المنتج. ثم تجربة نظام التصميم والاستجابات المتدفقة. وأخيرًا إطلاق مرحلي لحصة متزايدة من المستخدمين، مع مراقبة سجل التدقيق بحثًا عمّا فاتته الاختبارات. لا إطلاق دفعة واحدة.
الاختبار الذي يجب تطبيقه: أن ينتقل من شيء عرضته إلى شيء أطلقته، وأن تكون قائمة الدعم هي الدليل على أنه نجح.
هذا ما تشترك فيه أمثلتنا التطبيقية. المكسب ليس النموذج. بل الأجزاء المملة حوله: مجموعة الاختبارات وسجل التدقيق وبوابات المراجعة والإطلاق الذي يمكنك مراقبته. هذا ما يحوّل نموذجًا أوليًا إلى شيء يمكنك وضعه أمام كل مستخدم. إذا كان لديك بناء v0 أو lovable متوقف عند العرض دون طريق للمضي، فهذه بالضبط الفجوة التي نسدّها. أخبرنا بما تبنيه.
