בנה לוח בקרה ל-SaaS עם מעקב התקדמות, רשימת תיוג וסרגל צד למסמכים.
- דפים: סקירה, משימות, הגדרות.
- מודל נתונים: משימה { id, כותרת, מצב: 'todo' | 'in-progress' | 'done', בעלים, תאריך יעד }.
- תכונות: חיפוש, סינון לפי מצב, השלמה בכמות, התראות snackbar.
- UX: פריסה רספונסיבית, קיצורי מקלדת לפעולות מהירות, מצב לילה.

החלף את חנות האחסון המקומי בשכבת REST API באמצעות fetch.
- נקודות קצה: /tasks .
---
## פתרון בעיות: כש-Bolt.new לא מבין אותך
- הבהר את הכוונה: “שינית את מבנה הנתונים; בבקשה החזר ושמור רק על שדה ‘הערות’ נוסף.”
- הגבל היקף: “עדכן רק את רכיב ‘Dashboard’, לא את הפריסה כולה.”
- ספק דוגמאות: “מבנה JSON צפוי הוא {...}. עדכן את הפרסר בהתאם.”
- נעילת שמות: “אל תשנה שמות קבצים או יצוא.”
אם הבעיות ממשיכות, נסח מחדש את הדרישות כמפרט קצר ובקש מ-Bolt להתאים את היישום למפרט.
---
## דוגמה: מבקשה לאפליקציה מלוטשת ב-5 איטרציות
מטרה: עוקב קריאה אישי עם סטטיסטיקות ותגים.
- בקשה 1: “צור עוקב קריאה עם הוספה/עריכת ספרים, מצב (קורא/סיום), דירוג 1–5, וסינונים מבוססי תגיות. השתמש בממשק נקי ורספונסיבי.”
- בקשה 2: “הוסף דף סטטיסטיקות: סך הכל ספרים, דירוג ממוצע, תגיות מובילות.”
- בקשה 3: “ממש חיפוש-כאשר-כותבים עם דיבאונס והדגשת התאמות.”
- בקשה 4: “הוסף ייבוא/ייצוא דרך JSON. הצג מודאל אישור בהחלפה.”
- בקשה 5: “מעבר נגישות: ניווט במקלדת, טבעות מיקוד, aria-live להודעות.”
תוצאה: כלי אישי לשימוש מלא שאפשר לאיטרט לאפליקציה ציבורית.
---
## מהלכים עוצמתיים: קיצורי דרך ודפוסים שחוסכים זמן
- התחל עם רכיבים: “השתמש בתבנית Card, Button, Modal וורכב עם slots.”
- בקש בדיקות מוקדם: “הוסף בדיקות יחידה לעזרי נתונים ובדיקת עשן לתצוגה המובילה.”
- צפיות לוגינג: “הוסף פאנל מפתח שמציג קריאות API ומעברי מצב.”
- תיעוד מקוון: “תעד props ופונקציות עם JSDoc לכל סמל מיוצא.”
לסרטון מדריך מעמיק לבניית אפליקציות מקצה לקצה עם Bolt, הסרטון מאוד מועיל.
---
## מתי להשתמש ב-Bolt.new לעומת פיתוח מסורתי
השתמש ב-Bolt.new כאשר:
- אתה צריך אב-טיפוס או כלי פנימי במהירות.
- אתה מאמת UX מול בעלי עניין השבוע.
- קוד חוזר (boilerplate) מאט אותך.
השתמש בהגדרה מסורתית כאשר:
- אתה צריך תשתית מותאמת עמוקה או תזמור מורכב של שירותים מרובים.
- דרישות תאימות, אבטחה או ביצועים מחייבות קוד מטוייל ידנית.
- אתה בונה בסיס קוד ארוך טווח עם דפוסים נוקשים מיום הראשון.
---
## כדאי לדעת: שפר את הבקשות עם [Sider.AI](https://sider.ai)
אם אתה כותב מפרטים, סיפורי משתמש או קריטריוני קבלה מראש, תקבל תוצאות נקיות יותר מ-Bolt.new. [Sider.AI](https://sider.ai) יכולה לעזור להפוך רעיונות גולמיים לבקשות מדויקות, לפרק תכונות לכרטיסים ואפילו ליצור מקרי בדיקה שתוכל להדביק ישירות בצ׳אט של Bolt. דרך אגב, שימוש ב”רשימת בדיקה” או שלד מפרט יכול להפחית תקלות ולחסוך איטרציות.
נסה את המתווה המוכן ל-[Sider.AI](https://sider.ai):
- הצגת הבעיה
- תפקידי משתמש והרשאות
- מודל נתונים עם שדות/טיפוסים
- זרימות משתמש קריטיות
- מקרי קצה ודרישות לא פונקציונליות
---
## השלבים הבאים: ספר משחק של 30 דקות
- בחר רעיון לאפליקציה קטנה (לוח בקרה, עוקב, או CMS מיני).
- הדבק את תבנית בקשת ההתחלה והתאם אותה.
- בצע איטרציה ב-5–7 בקשות ממוקדות, עם בדיקה אחרי כל שינוי.
- הוסף נגישות, מצבי שגיאה ובדיקה בסיסית.
- שלח גרסה ראשונה; אסוף פידבק; בצע איטרציה שוב.
תמצא שזה מהיר—וגם כיף יותר—מהרכבה ידנית מההתחלה.
---
## מקורות ולמידה נוספת
- הקדמה רשמית ל-Bolt (זרימת עבודה מבקש למוצר).
- סרטון הדרכה צעד-אחר-צעד לשימוש ב-Bolt.new.
- טיפים מהקהילה: הימנע מהחלפת שאילתות בטעות ובצע איטרציה בטוחה.
### שאלות נפוצות
ש1: למה משמש Bolt.new?
Bolt.new הוא IDE מבוסס AI שממירה בקשות בשפה טבעית לאפליקציות עובדות עם תצוגות חיות. אידיאלי לפרוטוטייפ מהיר, כלים פנימיים, לוחות בקרה ואישורי רעיון עם ממשק משתמש כבד.
ש2: איך מתחילים פרויקט ב-Bolt.new?
פתח את bolt.new, התחבר, ותאר את האפליקציה שלך בבקשה ברורה אחת. Bolt יסרגל קוד, קבצים ותצוגה מקדימה לחיים, כך שתוכל לאיטרט בצ׳אט או בעריכות ישירות.
ש3: איך כותבים בקשות טובות ל-Bolt.new?
היה ספציפי לגבי תכונות, מודלי נתונים, ציפיות UX ומגבלות. למשל, הגדר שדות, דפים והתנהגויות; ואז בקש שינויים קטנים וממוקדים בכל איטרציה.
ש4: האם אפשר לחבר אפליקציות Bolt.new ל-API אמיתיים?
כן. התחל עם נתונים מדומים ובהמשך בקש מתאם REST או GraphQL, תוך שמירה על טיפוסים והוספת טיפול שגיאות תקין. גישה זו שומרת על מהירות ובטיחות באיטרציות הראשונות.
ש5: מתי לא להשתמש ב-Bolt.new?
אם האפליקציה דורשת תאימות מחמירה, תזמור שירותים מרובה מורכב או ביצועים אופטימליים מאוד, הגדרת פיתוח מסורתית עשויה להיות טובה יותר מהיום הראשון.