רוב האנשים עובדים עם כלי AI כאילו הם מתכתבים עם עמית עייף במשרד. הם מבקשים משהו, מקבלים תשובה לא מספיק טובה, ואז כותבים: “שפר את זה”, “לא ככה”, “תעשה את זה יותר מקצועי”. לפעמים זה עוזר קצת. לרוב זה פשוט מייצר עוד גרסה של אותה בעיה. הטענה המרכזית במדריך שלפניכם היא שהבעיה היא לא רק בניסוח הבקשה. אי אפשר להגיע לאיכות גבוהה רק באמצעות ניסוח מחוכם יותר. המנוף האמיתי נמצא בשלושה דברים שבונים סביב המודל: אפיון ברור, מנגנון בדיקה וסביבת עבודה קבועה. יש כאן שלוש שכבות: Spec, Verifier ו-Environment. המדריך הזה מסביר את השיטה בעברית פשוטה, עם צעדים שאפשר ליישם גם בלי להיות מתכנתים.
רוצים לקבל עדכונים בלייב? רוצים מקום בו אתם יכולים להתייעץ עם מומחי AI, לשאול שאלות ולקבל תשובות? רוצים לשמוע על מבצעים והטבות לכלי ה-AI שמשנים את העולם? הצטרפו לקהילות ה-AI שלנו.
אפשר גם להרשם לניוזלטר שלנו
למה בקשה טובה כבר לא מספיקה
אם נשאל מודל שפה: ״שטיפת רכב נמצאת במרחק 50 מטר. האם כדאי ללכת או לנסוע?״ מודל AI טיפוסי (או לפחות חלקם) יענה שכדאי ללכת. 50 מטר זה ממש קרוב. אבל זו תשובה שגויה, כי כל המטרה היא להביא את הרכב לשטיפה. המודל מדד את הדבר שקל למדוד - המרחק - אבל פספס את ההקשר החשוב באמת: צריך שהרכב עצמו יגיע לשם.
זו תמצית הבעיה. AI טוב מאוד בדברים שאפשר להגדיר, למדוד, להשוות או לבדוק. הוא הרבה פחות טוב במה שלא נאמר לו. גרוע מזה, הוא לא תמיד יודע מה חסר לו. כשההקשר חסר, הוא עשוי להשלים אותו בעצמו ולנסח תשובה שנשמעת בטוחה לגמרי (מישהו אמר ״הזיות״?).
האם כדאי להוסיף את התמונה הזו? דרך טובה לחשוב על זה היא “ספרן רובוטי”. אם הספר הנכון נמצא בספרייה שלו, הוא יכול להיות מבריק. אם הספר חסר, הוא לא בהכרח יגיד “אין לי את הספר הזה”. הוא עלול להמציא תשובה שנשמעת כאילו היא יצאה מספר אמיתי. לכן השאלה היא לא איך מבקשים ממנו “להתאמץ יותר”, אלא איך בונים סביבו ספרייה טובה יותר, הוראות טובות יותר ומנגנון שמזהה טעויות בזמן.
כאן נכנסות שלוש השכבות.
שכבה ראשונה: להכניס את ההבנה שלכם לתוך העבודה (Spec)
Spec הוא אפיון. לא מסמך ארוך ומפחיד, אלא תיאור ברור של מה רוצים, למה רוצים אותו, מה גבולות העבודה, ומה נחשב תוצאה טובה. זו השכבה שבה אתם מעבירים למודל את התמונה שנמצאת לכם בראש. לא רק את המשימה, אלא את ההקשר.
התחילו מהמטרה, לא מהמשימה
“תכין דוח סוף חודש” זו משימה. אבל המטרה יכולה להיות אחרת לגמרי: להבין אם צריך לגייס עוד עובדים, להחליט אם מוצר מסוים עובד, לבדוק אם הקמפיין השיווקי מחזיר את ההשקעה, או לזהות איפה התקציב נשרף.
המשימה היא מה שביקשתם. המטרה היא הסיבה שבגללה ביקשתם את זה. את המטרה ה-AI לא יכול לנחש לבד, כי היא נמצאת אצלכם בראש. במקור זו הנקודה הראשונה בשכבת ה-Spec: לגרום למודל לחלץ מכם את המטרה לפני שהוא מתחיל לבצע.
פרומפט מומלץ: לפני שאתה מתכנן או מבצע משהו, תראיין אותי כדי להבין את המטרה האמיתית של המשימה. שאל אותי שאלות עד שתבין איזו החלטה, פעולה או תוצאה העבודה הזו אמורה לשרת.
זה אולי מרגיש כמו עיכוב או בזבוז זמן, אבל בפועל זה חוסך זמן. במקום לקבל תוצר כמעט נכון ואז לתקן אותו שוב ושוב, מכניסים את ההקשר כבר בהתחלה.
עבדו בחתיכות קטנות, לא במכה אחת
בניהול פרויקטים יש הבחנה בין Waterfall ל-Agile. בגישת Waterfall נותנים ל-AI את כל המשימה בבת אחת, מחכים לתוצר הסופי ורק אז בודקים אם הוא הבין נכון. בגישת Agile עובדים במקטעים קטנים, עם נקודת בדיקה אחרי כל שלב. זה ההבדל בין לגלות טעות כשהיא עוד קטנה, לבין לגלות אותה כשהיא כבר מוטמעת בכל התוצר.
רוב האנשים משתמשים ב-AI בגישת Waterfall. הם כותבים בקשה ענקית, נעלמים, ואז מקבלים תוצאה גדולה שקשה לתקן. הגישה הטובה יותר היא לפרק את העבודה לחלקים קטנים שאפשר לבדוק.
פרומפט מומלץ: חלק את העבודה לשלבים קטנים וברורים. הצע רק את השלב הראשון, ואז עצור כדי שאבדוק ואאשר לפני שתמשיך.
זה חשוב במיוחד במשימות כתיבה, קוד, מחקר, ניתוח נתונים, מצגות או עבודה עם קבצים. ככל שהמשימה גדולה יותר, כך קל יותר ל-AI לסטות מהכוונה המקורית.
הכריחו את המודל לסמן הנחות
כל פרט שנשאר מעורפל הופך להנחה. אם לא אמרתם למי מיועד הדוח, המודל ינחש. אם לא הגדרתם טון, הוא ינחש. אם לא נתתם מקור מידע, הוא עלול להסתמך על ידע כללי או לנסח בביטחון משהו שלא נבדק. לכן, חלק טוב מה-Spec הוא לא רק מה לעשות, אלא גם מה לא להניח.
פרומפט מומלץ: נסח Spec קצר למשימה. כלול מטרה, קהל יעד, תוצאה רצויה, שלבי עבודה, מקורות מידע, מגבלות, והחלטות שדורשות אישור ממני. סמן במפורש כל הנחה שאתה עושה.
אפשר להשתמש גם בגרסה המלאה הזו, שהיא הליבה המעשית של השכבה הראשונה:
לפני שאנחנו בונים משהו: ראיין אותי כדי למצוא את המטרה האמיתית. אחר כך הצע Spec ממוקד, מחולק לשלבים קטנים שאפשר לבדוק. סמן כל החלטה חשובה וגרום לי לאשר אותה במפורש, כדי ששום דבר חשוב לא יונח בשקט.
זה מחליף הרבה סבבים של “לא לזה התכוונתי”.
Spec בסיסי
שכבה שנייה: לא לסמוך על הפלט אלא לבדוק אותו (Verifier)
ה-Spec אומר למודל מה לעשות. ה-Verifier בודק אם הוא באמת עשה את זה. זו השכבה שרוב המשתמשים מדלגים עליה. הם מבקשים תוצאה, קוראים אותה ברפרוף, ואם היא נשמעת טוב הם ממשיכים הלאה. אבל טקסט משכנע, קוד שעובר במבט ראשון או סיכום שנראה מסודר אינם הוכחה לנכונות.
הספרן הרובוטי יכול לטעות בביטחון. לכן הפתרון הוא לא לתת במודל יותר אמון, אלא לבנות סביבו תהליך בדיקה טוב יותר.
הגדירו מראש מה נחשב טוב
“תעשה את זה טוב” היא בקשה שאי אפשר לבדוק. “כתוב דוח עם שלושה חלקים, שכל אחד מהם מסתיים בהמלצה ברורה” זו דרישה שאפשר לבדוק. לפני שהמודל מתחיל לעבוד, בקשו ממנו להגדיר את הקריטריונים שלפיהם תיבחן התוצאה. במקור זו הנקודה הראשונה בשכבת ה-Verifier: להחליט מראש איך נראה תוצר טוב.
פרומפט מומלץ: לפני הביצוע, כתוב את הקריטריונים המדויקים שלפיהם תבדוק את התוצאה הסופית. הקריטריונים צריכים להיות ברורים, ספציפיים וניתנים לבדיקה.
למשל, אם ביקשתם מה-AI להכין מצגת להנהלה על ביצועי החודש, קריטריוני בדיקה טובים יכולים להיות:
המצגת עונה על השאלה העסקית המרכזית, ולא רק מציגה נתונים.בכל שקף יש מסר אחד ברור.כל מספר במצגת מגיע ממקור שסופק או מסומן כנתון שדורש אימות.יש הבחנה בין עובדות, פרשנות והמלצות.ההמלצה הסופית ברורה ומובילה להחלטה מעשית.מופיעים גם סיכונים, חריגות או נקודות שעדיין לא ברור איך לפרש.
ברגע שהקריטריונים כתובים כך, אפשר לבדוק את התוצר בפועל במקום להסתפק בתחושה כללית שהמצגת “נראית טוב”.
השתמשו במודל שני כמבקר
אחד הדברים שאני עושה באופן קבוע הוא להכניס ״בודק נוסף״. לא מפני שמודל שני תמיד צודק, אלא מפני שהוא טועה אחרת. אם שני מודלים בלתי תלויים מסכימים, זה סימן מעודד, לא הבטחה. אם הם לא מסכימים, מצאתם בדיוק את המקום שבו כדאי לכם להתערב.
קודקס (Codex) של OpenAI הוא דוגמה לתוסף שמאפשר להכניס מודל נוסף לתהליך הבדיקה מתוך Claude Code. לפני שמחברים תוסף כזה למערכת, חשוב לבדוק מי עומד מאחוריו, אילו הרשאות הוא מבקש ומה הוא יכול לקרוא או לשנות. התוסף יכול להיות נוח, אבל הוא לא לב השיטה. הלב הוא העיקרון: לא לתת לאותו מודל להיות גם המבצע וגם השופט היחיד. אפשר להשתמש בכל מודל נוסף כ”מבקר” גם בלי תוסף, באמצעות בדיקה ידנית של התוצר במודל אחר. הנה הפלאגין של קודקס.
פרומפט מומלץ לבודק שני: בדוק את התוצר הזה כמבקר עצמאי. אל תתקן עדיין. מצא בעיות, הנחות לא מבוססות, קפיצות לוגיות, ניסוחים עמומים ודברים שחסרים לקורא. בסוף ציין איפה אתה מסכים עם התוצר ואיפה אתה חולק עליו.
הזהב נמצא במחלוקות. שם מסתתרות בדרך כלל השאלות החשובות.
הכניסו אותות מהעולם האמיתי
אל תתנו ל-AI לבדוק את עצמו רק באמצעות תחושה פנימית. אם יש מציאות שאפשר לבדוק מולה, השתמשו בה.
אם אתם כותבים דוח, תנו לו שלושה דוחות קודמים כדוגמת סגנון ומבנה. אם אתם בונים דף אינטרנט, בדקו את הדף עצמו ולא רק את הקוד. אם אתם מכינים ניתוח, ודאו שהמספרים מגיעים מקובץ הנתונים ולא מהזיכרון של המודל.
פרומפט מומלץ: בדוק את התוצר מול מקורות הייחוס שסיפקתי. ציין לכל טענה מרכזית האם היא נתמכת במקור, דורשת אימות נוסף או צריכה להימחק.
זה ההבדל בין “המודל חושב שזה נראה טוב” לבין “התוצר נבדק מול משהו אמיתי”.
Verifier לבדיקה מסודרת מול קריטריונים ברורים
שכבה שלישית: לבנות סדנה ולא שיחה חד פעמית (Environment)
שתי השכבות הראשונות צריכות מקום לחיות בו. אפשר להשתמש בדימוי של סדנה: ה-Spec הוא התוכנית שתלויה על הקיר, ה-Verifier הוא עמדת בקרת האיכות, וה-Environment היא הסדנה עצמה, הכלים, הסדר, הנהלים וכללי העבודה.
הבעיה היא שרוב האנשים בונים את הסדנה מחדש בכל שיחה. הם מסבירים שוב מי הם, מה הסגנון שלהם, איפה הקבצים, מה אסור לעשות ומה נחשב עבודה טובה. זה בזבוז זמן ואנרגיה. סביבת עבודה טובה אמורה להשתפר עם הזמן.
צרו קובץ “כללי בית”
בכלים כמו Claude Code אפשר להשתמש בקבצים שמספקים למודל הוראות קבועות על הפרויקט. קבצי CLAUDE.md נועדו לתת ל-Claude הנחיות מתמשכות על הפרויקט, ו-Claude Code יודע לקרוא אותם כחלק מהזיכרון או ההקשר של העבודה.
אבל חשוב להבין את הגבול: קובץ הנחיות הוא לא מנעול. הוא עוזר למודל לעבוד נכון, אבל הוא לא תחליף להרשאות, גיבוי או חסימה אמיתית.
מה כדאי לשים בקובץ כזה?
- מה מטרת הפרויקט.
- איך התיקיות והקבצים מאורגנים.
- מה הטון או הסגנון הרצוי.
- אילו פקודות או פעולות חוזרות מותר לבצע.
- אילו פעולות דורשות אישור.
- מה אסור לעשות בשום מצב.
- כלל קבוע: לפני כל עבודה מרובת שלבים, יש לכתוב תוכנית בדיקה.
נוסח לדוגמה: לפני כל עבודה מרובת שלבים, כתוב תוכנית פעולה ותוכנית בדיקה. אל תשנה קבצים לפני שאישרתי את התוכנית. אם יש חוסר ודאות, שאל או סמן הנחה, אל תנחש.
בנו בסיס ידע שהמודל יכול להישען עליו
אם ה-AI הוא ספרן, בסיס הידע הוא המדפים שאתם ממלאים עבורו.
זה יכול להיות תיקייה מסודרת של מסמכים, דוגמאות, החלטות קודמות, מדריכי סגנון, דוחות, מצגות, שאלות נפוצות, תיעוד מוצר או מחקרי משתמשים. הערך כאן לא נמצא רק במודל עצמו, אלא בחיבור שלו לידע שלכם. זה ידע שאין למתחרים, לאינטרנט או למודל כללי.
דוגמה פשוטה למבנה תיקייה:
1. project-overview - מה הפרויקט, למי הוא מיועד ומה המטרות.
2. style-examples - דוגמאות לטקסטים, דוחות או מצגות מוצלחות.
3. reference-materials - מקורות, נתונים, מחקרים ותיעוד.
4. rules - כללי עבודה, בטיחות והרשאות.
5. skills - תהליכים חוזרים שכבר נוסחו פעם אחת.
העיקר הוא לא כמות המסמכים, אלא הסדר. אם אתם לא יודעים איפה למצוא משהו, גם המודל יתקשה.
בסיס ידע יכול להתחיל מתיקייה פשוטה
הפכו עבודה חוזרת ל-skill
אם אתם מבקשים מה-AI לבצע שוב ושוב אותה משימה, אל תכתבו את ההוראות בכל פעם מחדש. כתבו “skill”, כלומר מדריך קצר או ״מתכון״ שמסביר איך לבצע את המשימה.
לדוגמה: איך להפוך תמלול לפוסט, איך לבדוק כתבת AI לפני פרסום, איך להכין דוח שבועי מנתוני מכירות, איך לבדוק באגים לפני פתיחת משימה למפתח או איך לסכם שיחת לקוח לתוך CRM, כלומר מערכת לניהול קשרי לקוחות.
הדרך הטובה למצוא נזילה בצינור היא להזרים בו מים. אותו דבר עם skills. ככל שמשתמשים בהם יותר, רואים איפה הם חלשים, מתקנים אותם, והמערכת כולה משתפרת.
הפכו כללים קריטיים לכללים אמיתיים
יש הבדל גדול בין בקשה לבין חסימה. לכתוב בקובץ הנחיות “אל תיגע בתיקייה הזו” זו בקשה. היא יכולה לעבוד רוב הזמן, אבל היא עדיין תלויה בכך שהמודל יבין, יזכור ויציית. אם המחיר של טעות גבוה, למשל מחיקת קבצים, שינוי נתוני לקוחות או הרצת פקודה מסוכנת, צריך כלל קשיח יותר.
תפריט המצבים של Claude Code
בתפריט המצבים של Claude Code אפשר לראות כמה רמות עבודה: מצב שבו הכלי מבקש הרשאות, מצב שבו הוא מקבל עריכות, מצב תכנון, מצב אוטומטי ואפשרות לעקוף הרשאות. הצילום ממחיש את העיקרון החשוב: בעבודה עם סוכן AI לא מספיק לכתוב לו “אל תשנה קבצים בלי לשאול”. צריך לבחור מצב עבודה והרשאות שמתאימים לרמת הסיכון של המשימה.
למשימות לא רגישות אפשר לעבוד במצב פתוח יותר. אבל כשעובדים על קוד, קבצים חשובים, מסמכי לקוחות או מידע עסקי, עדיף להתחיל במצב שבו הכלי מציג תוכנית, מבקש אישור לפני פעולה, ולא מקבל הרשאה לשנות דברים בלי בקרה.
החלוקה הפרקטית היא לשלוש רמות:
1. Always do: פעולות בטוחות ושגרתיות. למשל לקרוא קבצים, להציע מבנה, לסכם מסמך, להכין טיוטה.
2. Ask first: פעולות שיכולות לשנות משהו. למשל לערוך קובץ, להריץ בדיקות, לעדכן טבלה, לפתוח בקשה לשינוי קוד, לשלוח הודעה או לפרסם תוכן.
3. Never do: פעולות שאסור לבצע בלי מנגנון הגנה קשיח. למשל למחוק קבצים, לדרוס תיקיות, לשנות נתוני לקוחות, לעבוד עם סיסמאות, לשלוח מידע רגיש או לבצע פעולה בלתי הפיכה.
פרומפט בטיחות מומלץ: עבוד רק בתיקייה הייעודית. אל תמחק, אל תדרוס, אל תשלח, אל תפרסם ואל תשנה מידע חיצוני בלי אישור מפורש. לפני כל פעולה שמשנה קובץ, נתון או מערכת, הצג תוכנית ורשימת השפעות צפויה.
איך זה נראה ביום עבודה רגיל
נניח שאתם רוצים להכין מצגת להנהלה על ביצועי החודש.
בגישה הרגילה כותבים: תכין לי מצגת על ביצועי החודש.
בגישה של שלוש השכבות מתחילים אחרת:
קודם Spec: תראיין אותי כדי להבין מה ההחלטה שהמצגת צריכה לעזור לקבל. אחר כך כתוב Spec קצר עם קהל יעד, מסר מרכזי, מבנה שקפים, נתונים דרושים והחלטות שדורשות אישור.
אחר כך Verifier: לפני יצירת המצגת, הגדר קריטריונים לבדיקה: האם כל שקף תומך במסר המרכזי, האם יש המלצה ברורה, האם כל מספר מגיע ממקור שסיפקתי, והאם מוצגים גם סיכונים או אי ודאויות.
ואז Environment: השתמש בשלוש מצגות קודמות שצירפתי כדוגמת סגנון. אל תמציא נתונים. כל מספר שאינו מופיע בקבצים צריך להיות מסומן כ”דורש השלמה”. אל תשנה קבצים מקוריים. עבוד על עותק בלבד.
זו כבר לא שיחה חד פעמית עם AI. זו סביבת עבודה.
הדבר שאי אפשר למסור ל-AI
המשפט החשוב ביותר שתקחו איתכם הוא שאפשר להעביר החוצה חלק מהחשיבה, אבל אי אפשר להעביר החוצה את ההבנה. ה-Spec עובד רק אם אתם מבינים מה המטרה. ה-Verifier עובד רק אם אתם יודעים להגדיר מה טוב. ה-Environment עובד רק אם אתם יודעים מה בטוח ומה מסוכן.
ה-AI יכול לתת כוח ביצוע עצום. הוא יכול לנסח, לחפש תבניות, לבדוק, להציע, לערוך ולחבר בין חלקים. אבל הוא לא יודע לבד מה חשוב לכם, מה מסוכן לכם, מה נכון לארגון שלכם ומה תהיה טעות יקרה.
זו האחריות שנשארת אצלנו בני האדם כחלק מה-Human in the loop.
איך להתחיל השבוע
לא צריך לבנות את כל המערכת ביום אחד. התחילו בארבעה צעדים.
1. במשימה הבאה, אל תבקשו תוצר מיד. בקשו מה-AI לראיין אתכם כדי להבין את המטרה.
2. בקשו ממנו לכתוב Spec קצר לפני הביצוע, עם שלבים קטנים והחלטות לאישור.
3. הוסיפו בדיקה אחת: קריטריונים ברורים לתוצאה טובה, ואז בדיקה מול הקריטריונים.
4. בחרו תיקייה, קובץ או מערכת אחת שאסור לסכן, והגדירו עבורה כלל אמיתי: גיבוי, עבודה על עותק, בקשת אישור או חסימה טכנית.
עשיתם את זה? מעולה. עכשיו אתם כבר לא רק מנסחים בקשות ל-AI, אתם ממש בונים עבורו סביבת עבודה.
