גילוי נאות: המדריך כולל קישורי שותפים ל-Base44. הרשמה דרכם אינה מייקרת לך דבר. חלק מהקישורים למטה יוחלפו בקישורי Impact כשיהיו מוכנים.
[התחל ב-Base44, יוחלף בקישור Impact]
שער 02, לעבוד עם ה־AI: צ'אט, ענפים והיסטוריה
רוב הזמן שלך ב-Base44 יעבור מול הצ'אט, וכאן נקבע גם כמה מהר תתקדם וגם כמה קרדיטים תשרוף. הפרק הזה מסביר מה עושה כל מצב צ'אט, איך מנסחים בקשת שינוי שה-AI מבצע נכון בפעם הראשונה, ואיך עובדים עם ענפים והיסטוריית גרסאות כדי לנסות דברים בלי לשבור אפליקציה חיה.
הצ'אט הוא ממשק הפיתוח של Base44. אתה מתאר מה צריך, ה-AI כותב את הקוד, והתוצאה מופיעה בתצוגה המקדימה תוך שניות. הבעיה מתחילה כשזה לא עובד: אתה מנסח מחדש, מקבל משהו אחר, מבקש לתקן, ופתאום עברו שלושים הודעות והאפליקציה במצב גרוע יותר מזה שהתחלת ממנו.
הפרק הזה עוסק בשליטה בתהליך. תלמד מה ההבדל בין מצבי הצ'אט ומתי כל אחד משתלם, איך בנויה בקשת שינוי שה-AI מבין בפעם הראשונה, ואיך עובדים עם ענפים (Branches) כדי לנסות רעיון מסוכן בלי לגעת בגרסה החיה. בנוסף נעבור על היסטוריית הגרסאות והשחזור, רשת הביטחון שמאפשרת לך להעז, ועל פרוטוקול מסודר לרגע שבו ה-AI נתקע בלולאת תיקונים. מי שמפנים את ארבעת הנושאים האלה בונה מהר יותר ומשלם פחות.
02.1 מצבי הצ'אט של ה־AI
רמה: בסיס
הצ'אט מול ה-AI הוא המקום שבו נבנית האפליקציה, ולא כל שיחה שם עולה אותו דבר. Base44 מפריד בין שלושה מצבי עבודה, ולכל אחד היקף שינוי, מהירות ומחיר שונים. בחירת המצב הנכון היא ההחלטה היומיומית שהכי משפיעה על כמות הקרדיטים שתשרוף החודש.
Build הוא ברירת המחדל. מה שתבקש ייבנה מיד, בלי שלב אישור ביניים. זה המצב לשינויים שאתה כבר בטוח בהם: להוסיף עמוד, לשנות שדה בטופס, לתקן באג מוגדר. ככל שהבקשה מפורטת יותר, התוצאה מדויקת יותר.
Discuss הוא מצב שיחה בלבד, ושום דבר לא נבנה עד שתאשר. הוא עולה כ-0.3 קרדיט להודעה ומשתמש במודל משלו, ללא קשר למודל שהוגדר לאפליקציה. כאן שואלים מה הדרך הנכונה לבנות מערכת הזמנות עם ביטולים, מקבלים הצעה, מתווכחים עליה, ורק אז עוברים לבנות. זה ההבדל בין לשלם על חשיבה ובין לשלם על בנייה חוזרת.
Edit הוא עריכה ויזואלית ישירה, דרך כפתור נפרד בראש העורך ולא מתוך תפריט הצ'אט. שינויים ידניים כמו צבע, מרווח או מחיקת אלמנט אינם עולים קרדיטים כלל ונשמרים אוטומטית, עם ביטול וחזרה של עד 50 צעדים באותו סשן. לחיצה על אלמנט בודד משנה אותו לבדו, ולחיצה על אלמנט שחוזר על עצמו מחילה את השינוי על כל המופעים. עריכה בעזרת AI דרך Edit Element כן נספרת כהודעה, לפי הגודל והמורכבות. מעבר מהיר בין המצבים נעשה עם Cmd ונקודה במק, או Ctrl ונקודה בווינדוס.
כלל אצבע מעשי לבחירה: אם אתה יודע בדיוק איך התוצאה צריכה להיראות, זה Build. אם אתה עדיין מנסח את השאלה תוך כדי כתיבה, זה Discuss. ואם אתה רק רוצה להזיז, לצבוע או למחוק משהו שאתה רואה מול העיניים, זה Edit, שהוא גם היחיד מהשלושה שבשימוש ידני לא עולה לך כלום.
דוגמה מהשטח: סטודיו פילאטיס בהרצליה שבונה מערכת רישום לשיעורים. חצי שעה ב-Discuss על מבנה הנתונים, כלומר מנוי, שיעור, רישום ורשימת המתנה, ואחריה שש הודעות Build ממוקדות. אותה עבודה ישירות ב-Build מגיעה בקלות לעשרים הודעות, כי כל החלטה מבנית שגויה מתגלה רק אחרי שכבר נבנתה. אם עוד אין לך חשבון, [התחל ב-Base44, יוחלף בקישור Impact] לפני שאתה מתחיל לשרוף הודעות.
שים לב: הטעות הנפוצה היא לתכנן ב-Build: כל שאלת תכנון שנשאלת במצב בנייה נגמרת בקוד שנכתב ונזרק, אז תשאל ב-Discuss ותעבור ל-Build רק כשיש החלטה.
02.2 אנטומיה של בקשת שינוי טובה
רמה: בסיס
ה-AI לא קורא מחשבות ולא רואה את המסך שלך. בקשה שמנוסחת כמו משפט בשיחה, למשל הטופס לא עובד טוב, תחזיר לך ניחוש. בקשה בנויה מחזירה שינוי. המבנה שעובד מורכב משלושה חלקים: הקשר, מטרה ואילוץ.
- הקשר הוא איפה זה קורה: שם העמוד, שם הקומפוננטה, ואיזה סוג משתמש רואה את זה.
- המטרה היא מה אמור לקרות, בלשון תוצאה: אחרי שליחה המשתמש מגיע לעמוד תודה ומקבל מייל אישור.
- האילוץ הוא מה אסור לשנות: בלי לגעת בעיצוב של שאר העמוד, בלי להוסיף שדות לישות הקיימת.
הכלל השני הוא שינוי אחד בכל turn. שתי בקשות באותה הודעה מייצרות שתי הזדמנויות לטעות, וכשמשהו נשבר אתה לא יודע איזו מהן אשמה. הכלל השלישי הוא להראות במקום לתאר. צילום מסך של התקלה או הדבקה של טקסט השגיאה הגולמי שווים פסקה שלמה של תיאור. אפשר להעלות צילומי מסך ישירות לצ'אט בפורמטים הרגילים, אבל שים לב ששינוי סיומת של קובץ בלי המרה אמיתית מייצר שגיאת פורמט והעלאה שנכשלת.
כשה-AI לא מבין, הוא בדרך כלל מבין בדיוק את מה שכתבת, רק שכתבת משהו אחר ממה שהתכוונת. אל תחזור על אותה בקשה בניסוח נלהב יותר. פרק אותה: קודם השינוי בנתונים, אחר כך השינוי בממשק. אפשר גם ללחוץ על האלמנט עצמו בתצוגה המקדימה ולפתוח עליו שיחה ממוקדת, כדי שלא יישאר ספק על מה מדובר. ואם הבקשה הראשונה באפליקציה חדשה ארוכה מאוד, פרק גם אותה, כי פרומפט פתיחה ענק הוא מתכון לתוצאה רחוקה מהכוונה.
יש גם ניסוחים שכדאי למחוק מהאוצר שלך. תעשה שיהיה יפה, תסדר לי את העמוד ותתקן את כל הבאגים הם בקשות בלי גבול, וה-AI ימלא את החסר לפי ניחוש, לרוב בעיצוב חדש שלא ביקשת. אם אתה לא מצליח לתאר את התוצאה במשפט אחד, זה סימן שהבקשה עדיין לא מוכנה לבנייה, והמקום שלה הוא Discuss.
דוגמה: בעל מוסך בחולון ביקש להוסיף אפשרות לתאם תור, וקיבל טופס בלי שום בדיקת זמינות. הניסוח שעבד היה זה: בעמוד תיאום תור, כשלקוח בוחר תאריך, הצג רק שעות פנויות לפי הישות הקיימת, בהפרשים של שעה, בין שמונה בבוקר לחמש אחר הצהריים, ראשון עד חמישי, ובלי לשנות את עיצוב העמוד.
שים לב: הטעות הנפוצה היא לתאר תסמין במקום תוצאה רצויה: במקום הכפתור לא עובד, כתוב מה הוא אמור לעשות, מה קורה בפועל, וצרף את טקסט השגיאה המלא.
02.3 עבודה עם ענפים (Branches)
רמה: מתקדם
ענף (Branch) הוא עותק עבודה נפרד של האפליקציה, שנוצר תמיד ממצב ה-main הנוכחי. יש לו צ'אט משלו, תצוגה מקדימה משלו, עיצוב, עמודים, קבצי קוד והיסטוריית גרסאות משלו. אתה יכול לשבור בו דברים בלי שמשתמש בגרסה המפורסמת ירגיש משהו.
פותחים ענף מתוך שם האפליקציה בפאנל הצ'אט, בוחרים ליצור ענף חדש ומתארים על מה הולכים לעבוד, ו-Base44 מייצר שם קצר באנגלית. מעבר בין ענפים נעשה מראש הפאנל, וגם באמצע בנייה, וה-AI ימשיך לעבוד על הענף שעזבת. כשה-main משתנה מופיע כרטיס עדכון מעל הצ'אט, ולחיצה עליו מושכת את השינויים פנימה: חפיפות פשוטות נפתרות אוטומטית, והתנגשויות אמיתיות מגיעות להכרעה שלך. בסיום לוחצים על מיזוג ל-main, ואחרי המיזוג הענף הופך לקריאה בלבד ונשאר ברשימה לתיעוד.
מה שמשותף לכל הענפים חשוב לא פחות: הנתונים החיים, וגם חיבורים, אוטומציות, אינטגרציות, סודות, הגדרות האפליקציה, הדומיינים והגרסה המפורסמת. כלומר אם תמחק רשומה בתצוגה של ענף, מחקת אותה באמת בכל מקום. לניסויים עם נתונים יש מצב test data, שזמין בתוכנית Builder ומעלה, ו[בדוק תוכניות Base44, יוחלף בקישור Impact]. גם חלק מהפעולות מתבצעות ב-main בלבד: פרסום, יצירה ועריכה של סודות, אוטומציות וסוכנים, שינוי הגדרות ערכת נושא וניהול רשומות. הוספת ישות או שדה חדש קורית בענף, אבל מחיקת ישות או שינוי סוג שדה מתבצעים ב-main.
לכל ענף יש גם היסטוריית גרסאות עצמאית, כך ששחזור בענף לא נוגע ב-main, ולשונית הקוד מציגה את הקבצים של הענף שאתה נמצא בו ולא של main. אם האפליקציה מחוברת ל-GitHub, כל ענף נשמר כענף אמיתי במאגר, ואפשר גם לייבא ענף קיים מהמאגר פנימה. פרסום עצמו זמין רק ב-main, כך שעבודה בענף תמיד נגמרת במיזוג.
מתי זה מיותר: לתיקון טקסט, צבע או באג קטן, ענף רק מוסיף שלב מיזוג. מתי זה הכרחי: שינוי מבני, ניסוי עיצובי, או שני אנשים במקביל. סוכנות דיגיטל בתל אביב שמריצה שני מעצבים על אותה אפליקציה תפתח ענף לכל אחד; האפליקציה תומכת בעד חמש בניות במקביל, ומעבר לזה הבקשות ממתינות בתור. מחיקת ענף היא סופית, אז מזגו לפני שמוחקים.
שים לב: הטעות הנפוצה היא להתייחס לענף כאל סביבת בדיקות מלאה: הנתונים משותפים, אז לפני ניסויי מחיקה או ייבוא המוני עבור לתצוגת test data.
02.4 Checkpoints, שחזור וביטול
רמה: בסיס
כל בנייה ב-Base44 מתועדת. לכל הודעה בצ'אט יש נקודת חזרה משלה, ובנוסף קיימת היסטוריית גרסאות של האפליקציה כולה. זו רשת הביטחון שמאפשרת לך לבקש שינוי אגרסיבי בלי לחשוש, אבל רק אם אתה יודע איפה היא לא תופסת.
יש שתי דרכים לחזור אחורה, והן לא מתחלפות זו בזו:
- ביטול הודעה בודדת מבטל את מה שהודעה מסוימת עשתה. זה הכלי כשהשינוי האחרון הוא הבעיה ואתה מזהה אותו מיד.
- היסטוריית הגרסאות מחזירה אותך לנקודת זמן שלמה, כמה צעדים אחורה. זה הכלי כשאתה כבר לא יודע איפה בדיוק זה התקלקל.
נקודה שמפילה הרבה אנשים: לבקש מה-AI בצ'אט להחזיר אחורה לא מבטל כלום. הצ'אט הוא ממשק בנייה, לא ממשק שחזור, ובקשה כזו רק תגרום לו לכתוב קוד חדש שמנסה לחקות את המצב הקודם ולשרוף עוד הודעה בדרך. השחזור נעשה מהכפתורים הייעודיים בלבד.
השחזור פועל ברמת הענף: אם אתה עובד בענף, חזרה לגרסה ישנה לא נוגעת ב-main, ואפשר לשחזר רק כשלא רצה בנייה באותו רגע. הסכנה האמיתית היא עריכות ידניות בקוד. אם נכנסת ללשונית הקוד, תיקנת פונקציה בעצמך, ואחר כך שחזרת גרסה מוקדמת יותר, התיקון הידני נעלם יחד עם הגרסה. לפני עריכה ידנית משמעותית שמור לעצמך עותק של הקובץ מחוץ למערכת.
שווה גם להבין מה נחשב נקודת חזרה ומה לא. הבנייה מתועדת לפי הודעות ולפי גרסאות, אבל פעולות שנעשות מחוץ לצ'אט, כמו שינוי רשומות בנתונים החיים או מחיקה של תוכן על ידי משתמש באפליקציה המפורסמת, אינן חלק מההיסטוריה של הקוד. שחזור גרסה יחזיר לך את הממשק והלוגיקה, לא את הנתונים שנמחקו.
ההרגל שמשתלם הוא פשוט: לפני כל שינוי גדול, כלומר החלפת עיצוב כוללת, שינוי מבנה נתונים או חיבור אינטגרציה, עצור, ודא שהגרסה הנוכחית עובדת, ורק אז בקש. דוגמה: עמותה בירושלים ביקשה להעביר את כל המערכת לעיצוב כהה ואיבדה בדרך שלוש שעות של התאמות בטפסים. חזרה לגרסה שלפני הבקשה החזירה הכול תוך דקה, בדיוק מפני שהן זיהו את הבעיה מיד ולא ניסו לתקן עשר הודעות קדימה.
שים לב: הטעות הנפוצה היא לנסות לתקן שבירה בעוד הודעות: אם שתי הודעות תיקון לא החזירו את המצב לתקין, חזור לגרסה האחרונה שעבדה והתחל ממנה.
02.5 הערות על האפליקציה (Commenting)
רמה: בסיס
הערות הן הדרך להצביע על אלמנט באפליקציה במקום לתאר אותו במילים. לוחצים על אייקון ההערות בפינה העליונה של העורך, ליד האווטאר וכפתורי הפרסום, ואז על האלמנט עצמו בתצוגה המקדימה. המערכת מצלמת את האזור שלחצת עליו ומצמידה אליו שרשור דיון.
ההערה נשארת מוצמדת לאלמנט גם כשהאפליקציה משתנה סביבה, ואפילו אם האלמנט נמחק השרשור והצילום נשמרים. אפשר לערוך הערה משלך, לחתוך מחדש את אזור הצילום, להגיב, להוסיף ריאקשן, לסמן כפתורה או למחוק אותה. שרשורים שנפתרו נעלמים מהתצוגה ומרשימת ברירת המחדל אבל ניתנים לשחזור.
החלק המעניין הוא החיבור ל-AI. אזכור של @Base44 בשרשור, או שליחה שלו לצ'אט מתוך ההערה, הופך את הדיון לבקשת שינוי עם ההקשר הוויזואלי מוצמד אליה. מתוך פאנל ההערות אפשר לשלוח עד 20 שרשורים בבת אחת, מה שהופך סבב הערות שלם למשימה אחת במקום לעשרים שיחות נפרדות.
שתי מגבלות שכדאי להכיר מראש: ההערות נראות רק בתוך עורך האפליקציה, ומי שמשתמש בגרסה המפורסמת לעולם לא יראה אותן, ובאזכורים מופיעים רק שותפים לאפליקציה. אורך הערה מוגבל לחמשת אלפים תווים, וההערות נשמרות גם בין ענפים.
הדרך היעילה לעבוד עם זה היא בסבבים ולא בזרם רציף. אוספים את כל ההערות בישיבה אחת, עוברים עליהן ומסמנים מה באמת נכנס לגרסה הזו, ורק אז שולחים לצ'אט. כך אתה גם מונע מצב שבו שתי הערות סותרות נשלחות לבנייה בזו אחר זו, והתוצאה השנייה מבטלת את הראשונה.
מול לקוח זה משנה את אופי העבודה. משרד עורכי דין ברמת גן שמקבל אפליקציה לניהול תיקים לא יודע לומר שהמרווח הפנימי בכרטיס גדול מדי, אבל הוא בהחלט יודע ללחוץ על הכרטיס ולכתוב שזה נראה דחוס. במקום פרוטוקול ישיבה של שמונה שורות מעורפלות אתה מקבל שמונה הערות מוצמדות למקום המדויק, ושולח אותן לצ'אט אחת אחרי השנייה. תוסיף לזה את הכלל מהנושא הקודם, שינוי אחד בכל פעם, ויש לך סבב תיקונים שנסגר באותו יום במקום להימרח על שבוע.
שים לב: הטעות הנפוצה היא לצפות שהלקוח יעיר מתוך האפליקציה החיה: ההערות קיימות רק בעורך, אז כדי שלקוח יוכל להעיר צריך לשתף אותו כשותף עם גישה לעורך.
02.6 כשה־AI נתקע: פרוטוקול חילוץ
רמה: מתקדם
לולאת תיקון היא המצב שבו אתה מבקש תיקון, מקבל שבירה חדשה, מבקש שוב, וכל סבב עולה לך הודעה. זה הבזבזן הגדול ביותר של קרדיטים, והוא כמעט תמיד תוצאה של החלטה להמשיך במקום לעצור. במקום זה, פרוטוקול קבוע בחמישה שלבים:
- עצור. אם turn רץ יותר מדי זמן, יש כפתור עצירה. בנייה שעברה עשר דקות בלי שום עדכון היא תקועה, לא איטית.
- העבר את השגיאה כמו שהיא. הדבק את טקסט שגיאת הבנייה או שגיאת הקונסול בצורה גולמית, בלי לנסח מחדש. השם המדויק של השגיאה הוא המידע היקר.
- עבור ל-Discuss. במקום לבקש תיקון נוסף, בקש אבחון: למה זה קורה ומה שתי האפשרויות לתקן. שליש קרדיט במקום עוד סבב בנייה.
- שחזר. אם שתי הודעות תיקון לא עזרו, חזור לגרסה האחרונה שעבדה. תיקונים נוספים רק מרחיקים אותך ממנה.
- בדוק אם זו בכלל תקלה שלך. רענון, ניקוי מטמון, חלון פרטי וכיבוי תוספים. יש דף סטטוס ציבורי וקהילת Discord שבהם מדווחות תקלות רוחביות.
טריק שימושי: לכתוב בצ'אט שמשהו לא בסדר ולתת למערכת לסרוק את האפליקציה ולהציע תיקונים לפי ההקשר. אם הצ'אט עצמו תקוע ולא מגיב בכלל, אפשר להחליף מודל בהגדרות, לשלוח הודעה קצרה ב-Discuss, או לבצע שינוי זעיר במצב Edit כדי להעיר אותו.
מקרה קצה שכדאי להכיר בנפרד הוא אפליקציה חדשה שנתקעת כבר על הפרומפט הראשון ולא יוצאת ממצב חשיבה. שם לרוב אין מה לתקן: משכפלים את האפליקציה או פותחים חדשה, ומגישים את אותו רעיון בשתיים שלוש בקשות קצרות במקום בפרומפט פתיחה ענק אחד.
מתי עוברים לעריכת קוד ידנית: כשהבעיה נקודתית וחוזרת, כמו שורה אחת בפונקציה, תנאי שגוי או מחרוזת בעברית שנשברת. בעל חנות אונליין בבאר שבע בזבז אחת עשרה הודעות על חישוב מע"מ, והתיקון בפועל היה שורה אחת בקומפוננטה. אם אתה יודע בדיוק מה לתקן, תקן בעצמך.
ומתי פונים לתמיכה: כשהתקלה אינה שלך. שגיאת שרת חוזרת, מסך לבן שמופיע גם בדפדפן אחר ובמכשיר אחר, או בנייה תקועה מעל עשר דקות. צרף קישור לאפליקציה, מה עשית בדיוק לפני, ומתי זה התחיל.
שים לב: הטעות הנפוצה היא לתאר את השגיאה במילים שלך: הדבק את הטקסט המלא של השגיאה, כי ניסוח מחדש מוחק בדיוק את הפרט שמזהה את הבעיה.
[התחל ב-Base44, יוחלף בקישור Impact]
