Anthropic הסירה 80% מה-system prompt שמנחה את Claude Code ודיווחה על היעדר ירידה ביכולת שלו לכתוב קוד. הניסוי מראה שככל שמודלי שפה גדולים (LLMs) הופכים ליכולתיים יותר, מפתחים יכולים לצמצם את הפיגומים המסורבלים שהם משתמשים בהם כדי להשאיר את המודלים במסלול, מבלי לפגוע בביצועים.
למה הפרומפט היה חשוב מלכתחילה
כש-Claude Code הושק, ה-system prompt שלו כלל עשרות כללים. מהנדסים הוסיפו שורות חדשות בכל פעם שהופיע באג, אך לעיתים רחוקות הסירה דבר שנראה שעובד. עם הזמן, הפרומפט הפך למסמך מסורבל וסטטי.
פער המודל מצטמצם
הכללים הנוספים הללו הסתירו "פער מודל" (model gap) – ההבדל בין מה שהמודל יכול היה לעשות לבין מה שהאפליקציה דרשה. בשנת 2024, מפתחים נאלצו לפרט אילוצים מחמירים כדי למנוע מהמודל, למשל, להוסיף יותר מדי הערות (over-commenting) לקוד. כיום, אותו מודל יכול להסיק את הסגנון הרצוי מתוך הוראה בודדת כמו "התאם לסגנון הקוד הקיים". הכללים הפכו מעזרה לרעש.
מה משתנה בהנדסת הקשר (context engineering)
הצמצום של Anthropic משקף שינוי רחב יותר באופן שבו מפתחים מבנים פרומפטים:
- הוראות קריטיות חד-פעמיות – ציין כלל פעם אחת ואפשר למודל לשמור עליו.
- פרמטרים מונחי-כלי (tool-driven) במקום דוגמאות few-shot – תאר את מבנה הקלט והפלט בתוך ה-tool schema ואפשר למודל למלא אותם.
- חשיפה הדרגתית (Progressive disclosure) – ספק רק את ההקשר הדרוש לשלב הנוכחי, והוסף עוד מאוחר יותר במידת הצורך.
- העברת הנחיות סטטיות לתיאורי כלים – דברים כמו "השתמש ב-camelCase עבור משתנים" שייכים למפרט (spec) של הכלי, ולא ל-system prompt.
- החלפת כללים קשיחים בהיוריסטיקות – אפשר למודל להחליט מתי חל כלל מסוים במקום לאכוף אותו ללא תנאי.
הטקטיקות הללו עובדות מכיוון שהמודל כבר מכיר מוסכמות רבות שבעבר דרשו חיזוק מפורש.
הסיכון בצמצום יתר
אותו גיזום (pruning) שמועיל למודלי קצה (frontier models) עלול לפגוע במודלים קטנים יותר. Anthropic מציינת שמודלים כמו Haiku עדיין מסתמכים על פרומפטים עשירים יותר כדי להישאר במסלול. הסרת הנחיות רבות מדי ממודל פחות יכולת עלולה להחזיר את השגיאות שהפרומפט המקורי ניסה למנוע: שמות לא עקביים, הערות מוגזמות או מקרי קצה שפספסו.
איך לבצע ביקורת (audit) לפרומפטים שלכם
אם אתם מנהלים תהליך (pipeline) של יצירת קוד, ביקורת פרומפטים יכולה לחשוף "משקל מת". רשימת בדיקה מעשית נראית כך:
- התאמת צפיפות ההוראות – התאימו את כמות ההנחיות למודל שבו אתם משתמשים בפועל.
- מחיקת הוראות כפולות – אם כלל מופיע גם ב-system prompt וגם בתיאור הכלי, שמרו עליו רק פעם אחת.
- הפיכת דוגמאות עובדות לסכמות (schemas) עשירות יותר – החליפו דוגמאות קונקרטיות בסוגי פרמטרים מפורטים או enums.
- הוצאת פרטים סיטואציוניים החוצה – העבירו בלוקים גדולים של מידע ייחוס לקבצים נפרדים שהמודל יכול לשלוף לפי דרישה.
- הסרת כללים המכסים התנהגויות שנעלמו – אם המודל כבר לא מוסיף הערות לא רצויות, הסירו את כלל ה-"no-comment".
אל תסתמכו על תחושת בטן. השתמשו ב"כלל 3-הבדיקות" הפשוט: הריצו חמש משימות תכנות ריאליסטיות, השוו תוצאות לפני ואחרי כל מחיקה, ושימו לב לכל נסיגה (regression) בביצועים.
- Baseline – מדדו ביצועים עם הפרומפט המלא.
- Delete – הסירו שורה או בלוק מועמדים למחיקה.
- Re-run – הריצו שוב את אותן חמש משימות.
אם הפלט משתנה, זיהיתם שורה שעדיין בעלת משמעות. אם לא, ניתן להשמיט את השורה בבטחה.
מה מפתחים צריכים לעקוב אחריו בהמשך
לעת עתה, השורה התחתונה ברורה: system prompt הוא מסמך חי. התייחסו לכל שורה ככזו שיש לה "תאריך תפוגה", בצעו ביקורות באופן קבוע, ותנו ליכולת הגדלה של המודל לעשות את העבודה הקשה.
מקור: dev.to/ialijr/your-system-prompt-has-a-shelf-life-maintaining-prompts-as-models-improve-cd9