איך לכתוב פרומפט מושלם ל-⁨Claude Code⁩

למה בקשה קצרה מחזירה תוצאה בינונית

יש שתי סיבות, ושתיהן כתובות בתיעוד של Anthropic.

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

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

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

מבנה הבקשה, חמישה חלקים

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

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

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

מה לעשות

הפעולה עצמה, בפועל אחד. תוסיף, תתקן, תעביר, תמחק, תסדר.

תתארו את התוצאה שאתם רוצים ולא את הצעדים להגיע אליה. הוא ימצא את הקבצים לבד, זה בדיוק מה שהוא טוב בו.

איפה

שם הקובץ או התיקייה. אם אתם לא זוכרים איפה זה יושב, תתארו את ההתנהגות במקום את המיקום.

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

מה שאסור לשנות

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

אם יש משהו שחייב להישאר כמו שהוא, תגידו את זה בשורה נפרדת.

איך נראית תוצאה טובה

לא "שיהיה יפה". לא "שיעבוד טוב".

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

איך הוא יבדוק את עצמו

החלק החשוב ביותר, ולכן יש לו פרק משלו למטה.

החלק הכי חשוב: איך הוא יידע שהוא הצליח

תנו לו בדיקה שהוא יכול להריץ בעצמו, ומשהו משתנה לגמרי.

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

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

ככה זה נראה בבקשה אמיתית:

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

המשפט האחרון הוא ההבדל בין בקשה שאתם בודקים לבין בקשה שנבדקת לבד.

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

בקשה גרועה מול בקשה טובה

ארבע דוגמאות. בכל אחת מהן מדובר בדיוק באותה משימה, רק כתובה אחרת.

לסדר תיקייה

גרוע:

תסדר לי את התיקייה

טוב:

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

לתקן תקלה

גרוע:

תתקן לי את הבאג בהתחברות

טוב:

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

להוסיף בדיקות

גרוע:

תוסיף בדיקות לקובץ

טוב:

תכתוב בדיקה לקובץ הזה למקרה שבו המשתמש לא מחובר.
תריץ את הבדיקות ותתקן כשלים עד שהכל עובר.

לשפר עיצוב

גרוע:

תעשה שהעמוד ייראה יותר טוב

טוב:

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

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

תנו לו את החומר, לא תיאור של החומר

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

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

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

למה הבנייה נכשלת? מצורף כאן קובץ הלוג המלא.

לפני משימה גדולה: מצב תכנון

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

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

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

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

ארבע הטעויות שהכי מבזבזות לכם זמן

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

סשן אחד לכל הדברים

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

הפתרון הוא פקודה אחת: /clear בין משימות שלא קשורות זו לזו. היא מאפסת את ההקשר ומתחילה נקי.

תיקון על גבי תיקון

הוא עשה משהו לא נכון, תיקנתם, יצא עדיין לא טוב, תיקנתם שוב.

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

זה הרגל שקשה לאמץ כי הוא מרגיש כמו לוותר. הוא לא. הוא חוסך לכם עשרים דקות.

חקירה בלי גבולות

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

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

להאמין בלי לבדוק

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

ואז מתברר שהוא לא מטפל במקרה קצה מסוים.

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

איך מפסיקים לחזור על אותה בקשה כל פעם

אחרי כמה ימים תשימו לב שאתם כותבים לו שוב ושוב את אותן הוראות. אל תעבדו לו יותר. תכתבו אותן פעם אחת בקובץ שנקרא CLAUDE.md, והוא קורא אותו בתחילת כל שיחה.

הפקודה /init יוצרת לכם קובץ התחלתי לפי המבנה של הפרויקט, ומשם אתם מוסיפים ומורידים לבד.

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

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

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

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

אתה ממשיך לעשות את הדבר הזה. תוסיף כלל ל-CLAUDE.md כדי שזה יפסיק לקרות.

מה זה לא יפתור

מדריך שמראה רק ניצחונות הוא מדריך שלא שווה כלום, אז הנה הצד השני.

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

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

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

סיכום

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

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

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

אהבתם את המדריך? מוזמנים לעקוב אחריי באינסטגרם @moshe.elkrief לעוד תכנים.