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

התייחסו ל-Claude כאל עובד חדש

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

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

חמשת החלקים של פרומפט מוצק

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

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

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

משימה (Task)
השתמשו בפעלים מדויקים. הימנעו ממילים מעורפלות כמו "לשפר", "להעצים" או "להפוך לטוב יותר". אין להן משמעות. במקום זאת, כתבו: "סכם את התמלול לשלוש נקודות (bullet points) של פחות מ-20 מילים כל אחת". או: "בצע refactor לפונקציה הזו כדי להשתמש ב-async/await והוסף טיפול בשגיאות עבור timeouts". המשימה היא ההוראה שלכם, אז הפכו אותה להוראה, לא למשאלה.

פורמט (Format)
הגדירו את צורת התשובה לפני ש-Claude מתחיל לכתוב. האם אתם רוצים רשימה ממוספרת, טבלת markdown, JSON תקין, אימייל עם שורת נושא, או מסמך משפטי? אם אתם זקוקים לטבלת השוואה עם עמודות ספציפיות, ציינו אותן. אם אתם רוצים את הפלט בתוך בלוק קוד עם הערות, אמרו זאת. הוראות פורמט מונעות מכם לקבל קיר של טקסט רציף כשאתם זקוקים לנתונים מובנים.

אילוצים (Constraints)
פרטו מה כדאי להימנע ממנו. זה כולל טון, אורך, מילים אסורות ונושאים שאינם רלוונטיים. לדוגמה: "שמור על התגובה מתחת ל-150 מילים. השתמש בטון שיחתי. אל תשתמש במילה 'סינרגיה'. הימנע מהצעת פתרונות הדורשים תקציב של מעל 500$". אילוצים הם מעקות בטיחות. המודל מטפל בהם היטב, אך רק אם תגדירו אותם בבירור.

ארבע טכניקות לתוצאות טובות יותר

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

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

בקשו את ההיגיון (Reasoning)
הנחיית שרשרת מחשבה (Chain-of-thought prompting) פירושה פשוט לבקש מ-Claude להציג את עבודתו לפני מתן התשובה הסופית. ביטויים כמו "עבור על תהליך החשיבה שלך צעד אחר צעד, ולאחר מכן תן את המסקנה שלך" עושים פלאים עבור בעיות לוגיות, מתמטיקה וניפוי שגיאות (debugging) בקוד. כשניתן לראות כיצד המודל הגיע לתשובה, ניתן לזהות את הרגע המדויק שבו הוא לא הבין דרישה או לקח ערך שגוי מתוך מערך נתונים. זה הופך "קופסה שחורה" למשהו שניתן לבקר.

השתמשו בתגיות XML כדי להפריד בין מידע
כאשר הנחיה מכילה בלוקים גדולים של טקסט, המודל עלול לבלבל בין חומר המקור לבין ההוראות. עטפו סעיפים נפרדים בתגיות כמו <context>, <task> או <example>. לדוגמה:

We are a remote-first SaaS company with 40 employees. Draft a company-wide memo announcing the switch from Slack to Microsoft Teams. Tone should be upbeat but not cringe. Keep it under 200 words.

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

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

תבנית מוכנה לשימוש

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

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

הנה איך זה נראה כשהוא מלא:

תפקיד: אתה מנהל שיווק מוצר בסטארט-אפ B2B לשכר (payroll). הקשר: אנחנו משיקים פיצ'ר שמבצע אוטומציה של דיווחי מס מדינתיים עבור חברות בשוק הביניים. קהל היעד הוא מנהלי משאבי אנוש שקבורים בתוך ניירת רגולטורית. המטרה היא לגרום להם לקבוע דמו. משימה: כתוב אימייל באורך 120 מילים שמתחיל בכאב של דיווח ידני ומסתיים בבקשה עדינה לקביעת שיחה של 15 דקות. פורמט: שורת נושא, שתי פסקאות גוף קצרות, ותווית לכפתור הנעה לפעולה (call-to-action). אילוצים: ללא ז'רגון כמו "synergy" או "bandwidth". הטון מקצועי אך חם. ללא סימני קריאה.

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

השורה התחתונה

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