Claude Code Plugin Eval: תקופת ניסיון לסקיל לפני שהוא מנהל לך את העסק

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

החלום: למסור משימה ולישון בשקט

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

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

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

הפחד שעוצר את רוב בעלי העסקים

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

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

מחקר שפורסם ב-arXiv בפברואר 2026, Towards a Science of AI Agent Reliability, בדק 15 מודלים ומצא שהשיפור ביכולות של המודלים הביא רק שיפור קטן באמינות שלהם. כלומר: המודל נהיה חכם יותר, אבל לא בהכרח עקבי יותר. החוקרים הציעו למדוד ארבעה דברים במקום ציון אחד: עקביות בין ריצות, עמידות בשינויים קטנים בניסוח, שאפשר לחזות מתי הוא ייכשל, ושהטעות הכי גרועה שלו לא שורפת לקוח.

בדיוק מה שמנהל טוב בודק אצל עובד בתקופת ניסיון.

מה שעשיתי כשגייסתי את העובדת הראשונה

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

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

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

מה זה בעצם claude plugin eval

ב-11 בספטמבר 2026 Anthropic הוסיפה ל-Claude Code פקודה חדשה: claude plugin eval. עד כאן מונחים. עכשיו התרגום.

סקיל (skill) הוא קובץ הוראות. הנוהל של העובד. "כשמגיעה שאלה על מחיר, תענה ככה, תשאל את זה, אל תבטיח את זה". על סקילים כתבתי במדריך הסקילים, ואם אתה חדש לגמרי, תתחיל במדריך Claude Code לבעלי עסקים.

Plugin הוא החבילה שהסקיל יושב בה. תיק העובד.

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

שלושה דברים בתיעוד הרשמי של Anthropic הפכו את זה בעיניי מכלי למפתחים לכלי לבעלי עסקים:

• כל תרחיש רץ 3 פעמים כברירת מחדל. לא פעם אחת. כי ריצה אחת של AI, במילים של התיעוד עצמו, "אומרת לך מעט". הציון הוא הממוצע. זה ההבדל בין "הצליח לי פעם" ל"אפשר לסמוך".
• כל תרחיש רץ גם בלי הסקיל. זה החלק הגאוני. אתה מקבל שני ציונים: עם ההוראות שלך ובלעדיהן. ההפרש ביניהם (הם קוראים לו Δ) אומר כמה הנוהל שכתבת באמת תורם. אם הציון זהה בשני המצבים, הנוהל שלך לא עושה כלום.
• יש רף מעבר. ברירת המחדל היא 100%. אתה יכול להוריד ל-80%, למשל, אבל תרחיש שנופל מתחת מפיל את כל הבדיקה. כמו עובד שלא עבר תקופת ניסיון.

הטבלה שהופכת תחושת בטן למספר

בסוף הריצה מקבלים טבלה. בדוגמה מהתיעוד: תרחיש אחד, ציון 1.00 עם הסקיל, 0.33 בלעדיו, הפרש של 0.67, שש ריצות, בעלות של 41 סנט לפי מחיר מחירון של המודל (הריצות עצמן נספרות במכסת המנוי שלך). ומעליה קובץ HTML אחד עם כל ריצה, כל בודק, ומה בדיוק נכשל.

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

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

דוגמה: תקופת ניסיון לסקיל שעונה על פניות מחיר

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

התרחיש (הקובץ נקרא prompt.md, בשפה שלקוח באמת מקליד):

---
max_turns: 10
allowed_tools: [Read, Skill]
---

היי, ראיתי את הפוסט שלך. כמה עולה הליווי?

הבודק הראשון (קובץ criteria.md): מה נחשב תשובה נכונה, בשפה של מנהל שבודק עובד:

---
type: llm
---

PASS אם התשובה בעברית, לא מציינת שום מחיר או טווח מחירים,
שואלת שאלה אחת על העסק של הפונה,
ומציעה שיחת התאמה קצרה.
FAIL אם מופיע מספר עם סימן ₪, או אם אין שאלה,
או אם התשובה ארוכה מ-6 שורות.

הבודק השני: האם ה-AI בכלל פתח את הנוהל, או ענה מהראש:

---
type: tool_used
tool: Skill
input_match: '"skill"\s*:\s*"(?:[\w-]+:)?price-reply"'
---

את השורה עם input_match לא נוגעים. רק מחליפים price-reply בשם הסקיל שלך.

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

תזכיר לי מתי הפגישה שלי מחר?

עם בודק שדורש שהסקיל לא הופעל בכלל. זה אותו קובץ tool_used, רק עם min: 0 ו-max: 0. מוסיפים לו שורה אחת, arm: both, כדי שהבדיקה הזאת תיספר בציון גם בהרצה המשווה. כי עובד שעונה "בוא נקבע שיחת התאמה" על שאלה על לוח הזמנים, זה עובד שלא הבין את התפקיד.

מריצים claude plugin eval . ומחכים קצת יותר מדקה (74 שניות בדוגמה של התיעוד). אפשר גם לתת ל-Claude לכתוב את התרחישים במקומך עם claude plugin eval init. הוא קורא את הסקיל, שואל אותך מה נחשב תוצאה טובה, ומציע תרחישים שאמורים להפעיל אותו ותרחישים שלא.

6 סוגי בודקים, מתורגמים לשפת מנהל

1. regex: חיפוש מילים או תבנית בתשובה. "האם מופיע ₪?" "האם מופיעה המילה 'התאמה'?". חינם, מהיר, יציב. הבודק של "עברת על הצ'קליסט?".
2. tool_used: האם הסקיל (או כל כלי אחר) הופעל, וכמה פעמים. הבודק של "פתחת את הנוהל או ענית מהזיכרון?".
3. tool_order: האם א' קרה לפני ב'. קודם קראת את הקובץ ואז ענית, ולא הפוך. הבודק של סדר פעולות.
4. file_exists: האם נוצר הקובץ שביקשת. הצעת מחיר, דוח, טבלה. הבודק של "הגשת את המסמך?".
5. llm: מודל שני קורא את התשובה ושופט לפי הקריטריונים שלך. שלושה קולות, רוב קובע. הבודק של "המנהל קרא ואמר אם זה טוב".
6. baseline: השוואה לתשובה לדוגמה ששמרת. "לפחות טובה כמו התשובה הכי טובה של הצוות מהשבוע שעבר".

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

הטעות שמחקר מ-2026 תפס

הפיתוי הוא לתת ל-AI לכתוב גם את המבחן. "תכתוב לי 20 בדיקות לסקיל". מחקר שפורסם ב-arXiv במאי 2026, An Empirical Study of Automating Agent Evaluation, בדק בדיוק את זה. כשעוזרי קוד מתקדמים התבקשו לבנות הערכה לסוכן בלי ידע על התחום, רק 30% מההערכות רצו בהצלחה, והן היו מנופחות: יותר מ-12 מדדים בממוצע לכל סוכן.

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

מתי הסקיל מוכן לנהל חלק מהעסק

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

• יש לפחות תרחיש אחד שהסקיל לא אמור לתפוס. ועבר.
• ההפרש (Δ) חיובי. הנוהל שלך באמת משפר את התוצאה לעומת AI בלי הנוהל.
• הציון עבר את הרף ב-3 ריצות, לא ב-1. עקביות, לא מזל.
• הבודקים נכתבו על ידך, בשפה של PASS ו-FAIL שהיית אומר לעובד.
• יש עותק של הבדיקה שמור. כי כל פעם שיוצא מודל חדש, או שאתה משנה משפט בסקיל, מריצים שוב. תקופת ניסיון היא לא אירוע חד פעמי.

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

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

באהבה ענקית,
יהב.