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

המכסה נגמרת לך באמצע היום? רוב הסיכויים שאתה שורף טוקנים בחינם.

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

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

Skills — היכולת הכי שוות שרוב המפתחים לא מכירים

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

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

איך יוצרים סקיל

יוצרים תיקייה בתוך .claude/skills/ בפרויקט, ובתוכה קובץ SKILL.md. בקובץ: שורת description שמתארת מתי הסקיל רלוונטי, ואחריה ההוראות עצמן.

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

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

שלושה סקילים ששווה לבנות היום

1. סקיל לדפוסי הקוד של הפרויקט — איך אתם בונים קומפוננטות, איך נראה handler טיפוסי, אילו מוסכמות שמות נהוגות. במקום שהמודל ינחש (וינחש לא נכון, ותתקן, וזה עוד סבב טוקנים) — הוא מקבל את הדפוס כשהוא כותב קוד.
2. סקיל לתהליך הדיפלוי — השלבים, הסדר, מה בודקים לפני ואחרי. נטען רק כשבאמת עושים דיפלוי, לא בכל שיחה על באג ב-CSS.
3. סקיל לכללי code review — מה אתם בודקים בכל סקירה, אילו דפוסים אסורים, מה חוסם מיזוג. כשמבקשים מהמודל לעבור על קוד, הוא עובד לפי הכללים שלכם ולא לפי כללים גנריים.

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

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

10 טיפים לחיסכון בטוקנים

1. CLAUDE.md רזה

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

2. ‎/compact ו-/clear הם חברים, לא עונש

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

3. קבצים ספציפיים, לא “תסתכל על הפרויקט”

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

4. משימה מלאה מראש במקום עשרים הודעות קצרות

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

5. מודל לפי משימה

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

6. סוכני משנה לחיפושים רחבים

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

7. פרומפט קאשינג אוהב קידומת יציבה

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

8. לחתוך לוגים, לא להדביק אותם

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

9. הוראה שחזרת עליה פעמיים — כבר לא מדביקים

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

10. לעקוב לפני שמאשימים

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

גם ב-Codex זה עובד ככה

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

שורה תחתונה

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

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