החוקים החדשים להנדסת קונטקסט: איך לקצר הנחיות ולנקות CLAUDE.md בלי לפגוע בתוצאות

קובץ ההנחיות שלכם כנראה לא התנפח ביום אחד. בהתחלה היו בו כמה שורות על הפרויקט, מי אתם וסגנון עבודה מועדף. אחר כך קלוד (Claude) הוסיף הערה שלא רציתם, אז כתבתם כלל נגד הערות. הוא יצר קובץ תכנון מיותר, אז הוספתם עוד איסור. הוא השתמש בכלי בצורה לא מדויקת, אז הכנסתם דוגמה. אחרי כמה חודשים, הקובץ שאמור לעזור למודל כבר נראה כמו אוסף תגובות לכל מה שהשתבש בעבר. אנטרופיק (Anthropic) מספרת שבקלוד קוד (Claude Code) היא נתקלה בבעיה דומה. בפוסט שפרסם Thariq Shihipar ב-24 ביולי 2026, החברה כתבה שהסירה יותר מ-80% (!) מה-system prompt של Claude Code עבור מודלים מתקדמים כמו Claude Opus 5 ו-Claude Fable 5, בלי ירידה מדידה בבחינות הקוד שלה. system prompt הוא שכבת ההנחיות הקבועה שהמודל מקבל לפני הבקשה של המשתמש. זו שכבה חשובה, אבל כשהיא מתנפחת, היא ממש עלולה להפריע במקום לסייע למשתמש.

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

קודם להבין מה אתם מנקים

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

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

הפרומפט נכתב לבקשה אחת. ההקשר נטען מחדש בכל בקשה

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

הוראות שסותרות זו את זו בתוך אותה בקשה

התחילו במחיקה, לא בעריכה

בוריס צ׳רני (Boris Cherny), מי שמוביל את קלוד קוד, תיאר בסרטון של Y Combinator שיטת עבודה חדה יותר מ”לקצר קצת את הקובץ”. בכל פעם שמודל חדש יוצא, הצוות מוחק חלקים מה-system prompt, משכתב חלקים אחרים, משנה את סט הכלים וגם את ההנחיות של הכלים. הסיבה פשוטה: מה שתיקן בעיה במודל מלפני שלושה חודשים לא בהכרח מתאים למודל החדש.

אבל השיטה החשובה יותר היא ablation (מחיקה מבוקרת). צ׳רני מסביר שבמחקר הכוונה היא למחוק רכיב ולבדוק מה ההשפעה שלו. במקרה של קלוד קוד, זה אומר למחוק את כל ה-system prompt ואז להחזיר אותו שורה אחר שורה כדי להבין מה כל שורה באמת עושה. הם עושים דבר דומה גם לכלים: מסירים כלים, מוחקים קוד מה-harness, כלומר המעטפת שמחברת בין המודל, המוצר וההרשאות, ובודקים מה עדיין נחוץ.

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

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

צ׳רני מציע את זה גם למשתמשים שלא בונים מוצרי AI מורכבים. מי שמשתמש בקלוד קוד יכול, לדבריו, למחוק כל חצי שנה את CLAUDE.md, את הסקילים ואת ה-hooks, ולראות איך המודל מגיב. hooks הם פעולות אוטומטיות שמופעלות בנקודות מסוימות בתהליך העבודה. זו ההמלצה שלו. ההמלצה המעשית שלי לקורא היא לעשות את זה עם גיבוי (או בענף נפרד), כדי שאפשר יהיה לחזור אחורה אם התברר שהקובץ הישן עדיין הכיל ידע חשוב.

השתמשו קודם, הוסיפו אחר כך

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

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

מוחקים, מריצים, ומחזירים רק הוראות שמתקנות כשל שחזר על עצמו

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

תחליפו כללים קשיחים בעקרונות פשוטים

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

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

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

אותה כוונה, ניסוח אחר

תנו לכלים להסביר את עצמם

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

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

אותו עיקרון נכון גם לכלים מסוכנים יותר. אם כלי משנה סביבת production, השם והתיאור שלו צריכים לומר זאת במפורש. ההוראות על אופן השימוש בכלי צריכות להופיע בתיאור הכלי, לא גם ב-CLAUDE.md, גם ב-system prompt וגם במסמך נפרד.

תעבירו תהליכים ארוכים ל-skills

CLAUDE.md צריך להכיל דברים שחשוב לדעת תמיד. הוא לא צריך להכיל כל תהליך עבודה אפשרי.

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

ב-CLAUDE.md אפשר להשאיר משפט קצר: “למשימות release השתמש ב-release skill”. את השלבים עצמם תשמרו בתוך הסקיל. ככה הקובץ הראשי נשאר קצר, והמידע המפורט עדיין זמין כשצריך אותו.

תשתמשו בדוגמאות חיות במקום עוד הסברים

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

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

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

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

המדריכים תמיד חינמיים, אבל אם בא לכם להתמקצע - יש גם קורס קלוד קוד (Claude code) וסביבת אנטרופיק

לפרטים נוספים לחצו כאן >>

תבדקו את הזיכרון

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

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

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

צ’קליסט ניקוי לשימושכם

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

קודם בונים מחדש, אחר כך מסדרים

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

איפה לא לקצר מהר מדי

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

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

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

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