פרומפטים ל-Claude Opus 5: המדריך הרשמי של Anthropic בעברית

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

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

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

הערה: לשינויי ה-API במעבר מ-Claude Opus 4.8 (חשיבה דלוקה כברירת מחדל, וכיבוי חשיבה שאפשרי רק ב-effort של high ומטה) יש מדריך מיגרציה נפרד בתיעוד של Anthropic.

שיפורי יכולת שרלוונטיים לפרומפטינג

בהשוואה ל-Claude Opus 4.8, אלה השיפורים שהכי משפיעים על אופן כתיבת הפרומפט:

• קידוד סוכני. Claude Opus 5 חזק במיוחד במשימות קידוד קשות: פיצ׳רים שנוגעים בהרבה קבצים, ריפקטורים גדולים ועבודת פיצ׳ר מקצה לקצה. הוא משלים משימות מלאות במקום להשאיר stubs או placeholders, והוא מתפקד הכי טוב כשנותנים לו את מפרט המשימה המלא מראש ומניחים לו לרוץ. גם במשימות קלות (עריכה בפנייה אחת) הוא טוב, אבל שם הפער מהדורות הקודמים קטן יותר.
• ביקורת קוד ואיתור באגים. דיוק (precision) וכיסוי (recall) גבוהים: הוא מוצא באגים אמיתיים בשיעור גבוה בכל מעבר, ורוב הממצאים הנוספים שלו הם בעיות אמיתיות ולא false positives. הדיוק נשמר גם ברמות effort נמוכות - מה שמאפשר מעבר מהיר בזמן הביקורת ומעבר יסודי יותר אחר כך. חשוב: אם בפרומפט הביקורת שלכם כתוב ״דווח רק על בעיות חמורות״ או ״היה שמרן״, המודל עלול לציית לזה מילולית ולדווח פחות. עדיף לבקש ממנו לדווח על הכול, ולסנן במעבר נפרד.
• יעילות ב-effort נמוך. הרמות low ו-medium נותנות איכות גבוהה בשבריר מהטוקנים ומזמן התגובה של הרמות הגבוהות. התחילו בברירת המחדל (high) והתאימו לפי ה-evals שלכם: השתמשו ב-low וב-medium בנדיבות, ככלי הבקרה העיקרי על עלות הטוקנים ועל זמן התגובה, בכל מקום שבו האיכות נשמרת - ועלו ל-xhigh לעבודת קידוד ולעבודה סוכנית תובענית. אם גררתם ברירות מחדל של effort ממודל קודם, הריצו בדיקת effort מחדש על ה-evals שלכם.
• ראייה (Vision). חזק בהבנת גרפים, מסמכים ודיאגרמות, וכן בשחזור ויזואלי של UI ושל ממשקי frontend. כדאי לבדוק מחדש כל עקיפה (workaround) שכתבתם בפרומפט בשביל מודלים קודמים - ייתכן שהיא כבר מיותרת. ביצועי הראייה הכי חזקים כשיש למודל כלים לנתח, לחתוך ולאמת ויזואלית את העבודה שלו שוב ושוב, ושימוש בכלים הוא מנוף משתלם יותר מהגדלת החשיבה לבדה.
• עבודה בקונטקסט ארוך. חלון קונטקסט של מיליון טוקנים - גם כברירת מחדל וגם כמקסימום - כשהציות להוראות, קריאות הכלים והחשיבה נשארים עקביים לאורך כל החלון.
• מסמכים ועבודה משרדית. יוצר גיליונות אלקטרוניים מורכבים עם כמה לשוניות ונוסחאות לא טריוויאליות, ומפיק מצגות מובנות היטב. תנו לו במפורש את הסגנון או התבנית שהוא צריך לעקוב אחריהם.
• תיאום רב-סוכני. מתאם צוותי סוכני משנה היטב, עם דפוסי writer-verifier אפקטיביים ומעט מקרים של סוכנים שדורסים זה את העבודה של זה. בעומסי עבודה רגישים לעלות - הגבילו את ההאצלה (ראו שליטה בפתיחת סוכני משנה).

אורך תשובה ומילוליות

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

הוראת תמצות קצרה עובדת. לדוגמה, למוצר שיחה רב-תורי מול משתמש:

Keep responses focused, brief, and concise. Keep disclaimers and caveats short, and spend most of the response on the main answer. When asked to explain something, give a high-level summary unless an in-depth explanation is specifically requested.

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

<tone_preference>
Keep outputs reasonably concise.
</tone_preference>

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

עדכוני התקדמות מול המשתמש

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

Before your first tool call, say in one sentence what you're about to do. While working, give a brief update only when you find something important or change direction. When you finish, lead with the outcome: your first sentence should answer "what happened" or "what did you find," with supporting detail after it for readers who want it.

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

אורך תוצרים כתובים

בנפרד ממילוליות שיחתית - קבצים ש-Claude Opus 5 כותב לדיסק (דוחות, מסמכי Markdown, סיכומים) יוצאים לרוב ארוכים יותר מאשר במודלים קודמים. אם המוצר שלכם כולל מסמכים שהמודל מחבר, הוסיפו כיול אורך מפורש:

Match the length of written documents to what the task needs: cover the substance, but do not pad with filler sections, redundant summaries, or boilerplate.

גבולות משימה ואימות יתר

Claude Opus 5 מאמת את עבודתו בעצמו בלי שמבקשים ממנו. אם בפרומפט שלכם יש הוראות אימות מפורשות (״כלול שלב אימות סופי בכל משימה לא טריוויאלית״, ״השתמש בסוכן משנה כדי לאמת״) - הסירו אותן: הוראות כאלה גורמות לאימות יתר ב-Claude Opus 5, והסרתן חוסכת טוקנים מבוזבזים בלי לפגוע באיכות. אותו דבר נכון למנגנוני harness ישנים שמוסיפים שלבי אימות נפרדים.

Claude Opus 5 עלול גם להרחיב את גבולות המשימה - להוסיף שלבים שלא התבקשו, או להפעיל שיקול דעת משלו לגבי מה המשימה אמורה להיות. במשימות צרות, תחמו במפורש:

Deliver what was asked, at the scope intended. Make routine judgment calls yourself, and check in only when different readings of the request would lead to materially different work. If the request seems mistaken or a better approach exists, say so in a sentence and continue with the task as asked rather than quietly narrowing, widening, or transforming it. Finish the whole task, and stop short of actions that are clearly beyond what was asked.

שליטה בפתיחת סוכני משנה

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

Delegate to a subagent only for large tasks that are genuinely independent and parallelizable, such as a wide multi-file investigation. Do not delegate work you can finish yourself in a handful of tool calls, and do not use subagents to verify or double-check your own work. If one subagent can complete the task, use one rather than several, and keep spawn counts low.

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

תיקון עצמי

Claude Opus 5 תופס ומתקן את הטעויות של עצמו היטב בלי שמבקשים. הימנעו מהוראות לבדיקה חוזרת שהוא כבר מבצע (״בדוק שוב את התשובה שלך״, ״אמת מחדש לפני שאתה עונה״) - כמו הוראות אימות, הן מצטברות מעל ההתנהגות הטבעית של המודל ומוסיפות עלות בלי לשפר תוצאות.

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

Only correct an earlier statement when the error would change the user's code, conclusions, or decisions. State corrections plainly and briefly, then continue the task. For slips that change nothing for the user, make the fix and move on without noting it.

הרצה עם חשיבה כבויה

Claude Opus 5 רץ עם חשיבה דלוקה כברירת מחדל, ואפשר לכבות אותה רק ב-effort של high ומטה. כשהחשיבה כבויה, שני ארטיפקטים עלולים להופיע מדי פעם בפלט הגלוי של המודל. הדרך העיקרית למנוע את שניהם היא פשוט להשאיר את החשיבה דלוקה ולשלוט בעלות הטוקנים דרך רמות effort נמוכות יותר: ברוב המשימות, חשיבה דלוקה ב-effort low מתפקדת טוב יותר מחשיבה כבויה בעלות דומה.

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

תגי XML פנימיים בפלט. כשהחשיבה כבויה, המודל עלול לפלוט תגיות <thinking> או תגיות XML פנימיות אחרות לתוך התשובה הגלויה. אם בפרומפט המערכת שלכם יש כלל שאומר למודל לא לחשוב או לא להסיק - הסירו אותו; הוראה כזאת דווקא מגדילה את דליפת התגיות.

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

When you use a tool, you may say a brief sentence first. If no tool can express what the user asked for, say so instead of guessing. Do not include internal or system XML tags in your response.

הוראות שמזכירות את תגיות החשיבה בשמן יעילות פחות מהצורה הכללית - לכן אל תנקבו בהן במפורש.

מה לשנות היום בפרומפטים קיימים - צ׳ק-ליסט

תמצית מעשית של המסמך, לפי סדר התועלת:

1. מחקו הוראות אימות ובדיקה חוזרת. ״double-check״, ״verify before responding״, ״add a final verification step״ - כולן עולות טוקנים ולא משפרות איכות ב-Opus 5.
2. הוסיפו הוראת תמצות מפורשת אם התשובות ארוכות מדי, ותזכורת קצרה בסוף פרומפט מערכת ארוך.
3. הגדירו קצב עדכונים לעבודה סוכנית - משפט לפני הכלי הראשון, עדכון רק בממצא חשוב או בשינוי כיוון, ותוצאה בשורה הראשונה בסיום.
4. תחמו את גבולות המשימה במשימות צרות, כדי שהמודל לא ירחיב אותן מיוזמתו.
5. הגבילו האצלה לסוכני משנה - בהנחיה, או בתקרה קשיחה ב-harness.
6. הריצו בדיקת effort מחדש על ה-evals שלכם; low ו-medium הם כלי בקרת העלות העיקרי.
7. בדקו מחדש עקיפות vision ישנות - רבות מהן כבר מיותרות.
8. השאירו את החשיבה דלוקה. אם אתם חייבים לכבות - הוסיפו את ההוראה המשולבת נגד הארטיפקטים.
9. בפרומפטי code review בקשו הכול וסננו בנפרד, במקום לכתוב ״רק חמור״.
10. תנו את המפרט המלא מראש והניחו למודל לרוץ, במקום להזין את המשימה בפירורים.

שאלות נפוצות

האם המדריך הזה הוא תוכן רשמי של Anthropic?

התוכן - כן; התרגום - שלי. המסמך המקורי, ״Prompting Claude Opus 5״, פורסם רשמית על ידי Anthropic בתיעוד המפתחים שלה בכתובת platform.claude.com. תרגמתי אותו לעברית במלואו, השארתי את דוגמאות הפרומפט באנגלית כפי שהן, והוספתי כמה הערות יישום שמסומנות במפורש כשלי. אני לא מייצג את Anthropic ואין ביני לבינה קשר רשמי - במקרה של סתירה, המקור באנגלית קובע.

האם צריך לשכתב פרומפטים קיימים מ-Claude Opus 4.8?

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

מה ההבדל בין effort לבין אורך התשובה?

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

כדאי לכבות חשיבה כדי לחסוך בעלויות?

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

למה לא לכתוב בפרומפט code review ״דווח רק על בעיות חמורות״?

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

כמה סוכני משנה כדאי לתת למודל לפתוח?

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

---

מקור: Prompting Claude Opus 5 - Anthropic Developer Docs. מסמך רשמי של Anthropic. כל הזכויות על התוכן המקורי שמורות ל-Anthropic; העמוד הזה הוא תרגום לעברית לצורכי לימוד, עם הפניה למקור.

מדריכים קשורים: Claude Opus 4 - המדריך המלא · subagents ב-Claude Code · כתיבת CLAUDE.md · שליטה בעלות טוקנים · prompt caching