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

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

טעות 1 - בקשה מעורפלת מדי

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

טעות 2 - חוסר הקשר על הפרויקט

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

טעות 3 - לבקש הכל בפעם אחת

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

טעות 4 - לא לתת דוגמה כשאפשר

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

טעות 5 - לסמוך על התוצאה הראשונה בלי לבדוק

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

טעות 6 - להתייחס לזה כמו לגוגל ולא כמו לשיחה

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

טעות 7 - לשכוח לציין אילוצים

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

טעות 8 - לא לתקן את עצמכם

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

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

לסיכום

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

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