עבור לתוכן הראשיעבור לתפריט הניווט
לכל הפוסטים

רשימות על עבודה עם AI

קובץ ההוראות שמתקצר, לא מתארך

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

3 דק׳ קריאה
  • claude-code
  • prompt-engineering
  • ai-skills
  • developer-workflow

קובץ ההוראות שגדל במשך חצי שנה

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

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

ההיפוך שמדווחים עליו

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

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

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

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

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

גרסת הקליטה של אותו רעיון

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

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

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

מה לנסות השבוע

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

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

הדרכות Claude לצוותים

רוצים להעביר את זה לצוות שלכם?

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