איך מדברים אליו — בקשה טובה מול בקשה שמייצרת בלגן

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

דוגמה 1 — בקשה בלי היקף

תשפר את הקוד

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

הגרסה המתוקנת:

בקובץ utils/dates.ts יש שלוש פונקציות שממירות תאריכים.
אחד אותן לפונקציה אחת. אל תיגע בקבצים אחרים.
בסוף הרץ את הבדיקות הקיימות וודא שהן עוברות.

היקף (קובץ אחד), הקשר (שלוש פונקציות כפולות), קריטריון (הבדיקות עוברות).

דוגמה 2 — בקשה בלי הקשר

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

למה זה מייצר בלגן: הוא לא היה שם כשזה קרה. בלי תסמינים הוא ינחש איזה באג, יתקן משהו — אולי את הלא-נכון — וידווח "תוקן". זה בדיוק המתכון לתיקון-לכאורה.

הגרסה המתוקנת:

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

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

דוגמה 3 — שתי משימות בבקשה אחת

תוסיף עמוד פרופיל וגם תשדרג את React ותסדר את ה-routing

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

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

/clear

הפקודה מנקה את השיחה ומתחילה משימה חדשה על דף חלק — הידע הקבוע של הפרויקט (CLAUDE.md, במאמר הבא) נשאר.

הכלל המסכם

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