Luma: בקשות, קרדיטים וקבצים אחרי הלחיצה על יצירה

לחצת על יצירה, חיכית, ולחצת שוב כי נדמה ששום דבר לא קורה. האם התחילו עכשיו שני סרטונים? האם שניהם יעלו קרדיטים? ואם הספק כבר סיים אבל האפליקציה עדיין מציגה טעינה, איפה הקובץ? את השאלות האלה צריך להכניס לאפיון לפני שנותנים למפתח או לסוכן לבנות את הכפתור.

אני דניאל גולדמן, ו-Luma הוא אחד הפרויקטים בתיק העבודות שלי. המקרה הזה עוסק בעבודה שמסביב לבקשת יצירה: זיהוי שליחה חוזרת, הקשר בין הקרדיטים ליצירה ושמירת תוצר שאפשר להשתמש בו. מדובר במוצר שבכתובת luma.ai, שמציג את עצמו בנפרד מ-Luma Labs ומ-Dream Machine.

מה נבדק לצורך המאמר

ב-2 באוקטובר 2026 נבדקו דף הבית ודפי יצירת התמונות והסרטונים הציבוריים, לצד גרסת קוד שמורה. בבדיקה המקומית הדפים הציגו את ממשק היצירה. בכלי גלישה אחר הופיעה הודעה שהמוצר אינו זמין באזור, כך שהזמינות יכולה להשתנות לפי מיקום. צפייה בדף ציבורי לא מוכיחה שבקשת יצירה בתשלום הסתיימה בהצלחה.

התיאור הטכני בהמשך מבוסס על קריאת קוד. לצורך המאמר לא בוצעה יצירה בתשלום, לא אומת החזר קרדיטים בחשבון ולא נבדקה העברת קובץ מתחילתה ועד סופה. מתוארים כאן מסלולים שקיימים במימוש שנבדק. זו לא הבטחה לגבי כל בקשה במערכת החיה. הבדיקות המעשיות שבהמשך הן הצעה לאפיון, ולא תוצאות של לקוח.

Luma: המוצר והזהות הציבורית

Luma: ממשק יצירת תמונה

Luma: ממשק יצירת סרטון

שליחה חוזרת צריכה לשמור על אותו מזהה

בשירות היצירה שנבדק, בקשה עם אותו מזהה בקשת לקוח של אותו משתמש יכולה להחזיר יצירה שכבר קיימת. כך המערכת יכולה לזהות שליחה חוזרת. התנאי הזה חשוב: שתי בקשות עם מזהים שונים לא הופכות לאותה בקשה רק כי המשתמש כתב בשתיהן את אותו תיאור.

באפיון צריך להחליט מתי שומרים את המזהה ומתי מתחילים בקשה חדשה. ניסיון נוסף אחרי שתשובת השרת לא הגיעה שונה מבקשה מכוונת ליצור גרסה נוספת. כדאי לכתוב את שני המצבים. כפתור מושבת יכול לעזור בממשק, אבל הוא לא מגדיר מה השרת יעשה אם אותה בקשה בכל זאת תגיע שוב.

צריך לדעת לאיזו יצירה שייך החיוב

במסלול שצורך קרדיטים בקוד שנבדק, החיוב מקושר ליצירה. יש בו גם מסלול החזר במקרה שהקריאה לספק נכשלת. הקשר הזה מאפשר לבדוק משהו מוגדר: לאיזו יצירה שייך החיוב, מה נכשל והאם מסלול הטיפול בכשל הופעל. עצם הופעתה של פעולת החזר בקוד לא מוכיחה שהקרדיטים חזרו לחשבון מסוים.

דרישה כמו "להחזיר קרדיטים כשיש שגיאה" משאירה יותר מדי פתוח. צריך לציין איזו שגיאה בודקים ואיזו ראיה תיחשב הצלחה. ספק שדוחה את הבקשה בהתחלה הוא מקרה שונה מקובץ שלא הועתק אחרי שהיצירה הסתיימה. לא מניחים שלשני המצבים אותה משמעות כספית. מדיניות כזאת דורשת החלטה ובדיקה נפרדת.

הספק סיים, אבל הקובץ עוד צריך להגיע

במסלול המדיה שנבדק יש שלב של העתקת התוצר לאחסון של המוצר ורישום מצב השמירה. קבלת תוצר מהספק וקיומו של עותק שמיש באפליקציה הם שני אירועים שונים. ההבחנה הזאת מסבירה למה לפעמים יש עוד עבודה גם אחרי שפעולת היצירה עצמה הסתיימה.

בדיקה מועילה מגיעה עד לפעולה של המשתמש: לפתוח או להוריד את הקובץ שנשמר. צריך לבדוק גם העתקה שנכשלה ומה מוצג בזמן שהכשל עדיין לא טופל. קוד שמירה לא מוכיח שהקבצים נשמרים לצמיתות, שכל תוצר הגיע ליעדו או שהטיפול בכשל יסתיים בתוך זמן מסוים.

משימה קטנה שאפשר לתת למפתח או לסוכן

מתחילים ממיפוי המסלול הקיים, לפני שמשנים אותו. אחר כך בוחרים כשל אחד ומשחזרים אותו בסביבת בדיקה מבוקרת. משתמשים בקלט מלאכותי ובתגובות ספק מדומות; בדיקה אמיתית שצורכת תשלום דורשת אישור משלה. אלה בדיקות מוצעות שאפשר לצרף לאפיון:

1. 01שלח שוב בקשה של אותו משתמש בדיקה עם אותו מזהה. בדוק את רשומות היצירה ואת מספר הקריאות לספק. תעד מה קרה בפועל במקום להניח שהכפתור מנע כפילות.
2. 02דמה דחייה של הבקשה אצל הספק אחרי חיוב. בדוק את מצב היצירה ואת רישומי הקרדיטים הרלוונטיים. הצלחה היא השינוי שהוגדר ברישומים, ולא רק הגעה לפונקציית החזר.
3. 03דמה כשל בהעתקת התוצר. בדוק את מצב השמירה ואת מה שהמשתמש רואה, ואז בדוק את מסלול ההתאוששות שתוכנן. סיום אצל הספק וזמינות הקובץ צריכים להיות בדיקות נפרדות.
4. 04בכל בדיקה שמור מזהה בקשה, פקודה, תוצאה שנצפתה ומה עדיין לא ידוע. אם ההתנהגות הרצויה לא הוגדרה, עצור. אל תמציא מדיניות החזר ואל תכריז על הצלחה רק על סמך צילום מסך.

גם הכשל שייך לגרסה הראשונה

הדגמה של יצירה מראה שהמודל מסוגל להפיק תוצר. אפיון של מוצר צריך להסביר גם את ההמתנה, הניסיון החוזר, רישום הקרדיטים והקובץ שנשמר. במקרה של Luma, הקוד שנבדק מאפשר לראות החלטות כאלה בלי להוכיח את כל התוצאות בזמן ריצה. מכאן אפשר להתחיל שיחה מדויקת על מה הגרסה הראשונה צריכה לכלול, ומה עוד צריך לבדוק לפני מסירה.

פיתוח מוצר עם דניאל גולדמן