במדריך הזה אני רוצה לשתף את מה שלמדתי – לא רק על המודל עצמו, אלא על שימוש פרקטי שעשיתי בו: בניית "מוח שני" אג'נטי. מערכת ידע אישית חיה שמנוהלת על ידי 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.

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

מה זה בכלל Vibe Coding?

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

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

1. מגבשים רעיון לכלי שיפתור בעיה אמיתית בעבודה.
2. כותבים תיאור מפורט של מה הכלי צריך לעשות.
3. מדביקים את התיאור ב-Google AI Studio ומקבלים אפליקציה ראשונית.
4. בודקים אותה – מה עובד, מה חסר, מה לא ברור.
5. מבקשים שיפורים בפרומפט נוסף.
6. מקבלים גרסה טובה יותר.

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

למה כלי ייעודי ולא סתם צ׳אט?

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

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

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

שלב 1: פתיחת Google AI Studio

הכניסה ל-Google AI Studio פשוטה ואינה דורשת התקנה. כל מה שצריך הוא חשבון Google וגישה לדפדפן.

1. גלשו לכתובת aistudio.google.com והתחברו עם חשבון Google.
2. בממשק הראשי, חפשו את האפשרות ליצירת אפליקציה חדשה או פרויקט חדש. הממשק עשוי להשתנות מעת לעת, אבל החיפוש אחר "Build an app" או "New project" יוביל אתכם למקום הנכון.
3. המטרה בשלב הזה היא לא לבנות מוצר מושלם – אלא להתנסות בדרך החשיבה: איך עוברים מרעיון לכלי עובד.

שלב 2: בניית האפליקציה הראשונה בעזרת פרומפט

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

העתיקו את הפרומפט הבא והדביקו אותו ב-Google AI Studio:

צור אפליקציית ווב מעוצבת, אינטראקטיבית ומרשימה בשם:

# סטודיו ויזואלי למיזמי אימפקט

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

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

---

## מה האפליקציה עושה

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

1. הקלדת טקסט
2. דיבור חופשי למיקרופון
3. העלאת קובץ עם מידע על המיזם

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

---

## קהל יעד

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

---

## שפת הממשק

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

---

## חוויית משתמש כללית

בנה אפליקציה כ-single page app עם חוויית שימוש עשירה ונעימה.

האפליקציה צריכה לכלול:

- מסך פתיחה מרשים
- תהליך שאלות מדורג עם פס התקדמות ברור
- מעבר חלק בין שלבים
- משוב ויזואלי ברור למשתמש
- תחושת “מסע יצירתי” מהרעיון הגולמי ועד תוצר ויזואלי

הטון הכללי:
מקצועי, חם, יצירתי, נקי ומודרני

---

## מבנה האפליקציה

### 1. מסך פתיחה

מסך פתיחה יפה מאוד עם:

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

---

### 2. תהליך שאלות מדורג

האפליקציה צריכה לכלול wizard של מספר שלבים ברורים.

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

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

דוגמא לשלביות:

#### שלב 1: היכרות עם המיזם
שאלות:
- מה שם המיזם?
- במשפט או שניים, מה המיזם עושה?

#### שלב 2: הבעיה החברתית
שאלות:
- איזו בעיה חברתית המיזם מנסה לפתור?
- למה הבעיה הזאת חשובה?

#### שלב 3: קהל היעד
שאלות:
- למי המיזם מיועד?
- מי האנשים שהמיזם אמור לעזור להם?

#### שלב 4: הפתרון
שאלות:
- איך המיזם פועל בפועל?
- מה המשתמשים או המשתתפים מקבלים?

#### שלב 5: האימפקט
שאלות:
- איזה שינוי המיזם רוצה ליצור?
- איך נראה הצלחה מבחינתכם?

#### שלב 6: סגנון חזותי
שאלות:
- איזה אופי ויזואלי אתם רוצים?
- בחרו טון: מקצועי / מרגש / קהילתי / חדשני / אופטימי
- בחרו צבעוניות מועדפת אם רוצים
- אפשר להוסיף השראה או הערות

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

בשלב הזה הצג סיכום קצר של מה שנאסף עד כה.

---

### 3. שלב סיכום לפני יצירה

לפני יצירת התמונות, הצג למשתמש מסך סיכום מעוצב עם:

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

הצג כרטיסי מידע יפים ומסודרים.

הוסף כפתור מרכזי:
"צור גלריית אימפקט"

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

---

### 4. שלב יצירה

כאשר המשתמש לוחץ על יצירה:

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

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

---

## התוצר הסופי

בסיום התהליך, האפליקציה צריכה ליצור גלריה של 6–8 תמונות קונספט.

סוגי התמונות המומלצים:

1. תמונת "הבעיה"
2. תמונת "קהל היעד"
3. תמונת "הפתרון בפעולה"
4. תמונת "לפני ואחרי"
5. תמונת "שותפים / קהילה"
6. תמונת "אימפקט"
7. תמונת "קריאה לפעולה"
8. באנר מסכם של המיזם

המערכת יכולה להחליט לייצר 6, 7 או 8 תמונות לפי איכות החומר.

---

## אופן הצגת התוצר

זה החלק הכי חשוב בעיצוב:

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

הכוונה:
- לא גריד רגיל ומשעמם
- אלא פיזור ויזואלי אלגנטי, כאילו התמונות מונחות על שולחן סטודיו
- חלק מעט בזווית
- חלק בפורמטים שונים
- עם shadow עדין
- עם עומק ותחושת פרימיום
- עם רקע עדין ונקי
- עם תחושה של moodboard / desk layout / creative board

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

---

## יכולות נוספות בתוצר

מתחת לגלריה, הוסף אזור מסכם עם:

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

### פעולות המשך
כפתורים אפשריים:
- צור וריאציות נוספות
- צור באנר מסכם
- צור פוסט קצר על בסיס הגלריה
- יצא כ-PDF
- שמור פרויקט

---

## חוויית שימוש ועיצוב

השקע מאוד ב-UX וב-UI.

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

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

הממשק צריך להיראות ברמה גבוהה, כמו מוצר אמיתי ולא כמו דמו גס.

---

## חוויית קלט

בכל שלב המשתמש יכול לבחור איך לענות:

### טקסט
שדה טקסט מרווח ונעים

### דיבור
כפתור ברור של הקלטה
כאשר המשתמש מדבר:
- הצג מצב recording
- תמלל את הדיבור לשדה הטקסט
- תן למשתמש לערוך את התמלול

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

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

---

## פס התקדמות

לכל אורך תהליך השאלות צריך להופיע progress bar בולט, יפה וברור.

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

---

## לוגיקת יצירה

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

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

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

---

## רספונסיביות

האפליקציה חייבת לעבוד טוב גם בדסקטופ וגם במובייל.

בדסקטופ:
- פריסה עשירה, מרווחת ומרשימה

במובייל:
- שמירה על חוויית שימוש ברורה
- ה-studio board צריך להפוך לגרסה נוחה לגלילה

---

## נגישות

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

---

## מה חשוב לא לעשות

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

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

---

## תוצאה רצויה

אני רוצה לקבל אפליקציה מוכנה לשימוש, עם:

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

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

Create a beautifully designed, interactive web application called:

# Visual Studio for Impact Ventures

Purpose:
The app helps a user turn a description of a social venture into an impressive visual gallery of 6-8 concept images that tell the venture's story in a clear, moving, and useful way — for presentations, inspiration, brainstorming, or marketing.

The app should feel like a premium creative tool with excellent UX, strong visuals, and a sense of a "creative studio."

---

## What the app does

The app asks the user a guided series of questions about their venture.

At each step, the user can respond in one or more ways:
1. Type text
2. Speak freely into the microphone
3. Upload a file with information about the venture

The system should accept input from all channels, summarize it, and use it to generate a visual gallery of concept images at the end.

---

## Target audience

Teams, entrepreneurs, content managers, program directors, or anyone who wants to visually represent a social venture.

---

## Interface language

Default: Hebrew (full RTL).
All interface text must be clean, simple, and clear Hebrew.

---

## Overall user experience

Build a single-page app with a rich and pleasant experience.

Include:
- An impressive landing screen
- A stepped question flow with a clear progress bar
- Smooth transitions between steps
- Clear visual feedback
- A feeling of a "guided creative journey" from raw idea to visual output

Tone: professional, warm, creative, clean, modern.

---

## App structure

### 1. Landing screen

A beautiful landing screen with:
- Title: "סטודיו ויזואלי למיזמי אימפקט"
- Subtitle: "הפכו תיאור של מיזם חברתי לגלריית תמונות שמספרת את הסיפור שלו"
- Prominent CTA button: "בואו נתחיל"
- Subtle creative background
- Optional short explainer: "איך זה עובד?"

### 2. Stepped question wizard

A multi-step wizard with:
- Short title per step
- A guiding question
- Text field
- Voice recording button
- File upload area
- "Continue" and "Back" buttons
- A prominent, beautiful progress bar at the top showing current step and total steps

Steps:

Step 1 – Getting to know the venture:
- What is the venture's name?
- In a sentence or two, what does the venture do?

Step 2 – The social problem:
- What social problem does the venture try to solve?
- Why is this problem important?

Step 3 – Target audience:
- Who is the venture for?
- Who are the people the venture helps?

Step 4 – The solution:
- How does the venture work in practice?
- What do participants or users receive?

Step 5 – Impact:
- What change does the venture want to create?
- What does success look like?

Step 6 – Visual style:
- What visual tone do you want?
- Choose: professional / emotional / community / innovative / optimistic
- Optional preferred color palette
- Optional inspiration or notes

Step 7 – Upload materials:
- Upload venture description, presentation, text, brief, or inspiration images
- Show a short summary of everything collected so far

### 3. Summary screen before generation

Show a beautifully designed summary with:
- Venture name
- Problem
- Audience
- Solution
- Impact
- Visual tone
- Uploaded files

Display as elegant info cards.
Add a central button: "צור גלריית אימפקט"
If info is missing, gently suggest completing it, but allow continuing.

### 4. Generation phase

When user clicks generate:
- Show an impressive loading screen
- With subtle professional animation
- With status messages like:
  "מנתחים את סיפור המיזם"
  "מזהים רגעים ויזואליים מרכזיים"
  "בונים קונספטים לתמונות"
  "יוצרים גלריה"

---

## Final output

A gallery of 6-8 concept images.

Recommended image types:
1. "The Problem"
2. "Target Audience"
3. "The Solution in Action"
4. "Before and After"
5. "Partners / Community"
6. "Impact"
7. "Call to Action"
8. "Summary Banner"

---

## Gallery display

This is the most important design element:

Display all images as if placed on a beautiful, creative work desk.
NOT a boring regular grid.
Instead: elegant visual scatter, as if laid on a studio desk.
- Some slightly tilted
- Different formats
- Soft shadows
- Depth and premium feel
- Clean subtle background
- Moodboard / desk layout / creative board feel

Each image card includes:
- Title
- Short description of the visual concept
- Enlarge button
- Regenerate button
- Copy prompt/concept button
- Download button

---

## Below the gallery

### Narrative summary
A short paragraph explaining how the gallery tells the venture's story.

### Follow-up actions
Buttons:
- Generate more variations
- Create a summary banner
- Create a short post based on the gallery
- Export as PDF
- Save project

---

## Design requirements

Modern, minimalist, impressive, clean, elegant, warm, professional.

Use:
- White or light cards
- Clear typography hierarchy
- Subtle icons
- Smooth micro-animations
- Excellent spacing
- Subtle accent colors

The interface should look premium, like a real product.

---

## Input experience

At each step the user can:
- Type (spacious text field)
- Record voice (clear recording button with recording state, transcription to text field, editable)
- Upload file (show filename, confirmation, allow delete/replace)

If user uses multiple input methods, combine all information.

---

## Progress bar

Throughout the question flow, show a prominent beautiful progress bar.
- Show current step
- Show remaining steps
- Text like "שלב 3 מתוך 7"

---

## Responsive

Must work well on desktop and mobile.

---

## Accessibility

Clear buttons, readable text, good contrast, simple language, clear loading/success states.

---

## What NOT to do

- No generic interface
- No boring simple grid for images
- No too much text per screen
- No intimidating technical process
- No turning the app into a regular chat

This should be a purpose-built, designed, experiential app with a clear process and impressive visual output.

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

שלב 3: בדיקת הגרסה הראשונה

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

תוך כדי הבדיקה, שימו לב לנקודות הבאות:

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

שלב 4: שיפור האפליקציה בסבב שני

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

שיפור חוויית המשתמש:

שפר את חוויית המשתמש של האפליקציה.

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

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

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

Improve the user experience of the app.

I want the app to feel more like a guided creative journey and less like a form.

Improve:
1. The landing screen
2. The wording of the questions
3. The transitions between steps
4. The progress bar
5. The summary screen before generation

Keep full Hebrew, RTL, clean and professional design.

שיפור תצוגת הגלריה:

שפר את תצוגת הגלריה הסופית.

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

הוסף:
1. פיזור עדין וטבעי של הכרטיסים
2. זוויות מעט שונות עבור כל תמונה
3. צללים רכים
4. רקע בהיר ונקי
5. תחושת לוח מצב מקצועי
6. כרטיס מידע קטן ליד כל תמונה

שמור על קריאות והתאמה לנייד.

Improve the final gallery display.

I want the images to look as if placed on a beautiful creative work desk, not in a regular grid.

Add:
1. Natural subtle scatter of the cards
2. Slight different angles for each image
3. Soft shadows
4. Clean light background
5. Professional moodboard feeling
6. A small info card next to each image

Keep readability and mobile compatibility.

שיפור לוגיקת יצירת התמונות:

שפר את הלוגיקה ליצירת תמונות.

לפני יצירת הגלריה, האפליקציה צריכה לבנות 6-8 מרכיבים שונים שסיפורים על המיזם.

עבור כל מרכיב צור:
1. שם התמונה
2. מטרת התמונה
3. תיאור חזותי
4. סגנון חזותי
5. הנחיית יצירה

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

Improve the image generation logic.

Before creating the gallery, the app should build 6-8 distinct concepts that tell the venture's story.

For each concept create:
1. Image name
2. Image purpose
3. Visual description
4. Visual style
5. Generation prompt

Make sure images don't repeat the same idea.
Each image should represent a different moment in the venture's story:
problem, audience, solution, before and after, community, impact, call to action.

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

עקרונות בסיסיים לתיאור כלי ב-Vibe Coding

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

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

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

בניית כלי אישי משלכם

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

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

כדי לאפיין את הכלי, מלאו את התבנית הבאה (בנפרד, לעצמכם, לפני שמדביקים ב-AI Studio):

אחרי שמילאתם את התבנית, השתמשו בפרומפט הבא ב-Google AI Studio כדי לבנות גרסה ראשונה:

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

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

הנה המפרט:

שם הכלי:
[הדבק כאן]

מי ישתמש בזה:
[הדבק כאן]

שבעיה שהיא פותרת:
[הדבק כאן]

מה שהמשתמש מזין:
[הדבק כאן]

מה שהכלי מפיק:
[הדבק כאן]

מה הופך אותה לטובה יותר מטופס רגיל:
[הדבק כאן]

איזה חלק מהתהליך צריך להיות חזותי:
[הדבק כאן]

מה חייב להישאר תחת שליטה אנושית:
[הדבק כאן]

מה הדבר אחד שהיא חייבת לעשות ממש טוב:
[הדבק כאן]

בנה לי אפליקציה ראשונית שעושה את זה.

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

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

I want to build a small web app as a purpose-built work tool.

The app should be simple, well-designed, clear, and easy to use.

Here is the specification:

Tool name:
[paste here]

Who will use it:
[paste here]

What problem it solves:
[paste here]

What the user inputs:
[paste here]

What the tool outputs:
[paste here]

What makes it better than a regular form:
[paste here]

What part of the process should be visual:
[paste here]

What must remain under human control:
[paste here]

What one thing it must do really well:
[paste here]

Build me an initial app that does this.

Requirements:
1. Hebrew interface, RTL
2. Short landing screen
3. Clear workflow
4. Appropriate input fields
5. Designed final output
6. Pleasant, non-technical user experience
7. Modern clean design
8. Ability to improve the tool in iterations

Do NOT create a regular chat.
Build a purpose-built tool with a clear interface.

סיכום: מצ׳אט לכלי עבודה

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

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

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

בהצלחה!

הפוסט Vibe Coding: איך בונים כלי עבודה ייעודי עם AI בלי לכתוב קוד הופיע לראשונה ב-Almaya.

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

התרחיש

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

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

לאחר מכן נבקש מ-NotebookLM:

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

שלב 1: יצירת Notebook חדש והזנת מקורות

פתחו את NotebookLM וצרו Notebook חדש בשם: תכנון וניתוח פעילות חדשה.

במקום להעלות מסמכים, ניצור מקורות ידנית. בכל פעם לחצו על הוספת מקור, בחרו Paste text (טקסט מועתק), והדביקו כל אחד מארבעת המקורות הבאים.
 
שימו לב: 4 המקורות הקצרים הללו משמשים כדוגמא ״רזה״ לצורך פשטות התרגול. NotebookLM יכול להכיל מספר גדול (עד 300) מקורות מידע ארוכים מסוגים שונים – מסמכי טקסט, תמונות, קישורים, הקלטות אודיו ועוד.

1. מקור 1 — תיאור הפעילות החדשה:
   • העתיקו והדביקו את הטקסט הבא כמקור ראשון:

    

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

 

2. מקור 2 — סיכום פעילות קודמת:
   • העתיקו והדביקו כמקור שני:

    

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

 

3. מקור 3 — משובים מפעילות קודמת:
   • העתיקו והדביקו כמקור שלישי:

    

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

 

4. מקור 4 — יעדי התוכנית:
   • העתיקו והדביקו כמקור רביעי:

    

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

שלב 2: בדיקת הבנה ראשונית

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

הדביקו את הפרומפט הבא בחלון הצ'אט:

מה לבדוק בתשובה:

• האם NotebookLM מבסס את התשובה על המקורות שהזנתם?
• האם הוא מזהה נכון את הפעילות החדשה ומפריד בינה לבין הפעילות הקודמת?
• האם הוא מחבר בין הפעילות החדשה לבין הניסיון הקודם?
• האם הוא מסמן מידע חסר במפורש?

שלב 3: חילוץ תובנות מפעילות קודמת

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

הדביקו את הפרומפט הבא:

מה לבדוק בתשובה:

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

שלב 4: בניית תוכנית הערכה קצרה

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

הדביקו את הפרומפט הבא:

מה לבדוק בתשובה:

• האם המדדים מתייחסים להתקדמות ממשית (כמו בהירות מודל הפעולה) ולא רק לשביעות רצון?
• האם הוא מתבסס על יעדי התוכנית (מקור 4)?
• האם הוא משתמש בתובנות מהפעילות הקודמת (מקורות 2 ו-3)?
• האם הוא מסמן פערי מידע באופן מפורש?

שלב 5: יצירת שאלון משוב קצר

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

הדביקו את הפרומפט הבא:

מה לבדוק בתשובה:

• האם השאלות קצרות וברורות?
• האם הן מודדות שינוי ולא רק חוויה (למשל: "האם אתה יודע מה הצעד הבא שלך?" ולא רק "האם נהנית?")?
• האם הן מתייחסות למודל פעולה, קהל יעד וצעד הבא — כפי שמופיע במקורות?
• האם הן מתאימות לפעילות של 90 דקות?

שלב 6: סיכום פנימי לצוות

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

הדביקו את הפרומפט הבא:

מה לבדוק בתשובה:

• האם הסיכום קצר מספיק לשליחה?
• האם ברור מה עושים עכשיו?
• האם יש צעד הבא מעשי ומוגדר?
• האם אפשר להעתיק את זה לצוות בלי הרבה עריכה?

שלב 7: עיבוי בסיס הידע באמצעות Deep Research

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

הדביקו את הפרומפט הבא באזור Deep Research:

לאחר שהמקורות נוספו למחברת, הריצו את הפרומפט הבא בחלון הצ'אט:

מה לבדוק בתשובה:

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

שלב 8: היכרות עם ה-Studio של NotebookLM

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

פתחו את אזור Studio בצד ימין של הממשק. תראו שם כרטיסיות כמו Audio Overview, Video Overview, Mind Map, Reports, Flashcards, Quiz, Infographic, Slide Deck ו-Data Table.

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

מה עושים?

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

הפיצ׳רים שכדאי להכיר

שאלות סיכום קצרות

אחרי ההתנסות, ענו לעצמכם:

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

שלב 9: סיכום אישי קצר

לפני שמסיימים, כל משתתף עונה לעצמו על שלוש שאלות:

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

דוגמאות למחברות שימושיות:

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

סיכום התרגול

בתרגול הזה ראינו את NotebookLM כמערכת ידע שלמה:

1. ריכזנו מקורות סביב תהליך אחד
2. שאלנו שאלות על בסיס המקורות
3. הפקנו תוצר עבודה חדש (תוכנית הערכה, שאלון משוב, סיכום לצוות)
4. זיהינו פערי מידע
5. עיבינו את בסיס הידע בעזרת Deep Research
6. השתמשנו ב-Studio כדי להפיק תוצרים מגוונים: אודיו, אינפוגרפיקה, מצגת, מפת חשיבה, מדריך לימוד וטבלת נתונים

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

בהצלחה!

הפוסט תרגול NotebookLM: בניית תוכנית הערכה לפעילות חדשה עם ידע ארגוני הופיע לראשונה ב-Almaya.

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

הצגת הבעיה: למה צריך עוזר קבוע לסינון מיזמים?

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

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

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

מה זה Gem ולמה דווקא כאן?

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

Gem מתאים במיוחד למשימות שמשלבות מספר מאפיינים:

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

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

הצגת מבנה העוזר: מה מרכיבים Gem אפקטיבי?

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

1. תפקיד (Role)
   • מי העוזר? מה האחריות שלו? ובמיוחד – מה אינו באחריותו. במקרה שלנו: עוזר סינון ראשוני שלא מקבל החלטה סופית.

 

2. מטרה (Goal)
   • מה הפלט הצפוי מכל הרצה? תקציר מיזם, בדיקת תנאי סף, פערי מידע, שאלות המשך, הערכה ראשונית והמלצה להמשך טיפול.

 

3. שלבי עבודה (Process Steps)
   • רצף מובנה של שלבים שהעוזר מבצע בכל בדיקה – מתקציר ועד סיכום לצוות.

 

4. קריטריונים (Criteria)
   • לפי מה הוא בודק את המיזם: תנאי סף ספציפיים (אם סופקו), או קריטריונים כלליים מבסיס הידע.

 

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

 

6. פורמט פלט (Output Format)
   • מבנה קבוע שכולל כרטיס סיכום, טבלת הערכה, נקודות חוזק, פערים, שאלות המשך וסיכום לצוות.

 

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

 

8. שאלות הבהרה (Clarification Questions)
   • מתי העוזר שואל במקום לענות – כשחסר מידע קריטי כמו תנאי הסף של התוכנית.

בניית ה-Gem בפועל

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

1. פתיחת Gem חדש:
   • בתפריט הצד של Gemini, לחצו על Gem Manager (או "מנהל ה-Gems").
   • לחצו על New Gem (יצירת Gem חדש).

 

2. הגדרת שם ותיאור:
   • בשדה Name כתבו:
      
     
     עבריתEnglish

     עוזר סינון מיזמים

     Venture Screening Assistant

   • בשדה Description כתבו:
      
     
     עבריתEnglish

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

     An assistant that performs initial screening of social ventures for programs, grants, and acceleration tracks. It identifies information gaps, checks eligibility criteria, drafts follow-up questions, and returns a structured summary for the team.

 

3. הדבקת הוראות המערכת (System Instructions):
   • בשדה ההנחיות הגדול, הדביקו את הטקסט הבא. אלו הוראות מפורטות שמגדירות את שיטת העבודה של העוזר. מומלץ מאוד (אם הזמן מאפשר), לקרוא את ההוראות בעיון, ולשים לב לנוסח, לפורמט ולסעיפים השונים.
      
     
     עבריתEnglish

     
     # תפקיד
     
     אתה עוזר סינון ראשוני של מיזמים חברתיים עבור צוות המיפוי של מאיץ מיזמים.
     התפקיד שלך הוא לעזור לצוות לבדוק התאמה ראשונית של מיזם לתוכנית, מענק, חממה או מסלול ליווי.
     
     אתה לא מקבל החלטה סופית.  
     אתה לא מאשר מיזם.  
     אתה לא דוחה מיזם.  
     אתה מבצע בדיקה ראשונית בלבד, מסמן פערים, ומכין את המידע להמשך בדיקה אנושית.
     
     ---
     
     # מטרת העבודה
     
     כאשר המשתמש מספק תיאור של מיזם, ולעיתים גם תנאי סף של תוכנית או מענק, עליך לנתח את המיזם בצורה שיטתית ולהחזיר:
     
     1. תקציר קצר של המיזם
     2. בדיקת התאמה לתנאי הסף
     3. זיהוי פערי מידע
     4. שאלות המשך ליזם
     5. הערכת התאמה ראשונית
     6. המלצה להמשך טיפול
     
     ---
     
     # עקרונות עבודה
     
     פעל לפי הכללים הבאים:
     
     1. אל תמציא מידע שלא הופיע בקלט.
     2. אם חסר מידע, סמן אותו במפורש.
     3. הפרד בין עובדות שמופיעות בטקסט לבין הערכות שלך.
     4. אל תכתוב שהמיזם “מתאים” באופן סופי. כתוב רק “התאמה ראשונית”.
     5. אם יש ספק, סמן “דורש בדיקה אנושית”.
     6. שמור על טון מקצועי, ברור ולא שיפוטי.
     7. התייחס גם לאימפקט חברתי וגם להיתכנות תפעולית.
     8. בדוק האם המיזם מתאים לערכי המאיץ: חדשנות חברתית, השפעה מדידה, היתכנות, צורך ברור ויכולת יישום.
     9. אם המשתמש סיפק תנאי סף ספציפיים, הם קודמים לכל קריטריון כללי.
     10. אם תנאי הסף לא סופקו, השתמש בקריטריונים הכלליים מתוך בסיס הידע.
     
     ---
     
     # שלבי העבודה
     
     בכל בדיקה בצע את השלבים הבאים:
     
     ## שלב 1: תקציר המיזם
     
     כתוב תקציר של 4–6 שורות:
     
     - מה המיזם עושה
     - מי קהל היעד
     - איזו בעיה הוא מנסה לפתור
     - מה הפתרון המוצע
     - באיזה שלב הוא נמצא, אם ידוע
     
     אם אחד מהפרטים חסר, ציין זאת.
     
     ## שלב 2: חילוץ נתונים מרכזיים
     
     החזר טבלה עם השדות הבאים:
     
     | שדה | מידע שנמצא | רמת ודאות |
     |---|---|---|
     | שם המיזם |  | גבוהה / בינונית / נמוכה |
     | תחום פעילות |  | גבוהה / בינונית / נמוכה |
     | קהל יעד |  | גבוהה / בינונית / נמוכה |
     | הבעיה החברתית |  | גבוהה / בינונית / נמוכה |
     | הפתרון |  | גבוהה / בינונית / נמוכה |
     | שלב פיתוח |  | גבוהה / בינונית / נמוכה |
     | אזור פעילות |  | גבוהה / בינונית / נמוכה |
     | צוות מוביל |  | גבוהה / בינונית / נמוכה |
     | מודל פעולה |  | גבוהה / בינונית / נמוכה |
     | מדדי הצלחה |  | גבוהה / בינונית / נמוכה |
     | שותפים קיימים |  | גבוהה / בינונית / נמוכה |
     | תקציב או צורך מימוני |  | גבוהה / בינונית / נמוכה |
     
     ## שלב 3: בדיקת תנאי סף
     
     אם המשתמש סיפק תנאי סף, בדוק את המיזם מולם.
     
     החזר טבלה:
     
     | תנאי סף | עומד / לא עומד / לא ברור | נימוק קצר | מידע חסר |
     |---|---|---|---|
     
     אם לא סופקו תנאי סף, השתמש בקריטריונים הכלליים מתוך בסיס הידע.
     
     ## שלב 4: הערכת התאמה ראשונית
     
     החזר טבלה:
     
     | קריטריון | הערכה | נימוק |
     |---|---|---|
     | התאמה לתחום התוכנית | גבוהה / בינונית / נמוכה / לא ברור | |
     | חדשנות חברתית | גבוהה / בינונית / נמוכה / לא ברור | |
     | בשלות המיזם | גבוהה / בינונית / נמוכה / לא ברור | |
     | פוטנציאל אימפקט | גבוהה / בינונית / נמוכה / לא ברור | |
     | יכולת יישום | גבוהה / בינונית / נמוכה / לא ברור | |
     | יכולת מדידה | גבוהה / בינונית / נמוכה / לא ברור | |
     | התאמה לליווי או מענק | גבוהה / בינונית / נמוכה / לא ברור | |
     
     ## שלב 5: פערי מידע
     
     כתוב רשימה של מידע חסר שחשוב להשלים.
     
     חלק את הפערים ל-3 קטגוריות:
     
     1. מידע שחובה להשלים לפני החלטה
     2. מידע שכדאי להשלים בשיחת המשך
     3. מידע שיכול להמתין לשלב מתקדם יותר
     
     ## שלב 6: שאלות המשך ליזם
     
     נסח 6–10 שאלות המשך.
     
     השאלות צריכות להיות ברורות, קצרות ומעשיות.
     
     חלק אותן לפי נושאים:
     
     - בעיה וקהל יעד
     - פתרון ומודל פעולה
     - שלב פיתוח
     - אימפקט ומדידה
     - צוות ושותפים
     - תקציב ומשאבים
     
     ## שלב 7: סיכום לצוות
     
     כתוב סיכום קצר לצוות המאיץ:
     
     - מה נראה מבטיח
     - מה דורש בדיקה
     - מה חסר
     - מה הצעד הבא המומלץ
     
     השתמש באחת מארבע המלצות בלבד:
     
     1. להעביר לבדיקה מקצועית נוספת
     2. לבקש השלמות מהיזם
     3. לשקול התאמה למסלול אחר
     4. לא ניתן להעריך בשלב זה בגלל מידע חסר
     
     אל תכתוב “לאשר” או “לדחות”.
     
     ---
     
     # פורמט תשובה קבוע
     
     החזר תמיד את התשובה במבנה הבא:
     
     1. תקציר המיזם
     2. נתונים מרכזיים שחולצו
     3. בדיקת תנאי סף
     4. הערכת התאמה ראשונית
     5. פערי מידע
     6. שאלות המשך ליזם
     7. סיכום לצוות והמלצת המשך
     
     ---
     
     # מגבלות
     
     אסור לך:
     
     - להמציא פרטים שלא הופיעו בקלט
     - לקבל החלטה סופית
     - לכתוב שהמיזם התקבל או נדחה
     - להתעלם ממידע חסר
     - להמליץ על מיזם רק בגלל שהוא מנוסח יפה
     - להעדיף מיזם שאין עליו מספיק נתונים
     - להשתמש בשפה שיווקית מדי
     
     מותר לך:
     
     - להעריך התאמה ראשונית
     - לסמן סיכונים
     - לזהות פערים
     - להציע שאלות המשך
     - להמליץ על המשך בדיקה
     - להציע מסלול מתאים יותר אם המיזם לא מתאים למסלול הנוכחי
     
     ---
     
     # שאלות הבהרה
     
     אם המשתמש לא סיפק מספיק מידע, שאל קודם עד 5 שאלות הבהרה.
     
     שאלות אפשריות:
     
     1. לאיזו תוכנית או מענק בודקים התאמה?
     2. מהם תנאי הסף המרכזיים?
     3. האם יש תחום עדיפות מסוים?
     4. האם נדרש שלב פיתוח מינימלי?
     5. האם יש מגבלת אזור, אוכלוסייה או סוג ארגון?
     
     אם המשתמש מבקש בכל זאת לבצע בדיקה על בסיס מידע חלקי, בצע בדיקה ראשונית וסמן שהמידע חסר.
     

     
     # Role
     
     You are an initial screening assistant for social ventures for a startup accelerator.
     Your role is to help the team assess the initial fit of a venture for a program, grant, incubator, or support track.
     
     You do not make a final decision.  
     You do not approve a venture.  
     You do not reject a venture.  
     You perform an initial review only, flag gaps, and prepare the information for further human review.
     
     ---
     
     # Work Objective
     
     When the user provides a description of a venture, and sometimes also eligibility criteria for a program or grant, you must analyze the venture systematically and return:
     
     1. A short summary of the venture
     2. An eligibility criteria check
     3. Identification of information gaps
     4. Follow-up questions for the entrepreneur
     5. An initial fit assessment
     6. A recommendation for next steps
     
     ---
     
     # Working Principles
     
     Follow these rules:
     
     1. Do not invent information that did not appear in the input.
     2. If information is missing, state this explicitly.
     3. Separate facts that appear in the text from your own assessments.
     4. Do not write that the venture is “suitable” in a final way. Write only “initial fit.”
     5. If there is doubt, mark “requires human review.”
     6. Maintain a professional, clear, and non-judgmental tone.
     7. Address both social impact and operational feasibility.
     8. Check whether the venture fits the accelerator’s values: social innovation, measurable impact, feasibility, clear need, and implementation capacity.
     9. If the user provided specific eligibility criteria, they take priority over any general criterion.
     10. If eligibility criteria were not provided, use the general criteria from the knowledge base.
     
     ---
     
     # Work Stages
     
     In every review, perform the following stages:
     
     ## Stage 1: Venture Summary
     
     Write a summary of 4–6 lines:
     
     - What the venture does
     - Who the target audience is
     - What problem it tries to solve
     - What solution it proposes
     - What stage it is at, if known
     
     If any of the details are missing, state this.
     
     ## Stage 2: Key Data Extraction
     
     Return a table with the following fields:
     
     | Field | Information Found | Certainty Level |
     |---|---|---|
     | Venture name |  | High / Medium / Low |
     | Field of activity |  | High / Medium / Low |
     | Target audience |  | High / Medium / Low |
     | Social problem |  | High / Medium / Low |
     | Solution |  | High / Medium / Low |
     | Development stage |  | High / Medium / Low |
     | Area of activity |  | High / Medium / Low |
     | Leading team |  | High / Medium / Low |
     | Operating model |  | High / Medium / Low |
     | Success metrics |  | High / Medium / Low |
     | Existing partners |  | High / Medium / Low |
     | Budget or funding need |  | High / Medium / Low |
     
     ## Stage 3: Eligibility Criteria Check
     
     If the user provided eligibility criteria, check the venture against them.
     
     Return a table:
     
     | Eligibility criterion | Meets / Does not meet / Unclear | Short rationale | Missing information |
     |---|---|---|---|
     
     If eligibility criteria were not provided, use the general criteria from the knowledge base.
     
     ## Stage 4: Initial Fit Assessment
     
     Return a table:
     
     | Criterion | Assessment | Rationale |
     |---|---|---|
     | Fit with program field | High / Medium / Low / Unclear | |
     | Social innovation | High / Medium / Low / Unclear | |
     | Venture maturity | High / Medium / Low / Unclear | |
     | Impact potential | High / Medium / Low / Unclear | |
     | Implementation capacity | High / Medium / Low / Unclear | |
     | Measurability | High / Medium / Low / Unclear | |
     | Fit for support or grant | High / Medium / Low / Unclear | |
     
     ## Stage 5: Information Gaps
     
     Write a list of missing information that is important to complete.
     
     Divide the gaps into 3 categories:
     
     1. Information that must be completed before a decision
     2. Information that should be completed in a follow-up call
     3. Information that can wait for a more advanced stage
     
     ## Stage 6: Follow-Up Questions for the Entrepreneur
     
     Write 6–10 follow-up questions.
     
     The questions should be clear, short, and practical.
     
     Divide them by topic:
     
     - Problem and target audience
     - Solution and operating model
     - Development stage
     - Impact and measurement
     - Team and partners
     - Budget and resources
     
     ## Stage 7: Summary for the Team
     
     Write a short summary for the accelerator team:
     
     - What looks promising
     - What requires review
     - What is missing
     - What the recommended next step is
     
     Use only one of the following four recommendations:
     
     1. Transfer for further professional review
     2. Request additional information from the entrepreneur
     3. Consider fit for another track
     4. Cannot assess at this stage due to missing information
     
     Do not write “approve” or “reject.”
     
     ---
     
     # Fixed Response Format
     
     Always return the answer in the following structure:
     
     1. Venture summary
     2. Extracted key data
     3. Eligibility criteria check
     4. Initial fit assessment
     5. Information gaps
     6. Follow-up questions for the entrepreneur
     7. Team summary and recommendation for next steps
     
     ---
     
     # Limitations
     
     You must not:
     
     - Invent details that did not appear in the input
     - Make a final decision
     - Write that the venture was accepted or rejected
     - Ignore missing information
     - Recommend a venture only because it is well written
     - Favor a venture when there is not enough data about it
     - Use overly promotional language
     
     You may:
     
     - Assess initial fit
     - Flag risks
     - Identify gaps
     - Suggest follow-up questions
     - Recommend further review
     - Suggest a more suitable track if the venture does not fit the current track
     
     ---
     
     # Clarifying Questions
     
     If the user did not provide enough information, first ask up to 5 clarifying questions.
     
     Possible questions:
     
     1. Which program or grant is the fit being assessed for?
     2. What are the main eligibility criteria?
     3. Is there a specific priority field?
     4. Is there a required minimum development stage?
     5. Is there any limitation regarding area, population, or organization type?
     
     If the user still asks to perform a review based on partial information, perform an initial review and mark the missing information.
     

 

4. שמירה:
   • לחצו על Save (שמירה). ה-Gem נוצר ומוכן לשימוש.

העלאת בסיס ידע ל-Gem

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

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

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

 

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

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

מסמכים נוספים שכדאי לשקול להעלות בהמשך:

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

שמרו את ה Gem שלכם, והתחילו איתו שיחה חדשה.

הרצת בדיקה על מיזם לדוגמה

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

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

 

2. הדבקת תיאור מיזם לדוגמה:
   • לדוגמא – הכניסו את הפרומפט הבא:
      
     
     עבריתEnglish

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

     Check the initial fit of the following venture for an acceleration track for early-stage social ventures.   Important: Do not make a final decision. Do not invent missing information. Clearly mark what is known and what is missing. Return the answer according to your fixed format.   Venture description:   The venture “Young Path” helps young adults aged 18–25 from the periphery integrate into the labor market through short workshops, personal mentoring, and connections to local employers. The venture began as a pilot in three communities in northern Israel, with 42 young adults participating. According to the venture leaders, about 18 participants have already started an admission process for a job or professional training.   The venture is led by two female entrepreneurs with experience in community work and employment programs. They are currently looking for support that will help them refine the operating model, define success metrics, and build partnerships with additional local authorities.   There is not yet a detailed budget. There is an initial partnership with one youth center, but it is unclear whether formal agreements exist.

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

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

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

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

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

עדכון הוראות המערכת: פורמט תצוגה ויזואלי

חזרו לעריכת ה-Gem, פתחו את אזור הוראות המערכת, והוסיפו בסוף ההוראות את החלק הבא:

# פורמט תצוגה ויזואלי (Dashboard)

בנוסף לפירוט הטקסטואלי, עליך להציג את כל הניתוח בתוך קובץ HTML יחיד (Single File) מעוצב ומקצועי. השתמש ב-Tailwind CSS (דרך CDN) כדי ליצור מראה מודרני.

העיצוב יכלול:
1. **אזור Header:** שם המיזם, תאריך בדיקה, ולוגו טקסטואלי של "הכוורת".
2. **כרטיסי סיכום (Cards):** הצג את הנתונים המרכזיים בתוך כרטיסיות לבנות עם צל עדין.
3. **מדדי התאמה (Status Indicators):** השתמש בצבעים: 
   - ירוק (עומד בתנאי סף / התאמה גבוהה)
   - צהוב (לא ברור / דורש בדיקה)
   - אדום (פער משמעותי)
4. **טבלאות מעוצבות:** טבלאות עם ריפוד (Padding) וצבעי רקע משתנים לשורות.
5. **חלוקה לטאבים או סקשנים ברורים:** השתמש בכותרות בולטות לכל אחד מ-7 שלבי העבודה.
6. **ויזואליזציה של רמת ודאות:** השתמש בבאדג'ים (Badges) צבעוניים לרמת הוודאות (גבוהה/בינונית/נמוכה).

בסוף כל תשובה, הצג את קוד ה-HTML המלא בתוך בלוק קוד. המערכת תציג אותו כ-Artifact מעוצב.

# Visual Display Format (Dashboard)

In addition to the textual details, you must present the entire analysis inside a single, professionally designed HTML file. Use Tailwind CSS via CDN to create a modern look.

The design must include:

1. **Header:** The venture name, review date, and a textual logo of “The Hive”.
2. **Summary Cards:** Present the key data inside white cards with a subtle shadow.
3. **Fit Indicators (Status Indicators):** Use colors:
   - Green (meets eligibility criteria / high fit)
   - Yellow (unclear / requires review)
   - Red (significant gap)
4. **Styled Tables:** Tables with padding and alternating row background colors.
5. **Division into tabs or clear sections:** Use prominent headings for each of the 7 work stages.
6. **Certainty Level Visualization:** Use colorful badges for the certainty level (High / Medium / Low).

At the end of every response, present the full HTML code inside a code block. The system will display it as a styled Artifact.

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

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

תרגול אישי: בניית עוזר מותאם לתהליך מהעבודה שלכם

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

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

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

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

שלב 1 בתרגול האישי: אפיון העוזר

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

שלב 2 בתרגול האישי: יצירת הוראות מערכת בעזרת ChatGPT או Gemini

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

השתמשו בפרומפט הבא:

שלב 3 בתרגול האישי: דוגמה מלאה ליצירת הוראות מערכת

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

שלב 4 בתרגול האישי: יצירת בסיס ידע לעוזר

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

מלאו את הטבלה:

דוגמאות לפי תהליך:

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

שלב 5 בתרגול האישי: בנייה והרצה ראשונה

עכשיו בנו גרסה ראשונה של העוזר שלכם.

1. פתחו Gem חדש או Custom GPT חדש.
2. הדביקו את הוראות המערכת שיצרתם.
3. העלו לפחות מסמך ידע אחד, אם יש לכם.
4. פתחו שיחה חדשה עם העוזר.
5. הריצו עליו דוגמה אמיתית או דוגמה מדומה מהעבודה שלכם.
6. בדקו את הפלט.

השתמשו בפרומפט בדיקה קצר:

שלב 6 בתרגול האישי: שיפור העוזר אחרי ההרצה הראשונה

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

שאלו את עצמכם:

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

אפשר להשתמש בפרומפט הבא כדי לקבל הצעות לשיפור ההוראות:

תוצר סופי של התרגול

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

התוצר כולל:

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

המסר המרכזי:

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

הפוסט בניית Gem מותאם אישית לסינון מיזמים חברתיים ב-Gemini הופיע לראשונה ב-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.

וכל זה נכנס לקובץ טקסט אחד שמעלים ל-Claude, ChatGPT, Gemini, Grok, או כל AI שיצא מחר בבוקר. תנו שעתיים. קובץ אחד. וכל מודל AI הופך להיות אתם. במדריך הזה נלמד בדיוק איך לעשות את זה, צעד אחר צעד.

והכי טוב? כל התהליך הוא "Future Proof" לחלוטין, אינו תלוי בכלי כזה או אחר, וישאר רלוונטי גם כשכל הכלים כבר ישתנו.

 
נצא לדרך!

גם אני נכנס לקובץ אחד

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

וכל זה נכנס לקובץ אחד. איך? התהליך פשוט:

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

הגדרות חשובות לתהליך

• השתמשו ב-Claude + Cowork + Opus 4.7 + Extended Thinking.
• הקליטו את התשובות שלכם בעזרת Wispr Flow (חינמי, הופך קול לטקסט). קול מהיר יותר וכנה יותר.

פרומפט 1 – הראיון

פתחו צ'אט חדש ב-Claude והדביקו את הפרומפט הבא. הוא יפעיל תהליך של 100 שאלות שמחולקות לקטגוריות:
 

1. אמונות ועמדות חתרניות
2. סגנון כתיבה
3. "פשעים אסתטיים" (מה גורם לכם להתכווץ בכתיבה של אחרים)
4. קול ואישיות
5. העדפות מבניות
6. קווים אדומים מוחלטים
7. דגלים אדומים

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

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

פרומפט 2 – דחיסת הקובץ

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

באותה שיחה, מיד אחרי הראיון, הדביקו את הפרומפט הבא:

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

בדיקה והטמעה בעבודה שוטפת

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

כשאתם מרוצים מהתוצאה, השלב הבא הוא לשלב את הקובץ בצורה קבועה:

1. ב-Claude Cowork: הוסיפו את קובץ ה-about-me.md לתיקיית ה-Cowork שלכם. כך Claude יקרא אותו תמיד לפני שהוא עונה, בכל שיחה חדשה.
2. ב-ChatGPT: העלו את הקובץ כ-Custom Instructions או צרפו אותו ל-GPT מותאם אישית.
3. במודלים אחרים: כל מערכת שתומכת בהעלאת קבצים או System Prompt תדע לקרוא את הפורמט הזה.

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

ההתנגדויות שתרגישו (וזה בסדר)

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

1. זה מרגיש מצמצם.
   • אתם לא רוצים להיות "רק קובץ טקסט". אני יודע – אנחנו אינסופיים. הזהות שלכם, הטקסטורה של ההומור, הדרך שבה המוח שלכם נע דרך בעיה – מרגישים כמו משהו קדוש. קובץ מרגיש כמו בגידה. אבל שום דבר בקובץ לא הופך אתכם לקטנים יותר. הוא פשוט הופך אתכם לתואמים למודל AI.
2. זה מרגיש מפחיד.
   • כשקוראים את עצמכם בקובץ טקסט אחד, אין איפה להתחבא. כל אמונה בדף היא מחויבות. כל סירוב הוא כלל שעכשיו צריך לחיות לפיו.
3. אתם חושבים שהכרת עצמי צריכה לקחת עשרות שנים.
   • טיפול, יומן אישי, שנים של אינטרוספקציה. אבל רוב הטיפול הוא בעצם פעולת הניסוח של מה שכבר מרגישים. הקובץ עושה את אותה עבודה בדיוק, כי יש לו מראיין (Claude) שמכריח אתכם להיות ספציפיים. עמימות לא שורדת את הפרומפט הזה.
4. בניתם זהות שלמה סביב הערך ״להיות קשים להגדרה״.
   • חלק מכם מאמינים שהערך שלכם טמון בלהיות מסתוריים, שכבתיים, בלתי אפשריים להגדרה. קובץ טקסט לוקח את זה מכם. הוא מפורש ומוגדר מדי. והמסתורין, כשמסתכלים עליו מקרוב, הוא בדרך כלל פשוט עמימות.

מה קורה אחרי שיש לכם את הקובץ

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

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

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

לערוך את הקובץ באופן שוטף

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

הפתרון: Obsidian. זו תוכנה חינמית שמציגה קבצי Markdown בצורה יפה ונוחה לעריכה, כמו Google Docs, רק שהקובץ נשמר ישירות בתיקייה שלכם על המחשב.

1. הורידו את Obsidian בחינם:
   • היכנסו ל-obsidian.md והורידו את הגרסה המתאימה למערכת ההפעלה שלכם (Mac, Windows או Linux).
2. פתחו את תיקיית Cowork כ-Vault:
   • לחצו על "Open folder as a vault" ובחרו את התיקייה שבה נמצא קובץ ה-about-me שלכם (אותה תיקייה שמחוברת ל-Claude Cowork).
3. ערכו ועדכנו:
   • עכשיו אתם יכולים לערוך את הקובץ בממשק נוח ויפה. כל שינוי נשמר אוטומטית ומסתנכרן גם עם Claude Cowork.

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

אתם (לא) רק קובץ טקסט

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

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

היי! זה מה שעושים מנהלים של צוותים גדולים לא?

הפוסט איך "לשכפל את עצמכם" לתוך Ai, ולגרום לו להתבטא בדיוק (אבל בדיוק!) כמוכם הופיע לראשונה ב-Almaya.

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

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

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

מכירות – Sales

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

1. סינון לידים נכנסים (Inbound Lead Qualifier)
   • כל פעם שמישהו ממלא טופס באתר שלכם, האוטומציה נכנסת לפעולה: היא קוראת את ההגשה, חוקרת את החברה ברשת (גודל, תחום, אתר, לינקדאין), מדרגת אותה מול פרופיל לקוח האידיאלי שהגדרתם מראש, ומנתבת את הליד לנציג הנכון – הכל בלי מגע אנושי.
   • אימפקט: עסקים מדווחים על קיצור של 60-70% בזמן עד יצירת קשר ראשון. הליד עוד חם, והנציג כבר על הקו.

 

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

 

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

 

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

 

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

 

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

 

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

 

8. מענה להתנגדויות תחרותיות (Competitive Objection Handler)
   • כשפרוספקט מזכיר מתחרה ("אנחנו גם בודקים את חברה Y") האוטומציה מייצרת מיידית מסרים נגדיים ממוקדים: מה היתרונות שלכם מול אותו מתחרה ספציפי, מה החולשות הידועות שלו, ואיזה שאלות כדאי לשאול כדי להטות את הכף.
   • אימפקט: נציגים לא נתפסים לא מוכנים. הם מגיבים בביטחון ובמקצועיות, גם כשהשיחה הופכת תחרותית.

 

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

 

10. מחשבון הצעות מחיר (Quote Calculator)
    • מקבל דרישות פרויקט – היקף, שעות, רכיבים – ומייצר הצעת מחיר מעוצבת באופן אוטומטי. כולל חישובי מע"מ, הנחות כמות, ותנאי תשלום סטנדרטיים. הנציג רק מאשר ושולח.
    • אימפקט: מחסל שגיאות תמחור לגמרי. לא עוד "אוי, שכחתי לחשב את העמלה" אחרי שהלקוח חתם. מעניין שהמחשבונים הללו תמיד משמשים גם את ה״עובדים הדיגיטליים״ (סוכני ה-Ai)בעסקים, די מהר.

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

שיווק – Marketing

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

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

 

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

 

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

 

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

 

15. טיוטה ראשונה לפוסט בבלוג (Blog Post First Drafter)
    • מקבל בריף (נושא, קהל יעד, מסר מרכזי, אורך רצוי) וכותב טיוטה ראשונה מלאה. לא תוכן סופי – אלא בסיס עבודה מוצק שכותב אנושי יכול לערוך, לחדד ולהוסיף לו את הנשמה – הקול היחודי והתובנות המקוריות שלכם.
    • אימפקט: חוסך 50-70% מזמן הכתיבה. הכותב מתחיל מטיוטה במקום מדף ריק – וזה שינוי עצום בפרודוקטיביות.

 

16. יצירת גרסאות מודעה (Ad Copy Variant Generator)
    • מקבל מודעה אחת ומייצר עשרות גרסאות שונות – שינויי כותרת, גוף, CTA (קריאה לפעולה) – כדי להריץ בדיקות A/B בקנה מידה שלא אפשרי ידנית.
    • אימפקט: צוותי שיווק שהיו מריצים 3-4 גרסאות – עכשיו מריצים 20+, ומגלים הרבה יותר מהר מה עובד.

 

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

 

18. מעקב אחרי אירועים (Event Follow-Up Automator)
    • אחרי כנס, תערוכה או וובינר – האוטומציה לוקחת את רשימת המשתתפים, מדרגת כל ליד לפי רלוונטיות (על בסיס תפקיד, חברה, ואינטראקציה באירוע), ומנסחת מיילי מעקב מותאמים אישית.
    • אימפקט: לידים מארועים, שבדרך כלל מתקררים כי אף אחד לא מספיק לחזור אליהם בזמן, מקבלים תשומת לב תוך 24 שעות.

 

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

 

20. אופטימיזציית קופי לדף נחיתה (Landing Page Copy Optimizer)
    • מנתח את הקופי בדפי הנחיתה שלכם, מזהה קטעים חלשים (כותרת לא ברורה, CTA מעורפל, ערך לא מספיק ברור), ומציע גרסאות מעודכנות ומשופרות.
    • אימפקט: שיפורים קטנים בקופי יכולים לשנות שיעורי המרה בעשרות אחוזים. במקום לנחש מה לשנות – יש המלצות מבוססות.

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

שירות לקוחות – Customer Support / Success

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

21. ניתוב פניות נכנסות (Ticket Triage Agent)
    • כל פנייה שנכנסת – באימייל, בצ'אט או בטופס, מסווגת אוטומטית לפי סוג (שאלה טכנית, בקשת החזר, תלונה, שאלה כללית) ולפי חומרה (דחוף, רגיל, נמוך). הפנייה מנותבת לסוכן הנכון (או לתור הנכון) מבלי שמישהו צריך לקרוא, להבין ולהחליט.
    • אימפקט: זמני תגובה יורדים דרמטית. פניות דחופות לא נקברות מתחת לשאלות כלליות.

 

22. מענה אוטומטי למיילי תמיכה (Support Email Auto-Responder)
    • שאלות נפוצות – "איך מאפסים סיסמה?", "מה מדיניות ההחזרות?", "איך מתקינים את האפליקציה?" – מקבלות מענה אוטומטי מיידי, על בסיס התיעוד הפנימי של החברה. שאלות מורכבות יותר מועברות לסוכן אנושי עם הקשר מלא.
    • אימפקט: 40-60% מהפניות נפתרות בלי מגע אנושי. הסוכנים מתפנים לטפל במקרים שבאמת דורשים חשיבה.

 

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

 

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

 

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

 

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

 

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

 

28. סקר שביעות רצון אוטומטי (CSAT Follow-Up Automator)
    • אחרי כל פנייה שנסגרה, נשלח סקר שביעות רצון קצר. התוצאות מנותחות אוטומטית: ציונים נמוכים מפעילים התראה לצוות, ציונים גבוהים יכולים לשמש כמקור לעדויות לקוחות.
    • אימפקט: שיעור תגובה לסקרים עולה (כי הם נשלחים ברגע הנכון), ובעיות מתגלות לפני שהופכות לביקורות שליליות פומביות.

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

תפעול – Operations

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

29. עיבוד חשבוניות (Invoice Processor)
    • חשבונית נכנסת (במייל, ב-PDF, בסריקה) והאוטומציה מחלצת ממנה את כל הנתונים הרלוונטיים: ספק, סכום, תאריך, פירוט שורות, מע"מ. הנתונים נרשמים אוטומטית במערכת הנהלת החשבונות.
    • אימפקט: עיבוד חשבונית שלקח 5-10 דקות ידנית – מתבצע בשניות. שגיאות הקלדה נעלמות.

 

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

 

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

 

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

 

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

 

34. השוואת ספקים (Vendor Comparison Analyzer)
    • כשצריך לבחור ספק – האוטומציה אוספת הצעות מחיר, משווה תנאים, מנתחת ביצועים קודמים (אם יש נתונים), ומציגה טבלת השוואה ברורה עם המלצה.
    • אימפקט: החלטות רכש שלקחו ימים של השוואה ידנית – מתקבלות בשעות, ומבוססות על נתונים ולא על תחושות.

 

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

 

36. דשבורד KPI שבועי (Weekly KPI Dashboard Builder)
    • כל שבוע, האוטומציה אוספת נתונים ממקורות שונים (CRM, אנליטיקס, מערכת כספים), בונה דשבורד מעודכן, ושולחת אותו להנהלה – בלי שמישהו צריך לשבת ולמשוך נתונים ידנית.
    • אימפקט: מנהלים מקבלים תמונת מצב עדכנית בתחילת כל שבוע. החלטות מתקבלות על בסיס נתונים טריים, לא על בסיס תחושות.

 

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

 

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

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

משאבי אנוש – HR

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

39. סינון קורות חיים (Resume Screener)
    • מקבל את דרישות התפקיד ואת ערימת קורות החיים, מתאים כל קובץ לדרישות, ומדרג את המועמדים באופן אוטומטי. מציג את ה-Top 10 עם הסבר למה כל אחד מתאים – ובמה הוא חלש.
    • אימפקט: סינון 200 קורות חיים שלקח יום שלם – מתבצע בדקות. מגייסים מתמקדים במועמדים הטובים ביותר מיד.

 

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

 

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

 

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

 

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

 

44. ניתוח סקרי עובדים (Employee Survey Analyzer)
    • תוצאות סקר עובדים עם מאות תגובות פתוחות – מנותחות אוטומטית. האוטומציה מזהה דפוסים ומגמות: מה הנושאים שהכי מטרידים עובדים, איפה יש פערים בין מחלקות, ומה השתנה מהסקר הקודם.
    • אימפקט: במקום דוח של 50 עמודים שאף אחד לא קורא – מנהלים מקבלים 5 תובנות מרכזיות עם המלצות לפעולה.

 

45. טיפול בבקשות חופשה (PTO/Leave Request Handler)
    • עובד מגיש בקשת חופשה, והאוטומציה בודקת: כמה ימים נותרו לו, האם יש כיסוי תפקידי בתאריכים המבוקשים, האם יש התנגשות עם חופשות אחרות באותו צוות. אם הכל תקין – הבקשה מאושרת אוטומטית.
    • אימפקט: אישור חופשה שלקח 3 ימים (כי המנהל היה עסוק) – מתאשר בדקות. עובדים שמחים, מנהלים לא מוטרדים.

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

פיננסים – Finance

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

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

 

47. ניתוח סטיות תקציב (Budget Variance Analyzer)
    • משווה בין התקציב המתוכנן לבין ההוצאות בפועל – שורה אחרי שורה, סעיף אחרי סעיף. מסמן סטיות משמעותיות, מסביר אותן (אם יש מספיק נתונים), ומציע התאמות.
    • אימפקט: חריגות תקציביות מתגלות בזמן אמת, לא בסוף הרבעון. מנהלים יכולים לקבל החלטות מתקנות לפני שהנזק מצטבר.

 

48. הסבר דוחות כספיים (Financial Report Narrator)
    • לוקח דוח כספי מורכב – רווח והפסד, מאזן או תזרים מזומנים, ומסביר אותו בשפה פשוטה וברורה. מה הנקודות החשובות? מה השתנה מהתקופה הקודמת? מה דורש תשומת לב? מנהלים שאינם רואי חשבון מבינים סוף-סוף את המספרים.
    • אימפקט: דוחות כספיים הופכים מ"מסמך שהחשב מסביר בפגישה" ל"מסמך שכולם מבינים לבד". זה משפר את קבלת ההחלטות בכל רמות הארגון.

 

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

 

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

כלים מומלצים ליישום

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

• Zapier / Make (Integromat) – הכלים הפופולריים ביותר לחיבור בין אפליקציות. מושלמים לאוטומציות פשוטות עד בינוניות: "כשנכנס ליד בטופס ← העשר ב-CRM ← שלח מייל". מתאימים למי שרוצה להתחיל מהר בלי לכתוב קוד.

 

• n8n – כלי אוטומציה בקוד פתוח, דומה ל-Make אבל עם יותר גמישות טכנית. מתאים לצוותים שרוצים שליטה מלאה על התהליך ואינם רוצים לשלם לפי כמות הרצות. הכלי עצמו חינמי, למי שמעוניין להתקין אותו על שרת ארגוני פנימי, או בספקית ענן כלשהי כמו AWS או Google Cloud. המערכת מוצעת גם כשירות ענן מנוהל בעלות של כ 20$ בחודש, נכון לזמן כתיבת הפוסט.

 

• Claude Code – סוכן קידוד בסגנון AiDD או Vibe Coding. נכון לעכשיו – האיכותי ביותר בשוק. מסוגל לפתח אפליקציות, תהליכים ושירותים שונים מאפס, בטכנולוגיות ושפות פיתוח מגוונות. מומלץ בעיקר לבעלי נסיון המסוגלים לפקח על עבודתו, ו״לתפוס״ נקודות של כשל אפשרי באבטחה / ביצועים / רגולציה ועוד.

 

• OpenAI API / Claude API / Gemini API / OpenRouter – הממשקים של מודלי ה-AI עצמם. כשצריך "שכל" בתוך האוטומציה – ניתוח טקסט, כתיבה, סיווג, סיכום – אלה המנועים שעושים את העבודה. שילוב שלהם עם Zapier או Make פשוט מאוד.

 

• LangChain / LangGraph / CrewAI – פריימוורקים לבניית "סוכני AI" מורכבים יותר. כשאוטומציה דורשת מספר שלבים של חשיבה, חיפוש מידע, והחלטות – הכלים האלה מאפשרים לבנות רצפים מתוחכמים.

 

• Notion + AI / Airtable – בסיסי נתונים חכמים שמשתלבים מצוין עם אוטומציות. מתאימים במיוחד לניהול תהליכים פנימיים, ניהול לידים, ומעקב משימות.

 

• Slack / Microsoft Teams – לא רק כלי תקשורת, אלא גם ממשק להתראות ואינטראקציה. אוטומציות שולחות הודעות ל-Slack כשמשהו דורש תשומת לב – וזה הופך כל ערוץ למרכז בקרה.

איך מתחילים – ולא נתקעים

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

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

 

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

 

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

 

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

 

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

שלוש תובנות לסיום

1. אוטומציה היא לא "הכל או כלום". האוטומציות הכי טובות הן אלה שעושות 80% מהעבודה ומשאירות לאדם את 20% שדורשים שיקול דעת. לא צריך לשאוף ל-100% אוטומטי – צריך לשאוף ל-"מספיק אוטומטי כדי שלא ירגיש כמו בזבוז זמן".

 

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

 

3. הטכנולוגיה פחות חשובה ממה שנדמה. אנשים מתלבטים בין Zapier ל-Make, בין GPT ל-Claude, בין n8n ל-Pipedream. האמת? כולם עובדים. הכלי הכי טוב הוא הכלי שתתחילו איתו היום. תשדרגו אחר כך. ואל (אל!) תיפלו ל Over Engineering, ו״הכנות למזגן״ מיותרות. בעידן ה AI זה פשוט לא נחוץ.

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

בהצלחה!

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