למה מחיקת סקילים והוראות משפרת את העבודה עם Claude Code?

למה פחות הוראות יכולות לשפר את התוצאות?

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

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

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

מה בעצם השתנה במודלים החדשים?

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

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

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

מה קרה בניסוי בלי סקילים בכלל?

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

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

---
name: resource-guide
description: Turn a video or interview into a resource guide for the audience.
---

Structure the guide however you judge best for this specific video.
Organize it around the ideas that actually matter, not a fixed template.

Always keep:
- Header image: assets/guide-header.png at the top
- Channel link directly under the header
- Community link at the bottom
- Brand colors from brand/colors.md

Before finishing: check every timestamp against the transcript.

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

איך מבחינים בין הוראה שמכוונת להוראה שמגבילה?

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

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

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

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

למה כדאי לתת למודל משימה קשה מדי?

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

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

/goal Build a client onboarding checklist tool from notes/onboarding.md.

What good looks like:
- A new client can finish onboarding without asking a single question
- Every step links to the exact document it needs

Prove it:
- Walk through the full flow as a new client, step by step
- Check that every link opens the right file
- List anything a client could misunderstand, then fix it

This is not a prototype. It should be tested and iterated on 10 times,
fully checked, and ready to hand to a real client tomorrow.

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

למה אימות הוא המיומנות החשובה ביותר עכשיו?

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

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

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

ממי כדאי לקחת עצות על עבודה עם AI?

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

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

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

חמש תובנות על ניקוי סקילים והוראות

סיכום: איך מתחילים לנקות את מערכת העבודה?

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

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

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