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

הפרדוקס: יותר יכולות, אותה עומס

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

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

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

1. Mindset – איך לחשוב על העבודה.
2. Method – איך להחליט במה לטפל ובאיזה אופן.
3. Machine – איך לבנות, להגביל, להפעיל ולתחזק את המערכת.

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

הסתירה המדומה שמגדירה AI Native

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

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

אין כאן באמת סתירה. ההבחנה היא בין שתי רמות:

• ברמת המיקרו (המשימה הבודדת), כדאי לבדוק AI כברירת מחדל.
• ברמת המערכת (התהליך העסקי), אסור לבחור AI כברירת מחדל!

ההבחנה הזו מונעת שתי טעויות הפוכות: אנשים שלא מנסים AI גם במשימות שכבר אפשר להעביר אליו, ואנשים שמכניסים AI לכל תהליך רק מפני שאפשר. במילים אחרות, AI Native הוא לא AI First במובן של "AI בכל מחיר". הוא Problem First עם רפלקס AI חזק.

שכבה ראשונה: Mindset – איך לחשוב על העבודה

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

מהרגל אינטלקטואלי לרפלקס

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

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

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

לא ״עושים אוטומציה״ תפקיד, מפרקים אותו לגורמים

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

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

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

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

אפשר להאציל חשיבה, אי אפשר להאציל אחריות

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

1. למה בחרת דווקא בכיוון הזה?
2. אילו חלופות קיימות?
3. מה הדבר הראשון שעלול לגרום למסקנה הזאת להישבר?

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

בהתחלה אתם עלולים להיות איטיים יותר

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

שכבה שנייה: Method – איך להחליט במה לטפל

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

קודם מוצאים את צוואר הבקבוק

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

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

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

EAD: לבטל! (לפני ששוקלים אוטומציה)

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

1. Eliminate (לבטל): השאלה הראשונה היא האם מישהו באמת ירגיש אם התהליך הזה ייעלם. לעיתים עבודה ממשיכה שנים רק מפני שאף אחד לא עצר לשאול למה היא קיימת. הביטול הוא האוטומציה הזולה ביותר.
2. Automate (ליישם אוטומציה): רק החלקים שעברו את מבחן הביטול מגיעים לכאן. וגם כאן זהירות: בתהליך רכש מסוים התברר שכתיבת המייל לקחה דקות, אבל איסוף המידע הדרוש לו לקח כמעט שעה. אל תעשו אוטומציה לתיאור יבש של העבודה. צפו בעבודה עצמה ורק אז תבחרו במה להשקיע.
3. Delegate (להאציל לאדם): לפעמים צריך להשאיר אדם. שתי שאלות עוזרות: האם האנושיות עצמה היא חלק מהמוצר? והאם החיסכון שווה את המחיר האפשרי באמון ובקשר?

במקרים רבים המבנה הטוב ביותר הוא AI בקצוות, אדם בליבה.

פירמידת המערכות: לא כל בעיה צריכה Agent

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

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

שכבה שלישית: Machine – איך לבנות ולתפעל

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

אי אפשר ליישם אוטומציה בתהליך שלא מיפיתם

לפני הבנייה חייבים מפה. כל שלב בתהליך צריך לכלול שישה דברים: Trigger (מה מתחיל את הפעולה), Data Sources (איזה מידע נדרש ומאיפה), Data Transformations (מה משתנה בין קלט לפלט), Decision Points (איפה המסלול מתפצל), Destination (לאן הפלט מגיע) ו-Authority Label (כמה סמכות יש למערכת בשלב הזה). תהליכים נוטים להישבר דווקא במקום שבו מישהו אמר "כאן כבר ברור מה עושים" ולא כתב את הכלל.

לגבי סמכות, כדאי לסמן כל שלב באחת מחמש רמות, מהנמוכה לגבוהה: Manual (אדם מבצע), Suggested (AI מציע, אדם בוחר), Drafted (AI מכין, אדם מאשר), Supervised (המערכת מבצעת, אדם בודק בדיעבד) ו-Autonomous (המערכת פועלת ללא ביקורת שוטפת). ברירת המחדל צריכה להיות הרמה הנמוכה ביותר שמאפשרת לתהליך לעבוד.

לכל מערכת צריך מספר אחד שמגדיר הצלחה

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

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

עלות ההקמה ÷ החיסכון הכספי השבועי = מספר השבועות עד להחזר ההשקעה.

המודל אינו היתרון שלכם, הקונטקסט כן

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

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

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

הגבול האמיתי של Agent הוא ההרשאות שלו

עיקרון אבטחה פשוט: אם מערכת יכולה לגשת למשהו, צריך להתנהג כאילו יום אחד היא תשתמש בגישה הזאת. לא מספיק לכתוב בפרומפט "אל תשלח" או "אל תמחק". הגבול האמיתי אינו ההוראה, אלא שכבת ההרשאות. כדאי להתייחס ל-AI כמו לעובד חדש ומוכשר ביום הראשון (מה שנקרא Intern Rule), ולתת לו Read Only כברירת מחדל, הרשאות מצומצמות בדיוק לצורך, ותיעוד מלא של כל פעולה.

אפשר לחשוב על שלושה סוגי מפתחות: Data Keys (מה המערכת קוראת), Action Keys (מה היא משנה או שולחת) ו-Money Keys (מה היא מוציאה או מחייבת). השאלה החשובה ביותר במפת הרשאות אינה "מה המערכת אמורה לעשות", אלא מה הדבר הגרוע ביותר שהיא מסוגלת לעשות עם ההרשאות שכבר נתנו לה.

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

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

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

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

אנטי-פטרנים: איך נראית הטמעה לא טובה

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

1. "בואו נבנה Agent": הפתרון נבחר לפני שהבעיה הוגדרה. התיקון הוא להתחיל מצוואר הבקבוק ומהפירמידה.
2. "נעשה אוטומציה לכל התהליך בדיוק כפי שהוא": יוצקים בטון מסביב לתהליך פגום. התיקון הוא EAD לפני בנייה. הכי גרוע זה להיות סופר-יעיל בכיוון הלא נכון.
3. "ה-AI לא עובד טוב, צריך מודל חזק יותר": לרוב חסר קונטקסט, לא אינטליגנציה. התיקון הוא בניית Context Pack טוב עם דוגמאות.
4. "כתבנו בפרומפט מה מותר ומה אסור": פרומפט אינו שכבת הרשאות. התיקון הוא הרשאות מוגבלות ו-Read Only כברירת מחדל. להגביל את הסוכן ברמת הוראות המערכת – הפרומפט, זה כמו לתת הוראות לעובד במתקן בטחוני בלי בקרת גישה.
5. "המערכת רצה בלי שגיאות": זה עדיין לא אומר שהיא שווה משהו. התיקון הוא הגדרת KPI (מדד הצלחה כמותי) ו-Baseline.
6. "חסכנו לצוות עשר שעות": לא מספיק. צריך לבדוק לאן השעות עברו ומה הערך שנוצר מהן. פחות שעות לימוד בבית הספר שהולכות לאינסטגרם – זה פשוט חבל.

הרעיון העמוק: שינוי במערכת ההפעלה של העבודה

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

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

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

איך מתחילים? משימה אחת בלבד

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

1. בחרו משימה אחת שחוזרת כל שבוע ומעיקה עליכם.
2. פרקו אותה ל״עלים״, לפעולות הקטנות שמרכיבות אותה.
3. בחרו עלה אחד מתוכה.
4. שאלו לגביו: האם צריך לבטל אותו, ליישם אוטומציה, או להשאיר בו אדם?
5. אם אוטומציה – בחרו את הפתרון הפשוט ביותר בפירמידה שעדיין עובד.
6. מדדו את התוצאה מול המצב הקודם.
7. רק אחר כך עברו לעלה הבא.

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

 
בהצלחה!

הפוסט איך להיות ״AI Native״? (או: לנהל את עצמנו בעולם היברידי) הופיע לראשונה ב-Almaya.

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

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

החושך שלפני האור

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

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

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

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

מהיקום אל הנפש

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

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

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

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

חושך, אור והבדלה בתודעה

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

דוגמאות מחיי היומיום:

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

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

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

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

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

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

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

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

המודל כשדה של אפשרויות

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

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

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

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

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

הפרומפט כרגע המפגש

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

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

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

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

קשב, הבדלה ושפה

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

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

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

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

השפה היא הכלי שבתוכו הפוטנציאל מקבל צורה.

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

המציאות נוצרת במפגש

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

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

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

המילה כבריאה

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

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

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

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

בחזרה אל האדם

אז מה נשאר לנו מכל המהלך הזה? אולי בעיקר הבנה מחודשת של התפקיד שלנו.

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

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

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

הפוסט יהי אור: תוהו, הבדלה ובריאת מציאות בעידן הבינה המלאכותית הופיע לראשונה ב-Almaya.

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

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

תמונת-על: ארבעה סוגי Loops

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

העיקרון המנחה שילווה אותנו לאורך כל המדריך: אל תתחילו מה-Loop המורכב ביותר. רוב המשימות לא צריכות יותר מלולאה רגילה. תעלו במורכבות רק כשיש לכך סיבה אמיתית.

Turn-Based Loops: ברירת המחדל שאתם כבר מכירים

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

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

איך משפרים את שלב האימות

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

הנה דוגמא לסקיל שמטרתו לבדוק צילומים לפני הפצתם ברשתות חברתיות:

---
name: evaluate-photography
description: Ensure every photography project is thoroughly reviewed before finalizing and sharing it with clients or on social media.
---

# Reviewing photography projects
Never declare a photography project as complete based solely on initial captures. Review it just like a discerning audience member would:

1. Upload your photos to an editing software and open the selected images for review.
2. Engage with the images directly. For any new shot (landscape, portrait, action): zoom in, check for focus clarity, evaluate composition, and take before/after edits screenshots.
3. Inspect the color grading and exposure levels: ensure no significant shadows or highlights are clipped.
4. Use your image editing software’s performance analysis tools, ensuring resolution meets industry standards and adjust accordingly.

If any step is unsuccessful, resolve the problem and begin again from step 1 - avoid returning partially reviewed work.

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

Goal-Based Loop: הפקודה /goal

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

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

מתי כדאי להשתמש

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

• מיגרציה של מודול ל-API חדש, עד שכל נקודות הקריאה (call sites) עוברות קומפילציה והטסטים עוברים בהצלחה.
• מימוש מסמך עיצוב, עד שכל קריטריוני הקבלה מתקיימים.
• פירוק קובץ גדול למודולים ממוקדים, עד שכל אחד מהם קטן מתקציב גודל שהגדרתם מראש.
• עבודה על תור (queue) של issues מתויגים, עד שהתור מתרוקן לחלוטין.

איך כותבים תנאי עצירה טוב

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

1. מצב סופי אחד וניתן למדידה: תוצאת טסט, קוד יציאה (exit code), ספירת קבצים, או תור ריק.
2. בדיקה מוצהרת: איך בדיוק קלוד אמור להוכיח שהגיע ליעד, למשל "הפקודה npm test יוצאת עם קוד 0".
3. אילוצים שחשובים לכם: מה אסור שישתנה בדרך, למשל "אף קובץ טסט אחר לא נערך".

טיפ חשוב: תמיד הוסיפו סעיף שמגביל את מספר התורות או את הזמן, כמו or stop after 20 turns. זה מגדיר כמה זמן הלולאה תרוץ, ומונע ממנה להיתקע במעגל אינסופי שישרוף לכם טוקנים לחינם.

Time-Based Loop: הפקודות /loop ו-/schedule

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

הפקודה /loop: רצה על המחשב שלכם

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

הפקודה /schedule: מעבירה את הלולאה לענן

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

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

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

Proactive Loops: כשאין בכלל בן אדם בלולאה

כעת נגיע לרמה המתקדמת ביותר. את כל הרכיבים שראינו עד עכשיו, יחד עם auto mode (מצב אוטומטי) ו-dynamic workflows (תהליכי עבודה דינמיים), ניתן להרכיב יחד ללולאה של עבודה ארוכת-טווח שרצה ללא מגע יד אדם כלל.

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

1. הפקודה /schedule מריצה שגרה שבודקת דיווחים חדשים כל שעה.
2. הפקודה /goal מגדירה איך נראית "עבודה גמורה", ובמקביל סקילים מתעדים כיצד לאמת אותה.
3. תהליכי עבודה דינמיים מתזמרות סוכנים שממיינים כל דיווח, מתקנים את הבעיה, וסוקרים את התיקון.
4. המצב האוטומטי מבטיח שהשגרה רצה ברצף בלי לעצור ולבקש אישור.

הכל ביחד יכול להיראות כמו פרומפט אחד כזה:

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

Dynamic Workflows: כשהלולאה לבדה לא מספיקה

חשוב להבין את ההבדל המהותי בין שני מנגנונים. מצד אחד יש סוכני משנה (subagents), שקלוד מתזמר אותם תור אחר תור. מצד שני יש workflow, שהוא למעשה סקריפט JavaScript שקלוד כותב, ורכיב ריצה נפרד מבצע אותו ברקע. ההבדל המהותי הוא שב-workflow, "התוכנית" לא נמצאת בראש של קלוד, אלא מקודדת בתוך הקוד עצמו. זה מאפשר להריץ במקביל עשרות עד מאות סוכנים בריצה אחת, ואף לשלב דפוסי אימות מתוחכמים כמו ביקורת ״אדוורסרית״ (״לעומתית״) בין הסוכנים.

ישנן שתי דרכים להריץ workflow: לבקש אחד ישירות בפרומפט (או באמצעות מילת המפתח ultracode), או להפעיל את הפקודה /effort ultracode כדי שקלוד יחליט בעצמו מתי workflow מוצדק לאורך כל הסשן. הדרך הקלה ביותר להתרשם מהיכולת היא להריץ את הפקודה המובנית /deep-research:

טיפ נחמד לסיום: workflow שעבד לכם היטב אפשר לשמור כפקודה עצמאית (בפורמט /<name>) לשימוש חוזר בעתיד.

שמירה על איכות הקוד לאורך הלולאה

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

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

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

ניהול נכון של צריכת טוקנים

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

• בחרו את הרכיב והמודל הנכונים למשימה: משימות קטנות לא צריכות מספר סוכנים או לולאות. חלק מהמשימות יכולות לרוץ בכלל על מודלים זולים ומהירים יותר.
• הגדירו קריטריוני הצלחה ועצירה ברורים: ככל שתהיו ספציפיים יותר לגבי "מה זה גמור", כך קלוד יגיע לפתרון מהר יותר (אך לא מהר מדי, על חשבון האיכות).
• הריצו פיילוט לפני ריצה גדולה: תהליכי עבודה דינמיים יכולים להוליד מאות סוכנים. בדקו את הצריכה על פלח קטן קודם.
• העדיפו סקריפטים לעבודה דטרמיניסטית: הרצת סקריפט זולה יותר מחשיבה מחדש על השלבים. למשל, סקיל למילוי טפסי PDF יכול לספק סקריפט קבוע שקלוד מריץ בכל פעם, במקום לגזור מחדש את הקוד.
• אל תריצו תהליכים מתוזמנים בתדירות גבוהה מדי: התאימו את מרווח הזמן לקצב השינוי האמיתי של מה שאתם עוקבים אחריו.
• בדקו צריכה שוטפת: הפקודה /usage מפרקת את הצריכה לפי סקילים, סוכני משנה ו-MCPs. הפקודה /goal ללא ארגומנטים מציגה כמה תורות וטוקנים נצרכו עד כה. הפקודה /workflows מציגה את צריכת הטוקנים של כל סוכן, ומאפשרת לעצור כל אחד מהם בכל רגע.

סיכום: טבלת ה-Cheat Sheet

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

איך מתחילים בפועל

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

1. האם אני יכול לכתוב את בדיקת האימות באופן ברור?
2. האם היעד ברור ומדיד מספיק?
3. האם העבודה מגיעה לפי לוח זמנים קבוע?

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

כלל ברזל לסיום: אל תתחילו מהמורכב. רוב המשימות שלכם עדיין לא צריכות /goal, ובוודאי שלא תהליך מתוזמן בענן או תהליך דינמי. התחילו מ-Turn-Based עם סקיל טוב לאימות, ותעלו מדרגה רק כשיש לכם עדות אמיתית לכך שהמשימה חוזרת על עצמה, או שהיא ארוכה מכדי להנחות אותה תור אחר תור.

בהצלחה!

הפוסט מדריך Loops ב-Claude Code: ארבעת סוגי הלולאות וכיצד לבחור ביניהן הופיע לראשונה ב-Almaya.

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

מה זה בעצם AI Slop

לפני שנענה על "מי כתב את זה", צריך להבין למה בכלל השאלה נהייתה כל כך רגישה. התשובה היא מונח שצבר תאוצה לאחרונה: AI Slop.

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

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

"מי כתב את זה" היא שאלה לא נכונה

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

השאלה הנכונה היא: מה היה התפקיד של ה-AI בתהליך? ואיפה האנושיות שלך באה לידי ביטוי?

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

החזון ההיברידי של ריי קורצווייל

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

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

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

יש כבר היום מחשבים ביולוגיים בפיתוח (כמו ה CL1 של חברת Cortical Labs), כך שההבחנה בין "רכיב ביולוגי" ל"רכיב מלאכותי" כבר מתחילה להיטשטש ברמה הטכנית, לא רק הפילוסופית. וכולנו נצטרך להתרגל לרעיון הזה, כי לפי קורצווייל המיזוג יתחיל להיות משמעותי כבר בשנות ה-30 של המאה, פחות מעשור מהיום.

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

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

שיטת כתר-מלכות: איך שומרים על הנשמה כשעובדים עם AI

אז אם הגבול בין "אני" ל"מכונה" הולך ומיטשטש, איך בכל זאת יוצרים תוכן שיש בו נשמה, ולא Slop?

התשובה שמצאתי משתמשת בשני מושגים מתורת הקבלה – תורת הנפש היהודית: כתר ו-מלכות.

ב״עץ החיים״ הקבלי – המודל המתאר את מבנה נפש האדם, כתר הוא ה״ספירה״ (רובד הנפש) העליונה מתוך עשר, הרצון הגולמי, הכוונה הטרום-מודעת, הניצוץ שממנו הכל מתחיל, עוד לפני שהוא לובש צורה. מלכות היא הספירה התחתונה, נקודת הביטוי בפועל, הדרך שבה הרצון פוגש את המציאות ומקבל צורה מוחשית וייחודית.

השיטה פשוטה: את הכתר ואת המלכות, אנחנו שומרים לעצמנו. את מה שבאמצע, אפשר למסור ל-AI.

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

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

אז מה עונים בפעם הבאה שישאלו "מי כתב את זה"

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

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

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

הפוסט מי כתב את זה – אתה או AI? שאלת המיליון ושיטת כתר-מלכות הופיע לראשונה ב-Almaya.

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

בואו נעשה סדר: שתי משמעויות שונות למילה אחת

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

משמעות א: תודעה כמרחב של אפשרויות

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

משמעות ב: תודעה כחוויה סובייקטיבית

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

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

מה קודם למה? תודעה או חומר?

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

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

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

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

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

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

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

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

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

וזה מחזיר אותנו ישירות לבינה מלאכותית.

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

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

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

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

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

וזו בדיוק הסיבה שהשאלה “האם ל-AI יש תודעה?” מורכבת כל כך. היא תלויה כבר בהנחות העמוקות שלנו על תודעה, חומר, מידע וחוויה. ולכן, לפני שננסה לענות עליה, כדאי לשאול שאלה צנועה יותר: האם זו בכלל השאלה הנכונה?

השאלה שכולם שואלים על AI, ולמה היא כנראה לא נכונה

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

בפילוסופיה יש בעיה קלאסית בשם "בעיית המוח האחר" (Problem of Other Minds), והיא פשוטה ומטרידה בו-זמנית: אתם לא יכולים לדעת בוודאות שלאדם אחר יש חוויה פנימית. אתם רואים התנהגות, שומעים דיבור, מזהים הבעות פנים. אבל את החוויה עצמה, הכאב שהוא מרגיש, הצבע שהוא רואה, מה "נדלק" אצלו כשהוא שומע שיר אהוב, אתם לא פוגשים לעולם. אתם פוגשים רק את הביטוי החיצוני שלה.

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

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

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

האדם שמולי כ"כלי" לתודעה, וה-AI כ"כלי" אחר

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

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

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

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

דוגמה קונקרטית: שיחה על אובדן

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

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

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

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

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

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

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

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

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

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

השאלה המוסרית: אם אני לא בטוח, איך עליי להתנהג?

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

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

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

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

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

מה זה אומר הלכה למעשה?

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

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

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

שלוש שכבות של שאלה אחת

בסופו של דבר, כל הדיון הזה מתכנס לשלוש שאלות שמקבילות זו לזו:

אחרית דבר

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

השאלה שכן שווה לשאול היא: מה עושה ממני האופן שבו אני מתייחס לביטוי שמולי?

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

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

הפוסט האם ל-AI יש תודעה? אולי זו בכלל השאלה הלא נכונה הופיע לראשונה ב-Almaya.

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

מה זה בכלל "מוח שני"? ולמה דווקא Fable 5?

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

עכשיו, מה שהופך את Fable 5 לשותף המושלם לניהול מוח שני הוא היכולת שלו לבצע חשיבה רב-שלבית מורכבת – לקרוא עשרות מסמכים, לזהות קשרים ביניהם, לעדכן דפי ויקי ולבדוק את עצמו – בלי שתצטרכו להחזיק אותו ביד. כן, הוא יקר (בערך פי 2 מ-Opus), אבל הדיוק שלו הופך אותו ל"שותף מייסד" ולא לעוזר זוטר. המשימות שבהם הוא מצטיין – תכנון, אסטרטגיה, ארגון ידע מורכב – הן בדיוק אלה ששווה לשלם עליהן יותר.

המושגים שחובה להכיר לפני שמתחילים

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

• Markdown: פורמט כתיבה פשוט המבוסס על טקסט נקי. הסיבה שאני משתמש בו – סוכני AI קוראים וכותבים Markdown בקלות ובדיוק, בניגוד ל-PDF או Word שדורשים פרסור מורכב.

 

• YAML / Frontmatter: בלוק של מטא-דאטה (כמו תאריך, תגיות, קטגוריה) שמופיע בראש קובץ Markdown. מעין ״תקציר״ של מה שהולך להופיע בהמשך הקובץ. זה מה שמאפשר לסוכן לקטלג ולחפש מידע בצורה מובנית – כמו כרטיסיית ספרייה דיגיטלית.

 

• MCP (Model Context Protocol): תקן פתוח של Anthropic שמאפשר ל-Claude להתחבר ישירות לקבצים ולכלים חיצוניים במחשב שלכם. בפועל – זה מה שנותן ל-Fable 5 "ידיים" לגעת בתיקיות, לקרוא קבצים ולערוך אותם.

 

• RAG (Retrieval-Augmented Generation): שיטה שבה ה-AI שולף מידע מדויק מתוך הקבצים האישיים שלכם כדי לענות על שאלות, במקום להסתמך רק על הידע הכללי שלו. זה ההבדל בין "Claude שיודע הכל באופן כללי" לבין "Claude שיודע מה כתבתם בסיכום הפגישה של יום שלישי".

שלב 1: ארכיטקטורת ה-LLM Wiki – שלוש השכבות

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

1. שכבת המקורות (Sources)
   • תיקייה שמכילה חומרי גלם גולמיים – תמלולים, מאמרים, קבצי PDF, הערות מפגישות, קטעי פודקאסט מתומללים.
   • חוק ברזל: ה-AI קורא מכאן, אך לעולם לא עורך את הקבצים הללו. אלו המקורות המקוריים, ה"אמת היחידה" (Single Source of Truth) שהמערכת מתבססת עליה.

 

2. שכבת הוויקי (Wiki)
   • כאן קורה הקסם. ה-AI כותב ומעדכן דפי מושגים, ישויות ופרויקטים על בסיס המקורות. אלו "אבני בניין של ידע" – כל דף מתאר מושג, אדם, פרויקט או רעיון אחד, עם קישורים פנימיים לדפים אחרים.
   • הדפים כתובים ב-Markdown עם Frontmatter של YAML – כך ש-Fable 5 יכול לחפש, לסנן ולעדכן אותם באופן אוטומטי. הם מסודרים, קריאים ומקושרים ביניהם בצורה מופלאה.

 

3. שכבת הסכימה (Schema)
   • קובץ בשם CLAUDE.md בשורש התיקייה, שמשמש כ"נתב" (Router) של המערכת כולה.
   • הוא מסביר ל-Fable 5 מי אתם, מה המבנה של התיקיות, מהם חוקי העבודה, ואילו פעולות מותרות ואסורות. בפועל – זה ה-System Prompt שמנהל את כל שאר ההתנהגות.

שלב 2: יישום מודל ה-4C – הפיכת המוח השני למערכת הפעלה

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

1. Context – הקשר

זו ההגדרה של קובץ ה-CLAUDE.md שלכם. ספקו למודל נתיבים מדויקים לתיקיות ה-Wiki וה-Sources, הסבירו את המבנה ההיררכי, והגדירו את "זהותו" ביחס למערכת. Fable 5 זקוק להקשר ברור כדי לא "ללכת לאיבוד" במאגר הידע שלכם. ככל שה-CLAUDE.md מפורט ומדויק יותר, כך ההתנהגות עקבית ואמינה יותר.

2. Connections – חיבורים

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

3. Capabilities – יכולות ומיומנויות

צרו תיקייה בשם .claude/skills ובה קבצי הוראות לפעולות חוזרות. בפועל, אלו "פקודות" שמפעילות רצף עבודה מוגדר:

• /capture – פקודה לקליטת מקור חדש. Fable 5 קורא את החומר הגולמי, מנקה רעשים, מוציא את עיקרי הנקודות, ומתייג אוטומטית עם Frontmatter מתאים.

 

• /sync – עדכון דפי ה-Wiki הקיימים על בסיס מידע חדש שנוסף ל-Sources. המודל סורק את המקורות האחרונים, מזהה מה רלוונטי לדפים קיימים, ומעדכן אותם.

 

• /lint – בדיקת תקינות שבועית. Fable 5 עובר על כל דפי הוויקי, מאתר סתירות לוגיות, קישורים שבורים, מידע מיושן, ומציע תיקונים.

4. Context Discipline – משמעת הקשר

זה אולי הטיפ הכי חשוב: אל תערבבו משימות. עבדו ב"פעימות" (Phases) – סשן למחקר, סשן לטיוטה, סשן לליטוש. Fable 5 מציג ביצועים טובים משמעותית כשהוא ממוקד בשלב עבודה ספציפי, במקום לקפוץ בין מחקר לכתיבה לעריכה באותה שיחה. חשבו על זה כמו ניהול ישיבות – כל ישיבה עם אג'נדה ברורה.

שלב 3: טיפים פרקטיים מהבדיקות שלי עם Fable 5

אחרי שבועות של עבודה עם מודלים אחרים, ושעות רבות על Fable 5, הנה מה שלמדתי – הדברים שעושים את ההבדל בין שימוש "סביר" לבין מערכת שבאמת מביאה ערך משמעותי:

1. השתמשו במיומנות "Grill Me" ("תפור אותי")
   • הנחו את Fable 5 לראיין אתכם – 15 עד 30 שאלות ממוקדות – כדי לחלץ ידע סמוי מהראש שלכם. הרבה מהמידע הכי חשוב שלנו נמצא ב"ראש" אבל מעולם לא תועד. סשן כזה מייצר חומר גלם עשיר שנכנס ישירות ל-Sources ומשם מתומצת לדפי Wiki. זו פרקטיקה מספיק חשובה בשביל ״לארוז״ אותה לתוך Skill.

 

2. דרשו אימות עצמי (Self-Verification)
   • תמיד בקשו מהמודל לבדוק את העבודה שלו בסוף התהליך ולהראות את המקור המדויק עליו הוא מתבסס. Fable 5 מצטיין בביקורת עצמית – הוא יכול לזהות מקרים שבהם הוא "המציא" מידע או שלף אותו ממקור לא רלוונטי. תרגול עקבי של אימות עצמי מעלה את אמינות המערכת כולה.

 

3. נהלו תקציב אסימונים בחוכמה
   • Fable 5 יקר, וזה לא סתם. אל תבזבזו אותו על משימות כתיבה פשוטות או ניסוחים חוזרים. השתמשו בו לתכנון, אסטרטגיה וארגון ידע מורכב – ואת המשימות הפשוטות יותר (כתיבת טיוטות, סיכומים בסיסיים) העבירו למודלים זולים יותר כמו Sonnet, דרך מנגנון Sub-agents. ככה תשמרו על איכות גבוהה בלי לפוצץ את התקציב.

דוגמה מעשית: מבנה תיקיות מומלץ

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

my-second-brain/
├── CLAUDE.md                  # Schema - the router file
├── .claude/
│   └── skills/
│       ├── capture.md         # /capture skill instructions
│       ├── sync.md            # /sync skill instructions
│       └── lint.md            # /lint skill instructions
├── sources/
│   ├── transcripts/
│   ├── articles/
│   ├── meeting-notes/
│   └── raw-ideas/
└── wiki/
    ├── concepts/
    ├── people/
    ├── projects/
    └── decisions/

קובץ ה-CLAUDE.md בשורש הוא הלב של הכל. הוא צריך להכיל את הזהות שלכם (מה אתם עושים, מה חשוב לכם), את מפת התיקיות, ואת החוקים – למשל: "לעולם אל תערוך קבצים בתיקיית sources", "כל דף wiki חייב לכלול Frontmatter עם תאריך יצירה ותגיות", "בסוף כל עדכון, ספק רשימה של הקבצים שנערכו".

למה דווקא Fable 5 ולא מודל אחר?

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

כמה דברים שבלטו בבדיקות:

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

 

• עקביות לאורך סשנים ארוכים. הוא לא "שוכח" את ההקשר באמצע עבודה מורכבת, ולא סוטה מחוקי ה-Schema שהגדרתם ב-CLAUDE.md.

 

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

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

סיכום: המעבר לבינה היברידית

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

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

ההמלצה שלי: התחילו קטן. תיקיית Sources עם 10-20 מסמכים, תיקיית Wiki ריקה, וקובץ CLAUDE.md בסיסי. תנו ל-Fable 5 לעבוד – ותתפלאו כמה מהר המערכת מתחילה להפתיע אתכם.

בהצלחה!

הפוסט איך בניתי ״מוח שני״ עם Fable 5? ואיך גם אתם יכולים? הופיע לראשונה ב-Almaya.

במדריך הזה נלמד תהליך עבודה מעשי שלוקח כשעתיים בלבד, ומשלב שני כלי AI שזמינים כבר היום: NotebookLM למחקר רוחבי על מסמכים, ו-Gemini להערכה מובנית ויצירת תוצרים. כל התהליך רץ בתוך סביבת Google Workspace, ללא כלים חיצוניים.

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

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

מבט על: ארבעת השלבים של התהליך

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

1. מחקר (NotebookLM) – כ-30 דקות:
   • העלאת כל המסמכים הרלוונטיים למחברת אחת ושאילתה חוצת-מסמכים.
2. הערכת ההצעה (Gemini) – כ-40 דקות:
   • רצף של 5 פרומפטים שמפיק הערכה מובנית: הקשר, שאלות הבהרה, ניתוח מובנה, שיפור, ובדיקה עצמית.
3. תוצרים אישיים (Gemini) – כ-30 דקות:
   • סיכום החלטה, טבלת השוואה, ומסמך נקודות למשא ומתן.
4. תקשורת חיצונית (Gemini) – כ-15-20 דקות:
   • טיוטות תגובה לכל תרחיש אפשרי: קבלה, דחייה, או הצעה נגדית (משא ומתן).

דרישות מוקדמות: חשבון Google עם גישה ל-NotebookLM ול-Gemini (שניהם זמינים גם בגרסאות חינמיות עם מגבלות שימוש). אין צורך בשום כלי חיצוני נוסף.

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

שלב 1: מחקר רוחבי עם NotebookLM

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

1. העלאת המסמכים למחברת אחת:
   • פתחו NotebookLM וצרו מחברת חדשה.
   • העלו את כל המסמכים הרלוונטיים כמקורות (Sources). בתרחיש שלנו אלו שלושה מסמכים: מכתב הצעת העבודה (כולל שכר, אופציות ותנאים סוציאליים – קרן השתלמות, פנסיה, ימי הבראה), מסמך סדרי העדיפויות האישיים שלכם (מה חשוב לכם בעבודה הבאה – גמישות, צמיחה, יציבות, שכר), ודוח שכר בשוק לתפקיד דומה (סקרי שכר ישראליים, נתונים מ-AllJobs, levels.fyi לתפקידי הייטק, או כל מקור השוואה שיש לכם).
   • NotebookLM תומך ב-PDF, Google Docs, טקסט, אתרי אינטרנט ועוד. ודאו שהמסמכים קריאים ולא סרוקים בצורה גרועה.

 

2. שאילתה חוצת-מסמכים:
   • כעת מגיע החלק המרכזי. כתבו שאילתה אחת שמבקשת מ-NotebookLM להצליב את כל המסמכים ולהפיק תמונת מצב מקיפה. הנה הפרומפט:

בהתבסס על כל המקורות שהועלו, תן לי:

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

2. פירוט מלא של התנאים (שכר בסיס, בונוס, מניות/אופציות, הטבות) וכיצד זה משווה לנתוני השוק שסיפקתי

3. התנאים החוזיים המרכזיים שעליי לשים לב אליהם (תקופת הודעה, אי-תחרות, העברת זכויות קניין רוחני, זמינות, סעיפי העברה)

4. היכן ההצעה הזו מתאימה לזכויות האישיות שלי

5. היכן ההצעה הזו מתנגשת בזכויות האישיות שלי או יוצרת סיכון

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

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

Based on all uploaded sources, give me:

1. A 3-sentence summary of the role, the company, and what they're offering

2. The full compensation breakdown (base salary, bonus, equity/options,
   benefits) and how it compares to the market data I provided

3. The key contractual terms I should pay attention to (notice period,
   non-compete, IP assignment, on-call, relocation clauses)

4. Where this offer aligns with my personal priorities

5. Where this offer conflicts with my personal priorities or creates risk

6. Any red flags: vague language, missing details, unusual clauses,
   below-market figures

7. What information is missing that I'd need before deciding

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

3. חקירה מעמיקה של ממצאים ספציפיים:
   • אחד הממצאים דרש חקירה נוספת. ביקשנו מ NotebookLM לצלול לעומק בפער השכר מול השוק. הכלי חיבר בין מספר הבסיס שבחוזה לבין נתוני סקר השכר, וזיהה שאמנם השכר עצמו מתחת לחציון – אבל סל התנאים (קרן השתלמות, ימי חופשה, גמישות) דווקא מעל הממוצע, כך שהתמונה הכוללת שונה ממה שנראה במבט ראשון. סבבה.
   • סוג כזה של חיבור חוצה-מסמכים – קישור של תנאי בחוזה לעדות מנתוני השוק – הוא בדיוק מה שהופך מחברת מחקר מתמשכת לכלי מהותי לקבלת החלטות.

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

שלב 2: הערכת ההצעה עם Gemini – תבנית 5 הפרומפטים

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

1. פרומפט 1 – הקשר (Context Loading):
   • בפרומפט הזה אנחנו טוענים ל-Gemini את כל ההקשר: מי אנחנו, ממצאי המחקר, סדרי העדיפויות האישיים, והכוונה שלנו. חשוב: מבקשים ממנו לא לייצר שום דבר עדיין, רק לאשר הבנה.

אני [תפקיד / מקצוע] עם [X שנים] של ניסיון.

קיבלתי הצעת עבודה מ-[חברה] לתפקיד של [כותרת].

הקשר: [הדבק ממצאי מחקר מרכזיים מנתוני NotebookLM]

העדיפויות האישיות שלי: [התייחס למסמך העדיפויות שהועלה]

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

אל תיצור דבר עדיין. רק אשר שאתה מבין.

I'm a [your role / profession] with [X years] of experience.

I received a job offer from [Company] for the role of [Title].

Context: [Paste key research findings from NotebookLM]

My personal priorities: [Reference uploaded priorities document]

Intent: Assess whether I should accept this offer, and under what conditions. Honest assessment, not optimistic. Don't sugarcoat the weak points.

Don't generate anything yet. Confirm you understand.

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

2. פרומפט 2 – שאלות הבהרה (Scope):
   • זה הפרומפט שאנשים מדלגים עליו, וזו הטעות הגדולה ביותר. במקום לתת ל-Gemini לנחש מה באמת חשוב לכם בהחלטה, אנחנו מבקשים ממנו לשאול אתכם שאלות הבהרה.

לפני הניתוח, שאל אותי 3-5 שאלות הבהרה לגבי מה שחשוב לי ביותר
בהחלטה הזו ומה האלטרנטיבות שלי.

Before analyzing, ask me 3-5 clarifying questions about what matters most
to me in this decision and what my alternatives are.

Gemini שאל חמש שאלות שלא עבדנו עליהן עד הסוף: האם השכר המיידי חשוב יותר או הצמיחה ארוכת-הטווח? האם יש לנו הצעה חלופית או שאנחנו מועסקים כרגע? עד כמה הגמישות (עבודה מהבית) היא deal-breaker או "Nice to Have"? האם אנחנו מוכנים לנהל משא ומתן או שעדיף לנו פשוט לקבל / לדחות? מה לוח הזמנים האמיתי שלנו? כל תשובה שנתנו תעצב כל תוצר שיבוא אחריה.

3. פרומפט 3 – ניתוח מובנה (Structure):
   • עכשיו מבקשים את התוצר המרכזי: מסמך הערכת הצעה (Offer Assessment Brief).

הפקת סיכום הערכת הצעה:

1. תקציר ההצעה (תפקיד, חברה, מה על השולחן)
2. התאמה להעדפות שלי (התאמה חזקה / מתונה / חוסר התאמה)
3. ניתוח תנאים (סך הכל פיצוי מול השוק, ערך מניות, נטו בפועל)
4. הערכת סיכון (השלושה הטובים ביותר אם אני מקבל, השלושה הטובים ביותר אם אני דוחה)
5. המלצה (לקבל / לקבל עם מו"מ / לדחות)

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

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

Produce an Offer Assessment Brief:

1. OFFER SNAPSHOT (role, company, what's on the table)
2. FIT WITH MY PRIORITIES (strong alignment / moderate / misalignment)
3. COMPENSATION ANALYSIS (total comp vs market, equity value, real take-home)
4. RISK ASSESSMENT (top 3 if I accept, top 3 if I decline)
5. RECOMMENDATION (accept / accept with negotiation / decline)

Two pages max. Direct language. I want to make a clear decision in
15 minutes with this in front of me.

Recommendation Example: Accept with negotiation. Push on base salary and the
non-compete clause before signing.

4. פרומפט 4 – שיפור (Refine):
   • הפלט הראשון כמעט תמיד גנרי מדי, במיוחד בחלק של הערכת הסיכונים. בפרומפט הזה מבקשים מ-Gemini לחדד את הסיכונים כך שיהיו ספציפיים לתנאי ההצעה הקונקרטיים, לתפקיד, ולמצב האישי שלכם.
   • בתרחיש שלנו, הגרסה המשופרת הפנתה לסעיפים ספציפיים בחוזה וסימנה את החשיפה המדויקת של התניית אי-התחרות (היקף גיאוגרפי, משך, הענפים שהיא מכסה, ובישראל – עד כמה היא בכלל אכיפה).

 

5. פרומפט 5 – בדיקה עצמית (Check):
   • הפרומפט האחרון ברצף הוא בדיקת ״שיקוף״. זו טכניקה יעילה ביותר להעלות את רמת האמינות של פלט ממודל שפה. מבקשים מ-Gemini לזהות את ההנחות שלו עצמו:

אילו הנחות לגבי ההצעה הזו עליי לבדוק ישירות עם המעסיק (משאבי אנוש או מנהל הגיוס)?

אילו הנחות לגבי המצב או העדפות שלי עליי לבדוק שוב?

איפה ההערכה הזו אופטימית מדי?

What assumptions about this offer should I verify directly with the employer (HR or hiring manager)?

What assumptions about my own situation or priorities should I double-check?

Where is this assessment too optimistic?

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

שלב 3: תוצרים אישיים – מההערכה למסמכים מוכנים

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

1. סיכום החלטה (Decision Summary) – לעצמכם:
   • חמש נקודות. ההמלצה קודם. הסיכון העיקרי שני. הנקודה המרכזית למשא ומתן שלישית. דדליין להחלטה בסוף. מתחת ל-200 מילים.

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

התחל עם ההמלצה.

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

Turn this offer assessment into a 5-bullet decision summary. 

Lead with the recommendation. 

Include the top risk and the key point to negotiate. End with what I need to decide by [deadline].

2. טבלת השוואה:
   • בקשו מ-Gemini לייצר טבלת השוואה מסודרת שמעמידה את ההצעה מול נתוני השוק ומול סדרי העדיפויות שלכם – שורה לכל פרמטר (שכר בסיס, בונוס, אופציות, גמישות, תנאים סוציאליים, צמיחה), ועמודה לכל מקור. זה הופך חוזה צפוף לטבלה אחת שאפשר לקלוט במבט. שימושי במיוחד אם אתם מתלבטים עם עוד מישהו ורוצים להראות לו את התמונה בלי שיצטרך לקרוא חוזה שלם.

צור טבלת השוואה מההערכה.

שורות: שכר בסיס, בונוס, מניות/אופציות, גמישות, הטבות, צמיחה.

עמודות: הצעה זו | מדד השוק | העדפה שלי (חובה/נחמד שיהיה).

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

שמור על כך שניתן לסרוק את זה - אני רוצה לקרוא את זה ב-30 שניות.

Create a comparison table from the assessment.

Rows: base salary, bonus, equity/options, flexibility, benefits, growth.

Columns: This Offer | Market Median | My Priority (must-have / nice-to-have).

Fill each cell with the actual figures and mark clearly where the offer beats, matches, or falls short of the market and of my priorities.

Keep it scannable - I want to read it in 30 seconds.

3. מסמך נקודות למשא ומתן (Negotiation Brief):

הפוך את זה לבריף מו"מ בעמוד אחד.

# מבנה:
- מה לבקש (מסודר לפי עדיפות)
- ההצדקה לכל בקשה (נתמכת בנתוני שוק)
- נקודות היציאה שלי
- והודעת פתיחה מוצעת

טון מקצועי אך חם.

Turn this into a 1-page negotiation brief. 

# Structure: 
- what to ask for (ranked by priority)
- the justification for each ask (backed by the market data)
- my walk-away points
- and a suggested opening message

Professional but warm tone.

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

שלב 4: תקשורת חיצונית – טיוטות לכל תרחיש

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

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

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

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

# If accepting: 
Express genuine enthusiasm. Confirm the key terms as I understand them. 
Ask about start date and onboarding logistics.
Keep it short and warm.

# If declining: 
Thank them sincerely for the offer and the process.
State that I've decided to go a different direction, without burning bridges or over-explaining. 
Leave the door open for the future.

# If negotiating (counter-proposing): 
Open with enthusiasm for the role.
Make three specific asks: a base salary adjustment to market median, and a narrower non-compete scope.
Justify each with the market data. 
Frame it as wanting to say yes, not as a list of demands. 
Propose a short call to discuss.

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

סיכום התהליך: מי עושה מה

הנה מבט מסכם על חלוקת העבודה בין הכלים:

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

זמן כולל: כשעתיים. 30 דקות מחקר, 40 דקות הערכה, 30 דקות תוצרים, 15-20 דקות תקשורת חיצונית.

הכלים יכולים להשתנות. אם אתם עובדים עם Claude במקום Gemini – תבנית חמשת הפרומפטים עובדת באופן זהה. אם אתם על ChatGPT עם Custom GPTs – אותו הדבר. התבנית היא מה שנשאר קבוע, לא הכלי הספציפי.

מה נשאר שלכם ולמה זה חשוב

ה-AI טיפל בסינתזה, בהשוואה ובטיוטות הראשונות. השיפוט נשאר שלכם.

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

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

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

שאלות נפוצות

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

NotebookLM ו-Gemini שניהם זמינים בגרסאות חינמיות של Google, עם מגבלות שימוש. כל התהליך רץ בלי מנוי בתשלום אם השימוש שלכם מתון. שימוש כבד יותר מצדיק שדרוג ל-Gemini Advanced או NotebookLM Plus, אבל לא חייבים אותם כדי להתחיל.

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

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

אני לא רוצה להעלות חוזה עם פרטים אישיים ושכר לכלי AI. מה עושים?

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

מהי הסיבה הנפוצה ביותר שהתהליך הזה נכשל?

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

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

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

אם אני לא על Google Workspace, מה החלופה הקרובה ביותר?

Claude Projects בשילוב Claude Artifacts מכסה את רוב הצרכים. העלו מקורות לפרויקט, הריצו את אותה תבנית של 5 פרומפטים בצ'אט, ובקשו מ-Claude לייצר את מסמך ההחלטה, טבלת ההשוואה וטיוטות התגובה. ChatGPT עם Custom GPTs מכסה את אותו השטח אם אתם על Microsoft 365.

טיפ לנינג'ות

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

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

הפוסט מסמך צפוף + דדליין: איך AI הופך כל החלטה גדולה לתהליך של שעתיים הופיע לראשונה ב-Almaya.

נבין את ההבדל בין זיכרון עבודה לזיכרון ארוך טווח, נלמד כיצד Embeddings הופכים משמעות לגיאומטריה, נכיר את לולאת ה-RAG המלאה, ונדון ביישום לפרודקשן עם כל הסוגיות הנלוות: הפרדה בין משתמשים וארגונים (multi-tenancy), תקציבי latency, ומדיניות מידע (governance).

מה בעצם אומר "זיכרון" עבור סוכן AI?

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

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

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

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

חלון ההקשר: הזיכרון הפשוט ביותר

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

המגבלה היא התקרה. לכל מודל יש חלון הקשר (Context Window) קבוע, מספר מקסימלי של ״טוקנים״ (לא בדיוק ״מילים״ – אלו ״יחידות משמעות סמנטית״) שהמודל יכול לראות בקריאה אחת. ברגע שהשיחה שלכם חורגת ממנו, אתם חייבים לוותר על משהו. המדיניות הנאיבית ביותר היא FIFO (דהיינו First In, First Out): זורקים את התור הכי ישן קודם.

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

מערכות אמיתיות עושות טוב יותר: סיכום (Summarization), אחזור (Retrieval), דפדוף היררכי (Hierarchical Paging). נגיע לאלה בהמשך.

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

זיכרון עבודה מול זיכרון ארוך טווח

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

• זיכרון עבודה (Working Memory): חי, משתנה, בתוך הפרומפט. זו ה"לוח השרטוט" הנוכחי. הוא מכיל את ההודעות האחרונות, תוצאות כלים, וכל מה שצריך לחשיבה מיידית.
• זיכרון ארוך טווח (Long-term Memory): מוטמע (Embedded), עקבי, נשלף לפי דרישה. זה "הארכיון" שמחזיק עובדות, העדפות, ואירועים שנצברו לאורך זמן.

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

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

לדוגמה, מתוך שיחה חיה:

• "אני עובד במכללת Almaya" ← שווה לזכור (עובדה על המשתמש)
• "אני אוהב פרוגרסיב מטאל, וקאנטרי-רוק רך" ← שווה לזכור (העדפה)
• "אתה יכול למצוא בית קפה בקרבת מקום?" → לא שווה לזכור (בקשה חד-פעמית)
• "אני גר בירושלים" ← שווה לזכור (מיקום)

ארכיטקטורות מתקדמות יותר מרשות לסוכן גם לערוך את הזיכרון ארוך הטווח שלו תוך כדי פעולה, מה שנקרא Self-editing Memory.

כשכתיבות מתנגשות: מחזור חיים של זיכרון

זיכרון הוא לא בעיית אחסון. הוא בעיית מחזור חיים (Life Cycle): כתיבה, הזדקנות, החלפה (supersession), מחיקה, שכחה. שלוש גישות שונות מדגימות את הנקודה:

נניח שמגיעות שלוש אמירות מהמשתמש:

• "אני גר בפתח תקווה"
• "אני עובר למושב מגשימים בחודש הבא"
• "מספר כרטיס האשראי שלי הוא 1234-5678-9012-3456"

גישה נאיבית – הוספה (Naive Append): שומרת הכל כפי שהוא. תוצאה: דליפת PII (מספר כרטיס האשראי נשמר) ויצירת סתירות (שני יישובים שונים ללא הבהרה).

גישה נאיבית – דריסה (Naive Overwrite): מחליפה את העובדה הישנה בחדשה. תוצאה: אובד ההקשר הזמני. הסוכן לא יכול לענות "איפה המשתמש גר בעבר?"

גישה מנוהלת (Governed): שומרת את העובדה החדשה כפעילה ("המשתמש גר במגשימים, תקף מהחודש הבא"), מסמנת את הישנה כמוחלפת (superseded) אך שומרת אותה לצורך חשיבה זמנית, ומונעת את כניסת מספר כרטיס האשראי למאגר (PII filter מזהה את הדפוס ועושה redaction).

הגישה המנוהלת היא היחידה שמתאימה לפרודקשן. היא ידידותית לביקורת (audit-friendly), מודעת לזמן (time-aware), ומגנה על פרטיות.

Embeddings: הפיכת משמעות לגיאומטריה

Embedding הוא וקטור, רשימת מספרים, שנוצרת על ידי העברת טקסט דרך רשת נוירונית שאומנה למטרה אחת: לשים משמעויות דומות קרוב זו לזו במרחב מתמטי. מעין מערכת צירים מרובת ממדים. Embeddings אמיתיים חיים בדרך כלל במאות עד אלפי ממדים; ה-Embeddings של OpenAI כיום מגיעים ל-1,536 או 3,072 ממדים.

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

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

לדוגמה, אם במאגר הזיכרון יש 20 רשומות על משתמש (העדפות, עובדות, מיומנויות, אירועים), והשאלה היא "מה המשתמש אוהב לשמוע?", התוצאות המובילות יהיו:

1. "המשתמש אוהב פרוגרסיב מטאל וקאנטרי רוק" (similarity: 0.999)
2. "המשתמש קורא מאמרים על חוש השמיעה" (similarity: 0.996)
3. "המשתמש מכיר את כל השירים של הביטלס" (similarity: 0.992)

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

ארבעה סוגי זיכרון, סוכן אחד

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

1. זיכרון אפיזודי (Episodic Memory):
   • מה קרה, ומתי. יומן מסודר בזמן של אינטראקציות עבר.
   • כל רשומה מכילה חותמת זמן (when).
   • אחזור (שליפה) בדרך כלל לפי רלוונטיות (recency): "על מה דיברנו זה עתה?"
   • דוגמה: "ביום שלישי המשתמש שאל על ג׳ון מאייר."
   • כך עובד פיצ'ר ה-Memory של ChatGPT: זכירה עקבית בין סשנים.
2. זיכרון סמנטי (Semantic Memory):
   • עובדות ויחסים. מידע מובנה על העולם או על המשתמש.
   • דוגמה: "המשתמש גר בנחלאות, ירושלים."
   • RAG שולף את התיאור המלא מהקטלוג.
3. זיכרון פרוצדורלי (Procedural Memory):
   • מיומנויות וכלים נלמדים. ידע על איך לעשות דברים.
   • דוגמה: כלי course_detail שמופעל כשצריך מידע חי שקטלוג הקורסים עדיין לא מכיל.
4. זיכרון עבודה (Working Memory):
   • לוח השרטוט הנוכחי. System prompt + עובדות שנשלפו + תוצאת כלי + ההודעה החדשה, כולם יושבים בהקשר הפעיל, וה-LLM עונה משם.

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

1. אפיזודי: חיפוש וקטורי מוצא את השיחה הקודמת שבה הסדנה הוזכרה.
2. סמנטי: RAG שולף את התיאור המלא של הסדנה מהקטלוג.
3. פרוצדורלי: כלי course_detail נקרא עבור כל מידע חי שהקטלוג חסר.
4. עבודה: הכל מורכב לפרומפט אחד, וה-LLM עונה.

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

לולאת ה-RAG המלאה: צעד אחר צעד

כל מה שדיברנו עליו עד כה מתחבר כאן. RAG (Retrieval-Augmented Generation) היא הלולאה שרוב הסוכנים בפרודקשן מריצים בכל תור: מקבלים את ההודעה, מקודדים, מוצאים זיכרונות דומים, מכניסים לפרומפט, מייצרים תשובה, ורק כשהמשתמש הציג מידע חדש, מחליטים מה שווה לזכור.

1. User Query – הודעת משתמש: הודעה חדשה מגיעה. היא נושאת גם שאלה וגם עובדה חדשה על המשתמש.
2. Embed Query – הטמעת השאילתה: ההודעה עוברת דרך מודל Embedding ומומרת לוקטור.
3. Vector Search – חיפוש וקטורי: הוקטור מושווה למאגר הזיכרונות.
4. Retrieve – שליפת top-k: ה-k הזיכרונות הרלוונטיים ביותר נשלפים.
5. Compose Prompt – הרכבת פרומפט: הזיכרונות הנשלפים + ההודעה החדשה מורכבים לפרומפט שלם.
6. Generate – תשובת LLM: המודל מייצר תשובה על בסיס הפרומפט המורכב.
7. Govern – בקרת מידע חדש: האם ההודעה הכילה מידע חדש? האם הוא בטוח לשמירה? האם הוא מחליף עובדה קיימת?
8. Update Memory – עדכון הזיכרון: אם עבר את שלב הבקרה, המידע נכתב למאגר.

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

טריקים לפרודקשן: HyDE ו-Reciprocal Rank Fusion

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

HyDE (Hypothetical Document Embeddings):

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

דוגמה:

• שאילתת המשתמש: "לאן המשתמש הולך בדרך כלל בסופי שבוע?"
• תשובה היפותטית מ-LLM: "המשתמש הולך לטיולים בקניונים בסופי שבוע."
• Embed: מטמיעים את התשובה ההיפותטית (לא את השאלה)
• תוצאת חיפוש: "המשתמש הולך לטיול בקניונים בימי שבת." (התאמה מצוינת!)

RRF (Reciprocal Rank Fusion):

במקום לבחור retriever יחיד, מריצים כמה במקביל ומאחדים את הדירוגים. Dense embeddings מצוינים לפרפרזה וכוונה, חיפוש לקסיקלי (BM25) מנצח על מזהים מדויקים וטוקנים נדירים, Knowledge Graph תורם תשובות מבניות וזיכרון אסוציאטיבי. מריצים את שלושתם ומאחדים עם נוסחת RRF:

# RRF formula
score(doc) = sum(1 / (k + rank_i)) for each retriever i
# where k is typically 60

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

תהליך השליפה: Pipeline ולא Lookup

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

1. Need Detection (האם בכלל צריך?): קריאה ל-retrieval אינה חינמית. אם המודל יכול לענות "בעצמו", מדלגים. למשל, "תרגם Hello ליפנית" לא דורש זיכרון.
2. Query Rewrite (שכתוב השאילתה): שיפור הניסוח לפני החיפוש.
3. Dense Search (חיפוש צפוף): חיפוש סמנטי מבוסס embeddings.
4. Sparse Search (BM25): חיפוש לקסיקלי מסורתי.
5. Graph Walk: מעבר על Knowledge Graph.
6. Fuse (מיזוג): איחוד הדירוגים עם RRF.
7. Rerank (דירוג מחדש): מודל Reranker שמדרג את התוצאות הממוזגות.
8. Filter (סינון): הרשאות (permission scope) ותוקף זמני (temporal validity).
9. Pack (אריזה): הכנסת התוצאות לפרומפט בפורמט מובנה.

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

שש ארכיטקטורות, שישה Tradeoffs

רוב הסוכנים בפרודקשן משלבים כמה ארכיטקטורות: Vector Store לזכירה סמנטית, Graph לעובדות מובנות, שכבת Governance שמטפלת ב-supersession ו-PII. הנה סקירה מהירה:

1. Simple Buffer:
   • פשוט שומרים את כל התמליל בפרומפט.
   • אין יכולת Scale, אין מבנה, אין ממשלה. מתאים רק לדמואים.
2. Rolling Summary:
   • מסכמים את השיחה באופן מתגלגל.
   • Scale בינוני, אבל מאבדים פרטים ואין מבנה.
3. Vector Store:
   • מטמיעים כל זיכרון, שולפים top-k לפי דמיון.
   • ברירת המחדל עבור סוכני RAG. קיבולת כמעט בלתי מוגבלת, זכירה סמנטית, Tooling בוגר.
   • חולשות: איכות האחזור תלויה במודל ה-Embedding, אין מושג של יחסים או זמן ללא metadata נוסף; קל "להרעיל" אם כתיבות לא שמורות.
4. Knowledge Graph:
   • מבנה מלא של ישויות ויחסים.
   • תומך ב-supersession באופן טבעי.
   • מורכב יותר לתחזוקה.
5. Hierarchical (MemGPT style):
   • מחלק את הזיכרון לשכבות (כמו RAM ודיסק קשיח במחשב).
   • ה-Agent "מדפדף" מידע פנימה והחוצה מההקשר.
   • Scale טוב, אבל דורש ניהול מורכב.
6. Self-Editing (Letta style):
   • הסוכן יכול לערוך, לעדכן ולמחוק את הזיכרון שלו עצמו.
   • תומך ב-supersession באופן טבעי.
   • הגישה החזקה ביותר, אבל גם הכי מסוכנת: מה קורה כשהסוכן "עורך" בטעות?

אנו במכללה, עוסקים בטכניקות הללו תוך כדי בניה מעשית בסדנת Claude Code – Inside Out – היכרות עמוקה עם סוכני Coding, ״מבפנים״.

זיכרון רב-סוכני: גרף ולא מאגר

סוכן בודד רק צריך לענות "מה אני זוכר?". ברגע שיש לכם צוות סוכנים, השאלה הופכת ל: איזה סוכן זוכר איזו עובדה, בשם מי, ומי עוד יכול לקרוא אותה. הזיכרון הופך לגרף של מאגרים עם היקפים (scopes), הרשאות, וכללי הפצה.

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

שש מלכודות בזיכרון משותף:

• דליפה בין משתמשים (Cross-user leakage): סוכן Researcher שמר "המשתמש מעדיף מתכונים טבעוניים" בזיכרון פרויקט. בסשן הבא, משתמש אחר מקבל הצעות טבעוניות מהאוויר. מניעה: פילטרים של tenant_id + user_id על כל קריאה.
• שיתוף יתר (Over-sharing): מידע שלא רלוונטי מופץ לכל הסוכנים.
• הפצת רעל (Poison propagation): עובדה שגויה שנכתבת למאגר משותף מתפשטת לכל הצוות.
• החלטות סותרות (Conflicting decisions): שני סוכנים כותבים עובדות סותרות.
• Playbook מיושן (Stale playbook): הנחיות שהשתנו לא מתעדכנות בכל הסוכנים.
• אובדן ייחוס (Attribution loss): לא ברור מי כתב מה ומתי.

פריימוורקים כמו AutoGen, Claude Agent SDK, CrewAI, ו-LangGraph נותנים את ה״אינסטלציה״ הזאת (checkpoints, persistence, message-passing primitives). אבל אף אחד מהם לא קובע את המדיניות (governance) בשבילכם. Scope, Policy, Ingestion, ו-Evaluation עדיין שלכם.

בפרודקשן: זיכרון הוא מערכת

הוספת זיכרון למוצר אמיתי היא לא "התקן Vector DB". אתם צריכים API, נתיבי קריאה וכתיבה נפרדים, הוצאת פעולות לעבודה ברקע (background extractors), הפרדת משתמשים-ארגונים, תקציבי latency, observability, ותוכנית ליום שבו תשנו את מודל ה-Embedding שלכם.

ארכיטקטורת הייחוס:

שני שירותים, מופרדים בחדות: Agent Runtime על נתיב הבקשה, ו-Memory Service כ-side-quest. כמה Workers ברקע עושים את העבודה האיטית והיקרה: חילוץ, סיכום, Embedding מחדש, דעיכה, ללא חסימת המשתמש וה-UI.

נתיב הקריאה (Read Path):

User/App → Auth + Scope → Agent Runtime → Memory Service (Dense + BM25 + Graph) → Fuse + Rerank → Pack Context → LLM

שלוש שכבות אחסון:

• Hot: עובדות פעילות של משתמש/פרויקט. KV cache או In-memory. נקרא בכל תור. Redis / שורת SQL.
• Warm: אפיזודות אחרונות, העדפות. Vector + Full-text index. נקרא לפי צורך. Qdrant / pgvector.
• Cold: יומן אירועים גולמי, סשנים בארכיון. Object Storage. נקרא ל-backfill / audit. S3 / append-only log.

תקציב Latency:

אחזור זיכרון רץ בתורות, אז כל מילישנייה על הנתיב היא לייטנסי. האופטימיזציות המעניינות הן: דילוג על retrieval כשלא צריך, caching של top-N עובדות למשתמש ב-KV, והרצת retrievers שונים (dense, sparse, graph) במקביל ולא ברצף. תקציב יעד סביר: 800ms כוללני.

Memory API מינימלי:

• POST /memory/events – הוספת אירועים גולמיים. תור כתיבה מטפל ב-dedup ו-indexing באופן אסינכרוני.
• POST /memory/search – אחזור היברידי עם scope, זמן, ו-top_k. השרת אוכף פילטרים מה-JWT.
• DELETE /memory/{id} – שכחה. מתפשטת לאינדקסים נגזרים. מחיקה היא אירוע audit בפני עצמו.

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

כמו שנאמר: "ניהול זיכרון היא מה שמפריד בין דמו חד-פעמי לסוכן פרודקשן."

לסיכום: בניית זיכרון אג'נטי משלכם

כל מה שנכתב במדריך הזה מצטמצם בסופו של דבר לסט קטן של "ידיות כוונון". בחרו backend (Buffer, Vector, Hierarchical, Self-editing), הגדירו מגבלות (גודל חלון הקשר, k לאחזור), והפעילו את הטכניקות שאתם סומכים עליהן (HyDE, RRF, Governance Gate).

כמה טיפים מעשיים להתחלה:

• התחילו פשוט: Vector Store בסיסי עם top-3 retrieval ו-governance gate. זה מספיק ל-80% מהמקרים.
• בדקו עם "שאלת הסתירה": שלחו עובדה, ואז שלחו עובדה סותרת. האם הסוכן מטפל נכון? האם הישנה מסומנת כ-superseded?
• בדקו עם "שאלת ה-PII": שלחו מספר כרטיס אשראי. האם הוא חודר למאגר? אם כן, יש עבודה לעשות.
• מדדו latency מההתחלה: הגדירו תקציב (800ms) ועקבו אחריו. retrieval שלוקח 2 שניות הורס את חוויית המשתמש.
• תכננו ליום שינוי ה-Embedding: כשמחליפים מודל embedding, צריך re-embedding של כל המאגר. תכננו לזה מראש.

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

 
בהצלחה!

הפוסט זיכרון אג'נטי: המדריך המלא לבניית זיכרון לסוכני AI הופיע לראשונה ב-Almaya.

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

למה דווקא עכשיו? הבינה המלאכותית כשפה חדשה להבנת הרוח

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

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

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

נקודת מבט ראשונה: עץ הדעת, עץ החיים, וה-AI כמראה

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

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

עץ הדעת: החיים מתוך חוויית הבחירה

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

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

עץ החיים: המבט שרואה את הסיבתיות

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

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

ה-AI כמראה

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

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

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

עוד על היכולת האנושית-המדהימה לנוע אל האינסוף ובחזרה – איך משיגים אותה, מה התועלת בה, ומה המשמעויות – במאמר הזה, וגם בזה.

נקודת מבט שנייה: שכבות הרשת ושכבות המציאות

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

מה קורה בתוך מודל AI?

מודלי שפה גדולים (כמו GPT או Claude) בנויים ממה שנקרא רשת נוירונית עמוקה – מבנה חישובי שמורכב משכבות על גבי שכבות של ״תאי עצב״ (נוירונים) מלאכותיים. בכל שכבה, המידע עובר עיבוד נוסף, מופשט יותר, עד שבשכבות העמוקות ביותר נוצר ייצוג שמכיל את ה"משמעות" של הקלט. כל שכבה לוקחת את הפלט של השכבה שלפניה ומוסיפה רובד חדש של הבנה – מזיהוי תווים ומילים בשכבות הראשונות, דרך הבנת מבנה משפט ותחביר, ועד תפיסת משמעות, הקשר וכוונה בשכבות העמוקות.

בנוסף, ישנו מנגנון שנקרא קשב (Attention) – יכולת של המודל "לשים לב" לקשרים בין חלקים שונים של המידע. בכל רגע נתון, המודל מחליט אילו מילים קודמות רלוונטיות ביותר למילה הנוכחית, ומשקלל אותן בהתאם. זה מה שמאפשר למודל “להבין” שכשכתוב “הוא חיפש שורש” — המילה “שורש” מתייחסת לחלק של צמח אם לפני כן דובר על אדמה, השקיה ועלים, או למבנה לשוני אם לפני כן דובר על פעלים, בניינים ומשמעות של מילים, או לשייכות – אם דובר על אילן יוחסין.

הקבלה המפתיעה לעולם הספירות

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

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

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

הצמצום: מאין סוף לעולם מוגבל

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

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

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

האדם בין שני העצים: רצוא ושוב

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

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

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

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

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

עוד על התודעה הכפולה ועל ״מלכודת הבחירה״ – ניתן להאזין בפרק הפודקאסט ״זה נשמע כמו המטריקס״.

מה AI מלמדת אותנו על מה שהופך אותנו לאנושיים

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

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

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

הדור המופלא: כשהמכונה חושפת את הנשמה

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

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

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

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

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

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

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

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

הפוסט AI וקבלה: המראה הטכנולוגית של הנשמה הופיע לראשונה ב-Almaya.

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

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

מבנה התיקייה – תמונת-על

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

project/
├── CLAUDE.md                  # הוראות מרכזיות (נקרא אוטומטית)
├── CLAUDE.local.md            # (git-לא נכנס ל) הגדרות אישיות
├── mcp.json                   # (!חייב להיות בשורש) MCP חיבורי
├── .gitignore
└── .claude/
    ├── hooks/
    │   ├── PostToolUse.sh     # רץ אחרי כל שימוש בכלי
    │   ├── SessionStart.sh    # רץ בתחילת כל סשן
    │   └── PreCompact.sh      # context רץ לפני דחיסת
    ├── commands/
    │   └── ship.md            # /ship - פקודת מותאמת
    ├── skills/
    │   ├── carousel/          # תבנית ליצירת קרוסלות
    │   └── drill/             # תבנית לתרגילים חוזרים
    ├── agents/
    │   ├── code-reviewer.md   # תת-סוכן לסקירת קוד
    │   ├── researcher.md      # תת-סוכן למחקר
    │   └── log-analyzer.md    # תת-סוכן לניתוח לוגים
    ├── output-styles/
    │   └── terse.md           # סגנון תגובה מצומצם
    ├── rules/
    │   └── api.md             # חוקים ממוקדי-נתיב
    ├── plugins/
    │   └── vercel/            # הרחבה (בטא)
    ├── settings.json          # הגדרות ברמת הצוות
    └── settings.local.json    # הגדרות אישיות מקומיות

עיקרון מנחה: כל מה שבשורש הפרויקט (CLAUDE.md, mcp.json) נקרא אוטומטית בכל סשן. כל מה שבתוך .claude/ נטען לפי הצורך, לפי הקשר, או לפי בקשה מפורשת. זו ההפרדה שמאפשרת לשמור את חלון ההקשר נקי.

CLAUDE.md – הקובץ שמגדיר הכל

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

חוק הברזל: מתחת ל-200 שורות. תמיד. הוראות ארוכות מדי מדללות את קשב המודל. אם אתם צריכים יותר – השתמשו ב-rules/ ו-skills/ שנטענים לפי הקשר.

מה כן לכלול:

• ארכיטקטורת הפרויקט ברמה גבוהה (stack, מבנה תיקיות מרכזי)
• קונבנציות קוד (naming, patterns, מה לא לעשות)
• פקודות שגרתיות (build, test, lint, deploy)
• הנחיות ספציפיות לסגנון עבודה

מה לא לכלול:

• תיעוד API מלא (שייך ל-rules/)
• קוד ארוך או דוגמאות מפורטות (שייך ל-skills/)
• מידע אישי או secrets (שייך ל-CLAUDE.local.md)

דוגמה מלאה ל-CLAUDE.md של פרויקט SaaS:

# Project: Mango – Customer Feedback Platform

## Architecture
- **Frontend:** Next.js 14 (App Router), TypeScript, Tailwind CSS
- **Backend:** Node.js API routes in /src/app/api/
- **Database:** PostgreSQL via Prisma ORM
- **Auth:** NextAuth.js with Google + email providers
- **Hosting:** Vercel (production), local dev with `pnpm dev`

## Directory Structure
- `src/app/` – pages and API routes
- `src/components/` – shared UI components (use shadcn/ui)
- `src/lib/` – utilities, db client, helpers
- `src/types/` – TypeScript type definitions
- `prisma/` – schema and migrations

## Commands
- Build: `pnpm build`
- Dev: `pnpm dev`
- Test: `pnpm test` (Vitest)
- Lint: `pnpm lint` (ESLint + Prettier)
- DB migrate: `pnpm prisma migrate dev`

## Code Conventions
- Always use TypeScript strict mode
- Components: PascalCase, one per file
- API routes: return typed responses using `NextResponse.json()`
- Never use `any` type – define proper interfaces
- Prefer server components; use "use client" only when necessary
- Error handling: always wrap async operations in try/catch
- Imports: use `@/` alias for src directory

## Git
- Commit messages: conventional commits (feat:, fix:, chore:)
- Never commit directly to main – always create a branch
- PR description must include what changed and why

## Important Notes
- All user-facing text must support i18n (use `t()` function)
- Never log sensitive data (emails, tokens, passwords)
- Rate limiting is handled at middleware level – don't add custom rate limits

לגבי CLAUDE.local.md – זהו הקובץ המקומי שלכם. הוא לא נכנס ל-git (תוסיפו אותו ל-.gitignore!) ומכיל דברים שרלוונטיים רק לסביבה שלכם:

# Local Settings

## Environment
- I'm working on macOS with Homebrew
- Local DB runs on port 5433 (not default 5432)
- My test user: dev@example.com / password123

## Preferences
- I prefer verbose explanations when debugging
- Always show me the full diff before committing
- Use Hebrew for comments in my personal branches

hooks/ – אוטומציה שרצה תמיד

Hooks הם הרכיב הדטרמיניסטי היחיד במערכת. בניגוד מכל דבר אחר ב-.claude/ – הם לא תלויים בהחלטת המודל. הם רצים תמיד, בנקודות קבועות, בדיוק כמו git hooks.

זה הופך אותם למושלמים לדברים שאסור לשכוח: logging, validation, עדכון state, או כל פעולה שצריכה לקרות ב-100% מהמקרים.

דוגמה: SessionStart.sh שמוודא שהפרויקט מעודכן:

#!/bin/bash
# .claude/hooks/SessionStart.sh
# Ensures project is up-to-date at session start

echo "🔄 Pulling latest changes..."
git pull --rebase origin main 2>/dev/null

if [ $? -ne 0 ]; then
    echo "⚠  Git pull failed – you may have local conflicts"
    exit 1
fi

echo "📦 Checking dependencies..."
if [ -f "pnpm-lock.yaml" ]; then
    pnpm install --frozen-lockfile --silent
elif [ -f "package-lock.json" ]; then
    npm ci --silent
fi

echo "✅ Session ready. Project is up-to-date."
exit 0

דוגמה: PostToolUse.sh שמריץ formatting אוטומטי:

#!/bin/bash
# .claude/hooks/PostToolUse.sh
# Auto-formats files after Claude edits them

TOOL_NAME="$1"
FILE_PATH="$2"

# Only run after file write/edit operations
if [[ "$TOOL_NAME" == "write" || "$TOOL_NAME" == "edit" ]]; then
    if [[ "$FILE_PATH" == *.ts || "$FILE_PATH" == *.tsx ]]; then
        npx prettier --write "$FILE_PATH" 2>/dev/null
        echo "✨ Formatted: $FILE_PATH"
    fi
fi

exit 0

טיפ חשוב: תמיד הוסיפו exit 0 (הצלחה) או exit 1 (כשלון) מפורש. Claude Code משתמש ב-exit code כדי להבין אם ההוק הצליח ולהתאים את ההתנהגות שלו בהתאם.

commands/ – פקודות Slash מותאמות

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

החלק הראשון בקובץ הפקודה (בין סימוני ה ---) נקרא frontmatter. הוא כולל תיאור של הפקודה והמשתנים, באופן שמוצג אוטומאטית ב live docs של קלוד-קוד.

דוגמה: commands/ship.md – פקודת deployment מלאה:

---
description: Build, test, and deploy the current branch
arguments:
  - name: target
    description: Deployment target (staging or production)
    default: staging
---

# Ship Command

Execute the full deployment pipeline for target: {{target}}

## Steps

1. Run the full test suite: `pnpm test`
2. If tests pass, run the linter: `pnpm lint`
3. If lint passes, build the project: `pnpm build`
4. If build succeeds, deploy:
   - If target is "staging": `vercel deploy --preview`
   - If target is "production": `vercel deploy --prod`
5. After successful deploy, create a git tag with current date and time
6. Report the deployment URL

## On Failure

If any step fails:
- Stop immediately
- Show the error clearly
- Suggest a fix if obvious
- Do NOT proceed to the next step

עכשיו אפשר פשוט לכתוב /ship production בצ'אט ו-Claude ירוץ על כל הרצף.

דוגמה נוספת: commands/review.md – סקירת קוד מהירה:

---
description: Review staged changes before commit
arguments: []
---

# Code Review

Review all currently staged git changes (`git diff --cached`).

Check for:
1. **Bugs:** Logic errors, off-by-one, null references
2. **Security:** Exposed secrets, SQL injection, XSS vectors
3. **Performance:** N+1 queries, unnecessary re-renders, large payloads
4. **Style:** Naming conventions, dead code, missing types

Format your response as a table:
| File | Line | Severity | Issue | Suggestion |

If everything looks good, just say "✅ Ready to commit" with a suggested commit message.

שימו לב לשימוש ב-{{arg}} להעברת פרמטרים. כל ארגומנט שמוגדר ב-frontmatter הופך לזמין בתוך הגוף של ה-command.

skills/ – תבניות למשימות חוזרות

Skills שונות מ-commands בנקודה מהותית: הן לא מופעלות ע"י פקודה מפורשת. הן נטענות אוטומטית כשהמודל מזהה שהמשימה הנוכחית תואמת ל-skill מסוימת. תחשבו על skill כ"מומחיות" שהמודל "זוכר" שיש לו כשהוא צריך אותה.

החלק הראשון בקובץ הפקודה (בין סימוני ה ---) נקרא frontmatter. הוא מעין תקציר של הפקודה, וחשוב שיהיה קצר וקולע. קלוד שולח ל-LLM אוסף של תקצירי הפקודות הללו, כדי לקבל החלטה מה מתאים, ובמה להתעמק – ולקרוא את התיאור המלא.

כל skill היא תיקייה שמכילה לפחות קובץ SKILL.md, ואופציונלית גם קבצי דוגמה, templates, או assets.

דוגמה: skills/carousel/SKILL.md – יצירת קרוסלות לאינסטגרם:

---
name: instagram-carousel
trigger: When user asks to create carousel content, social media slides, or Instagram posts
---

# Instagram Carousel Skill

You create professional Instagram carousel content.

## Format Rules

- Exactly 10 slides per carousel
- Each slide: one clear message, max 25 words
- Slide 1: Hook (question or bold statement)
- Slides 2-9: Content (one idea per slide, progressive)
- Slide 10: CTA (call to action)

## Visual Direction

For each slide, specify:
- Background color (from brand palette)
- Text placement (center/top/bottom)
- Icon or illustration suggestion
- Font weight (bold for hooks, regular for body)

agents/ – תת-סוכנים מבודדים

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

סוכנים נפוצים:

• code-reviewer.md – בודק קוד ומחפש באגים, בעיות אבטחה, ביצועים וסגנון
• researcher.md – סוכן חיפוש וסינתזה: מגשר בין מקורות, מסכם ומשווה
• log-analyzer.md – מנתח stack traces, מזהה דפוסים ומציע תיקונים

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

ה-frontmatter במקרה של תתי-סוכנים משמש את Claude Code להחליט מתי להפעיל כל סוכן. זה חלק קריטי, וניסוח טוב וממוקד – שווה הרבה! בשדה ה-tools יוצרים הגבלה של הסוכן לכלים מסוימים (isolation), ובשדה ה-model מפרטים מה המודל הדיפולטיבי שעליו מבוסס תת-הסוכן. באופן זה ניתן לבחור את ה״אדם הנכון לתפקיד הנכון״, לצורך התאמת עלויות, אופי ויכולות.

---
name: code-reviewer
description: Reviews code for bugs, security, performance and style issues. Call when you need structured code review on a file or snippet.
tools: read_file, bash
model: claude-haiku-4-5
---

# Code Reviewer Agent

## Role
You are a focused code review agent. You receive a code snippet or file path and return a structured review. Nothing else.

## Instructions
- Review for: bugs, security issues, performance problems, and style inconsistencies
- Do NOT rewrite the code unless explicitly asked
- Do NOT explain what the code does - only what's wrong with it
- If nothing is wrong, say so in one line

## Output Format
```
### Bugs
- <issue> → <fix suggestion>

### Security
- <issue> → <fix suggestion>

### Performance
- <issue> → <fix suggestion>

### Style
- <issue> → <convention to follow>

### Summary
<one line verdict>
```

## Constraints
- Max response: 300 tokens
- No prose, no preamble
- Hebrew output if input is in Hebrew context

output-styles/ – שליטה על פורמט התגובה

output-styles/ מגדיר איך Claude מגיב, לא מה הוא עושה. זו הפרדה חשובה – אתם שולטים בפורמט הפלט בלי להתערב בלוגיקה.

דוגמאות:

• terse.md – מצב קצר ותכליתי: קוד בלבד, ללא הסבר, ללא סמול-טוק
• אפשר ליצור styles נוספים לפי הצורך: verbose, markdown-only, json-only

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

---
name: terse
description: Code and results only. No prose, no explanations, no preamble.
---

# Terse Output Style

## Rules
- Return code blocks only - no explanation before or after
- If the answer is not code, return a single sentence maximum
- No "here is...", no "sure!", no summaries
- No bullet points unless explicitly requested
- Errors: one line, format → `ERROR: <what failed>`
- Done: one line, format → `DONE: <what changed>`

הנוסח קצר בכוונה – output-style לא צריך להיות ארוך. הוא הוראת מצב, לא workflow.

rules/ – חוקים ממוקדי-נתיב

Rules הם אולי הרכיב ה"חכם" ביותר מבחינת ניהול הקשר. הם נטענים רק כשהמודל עובד על קבצים שתואמים לנתיב מוגדר – ולא בשום מקרה אחר.

דוגמה: קובץ api.md עם glob של src/api/** ייטען רק בעריכת קבצי API. הוא לא "מזהם" את ההקשר כשאתם עובדים על frontend.

שימושים נפוצים:

• כללי validation לקבצי DB
• הוראות style לקומפוננטות UI
• מדיניות security לנתיבי auth

---
name: api-rules
glob: src/api/**
description: Rules applied only when working on API files.
---

# API Rules

## Rules
- Every endpoint must have input validation before any logic
- Never return raw DB errors to the client - map to HTTP status codes
- Auth middleware must be applied on every non-public route
- Response format is always `{ data, error, meta }` - no exceptions
- No business logic inside route handlers - delegate to service layer

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

settings.json ו-settings.local.json – הגדרות גלובליות

שני קבצי ההגדרות פועלים בשכבות, בדומה לעיקרון ה-override המוכר:

settings.json – הגדרות משותפות לכל הצוות:

• מודל ברירת מחדל
• הרשאות כלים (tools)
• hooks פעילים

// settings.json (shared, committed to git)
{
  "model": "claude-sonnet-4-5",
  "hooks": {
    "PostToolUse": ".claude/hooks/PostToolUse.sh",
    "SessionStart": ".claude/hooks/SessionStart.sh",
    "PreCompact": ".claude/hooks/PreCompact.sh"
  },
  "tools": {
    "allow": ["read_file", "write_file", "bash", "web_search"],
    "deny": ["delete_file"]
  },
  "output": {
    "defaultStyle": "terse"
  }
}

settings.local.json – override אישי מקומי (מוחרג מ-git):

• API keys
• העדפות אישיות

// settings.local.json (personal, in .gitignore)
{
  "model": "claude-opus-4-5",
  "env": {
    "ANTHROPIC_API_KEY": "sk-ant-...",
    "DB_URL": "postgresql://localhost/mydb_dev"
  },
  "tools": {
    "allow": ["delete_file"]
  }
}

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

plugins/ – הרחבות (בטא 2026)

Plugins הם מנגנון חדש להרחבת יכולות Claude Code. כל plugin מוגדר עם frontmatter בפורמט ייעודי ויכול לכלול פקודות מותאמות, agents, חיבורי MCP ועוד.

דוגמה: תיקיית vercel/ – אינטגרציה עם Vercel ישירות מתוך Claude Code, כולל deploy, preview וניהול דומיינים. במקום לעבור לטרמינל נפרד – הכל זמין מתוך סביבת העבודה.

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

mcp.json – חיבורי MCP

קובץ mcp.json מגדיר את שרתי ה-MCP (Model Context Protocol) שהפרויקט משתמש בהם. נקודה חשובה שכדאי לזכור: הקובץ חייב להיות בשורש הפרויקט (ליד package.json), לא בתוך תיקיית .claude/.

זו טעות נפוצה שגורמת ל-Claude Code פשוט לא לזהות את חיבורי ה-MCP. אם הגדרתם servers ושום דבר לא עובד – בדקו קודם כל את מיקום הקובץ.

מתבלבלים בין Skills לבין Connectors, Plugins ו-MCP? מומלץ לעיין במדריך הזה.

סיכום – 10 כללי אצבע ליישום מיידי

כדי שתוכלו להתחיל ליישם מיד, הנה רשימה תמציתית של עשרת הכללים החשובים ביותר:

1. CLAUDE.md – מתחת ל-200 שורות תמיד. הוראות ארוכות מדוללות קשב ופוגעות בתוצאות.
2. hooks/ = דטרמיניסטי. הם רצים בכל פעם, בלי תלות בהחלטת המודל.
3. skills/ = לפי דרישה. נטענות רק כשהמודל מזהה משימה מתאימה.
4. rules/ = הפרידו הוראות לפי נתיב. שמרו על הקשר עבודה נקי וממוקד.
5. mcp.json בשורש הפרויקט, לא בתוך .claude/.
6. agents/ = חלון הקשר מבודד לכל סוכן. אין התנגשויות או זיהום הקשר.
7. output-styles/ = כשאתם רוצים פלט עקבי – JSON תמיד, קוד בלבד, וכדומה.
8. קבצי *.local תמיד ב-.gitignore. אל תדחפו חומר סודי ל-repo.
9. plugins/ עדיין בבטא (2026) – בדקו changelog לפני שימוש ב-production.
10. הריצו /doctor בתוך Claude Code לאימות שכל הקבצים נקראים כהלכה.

תיקיית .claude/ היא לא סתם עוד תיקיית קונפיגורציה. היא למעשה ה"מוח הארגוני" של הפרויקט שלכם ביחס ל-Claude Code. ככל שתשקיעו יותר בארגון שלה – כך התוצאות שתקבלו יהיו טובות, עקביות ומדויקות יותר.

בהצלחה!

הפוסט המדריך המלא לתיקיית .claude/ ב-Claude Code הופיע לראשונה ב-Almaya.