GPT-6 הגיע: מה באמת השתנה, ואיך מעדכנים את הפרומפטים והכלים שלכם בלי לשבור כלום

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

המדריך הזה בשבילכם אם יש לכם נכסים שנבנו על מודלים ישנים: ספריית פרומפטים, GPT מותאם, פרויקט ב-Claude, אוטומציה שמושכת API, תבניות תוכן, או פשוט הרגלי עבודה שהתקבעו. הוא לא מדריך “10 טריקים לפרומפטים” — הוא תוכנית מעבר. בסוף תדעו בדיוק מה לבדוק, מה למחוק, מה לשכתב, ומה להשאיר בשקט.

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

מה באמת משתנה במעבר בין דורות (ולמה זה מרגיש מבלבל)

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

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

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

3. שליטה על עומק החשיבה. הכלים המודרניים — ChatGPT, Claude, Gemini — כולם מפרידים היום בין מצב מהיר למצב חשיבה עמוקה יותר. ההרגל הישן של “תמיד לבחור את המודל הכי חזק לכל דבר” הפך מבזבזני: אתם משלמים בזמן המתנה על שאלות שלא דורשות את זה.

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

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

שלב 0: אל תשדרגו כלום לפני שיש לכם ערכת בדיקה

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

זה נשמע מפחיד וזה לוקח 40 דקות:

1. פתחו מסמך אחד בשם prompt-tests.
2. בחרו 8–12 משימות אמיתיות שאתם עושים באמת — לא דוגמאות תיאורטיות. מייל ללקוח שמתעכב, סיכום פגישה, תיאור מוצר, ניתוח טבלה, תיקון קוד, פוסט לרשת.
3. לכל משימה שמרו: את הפרומפט המדויק, קלט לדוגמה, ואת הפלט שקיבלתם מהמודל הישן.
4. הוסיפו שורה אחת לכל משימה: “מה הופך תשובה כאן לטובה?” — למשל “עד 120 מילה, בלי אימוג’ים, מסתיים בשאלה”.

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

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

מה למחוק מהפרומפטים הישנים כבר היום

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

מחקו או בדקו מחדש:

• “קח נשימה עמוקה”, “אתה מומחה עולמי עם 20 שנות ניסיון” — הצגה של תפקיד עדיין עוזרת כשהיא מוסיפה מידע אמיתי (“אתה רואה חשבון שמכיר את חוקי המע”מ בישראל”), אבל המחמאות הריקות כבר לא קונות כלום.
• “חשוב צעד אחר צעד לפני שאתה עונה” — במודלים שיודעים לחשוב לבד זה לרוב מיותר, ולפעמים גורם לתשובות ארוכות ומסורבלות. אם אתם רוצים חשיבה, בקשו את מצב החשיבה של הכלי, לא משפט קסם.
• “אל תכתוב מבוא ארוך”, “אל תסביר מה אתה עומד לעשות” — שווה לבדוק אם זה עדיין נחוץ. לעיתים קרובות זה כן, כי זו התנהגות ברירת מחדל, אבל אל תסחבו חמישה משפטי “אל תעשה” כשאחד מספיק.
• הוראות שנועדו לעקוף חוסר בקונטקסט — כמו “חלק את הקובץ לשלושה חלקים כי אתה לא זוכר הכל”. אם החלון ארוך יותר, ההנחיה הזו רק פוגעת באיכות.
• דוגמאות (few-shot) ישנות באיכות בינונית. זו הטעות היקרה ביותר: המודל החדש היה כותב טוב יותר מהדוגמה שנתתם לו, אבל הוא מתיישר לפיה. שתי דוגמאות מצוינות עדיפות על שש בינוניות.

הנה פרומפט שתוכלו להעתיק ולהריץ על כל פרומפט ישן שלכם:

אני מעביר פרומפט שנכתב לפני שנה למודל חדש יותר.
הפרומפט המקורי:
---
[הדביקו כאן את הפרומפט]
---
דוגמה לפלט שקיבלתי מהמודל הישן ולא אהבתי:
---
[הדביקו פלט]
---
עשה שלושה דברים, בנפרד:
1. סמן אילו משפטים בפרומפט הם "קביים" — כלומר נועדו לפצות על חולשה של מודל,
   ולא מוסיפים מידע על המשימה עצמה.
2. סמן אילו משפטים מכילים מידע עסקי אמיתי שאסור לאבד (קהל, טון, אילוצים, מונחים).
3. כתוב גרסה חדשה, קצרה יותר, שמשמרת רק את (2).
אל תשפר את התוכן — רק נקה. אם משהו לא ברור לך בפרומפט המקורי, שאל אותי במקום לנחש.

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

המבנה שעובד היום: פחות קסמים, יותר מפרט

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

## משימה
כתוב מייל תזכורת ללקוח על חשבונית שלא שולמה.

## רקע
אנחנו סטודיו עיצוב קטן. הלקוח עובד איתנו שנתיים, יחסים טובים.
זו הפעם השנייה שהחשבונית מתעכבת. סכום: 4,200 ש"ח, איחור של 19 יום.

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

## פורמט
שורת נושא, ואז גוף המייל. בלי הסברים שלך מסביב.

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

שלושה דברים שכדאי לשים לב אליהם כאן:

ההוראות באות בסוף, לא בהתחלה. כשאתם מדביקים מסמך ארוך, שימו את הטקסט למעלה ואת המשימה למטה. הסבירות שההוראה “תיבלע” בתוך חומר ארוך קטנה משמעותית כשהיא אחרונה.

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

הגדרת הפורמט תופסת מקום של חמישה תיקונים. “בלי הסברים שלך מסביב” חוסך לכם את הסבב של “רק את המייל בבקשה”.

הרגלי עבודה שכדאי לשנות עכשיו

תפסיקו לפתוח שיחה חדשה לכל דבר. הפרויקטים והזיכרון בכלים המודרניים מחליפים חלק גדול מ“הפרומפט הפותח הארוך” שהייתם מדביקים כל בוקר. העבירו את ההקשר הקבוע שלכם — מי אתם, מה העסק, איך אתם כותבים, מה אתם שונאים — למקום הקבוע (הוראות מותאמות ב-ChatGPT, פרויקט ב-Claude, Gem ב-Gemini), והשאירו לפרומפט רק את המשימה של עכשיו.

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

הפסיקו “לתקן בשיחה” ארוכה. ההרגל של 12 סבבי תיקון (“קצר יותר”, “פחות רשמי”, “בלי המילה הזאת”) מייצר שיחה עמוסה שדוחפת את המודל לפשרות. אחרי שני תיקונים — קחו את התיקונים, הכניסו אותם לפרומפט המקורי כאילוצים, והתחילו מחדש. זה כמעט תמיד מהיר יותר ונותן תוצאה נקייה יותר.

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

אוטומציות, API וכלים: איפה באמת נשבר משהו

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

סדר פעולות בטוח:

1. אל תחליפו מודל ישירות בסביבת ייצור. הריצו הרצה מקבילה: אותם קלטים לשני המודלים, שמירת שתי התוצאות, השוואה ידנית של 30–50 מקרים.
2. בדקו את ה-parser קודם. אם אתם מפרקים את התשובה עם חיתוך מחרוזות או ביטוי רגולרי כי “המודל תמיד מחזיר את זה ככה” — זה ישבר. עברו לפלט מובנה: בקשו JSON עם סכמה מוגדרת, ואמתו אותו בקוד לפני שימוש.
3. בדקו פרמטרים שאולי לא נתמכים. בין דורות משתנים לפעמים אילוצים על פרמטרים כמו טמפרטורה או אורך פלט מקסימלי. אל תניחו — הריצו קריאה אחת ותראו מה חוזר.
4. בדקו עלות מחדש, לא לפי אינטואיציה. מודלים שחושבים יותר צורכים יותר טוקנים גם כשהתשובה הסופית קצרה. הריצו 100 קריאות אמיתיות ומדדו, במקום להעריך.
5. הוסיפו ניטור לאיכות, לא רק לשגיאות. שיעור תשובות שנכשלו בוולידציה, אורך פלט ממוצע, זמן תגובה. ירידת איכות היא כמעט אף פעם לא קריסה — היא הזחה איטית.

לגבי GPTs מותאמים, פרויקטים ו-Gems: אל תעבירו את ההוראות כמו שהן. ברוב המקרים ההוראות שכתבתם מכילות 40% ניסיונות אילוף שכבר לא נחוצים. העבירו רק את הידע הייחודי לכם — טרמינולוגיה, נהלים, קהל, דוגמאות מהמותג שלכם — ואת הקבצים. את ההתנהגות הכללית תנו למודל.

טעויות נפוצות

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

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

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

לפניך שתי תשובות לאותה משימה, A ו-B.
המשימה הייתה: [תיאור]
הקריטריונים, לפי סדר חשיבות: (1) דיוק עובדתי, (2) עמידה באורך שנדרש,
(3) טון מתאים לקהל, (4) אין תוכן מיותר.
לכל קריטריון תן ציון 1-5 לכל תשובה, עם ציטוט אחד מהטקסט שמצדיק את הציון.
אל תכריז על מנצח לפני שסיימת לתת את כל הציונים.

לשכתב פרומפט שעובד מצוין. אם משהו עובד — אל תיגעו. “עדכון” הוא לא ערך בפני עצמו.

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

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

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

סיכום: צ’קליסט ההתחלה

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

הצ’קליסט (בסדר הזה):

1. בנו ערכת בדיקה — 8–12 משימות אמיתיות, עם הפלט הישן שמור לצד כל אחת.
2. הריצו את הערכה על המודל החדש — שלוש הרצות לכל משימה, בלי לשנות שום פרומפט עדיין.
3. סמנו שלוש קטגוריות: השתפר מעצמו / נשאר זהה / נשבר.
4. את ה“נשבר” תקנו ראשון — ברוב המקרים זו הוראת פורמט או אורך, לא בעיה עמוקה.
5. נקו קביים מהפרומפטים שאתם מריצים הכי הרבה, בעזרת פרומפט הניקוי מלמעלה.
6. החליפו דוגמאות ישנות — פחות דוגמאות, באיכות גבוהה יותר.
7. העבירו הקשר קבוע מהפרומפטים אל ההוראות המותאמות / הפרויקט / ה-Gem.
8. החליטו כלל מצב: מתי מהיר, מתי חשיבה עמוקה. כתבו אותו למעלה בצ’קליסט של הצוות.
9. אוטומציות: הרצה מקבילה לפני החלפה, פלט מובנה עם ולידציה, ומדידת עלות אמיתית.
10. תעדו: בכל פרומפט שמור — תאריך עדכון ומודל שנבדק עליו.
11. עדכנו את הצוות על מה שהשתנה, בשורה אחת לכל פרומפט משותף.
12. שמרו את ערכת הבדיקה. בפעם הבאה זה ייקח 30 דקות במקום יומיים.

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