מדריך לכתיבת פרומפטים

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

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

תנו לצוות לשאול לפני שהוא בונה

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

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

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

שלב 1: החליטו לפני שאתם מקלידים

דעו מה אתם בונים

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

לפעולה העיקרית הזו קוראים לעיתים קרובות CTA, קיצור של call to action. זהו הכפתור, הקישור או השלב הבא שאתם הכי רוצים שהמשתמשים יבחרו, כמו Sign Up, Book a Demo, Start Free, או Buy Now.

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

בנו אתר של עמוד אחד עבור אפליקציית תקציב המיועדת לפרילנסרים. ה-CTA הראשי הוא “Start Saving Smarter.” השתמשו במראה נועז ואקספרסיבי עם טיפוגרפיה גדולה וצבעים בולטים.

שרטטו את המסע, לא רק את המסכים

עיצוב טוב מתקיים בין המסכים לא פחות מאשר עליהם. עברו על המסלול שהמשתמש שלכם עובר: מה הוא רואה קודם, מה בונה אמון, מה נותן לו ביטחון לפעול, ולאן הפעולה הזו מובילה? אפילו שרטוט בן שלושה שלבים, hero, proof, call to action, הופך את הבקשות שלכם ליעילות הרבה יותר, כי לכל מקטע יש עכשיו סיבה להתקיים וסיבה להוביל לבא אחריו.

קבעו את הכיוון הוויזואלי מוקדם

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

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

שלב 2: כתבו בקשות שפוגעות במטרה

תארו תוצאות, לא מימושים

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

עבדו בחלקים, לא בעמודים

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

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

השתמשו במילים אמיתיות

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

כותרת hero: “Design Calmly.” טקסט משנה: “Turn stress into structure.” CTA: “Start Building Free.” פריסה ממוקדת-טקסט עם ריווח אנכי נדיב.

תנו שמות לאלמנטים אמיתיים

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

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

צרו כרטיס פרופיל עם תמונה, שם וכפתור follow. הוסיפו תווית קטנה “Verified” ליד השם, והציגו הסבר קצר כשמישהו מרחף מעליה.

שלב 3: שנו בדיוק

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

כשמתאימים עבודה קיימת, היו מפורשים בשני הצדדים: מה צריך להשתנות ומה חייב להישאר כפי שהוא. השתמשו במילות כיוון כמו “replace”, “update” ו-“adjust” במקום “make this better”, ותחמו את החלקים שאתם אוהבים. הדיוק כאן הוא מה שמונע מאיטרציה להפוך לרגרסיה.

שנו את טקסט ה-CTA ל-“Get Started” והגדילו את הריווח הפנימי האופקי שלו. השאירו את הצבעים הנוכחיים, הגופן וכל השאר במקטע הזה ללא שינוי.

שינוי משמעותי אחד בכל פעם

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

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

חשבו צעד אחד קדימה מה-UI

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

אם המשתמש מחובר, הציגו את האווטאר והשם שלו בפינה הימנית העליונה. אם לא, הציגו כפתור “Log In” שמנווט למסך האימות.

שאלות נפוצות

איך כותבים פרומפט יעיל לסוכן ה-AI?

בנו את הפרומפט שלכם עם המרכיבים המרכזיים הבאים:

1. Context — הציבו את הסצנה. הסבירו מה אתם בונים ואיפה הדברים עומדים כרגע.

2. Goal — היו ספציפיים לגבי התוצאה או הפיצ'ר המדויקים שאתם רוצים.

3. דרישות & Constraints — רשמו בבירור מה צריך להשתנות ומה חייב להישאר ללא מגע.

4. Expected Result — הגדירו איך נראית הצלחה (למשל, התנהגות UI, טיפול בשגיאות, התמדה של מצב).

5. References — צרפו צילומי מסך, קישורים, שלבי workflow או דוגמאות קוד בכל פעם שאפשר. הסירו סיסמאות, קודי אימות, מפתחות API, cookies, נתונים אישיים ופרטי תשלום לפני השיתוף.

דוגמה: "אני בונה dashboard עם sidebar. הוסיפו כפתור logout לתחתית ה-sidebar. הוא צריך לנקות את ה-session ולהפנות אל /login. אל תשנו את פריסת ה-sidebar או את קישורי הניווט. לאחר הלחיצה, המשתמש צריך לראות את דף ההתחברות בתוך שנייה אחת."

איך עליי לטפל בבקשות מורכבות שכוללות כמה פיצ'רים?

לבקשות מורכבות, פצלו אותן למשימות קטנות יותר:

1. ציינו את הבעיה הנוכחית ואת המטרה הסופית.

2. רשמו כל תת-משימה בנפרד (משימה 1, משימה 2, משימה 3).

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

4. בדקו את הזרימה המלאה בסוף.

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

איך כותבים פרומפט לתיקון באג?

פרומפט שימושי לתיקון באג צריך לכלול:

• העמוד, הפיצ'ר, הסביבה והמשתמשים המושפעים
• שלבים מדויקים לשחזור הבעיה
• ההתנהגות בפועל וההתנהגות הצפויה
• טקסט השגיאה המלא ומתי היא התרחשה
• צילומי מסך או לוגים רלוונטיים, לאחר הסרת סיסמאות, tokens, cookies, נתונים אישיים ופרטי תשלום
• מה חייב להישאר ללא שינוי
• איך לאמת את התיקון ואילו בדיקות רגרסיה להריץ

דוגמה: “בדף התשלום ב-Preview, בחירה ב-Submit מחזירה שגיאת 500. צפוי: ההזמנה מאושרת והמשתמש מגיע לדף התודה. שחזור: [שלבים]. תקנו את הסיבה בלי לשנות את סיכומי העגלה או את זרימת התשלום, ואז אמתו מקרה אחד מוצלח ומקרה אחד של תשלום שנדחה. הסרתי את כל הערכים הסודיים מהלוג המצורף.”

איך כותבים פרומפט לשינוי פריסת עמוד או עיצוב?

כשמבקשים שינויים בעמוד, כללו:

1. העמוד, המודול והאלמנט הספציפיים שיש לשנות.

2. המצב הנוכחי והתוצאה הרצויה.

3. קישורי ייחוס או צילומי מסך.

4. פיצ'רים שחייבים להישאר ללא שינוי.

5. קריטריוני קבלה (למשל, חייב לעבוד גם בדסקטופ וגם במובייל).

דוגמה: "בדף /pricing, שנו את רשת כרטיסי התוכניות מ-2 עמודות ל-3 עמודות בדסקטופ. השאירו את פריסת המובייל כעמודה אחת. התייחסו לצילום המסך הזה [צרפו]. אל תשנו את תוכן הכרטיסים או את סגנונות הכפתורים."

מה עליי לעשות כשהסוכן ממשיך לבצע את השינויים הלא נכונים למרות תיקונים?

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

1. שמרו על המצב הנוכחי — הפסיקו לשלוח תיקונים חופפים. אם הצ'אט שלכם מציג פקד Revert, קראו את טקסט האישור שלו לפני השימוש, שימו לב לכל שינוי מאוחר יותר שאתם צריכים לשמור, ואמתו את הפרויקט לאחר מכן. אם ההיקף אינו ברור, אל תמשיכו; השתמשו ב- צ'אט פרויקט הנחיות או פנו לתמיכה עם Chat Link מושחר וצילום מסך.

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

3. משימה אחת בכל פעם — התמקדו בתיקון בעיה אחת לפני שעוברים הלאה.

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