כך תבדקו אם התוסף שלכם משפר את Claude Code
הפקודה claude plugin eval בודקת תוספים ל־Claude Code ומפיקה ציונים ודוחות. כך בונים משימת בדיקה ומשווים ביצועים עם התוסף ובלעדיו.
התוסף שלכם ל־Claude Code מבטיח ביקורת קוד טובה יותר או עבודה לפי כללי הצוות, אבל איך יודעים שהוא באמת עוזר? ב־11 בספטמבר 2026 שוחררה Claude Code v2.1.269 עם הפקודה החדשה `claude plugin eval`, המאפשרת להריץ בדיקות לתוספים ולהפיק ציונים ודוחות JSON ו־HTML. הנה דרך מעשית לבנות ניסוי קטן, להשוות תוצאות ולהחליט אם להשאיר את התוסף בתהליך העבודה.
1. הכינו סביבת בדיקה והגדירו מה התוסף אמור לשפר
לפני שבונים בדיקה, ודאו שאתם עובדים עם גרסה הכוללת את הפקודה החדשה. השוו את הגרסה המותקנת להערות השחרור הרשמיות, ובמידת הצורך עדכנו דרך מנגנון ההתקנה שבו אתם משתמשים. בצוות ארגוני כדאי לתאם את העדכון, כדי שלא תבצעו השוואה בין מחשבים עם גרסאות שונות ותייחסו את ההבדל דווקא לתוסף.
גבולות המדריך: המקור הרשמי מאמת את שם הפקודה, הפקת הציונים ודוחות JSON ו־HTML. התחקיר אינו כולל סכמת קלט, דגלים או מיקום שמירת דוחות. לכן השלבים כאן מפרטים את מתודולוגיית הבדיקה, ואת התחביר המלא יש להשלים מהעזרה או מהתיעוד של הגרסה המותקנת, בלי להמציא קובץ הגדרות.
בחרו תוסף אחד ומשימה אחת שמייצגת צורך אמיתי. למשל, תוסף שנועד להנחות את הסוכן לעבוד לפי כללי הריפוזיטורי: במקום לבקש ממנו באופן כללי לשפר קוד, בקשו תיקון ממוקד של ולידציה בטופס הרשמה. הגדירו מראש אילו התנהגויות צריכות להשתנות ואילו חייבות להישאר כפי שהן.
עבדו בעותק מבודד של הפרויקט או בסביבת ניסוי, ללא סודות וללא גישה מיותרת למערכות פעילות. שמרו את נקודת ההתחלה ב־Git, כולל הבדיקות הקיימות. המטרה היא שכל ניסיון יתחיל מאותו מצב, ולא מקוד שהסוכן כבר תיקן בהרצה קודמת.
2. כתבו תרחיש עם תנאי הצלחה שאפשר לבדוק
בדיקה שימושית צריכה להבדיל בין תשובה שנשמעת מקצועית לבין תוצאה תקינה. כתבו דף תרחיש קצר ובו המשימה, הקלט, ההתנהגות המצופה והאיסורים. זהו מסמך תכנון אנושי, לא פורמט קלט רשמי של Plugin Eval; בהמשך תתרגמו אותו לפורמט שהכלי דורש.
- משימה: לתקן טיפול ברווחים מיותרים בשדה שם בטופס, בלי למחוק תווים תקינים.
- תנאי הצלחה: השם נשמר בהתאם למפרט, ובדיקות הפרויקט ממשיכות לעבור.
- מקרה קצה: שם בעברית עם גרש או מקף, לצד שם באותיות לטיניות.
- מגבלת שינוי: אין שינוי ב־API ואין הוספת תלות ללא צורך.
- ראיית הצלחה: בדיקה שמדגימה את התקלה לפני התיקון ואת ההתנהגות התקינה אחריו.
לצוות ישראלי, עברית אינה תוספת קוסמטית לתרחיש. מערכת שמשלבת שמות בעברית, מזהים באנגלית ותצוגת RTL דורשת בדיקות שמייצגות את השילוב הזה. אם התוסף אמור לסייע בפיתוח ממשק, הוסיפו גם בדיקה חזותית נפרדת: מעבר של בדיקות לוגיקה אינו מוכיח שסדר התצוגה תקין.
תוסף מועיל צריך לשפר תוצאה שאפשר לבדוק, לא רק לייצר הסבר שנשמע טוב יותר.
החליטו מראש מה נחשב כישלון גם אם הציון המסכם גבוה. שינוי בממשק ציבורי בניגוד להנחיה, למשל, יכול לפסול את התוצאה מבחינתכם. כך תמנעו מצב שבו הקריטריונים משתנים בדיעבד רק משום שהתוצר נראה מרשים.
3. הריצו את ההערכה ובנו השוואה ללא התוסף
כעת פתחו את התיעוד או העזרה הזמינים בסביבה שלכם וחפשו את דרישות ההפעלה של הפקודה הבאה. זו הפקודה שאומתה בהערות השחרור, ולא דוגמת הפעלה מלאה עם קובץ בדיקה:
claude plugin evalבדקו כיצד מציינים את התוסף ואת תרחיש הבדיקה, אילו שדות חובה נדרשים ואיך מבקשים את הדוחות. התאימו את דף התרחיש למבנה המתועד, והתחילו בבדיקה מצומצמת כדי לוודא שההגדרות נקלטות. אם מתקבלת שגיאת קלט, פתרו אותה לפני שאתם מפרשים תוצאה כלשהי כמדד לאיכות התוסף.
לצד ההערכה, בצעו את אותה משימה ללא התוסף ושמרו את התוצרים. אין בתחקיר אישור למצב השוואה אוטומטי בתוך הפקודה, ולכן אפשר לנהל את ההשוואה בנפרד. השאירו קבועים ככל האפשר את הגדרות המודל, ההרשאות, נוסח המשימה, קובצי הפרויקט ושאר התוספים הפעילים.
אפסו את סביבת העבודה לנקודת ההתחלה לפני כל ניסיון, ובדקו שהתוסף אכן פעיל או מושבת בהתאם למסלול. חזרו על ההשוואה כדי לזהות תוצאה מקרית, בהתאם לתקציב שלכם. תעדו גם זמן עבודה ותיקונים ידניים; אם נתוני שימוש או עלות זמינים בסביבתכם, שמרו אותם בנפרד ואל תניחו שהם כלולים בדוח.
4. קראו את הדוחות ובדקו גם את הקוד
הפקודה תומכת בדוחות HTML ו־JSON. פתחו את דוח ה־HTML לסקירה ושמרו את ה־JSON אם תרצו לעבד תוצאות בהמשך. לפני השוואת ציונים, בדקו מה כל מדד מייצג לפי התיעוד: אין סיבה להניח שציון מסכם בודק אוטומטית אבטחה, עמידה במפרט או נכונות של כל שינוי.
חזרו לתוצר עצמו: הריצו את בדיקות הפרויקט, עברו על ה־diff ובדקו את המקרים שהגדרתם. תוצאה שעוברת בדיקה אחת באמצעות הסרת ולידציה אחרת אינה הצלחה. גם שינוי רחב שלא התבקש צריך להיכנס לשיקול, משום שהוא מגדיל את עבודת הביקורת ואת הסיכון לתקלות.
רכזו את ההשוואה בטבלה פנימית עם עמודות לתרחיש, שימוש בתוסף, עמידה בדרישות, תקלות ותיקון ידני שנדרש. קשרו כל שורה לדוח ולתוצר המתאימים. אם התוסף מצליח בתיקון פשוט ונכשל במקרה העברי, המסקנה אינה שהוא טוב או רע באופן גורף, אלא שצריך לברר באילו משימות הוא מתאים.
5. קבעו כלל החלטה לפני שמרחיבים את השימוש
בסטארטאפ ישראלי או בצוות פיתוח קטן, גם תוסף שאינו כרוך ברכישה נוספת יכול לעלות בזמן ביקורת. הגדירו כלל אימוץ פשוט: הוא צריך לשפר את העמידה בדרישות בלי להוסיף סיכון או עבודת תיקון שאינם מקובלים על הצוות. אם התמונה מעורבת, הגבילו את השימוש לסוג המשימות שבו ראיתם תועלת.
שמרו את התרחיש, גרסת Claude Code, פרטי התוסף והדוחות יחד עם תיעוד הפרויקט. לאחר שינוי בתוסף או בסביבת העבודה, הריצו שוב את אותה בדיקה. הערך המעשי של Plugin Eval אינו עצם קבלת הציון, אלא יצירת תהליך שבו אפשר להסביר מדוע תוסף נכנס לעבודה, ומתי צריך לבחון אותו מחדש.
שאלות נפוצות
מה עושה הפקודה claude plugin eval?
הפקודה, שנוספה ב־Claude Code v2.1.269, מאפשרת להריץ בדיקות לתוספים ולהפיק ציונים ודוחות JSON ו־HTML. כדי להעריך אם תוסף משפר את העבודה, כדאי להשוות גם לתוצאה של אותה משימה ללא התוסף.
איך בודקים אם תוסף ל־Claude Code באמת מועיל?
מגדירים משימה עם תנאי הצלחה ברורים, ומבצעים השוואה עם התוסף ובלעדיו מאותה נקודת התחלה. בודקים את התוצר בפועל ואת העמידה בדרישות, ולא מסתפקים בציון מסכם או בהסבר משכנע של הסוכן.
האם אפשר להעתיק קובץ בדיקה מוכן ל־claude plugin eval?
צריך לוודא שקובץ הבדיקה תואם לפורמט שהגרסה המותקנת דורשת. התחקיר שעליו מבוסס המדריך מאמת את הפקודה ואת פורמטי הדוחות, אך אינו כולל את סכמת הקלט או את הדגלים שלה.
דרגו את הכתבה
הדירוג עוזר לנו לדעת מה שווה לכם.
תגובות