← חזרה למדריך המלא

גילוי נאות: המדריך כולל קישורי שותפים ל-Base44. הרשמה דרכם אינה מייקרת לך דבר. חלק מהקישורים למטה יוחלפו בקישורי Impact כשיהיו מוכנים.

[התחל ב-Base44, יוחלף בקישור Impact]

שער 01, מהפרומפט הראשון לאפליקציה חיה

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

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

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

01.1 הפרומפט הראשון , אנטומיה

רמה: בסיס

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

המבנה שעובד

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

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

מצב התכנון

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

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

שים לב: הטעות הנפוצה ביותר היא לדחוס לפרומפט הפותח את כל הפיצ'רים שחלמת עליהם, תאר את הליבה בלבד, ותוסיף את השאר בהודעות נפרדות אחרי שהבסיס עומד.

בתיעוד הרשמי: First prompt

01.2 בניית אפליקציה מאפס , שלב אחר שלב

רמה: בסיס

המסלול המלא מתאר חמישה שלבים, ורובם לא קורים בצ'אט. מי שמדלג על שלבי הבדיקה וההרשאות מגלה את הבעיות מול הלקוח הראשון.

60 השניות הראשונות

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

סדר הבנייה שמונע עבודה כפולה

  1. ישויות ושדות, ודא במסך Data שהטבלאות נכונות לפני שאתה נוגע בעיצוב. שינוי שדה מאוחר גורר תיקון בכל עמוד שמציג אותו.
  2. עמודים ותהליכים, הוסף פונקציונליות בהודעות קצרות: טופס, מסך רשימה, לוח בקרה.
  3. הרשאות ותפקידים, הגדר מי רואה מה, כולל תפקידים מותאמים. זה נעשה מ-Settings, לא מהצ'אט.
  4. עיצוב וליטוש, כאן משתלם להשתמש במצב העריכה הידני לשינויים נקודתיים במקום לבזבז סבב AI שלם.
  5. בדיקה ואז פרסום, בסדר הזה בלבד.

צ'קליסט ״האפליקציה הראשונה שלי״

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

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

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

בתיעוד הרשמי: Building an app

01.3 בניית אתר , במה זה שונה מאפליקציה

רמה: בסיס

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

מתי אתר מספיק

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

השלבים שלא מדלגים עליהם

  1. מבנה ותוכן, עמודים, ניווט ומסרים. תגיד מראש אילו עמודים אתה רוצה, אחרת תקבל ברירת מחדל גנרית.
  2. נגישות, כותרת ראשית אחת בכל עמוד והיררכיית כותרות הגיונית, טקסט חלופי לתמונות, ניגודיות צבעים מספקת, טקסט קישור תיאורי במקום ״לחץ כאן״, וניווט מלא במקלדת. בישראל זו לא המלצה בלבד אלא דרישה רגולטורית לעסקים רבים, ועדיף לבקש את זה מהצ'אט מראש.
  3. בדיקה, דסקטופ ומובייל, שליחת טפסים, כל הקישורים, והגהה של התוכן בעברית.
  4. דומיין, אפשר לרכוש דרך Base44 או לחבר דומיין קיים בעדכון רשומות DNS.
  5. פרסום, כולל קביעת מי רואה את האתר וסריקת אבטחה.

SEO מהיום הראשון

יש לוח בקרה ייעודי ל-SEO ו-GEO שסורק את האתר, נותן ציון, מאפשר להגדיר כותרת ותיאור לכל עמוד ולשלוט באינדוקס. GEO הוא הנראות בכלי AI שמצטטים מקורות, וזה כבר מזמן לא נספח אלא ערוץ תנועה בפני עצמו. תעשה את זה בזמן הבנייה ולא חודשיים אחרי, כי כותרת ותיאור שנכתבים בדיעבד כמעט תמיד נכתבים בחיפזון. מאמן כושר מראשון לציון שמפרסם אתר בלי כותרות ותיאורים מותאמים פשוט לא יופיע על חיפושים מקומיים. [התחל ב-Base44, יוחלף בקישור Impact].

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

בתיעוד הרשמי: Building a website

01.4 תבניות אפליקציה

רמה: בסיס

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

איפה זה יושב ומה מקבלים

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

המחיר של להתחיל מתבנית

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

איך מתאימים בלי לשבור

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

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

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

בתיעוד הרשמי: App templates

01.5 ייבוא עיצוב מ־Figma

רמה: מתקדם

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

תנאי סף

  • נדרש מושב Editor בפיגמה. חשבונות צפייה ושיתוף פעולה חסומים לגישת API מצד פיגמה עצמה.
  • נדרש קובץ מסוג Figma Design. קבצי FigJam ומצגות אינם נתמכים.
  • קישור הפריים חייב להיות פתוח לצפייה לכל מי שיש לו קישור. אפשר להחזיר אותו לפרטי אחרי הייבוא.
  • אפשר לחבר חשבון פיגמה אחד לכל סביבת עבודה.

איך עושים

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

איך להכין את הקובץ

  1. חלק את העמוד לאזורים לוגיים בתוך פריימים או קבוצות: כותרת, אזור פיצ'רים, פוטר.
  2. השתמש ב-Auto Layout ברכיבים חוזרים כמו כרטיסים וסרגלי ניווט. זה מה שמאפשר להבין יחסים ולבנות פריסה רספונסיבית.
  3. שמור על היררכיה הגיונית ועל מרווחים וריווח אחידים, והימנע מקינון מיותר.
  4. שטח וקטורים מורכבים לאלמנט אחד, והפוך קווים ומסגרות למתאר לפני השיטוח.
  5. מחק שכבות מוסתרות או שנדחפו מחוץ לקנבס.
  6. פשט מילויים, רק המילוי האחרון על אלמנט מיובא.

מה תמיד צריך לתקן אחרי

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

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

בתיעוד הרשמי: Import from Figma

01.6 מיגרציה של פרויקט קיים

רמה: מתקדם

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

מה אפשר להעביר

  • Salesforce, עשרים וארבעה אובייקטים סטנדרטיים כמו לקוח, איש קשר, ליד והזדמנות, וגם אובייקטים מותאמים, שדות והקשרים ביניהם.
  • HubSpot, אנשי קשר, חברות, עסקאות, שורות פריט ובעלים, כולל הסכמות.
  • Shopify, מוצרים, הזמנות, לקוחות, קולקציות, עמודים, מאמרים והנחות, וגם קוד התבנית.
  • WordPress, פוסטים, עמודים, קטגוריות, תגיות, מטא-דאטה של מדיה ותגובות, ומשתמשים באתרים באחסון עצמי. עם WooCommerce מצטרפים גם מוצרים, הזמנות ולקוחות בשדות הסטנדרטיים.
  • Lovable ו-Bolt.new, הטבלאות שיצרת, כולל סכמה, מפתחות ראשיים וזרים ונתונים, והקוד מהמאגר ב-GitHub.

מה לא עובר

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

אסטרטגיית מעבר

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

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

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

בתיעוד הרשמי: Migrating a project

01.7 חיבור מאגר GitHub

רמה: מפתחים

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

ייבוא מאגר קיים

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

סנכרון, ענפים וקונפליקטים

המערכת יוצרת ענף התקנה בשם שמתחיל ב-base44/setup-, ומשם מבצעת commit ו-push לענף שאתה עובד עליו בכל פעם שהצ'אט מסיים שינוי. ענפים חדשים מקבלים שמות קצרים ותיאוריים. ענף ברירת המחדל שלך לא נגוע לעולם, השינויים מגיעים אליו רק דרך pull request. כשקובץ השתנה בשני הצדדים נוצר קונפליקט, וה-AI קורא את הקבצים ומנסה לשמר את שני השינויים; כשהמימושים באמת סותרים זה את זה הוא עוצר ושואל אותך איזו התנהגות נכונה. כתיבה ישירה למאגר דורשת אישור שלך בצ'אט.

מדיניות ארגונית

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

סטארטאפ ישראלי עם צוות של שלושה מפתחות יכול לתת למנהלת המוצר לבצע שינויים בשפה טבעית, בעוד כל שינוי עובר pull request ובדיקת קוד רגילה. שים לב שייצוא קוד וחיבור GitHub פתוחים מתוכנית Builder ומעלה, אז [בדוק תוכניות Base44, יוחלף בקישור Impact] לפני שאתה מבטיח את זה לצוות.

שים לב: הטעות הנפוצה ביותר היא להניח שפרויקט מיובא מ-GitHub מקבל את הישויות וההתחברות של Base44, הוא לא, והוא ממשיך לעבוד מול מסד הנתונים והאימות שלו עצמו.

בתיעוד הרשמי: GitHub repository

01.8 כתיבת פרומפטים אפקטיביים + ספריית פרומפטים

רמה: בסיס

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

חמישה עקרונות

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

בנק פרומפטים בעברית

  • תיקון באג: ״בעמוד X, כשאני לוחץ על Y, קורה Z ואני מצפה ל-W. תקן את זה בלי לשנות את שאר העמוד.״
  • שינוי עיצוב: ״בעמוד X בלבד: שנה את רקע האזור העליון ל־Y, הגדל את המרווח בין הכרטיסים, והשאר את הטיפוגרפיה כפי שהיא.״
  • הוספת פיצ'ר: ״הוסף לישות X שדה Y מסוג Z, הצג אותו בטופס ובמסך הרשימה, ואל תיגע בהרשאות.״
  • ריפקטור: ״אחד את הלוגיקה החוזרת בעמודים X ו-Y לרכיב אחד, בלי לשנות את ההתנהגות כלפי המשתמש.״
  • לוגיקה מותנית: ״הצג את כפתור ההורדה רק למשתמש בתפקיד X ורק אחרי שהסטטוס הוא Y.״

כשהתוצאה לא מה שביקשת

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

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

בתיעוד הרשמי: Prompt guide + library

← חזרה למדריך המלא

[התחל ב-Base44, יוחלף בקישור Impact]