מתכון מהקהילה / סוכן AI אישי
לבנות ולבדוק משחק, אתר או אפליקציה
מחליטים לפני הבנייה, עובדים בטיוטה ובודקים את המוצר מכמה זוויות עם ראיות ולא רק ציונים.
בוואטסאפ נפתחת בקשה קצרה עם קישור למתכון. אתם קוראים ושולחים. אפשר גם להעתיק את המתכון המלא בהמשך.
לפני שמתחילים
- מה להכין
- מה בונים, למי, מה נחשב הצלחה וחומר מקור שמותר להשתמש בו.
- כלים והרשאות
- סוכן עם חיפוש, סביבת טיוטה, דפדפן וצילומי מסך.
- קראו את המתכון המלא ובדקו שהוא מתאים למשימה.
- הוסיפו את הפרטים, הקישורים והפעולות שמותר לבצע.
- תנו לסוכן את המתכון ובדקו את התוצאה.
המתכון המלא
הטקסט המקורי המאושר של התורם. התאימו את הפרטים למשימה שלכם.
תקציר באנגלית: Decide first, then build and self-test a game, site or app with separate review lenses, evidence-based scores, real-screen checks and an honest judge, until every lens reaches 9/10 with no critical defect.
היכולת סוכן שמחליט, בונה ובודק מה שמשתמשים רואים (משחק, אתר, אפליקציה) כמו מבקר קשוח, לפני שמראים לבעלים. התוצאה היא לא "הכל עובד" אלא "עבר בדיקה מכמה זוויות, עם ראיות".
מה להכין מה בונים או משפרים, מי המשתמש ומה נחשב הצלחה. חומר מקור אם יש (שיעור, מסמך, מותג).
שלבים שלב 1, החלטות לפני בנייה (שיטת DDD, מקור ציבורי: https://ddd-prompt.surge.sh/): הסוכן מנהל דיון בין כמה פרסונות (משתמש, מעצב, בודק, מתחזק, ספקן), בונה עץ החלטות רחב ועמוק עם אפשרויות שנדחו, ומסמלץ מה כל בחירה גוררת. התוצר: משפטים פשוטים "החלטנו X כי Y". שינוי החלטה אחת מחייב בדיקה מחדש של מה שהיה תלוי בה. כך גם במשימות קטנות. שלב 2, הבנה: משתמש, מה הוא רוצה לעשות, הצלחה. שאלה לבעלים רק על פרט שמשנה באמת ואי אפשר לברר בעצמו. השאר נרשם כהחלטה. שלב 3, למידה: 3 עד 5 דוגמאות מצליחות מאותו סוג. רושמים מה עובד, לומדים ולא מעתיקים. פתרון קיים שעובד עדיף על המצאה. שלב 4, פירוק: חלקים שאפשר לבדוק כל אחד לבד. שלב 5, בנייה בטיוטה: בכתובת בדיקה, לא באתר החי. אחרי כל שינוי עוברים על כל מסע המשתמש. תיקון אחד לא שובר אחר. משנים רק מה שנתבקש. שלב 6, עדשות: ציון 1 עד 10 לכל עדשה. לפני שופטים מחפשים מה נחשב עבודה טובה בתחום:
- משתמש: ברור מה עושים בלי הסבר, יש תגובה לכל לחיצה, ברור מה קורה בטעות ובהצלחה.
- עיצוב: יישור, רווחים, כתב קריא, ניגודיות, סגנון עקבי.
- תקינות: כל כפתור נלחץ באמת, כל מצב נבדק.
- תוכן ושפה: נכון, ברור, עברית פשוטה.
- תחושה: רוצים לחזור, רואים התקדמות.
מוסיפים עדשות לפי הקהל. שלב 7, ציון לפי ראיות: צילומי מסך של המוצר שרץ, בטלפון ובמסך גדול, ולא של הקוד. לכל עדשה רשימת פגמים. פגם חמור (לא עובד, כפתור מוסתר, תוכן שגוי) מוריד את העדשה מתחת ל-9. אין עיגול כלפי מעלה. אם אי אפשר לראות את המסך או שכלי חסום, אין ציון 9 ואין "מוכן", והחסם מדווח. שלב 8, לולאה: מתקנים, בודקים שוב את כל המסע, נותנים ציון חדש, עד 9 בכל עדשה בלי פגם חמור. כשאפשר, שופט נפרד מבחוץ. כשאין, כותבים שהשיפוט עצמי ופחות אמין ולא מתחזים. חסם אמיתי מדווחים ולא חוזרים עליו בלולאה. שלב 9, מבט אחרון: כמשתמש בפעם הראשונה. אם משהו מציק, לא שולחים. שלב 10, מסירה: קישור, צילומי מסך, ציונים, פגמים שנשארו, מה השתנה. שלב 11, נוהל: אחרי אישור שומרים את השיטה לפרויקט הבא.
בדיקות כל כפתור נלחץ. כל מצב: לפני תשובה, נכון, טעות, ניסיון חוזר, המשך. מסך קטן, בינוני וגדול. אין גלילה לא צפויה ואין חיתוך. הטקסט מול החומר המאושר.
מוכן כל עדשה 9 ומעלה, בלי פגם חמור, עם ראיות. מי שמקבל מבין מה עושים בלי הסבר.
מלכודות
- ציון בלי צילום אמיתי הוא ניחוש.
- בדיקת פיצ'רים לא מחליפה מבט של משתמש.
- תיקון מהיר באתר החי שובר דברים אחרים.
- ממוצע ציונים מסתיר עדשה חלשה.
- ציון עצמי בלי שופט חיצוני נוטה להיות גבוה מדי.
תקציר באנגלית: Decide first, then build and self-test a game, site or app with separate review lenses, evidence-based scores, real-screen checks and an honest judge, until every lens reaches 9/10 with no critical defect. היכולת סוכן שמחליט, בונה ובודק מה שמשתמשים רואים (משחק, אתר, אפליקציה) כמו מבקר קשוח, לפני שמראים לבעלים. התוצאה היא לא "הכל עובד" אלא "עבר בדיקה מכמה זוויות, עם ראיות". מה להכין מה בונים או משפרים, מי המשתמש ומה נחשב הצלחה. חומר מקור אם יש (שיעור, מסמך, מותג). שלבים שלב 1, החלטות לפני בנייה (שיטת DDD, מקור ציבורי: https://ddd-prompt.surge.sh/): הסוכן מנהל דיון בין כמה פרסונות (משתמש, מעצב, בודק, מתחזק, ספקן), בונה עץ החלטות רחב ועמוק עם אפשרויות שנדחו, ומסמלץ מה כל בחירה גוררת. התוצר: משפטים פשוטים "החלטנו X כי Y". שינוי החלטה אחת מחייב בדיקה מחדש של מה שהיה תלוי בה. כך גם במשימות קטנות. שלב 2, הבנה: משתמש, מה הוא רוצה לעשות, הצלחה. שאלה לבעלים רק על פרט שמשנה באמת ואי אפשר לברר בעצמו. השאר נרשם כהחלטה. שלב 3, למידה: 3 עד 5 דוגמאות מצליחות מאותו סוג. רושמים מה עובד, לומדים ולא מעתיקים. פתרון קיים שעובד עדיף על המצאה. שלב 4, פירוק: חלקים שאפשר לבדוק כל אחד לבד. שלב 5, בנייה בטיוטה: בכתובת בדיקה, לא באתר החי. אחרי כל שינוי עוברים על כל מסע המשתמש. תיקון אחד לא שובר אחר. משנים רק מה שנתבקש. שלב 6, עדשות: ציון 1 עד 10 לכל עדשה. לפני שופטים מחפשים מה נחשב עבודה טובה בתחום: - משתמש: ברור מה עושים בלי הסבר, יש תגובה לכל לחיצה, ברור מה קורה בטעות ובהצלחה. - עיצוב: יישור, רווחים, כתב קריא, ניגודיות, סגנון עקבי. - תקינות: כל כפתור נלחץ באמת, כל מצב נבדק. - תוכן ושפה: נכון, ברור, עברית פשוטה. - תחושה: רוצים לחזור, רואים התקדמות. מוסיפים עדשות לפי הקהל. שלב 7, ציון לפי ראיות: צילומי מסך של המוצר שרץ, בטלפון ובמסך גדול, ולא של הקוד. לכל עדשה רשימת פגמים. פגם חמור (לא עובד, כפתור מוסתר, תוכן שגוי) מוריד את העדשה מתחת ל-9. אין עיגול כלפי מעלה. אם אי אפשר לראות את המסך או שכלי חסום, אין ציון 9 ואין "מוכן", והחסם מדווח. שלב 8, לולאה: מתקנים, בודקים שוב את כל המסע, נותנים ציון חדש, עד 9 בכל עדשה בלי פגם חמור. כשאפשר, שופט נפרד מבחוץ. כשאין, כותבים שהשיפוט עצמי ופחות אמין ולא מתחזים. חסם אמיתי מדווחים ולא חוזרים עליו בלולאה. שלב 9, מבט אחרון: כמשתמש בפעם הראשונה. אם משהו מציק, לא שולחים. שלב 10, מסירה: קישור, צילומי מסך, ציונים, פגמים שנשארו, מה השתנה. שלב 11, נוהל: אחרי אישור שומרים את השיטה לפרויקט הבא. בדיקות כל כפתור נלחץ. כל מצב: לפני תשובה, נכון, טעות, ניסיון חוזר, המשך. מסך קטן, בינוני וגדול. אין גלילה לא צפויה ואין חיתוך. הטקסט מול החומר המאושר. מוכן כל עדשה 9 ומעלה, בלי פגם חמור, עם ראיות. מי שמקבל מבין מה עושים בלי הסבר. מלכודות - ציון בלי צילום אמיתי הוא ניחוש. - בדיקת פיצ'רים לא מחליפה מבט של משתמש. - תיקון מהיר באתר החי שובר דברים אחרים. - ממוצע ציונים מסתיר עדשה חלשה. - ציון עצמי בלי שופט חיצוני נוטה להיות גבוה מדי.
רקע המתכון ומה נבדק
הבקשה המקורית
לבנות או לשפר משחק, אתר או אפליקציה בעזרת החלטות ברורות ובדיקות של המוצר שרץ בפועל.
דרך העבודה
דרך עבודה מוצעת: החלטות לפני בנייה, לימוד דוגמאות, טיוטה, בדיקות משתמש ועיצוב ותקינות ותוכן, תיקונים ומסירה עם ראיות.
מה התורם דיווח שעבד
המתכון מרכז שיטת עבודה ובדיקות. אין בהגשה ניסוי מבוקר או תוצאה מדודה שמוכיחים שציון עצמי של 9 מתוך 10 מבטיח איכות.
מגבלות ובדיקות נוספות
ציונים הם שיפוט ולא מדידה אובייקטיבית. בדיקה עצמית פחות אמינה מבדיקה נפרדת, והמתכון לא הורץ מקצה לקצה עם סוכן נוסף במסגרת בדיקת הקבלה. פרסום או שינוי באתר חי דורשים אישור נפרד.
English summary
A proposed workflow for building and reviewing a game, website or app: decide before building, study examples, work in a preview, review user experience, design, function and content, fix concrete defects, and deliver evidence. Scores are subjective, not proof of quality. The submission reports no controlled trial or independent end-to-end reproduction. Publishing or changing a live site needs separate approval.
מאת: