הייקו 5.5 למי שצריך לבצע הרבה משימות מוגדרות

אנטרופיק (Anthropic) השיקו את Claude Haiku 5.5, המודל המהיר והזול ביותר במשפחת 5.5 של קלוד. הוא מיועד במיוחד למשימות שחוזרות פעמים רבות, כמו סיכום, סיווג, חילוץ מידע וניתוב בקשות. אנטרופיק מעריכה שעלות ההפעלה שלו נמוכה בכ-75% בממוצע לעומת הייקו 4.5. הנתון מתייחס להפעלה דרך ה-API.

הייקו 5.5 דרך ה-API זול משמעותית מקודמו | Anthropic

למשתמש הפשוט, הערך המרכזי הוא לקבל תשובה במהירות למשימה שאפשר להגדיר היטב. למי שבונה מערכת שמטפלת במאות או באלפי פניות, גם העלות לכל פעולה נעשית משמעותית. הייקו 5.5 זמין לבחירה בקלוד גם למשתמשים בתוכניות Pro ,Max ,Team וכמובן Enterprise וגם בתוכנית החינמית.

בטבלת הבנצ'מרקים שמפרסמת אנטרופיק, הייקו 5.5 מציג שיפור ניכר לעומת הייקו 4.5 בעבודת ידע, בהפעלת מחשב, בתכנות ובניתוח חזותי. הוא גם מקדים את GPT-6 Luna בכל המדדים שבהם מוצגת השוואה, אבל סונטה (Sonnet) 5.5 עדיין מוביל בכל המבחנים שבטבלה. התוצאות מצביעות על הרחבת היכולות של הייקו, לצד יתרון שנותר לסונטה במשימות מורכבות.

במבחנים של אנטרופיק, הייקו 5.5 משתפר משמעותית לעומת קודמו | Anthropic

איזה משימות כדאי לנסות איתו?

אפשר להתחיל במשימות שבהן ברור מה נכנס ומה צריך לצאת:

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

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

פרומפט לדוגמה:

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

הייקו החדש זמין תחת בורר במודלים

מתי כדאי לבחור מודל אחר?

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

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

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

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

הכרזה מעניינת לא פחות התרחשה ב-6 באוקטובר, אז הכריזה אנטרופיק על Claude for Google Workspace, לצד חיבורים חדשים ל- Docs, Sheets ו-Slides. היכולות זמינות בבטא בכל התוכניות בתשלום, ומאפשרות לעבוד עם קלוד ישירות על קובצי גוגל במקום להעביר תוכן הלוך ושוב בין החלונות.

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

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

הסקילים והחיבורים שלכם מגיעים איתכם

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

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

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

הסקיל מנחה את קלוד כיצד ליצור ולערוך קובצי גוגל

ב-Docs: לערוך את המסמך עצמו

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

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

ב-Sheets: לבנות חישובים וגם לבדוק אותם

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

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

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

ב-Slides: להתאים את המצגת לקהל ולזמן

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

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

איך מתחילים?

לשימוש בתוך גוגל:

1. התקינו את התוסף הרשמי Claude מחנות Google Workspace Marketplace.
2. עברו על ההרשאות ורעננו קבצים שכבר פתוחים אצלכם.
3. פתחו את תפריט Extensions, בחרו Claude ואז Open Claude.
4. התחברו לחשבון קלוד והתחילו עם בקשה קטנה על הקובץ מהחלון הצידי שנפתח במסמך/גליון/מצגת שלכם.

איך מורידים את התוסף ומחברים את קלוד לכלים שלכם

התקנה אחת מכסה את Docs, Sheets ו-Slides. אם ההתקנה חסומה בארגון, פנו למנהל Google Workspace. אם קלוד לא מופיע לאחר ההתקנה, רעננו את הקובץ ובדקו שאתם מחוברים לחשבון גוגל שבו התקנתם את התוסף.

ככה נראה קלוד בדוקס, שיטס וסליידס

עובדים על קובץ Word או Excel שהעליתם ל-Drive?אם הוא עדיין בפורמט Office, צריך להמיר אותו לפורמט גוגל כדי להשתמש בתוספים. פתחו את הקובץ ובתפריט File בחרו Save as Google Docs, Sheets או Slides, בהתאם לסוג הקובץ. ההמרה יוצרת עותק בפורמט גוגל ומשאירה את הקובץ המקורי.

לעבודה מתוך קלוד, הפעילו את חיבורי Google Docs, Sheets ו-Slides דרך תפריט החיבורים בצ׳אט. אלה חיבורים נפרדים מחיבור Google Drive. לאחר מכן הדביקו קישור לקובץ או בקשו במפורש תוצר בפורמט גוגל, למשל: ״צור Google Docs מהסיכום המצורף״. בתוכניות Team ו-Enterprise נדרשת תחילה הפעלה של החיבורים בידי בעל הרשאה ארגונית מתאימה.

חיבור קלוד ל-Docs, ל-Sheets ול-Slides

בסביבות הנתמכות, הקובץ נפתח בחלונית לצד השיחה. החלונית זמינה בקלוד בדפדפן Chrome, וב-Claude Desktop כשהדפדפן המובנה מופעל. אם היא לא זמינה, אפשר לבחור Open in Google ולפתוח את הקובץ בגוגל. הגישה והעריכה נשארות כפופות להרשאות חשבון הגוגל שלכם.

לפני שנותנים לקלוד לערוך קובץ חשוב

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

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

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

לפרטים נוספים לחצו כאן >>

וגם קרדיטים למי שבונה עם קלוד

עדכון נוסף הוא קרדיטים חודשיים ל-API למנויי Max וTeam: 100 דולר ל-Max 5x ו-200 דולר ל-Max 20x. ב-Team מתקבלים 20 דולר לכל משתמש Standard ו-100 דולר לכל משתמש Premium, במאגר משותף עד 500 דולר בחודש.

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

איך תדעו אם העדכונים מועילים לכם?

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

הפוסט הייקו (Haiku) 5.5 כבר באוויר וקלוד מתחבר לסביבת גוגל הופיע ראשון בLet's AI בינה מלאכותית

טומי ברב, מייסד-שותף ומנכ״ל Timeless, מציג את Playbooks

אז מה זה בעצם Playbook?

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

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

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

מה כבר אפשר לבנות?

בגלריית ה-Playbooks של Timeless מופיעות כמה דוגמאות שממחישות היטב את הרעיון:

Promise Tracker עובר על הפגישות ומחפש דברים שהבטחתם לעשות, למי הבטחתם אותם והאם צוין מועד:

מרכז את ההתחייבויות שעלו בפגישות ומראה מה עדיין פתוח | Timeless

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

מרכז את הפגישות וההקשר החשוב לתדריך קצר לקראת היום | Timeless

Branded Notes הופך פגישה למסמך מסודר במבנה ובעיצוב שמתאימים לארגון:

הופך פגישה למסמך מסודר וממותג עם החלטות ומשימות | Timeless

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

מציג מי דיבר, מתי ואיך השיחה התפתחה לאורך הפגישה | Timeless

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

איך מתחילים בלי להסתבך?

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

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

שלב 1: התחילו מבעיה אחת

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

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

כבר כאן יש כמעט את כל מה שצריך כדי להתחיל.

שלב 2: הגדירו מה אתם רוצים לקבל

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

After every client meeting, create a short decision brief.

Include:
- decisions that were made
- action items
- the owner of each action
- deadlines only when they were explicitly mentioned
- unresolved questions
- anything I personally promised to do

Keep it short enough to read in two minutes.

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

אפשר גם להתכונן לפגישות, לא רק לסכם אותן

Playbooks לא חייבים לפעול רק אחרי שיחה. אפשר להשתמש במידע שכבר קיים ב-Timeless כדי להתכונן למה שיקרה בהמשך. לדוגמה:

Every weekday morning, review my meetings scheduled for today.

For each meeting, show:
- who I am meeting
- what we discussed last time
- unresolved commitments
- open questions
- anything I should remember before the meeting

Keep the brief short and practical.

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

ומה לגבי הדברים שאנחנו מבטיחים לאחרים?

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

Review my meetings from the previous seven days.

Find commitments that I made and commitments other people made to me.

Separate them into:
1. I owe
2. They owe me
3. No clear owner

Never invent a deadline.
If no deadline was mentioned, say so explicitly.

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

איך כותבים Playbook טוב?

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

מתי זה צריך לקרות?

אחרי כל פגישה? בכל בוקר? פעם בשבוע?

על איזה מידע לעבוד?

פגישות מהיום? פגישות עם לקוח מסוים? כל השיחות מהשבוע האחרון?

מה אתם רוצים לקבל?

רשימת משימות? תדריך? מסמך? התחייבויות? שאלות פתוחות?

אילו כללים חשוב לשמור?

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

ככל שתגדירו את ארבעת הדברים האלה טוב יותר, כך ה-Playbook יהיה שימושי יותר.

הופך משימות שעלו בפגישה לכרטיסים שאפשר למיין | Timeless

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

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

שימו לב לשלושה דברים:

1. האם הוא זיהה נכון מה חשוב?

2. האם חסר משהו שאתם תמיד צריכים?

3. והאם הוא הסיק משהו שלא באמת נאמר?

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

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

לפרטים נוספים לחצו כאן >>

למה הפיצ'ר הזה מעניין?

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

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

להנחיות התקנה כנסו כאן.

הפוסט כך הופכים את הפגישות שלכם לכלי עבודה שבונה את עצמו עם Timeless Playbooks הופיע ראשון בLet's AI בינה מלאכותית

מה נבנה ולמי זה מתאים?

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

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

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

מה צריך לפני שמתחילים?

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

• שניים או שלושה פוסטים שכתבתם: בקובץ טקסט אחד. בחרו פוסטים שאתם אוהבים, לא בהכרח את אלה שקיבלו הכי הרבה תגובות

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

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

שלב 1: פותחים פרויקט חדש

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

בחלון Create project הקלידו שם לפרויקט בשדה Project name במקרה שלנו שם הפרויקט יהיה "פוסטים ללינקדאין".

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

שלב 2: כותבים את ההוראות

בדף הפרויקט שנפתח, לחצו על כפתור שלוש הנקודות בפינה ובחרו ב- Project settings

בחלון ההגדרות הדביקו את ההוראות בשדה Instructions, ולחצו על Save.

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

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

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

## דוגמאות לקול שלי
בקובץ noa-linkedin-posts.txt בפרויקט יש שלושה פוסטים שכתבתי. לפני כל פוסט, קרא אותם ולמד מהם את הסגנון. אל תעתיק מהם משפטים.

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

## תבנית
1. פתיחה: רגע קונקרטי
2. מה קרה
3. מה למדתי
4. שאלה לקוראים
5. האשטגים (לא חובה)

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

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

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

שלב 3: מעלים את הפוסטים לדוגמה

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

במקרה שלנו הוא נקרא noa-linkedin-posts.txt, ואחרי ההעלאה הוא מופיע ברשימה.

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

שלב 4: מבקשים את הפוסט הראשון

חזרו לטאב Chats וכתבו את הבקשה בתיבת השיחה של הפרויקט.

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

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

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

לפני ואחרי - אותה בקשה, שתי תוצאות:

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

מחוץ לפרויקט: פוסט של בלוג

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

בתוך הפרויקט: פוסט שנשמע כמו נועה

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

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

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

בכמה מהצילומים מופיע מעל התשובה מתג Original / Write Like Me. זהו פיצ'ר של ChatGPT עצמו, והוא לא חלק מהמדריך. בכל הצילומים שלנו הוא מסומן על Original.

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

שלב 5: בדקו מה קורה כשחסר מידע

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

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

שלב 6: מלטשים באותה שיחה

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

שלב 7: שומרים את הפוסט המוצלח

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

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

טיפים וטעויות נפוצות

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

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

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

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

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

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

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

מה הלאה

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

יש גם כיוונים מתקדמים יותר: פלאגינים (Plugins), שהאפשרויות בהם תלויות במסלול, ותכונת סגנון הכתיבה (Writing Style) ב-ChatGPT Work, שזמינה במסלולים בתשלום ולומדת את הסגנון מחשבונות מחוברים. אבל לרוב האנשים, פרויקט עם שלושה פוסטים טובים יספיק בהחלט.

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

הפוסט כך הופכים את ChatGPT לכותב הפוסטים שלכם בלינקדאין הופיע ראשון בLet's AI בינה מלאכותית

מה זה בעצם Facilitator?

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

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

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

הוא גם עוזר לנהל את הפגישה עצמה

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

@Facilitator, here's the agenda: project status 10 minutes, blockers 10 minutes, next steps 5 minutes.

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

@Facilitator, add Strategy review to the agenda for 15 minutes.

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

Facilitator פועל בתוך פגישת Teams, עוקב, מעדכן ומגיב | Microsoft

לא צריך אג'נדה כדי להשתמש בטיימר

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

@Facilitator, add a timer for five minutes.

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

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

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

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

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

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

@Facilitator, summarize the decisions we've made so far and list the open questions.

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

אחרי הפגישה העבודה ממשיכה

התוכן ש-Facilitator יצר במהלך הפגישה נשאר נגיש דרך ה-Recap של Teams. ההערות נשמרות בעמוד Microsoft Loop וניתנות לעריכה על ידי משתתפי הפגישה לפני הפגישה, במהלכה ואחריה. בנוסף להערות שנוצרו בזמן אמת, אזור ה-AI Summary יכול להציג סיכום המבוסס על התמלול המלא לאחר שהפגישה הסתיימה.

כל החומרים נשארים זמינים ב-Recap של Teams להמשך עבודה | Microsoft

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

אפשר להפוך את הפגישה למסמך Word

אחת היכולות השימושיות של Facilitator היא לקחת את השיחה ולהפוך אותה למסמך עבודה. לדוגמה:

@Facilitator, create a project brief based on this meeting, including the decisions, open issues and next steps.

הבקשה יכולה להישלח במהלך הפגישה או אחריה. Facilitator עשוי לשאול שאלות הבהרה אם הבקשה לא ברורה מספיק, ולאחר מכן הוא יוצר מסמך Word ומעלה אותו ל-OneDrive.

אפשר לבקש מ-Facilitator להפוך את תוכן הפגישה למסמך עבודה | Microsoft

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

ומה לגבי המשימות שעלו בפגישה?

Facilitator יכול לזהות משימות מתוך השיחה ולהציג אותן באזור Follow-up tasks שבהערות. כאן יש הבחנה חשובה. כאשר Facilitator מזהה משימה בעצמו, המשתמש צריך לבחור Accept to sync כדי להעביר אותה ל-Microsoft Planner.

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

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

אפשר להשתמש בו גם בפגישה שמתקיימת בחדר

ה-Facilitator לא מוגבל למצב שבו כל המשתתפים יושבים מול Teams במחשב. באפליקציית Teams לנייד קיימת האפשרות Take notes with Facilitator, שמיועדת גם ללכידת דיונים שמתקיימים פנים אל פנים. המערכת יכולה לתמלל את השיחה, להבחין בין דוברים, לארגן את ההערות ולחלץ פעולות המשך.

לאחר השיחה אפשר לחזור להערות דרך הפגישה ב-Calendar או ברשימת הצ'אטים ולפתוח את ה-Recap. אפשר גם לקבל קישור שניתן לשיתוף.

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

ומה קורה בחדרי ישיבות עם Teams Rooms?

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

איך מתחילים לעבוד עם Facilitator?

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

1. בודקים את הרישיונות

כדי ליזום ולהשתמש ביכולות Facilitator נדרשים רישיון בסיס מתאים של Microsoft 365, רישיון Teams מתאים ורישיון Microsoft Copilot. מיקרוסופט מציינת ש-Facilitator כלול ברישיון Copilot, בכפוף לקיבולת הזמינה.

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

2. בודקים שהארגון מאפשר את האפליקציה

מנהל Teams יכול להיכנס ל-Teams Admin Center, לעבור אל:

Teams apps > Manage apps

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

3. מוודאים ש-Loop פעיל

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

4. מפעילים אותו כבר בזמן קביעת הפגישה

ב-Teams נכנסים ל-Calendar ויוצרים פגישה חדשה. בתוך אפשרויות הפגישה נכנסים ל:

Options > Copilot and other AI

צריך לוודא שהאפשרות Allow Copilot and Facilitator מוגדרת לשימוש במהלך הפגישה או במהלך הפגישה ואחריה, ואז להפעיל את Facilitator. חשוב לדעת שהוא ניתן להוספה מראש רק לפגישות מתוזמנות. נכון לעכשיו, אי אפשר להוסיף אותו מראש לפגישות Channel, לפגישות מיידיות או לשיחות Teams רגילות.

5. אפשר להפעיל אותו גם במהלך הפגישה

אם הוא לא הופעל מראש, מארגן הפגישה או Presenter יכולים לבחור:

More actions > Turn on Facilitator

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

6. מכינים אג'נדה ונותנים לו חומר לעבוד איתו

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

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

7. אחרי הפגישה נכנסים ל-Recap

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

כן, אפשר לעבוד איתו גם בעברית

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

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

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

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

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

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

כדאי לבדוק גם פרטיות ותאימות

נתוני Facilitator בפגישות נשמרים כקובץ .loop בתיקיית Meetings ב-OneDrive של המשתמש שהפעיל אותו, והנתונים מטופלים כנתוני תמלול של פגישה.

לארגונים עם דרישות אבטחה, רגולציה, שמירת מידע או eDiscovery יש כמה מגבלות שחשוב להכיר לפני פריסה רחבה. במקום להיכנס כאן לכל הפרטים, מומלץ לעבור על סעיף Data, privacy, and security בתיעוד הרשמי של Microsoft עבור Facilitator, ולוודא שההתנהגות של ההערות, תוויות הרגישות, ההגנות וה-retention מתאימה למדיניות הארגונית.

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

הדרך הטובה לבדוק אם הוא באמת חוסך לכם זמן

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

אחרי כמה פגישות תבדקו ארבעה דברים:

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

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

הפוסט הסוכן של Microsoft שיושב איתכם בפגישת Teams הופיע ראשון בLet's AI בינה מלאכותית

ארבעה חלקים שמבהירים מה אתם רוצים

1. הרעיון המרכזי: מה יוצרים ולשם מה?

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

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

2. תמונות ייחוס: מה לקחת מכל תמונה?

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

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

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

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

3. הפרטים החזותיים: מה נמצא איפה?

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

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

המדריכים תמיד חינמיים, אבל אם בא לכם להתמקצע - יש גם קורס מקיף לבינה מלאכותית - GenAI Master

לפרטים נוספים לחצו כאן >>

4. התוצר והגימור: מה צריך לקבל בסוף?

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

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

התבנית המקורית באנגלית

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

תבנית בסיס לפרומפט באנגלית

אותה תבנית בעברית

תבנית בסיס לפרומפט בעברית

דוגמה מוכנה: תמונת שער למדריך על ניהול משימות

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

דוגמה בסיסית ופשוטה שהשתמשתי בה

וזה מה שיצא:

התמונה שג׳ונרטה מהפרומפט

איך לנסות ולשפר את התוצאה

1. בחרו כלי שיש לכם גישה אליו. אפשר להתחיל ב-ChatGPT שמודל התמונה החדש שלו (chatgpt-images-2-5) פשוט מצוין. אם יש לכם תוכנית Google AI או Google Workspace שמתאימה, אפשר לנסות גם את Google Pics.

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

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

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

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

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

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

הפוסט איך ליצור תמונות AI מדויקות יותר: תבנית פרומפט בארבעה חלקים הופיע ראשון בLet's AI בינה מלאכותית

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

לפרטים נוספים לחצו כאן >>

שלושה מצבים, שלושה תפקידים

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

1) מצב Build: במצב הזה Lovable בונה בפועל, כלומר כותב קוד ומשנה את האפליקציה. זהו מצב ברירת המחדל, והתמחור בו מבוסס על היקף השימוש.

2) מצב Chat: מרחב שנועד לשיחה בלבד. שואלים, מתייעצים, בוחנים רעיונות ומקבלים תשובה מקצועית, בלי שנכתבת אף שורת קוד ובלי לגעת בקרדיטים של הבנייה.

3) מצב Plan: במצב הזה Lovable בוחן את הפרויקט ומנסח תוכנית עבודה מובנית לפיצ'ר או לרכיב, מעין מסמך תכנון מפורט (Detailed Design). הוא אינו נוגע בקוד. אפשר לערוך את התוכנית כטקסט בפורמט Markdown, וברגע שמאשרים אותה, הכלי עובר אוטומטית למצב Build ומתחיל לממש אותה. התוכנית המאושרת נשמרת כקובץ בתוך הפרויקט, וכל הודעה במצב הזה עולה קרדיט אחד

ניתן לעבור בין המצבים בכל רגע, דרך הבורר שליד תיבת הטקסט או בקיצור המקלדת Option+P במק ו-Alt+P בווינדוס. השיחה נשמרת לאורך כל המעברים, כך שכל מה שדיברתם עליו ב-Chat ילווה גם את שלבי התכנון והבנייה.

מעבר בין מצבים

מה אפשר לשאול, ומה לא יקרה

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

Chat שפועל בתוך פרויקט קיים

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

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

קרדיטים נפרדים שמתאפסים כל יום

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

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

שיחות גם מחוץ לפרויקט

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

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

רעיון מוכר מעולם הקוד

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

מצב Ask בקרסר

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

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

הפוסט מצב Chat ב-Lovable: לחשוב בקול בלי לשרוף קרדיטים הופיע ראשון בLet's AI בינה מלאכותית

למה OpenAI משנה את הדרך שבה בונים כלים אישיים?

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

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

שלב 1: בחרו איזה GPTs חשוב לכם לשמור

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

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

בתמונה המצורפת רואים את עמוד My GPTs. בראשו מופיעה הודעה שלפיה יש להעביר את ה-GPTs לפלאגינים עד 11 בדצמבר. לצד GPTs שטרם הועברו מופיע הכפתור ״Migrate to plugin״, ולצד GPT שכבר הועבר מופיע ״Open plugin״:

המסך של “My GPTs” עם כפתורי “Migrate to plugin”

שלב 2: הכינו את ה-GPT לפני המעבר

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

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

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

שלב 3: לחצו על “Migrate to plugin”

כשתהיו מוכנים, חזרו אל My GPTs ולחצו על ״Migrate to plugin״ לצד ה-GPT שבחרתם. עברו על הפרטים שמוצגים בתהליך והמשיכו לפי ההוראות שעל המסך. כאשר תהליך ההעברה הסתיים, תופיע הודעת הצלחה עם אפשרות לפתוח ולערוך את הפלאגין.

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

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

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

לאחר ההעברה, פתחו את עמוד הפלאגין החדש. אם חזרתם לרשימת My GPTs, לחצו על Open plugin לצד ה-GPT שהעברתם. בעמוד תראו את ה-Skill שנוצר מהוראות ה-GPT. לחצו על Try in chat כדי לנסות את הפלאגין במשימה שאתם מכירים.

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

בתפריט שלוש הנקודות מופיעות גם אופציית Manage לניהול הפלאגין, Download plugin ZIP להורדת הקבצים, הנכסים וההנחיות של ה-GPT שלכם, Upload new version להעלות גרסה חדשה של קבצי הפלאגין ו-Uninstall להסרת הפלאגין המותקן. לצורך הבדיקה הראשונית, התחילו ב-Try in chat והשתמשו ב-Edit plugin כשיש דבר מוגדר שתרצו לבדוק או לשנות.

רוצים לבדוק את ההוראות או לבקש שינוי? לחצו על Edit plugin בראש העמוד או בתפריט של שלוש הנקודות. הפעולה פותחת שיחה עם Plugin Creator, ובה בקשה מוכנה לעדכון הפלאגין. השלימו אותה בשפה רגילה עם השינוי הרצוי. למשל: ”בדוק שהוראות הכתיבה מה-GPT המקורי נמצאות בפלאגין, ועדכן אותן כך שתשאל קודם מי קהל היעד”.

לחיצה על Edit plugin פותחת שיחה עם Plugin Creator

לאחר העדכון, חזרו אל Try in chat ונסו שוב את אותה משימה. השוו את התוצאה למה שקיבלתם מה-GPT המקורי. מזכיר לכם שכדאי לבדוק גם משימה שנשענת על קובץ ידע, אם היה כזה ב-GPT. ככה תוכלו לגלות אם חסר מידע או אם ההוראות דורשות התאמה.

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

שלב 5: נסו את הפלאגין במשימות אמיתיות

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

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

אחרי המעבר אפשר להשתמש ב-GPT המקורי עד ל-11 בדצמבר

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

ההודעה שתקבלו לאחר ביצוע ההעברה

שלב 6: בדקו חיבורים ושיתוף

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

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

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

איך משתמשים בפלאגין לאחר המעבר?

לאחר שיש לכם גישה לפלאגין והוא מותקן, אפשר לבחור אותו למשימה. אפשר לקרוא לפלאגין זמין באמצעות @ ממש בחלון הצ׳אט. לפעמים ChatGPT מזהה בעצמו ש-Skill שהתקנתם מתאים למשימה ומשתמש בו. אם חשוב לכם לעבוד דווקא עם פלאגין מסוים, בחרו אותו במפורש או פתחו אותו דרך Try in chat.

רוצים לבנות פלאגין חדש?

אם יש לכם רעיון לכלי שעדיין לא בניתם כ-GPT, אפשר להתחיל ישירות עם Plugin Creator. פתחו אותו ותארו בשפה רגילה מה תרצו שהפלאגין יעשה, למי הוא מיועד ואיך תרצו שיבצע את המשימה. כך תוכלו לבנות פלאגין חדש מתוך הרעיון שלכם.

כדי להפעיל אותו בתוך שיחה, כתבו Plugin Creator@ ואז את הבקשה שלכם:

אפשר לתאר ל-Plugin Creator בשפה רגילה איזה פלאגין רוצים ליצור

ככה נראה העמוד של Plugin Creator, הכלי ליצירה ולעדכון של פלאגינים. לחצו על Try in chat כדי לפתוח איתו שיחה, ואז תארו מה תרצו ליצור או לשנות:

העמוד של Plugin Creator עם הסקילים הייחודיים שלו

אל תחכו לתאריך היעד

אם יצרתם GPT שאתם רוצים להמשיך להשתמש בו, אל תחכו ל-11 בדצמבר 2026. תעברו על ההוראות והקבצים שלו, פרסמו שינויים חשובים, ובחרו ״Migrate to plugin״ מתוך My GPTs. לאחר מכן פתחו את הפלאגין, בדקו אותו עם משימות מוכרות, וטפלו בנפרד בחיבורים ובגישה של משתמשים אחרים. ככה תגיעו למועד עם תהליך עבודה שבדקתם ושאפשר להמשיך להשתמש בו.

הפוסט ככה תעבירו את ה-GPTs המותאמים אישית שלכם ל-Plugins הופיע ראשון בLet's AI בינה מלאכותית

צ'אט ו-Cowork מתאחדים

ב-16 בספטמבר 2026 החברה החלה לאחד את Claude Cowork ואת הצ'אט לחוויה אחת. במקום לבחור מראש לאן שייכת המשימה, מתארים לקלוד את התוצאה שרוצים והוא אמור להפעיל את היכולות המתאימות.

האיחוד מתגלגל קודם כל למשתמשי Pro ו-Max

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

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

מתחילים מהמשימה, לא מהכלי

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

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

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

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

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

Docs הופך את העבודה למסמך שאפשר להמשיך לערוך

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

לחיצה על "Output" פותחת חלון עם האפשרויות

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

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

למשל:

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

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

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

למשל:

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

בסיום אפשר לייצא את המסמך ל-Word, ל-PDF, ל-Markdown או ל-Google Docs. אפשר גם לבקש מקלוד לקחת את המסמך ולהפוך אותו למצגת באמצעות Claude Slides.

Slides ממשיך מאותו חומר למצגת

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

אפשר לבקש מצגת ישירות בשיחה או לבחור Output ולבחור בתוצר של Slides. אחרי היצירה אפשר לערוך שקופיות, לבקש מקלוד שינויים, להציג את המצגת מתוך המערכת או לייצא אותה ל-PowerPoint או ל-PDF.

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

לדוגמה:

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

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

לפני שמייצרים מצגות ועיצובים, מגדירים Design System

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

מסמנים את ה-"System Design" שאיתו אתם רוצים לעבוד

אפשר לבנות אותה ממצגת קיימת, מסמכי מותג, קבצי עיצוב או רכיבים מתוך בסיס קוד. קלוד מנתח את החומרים ומנסה לחלץ מהם את השפה החזותית של הארגון. כדי להגיע לאזור הזה, פתחו את Settings ובחרו Design systems מסרגל הצד. אם אתם עובדים ב-Team או Enterprise, ייתכן שהגישה תלויה בהרשאות שהגדיר מנהל הארגון.

אפשר להתחיל אפילו ממצגת אחת שאתם מרוצים ממנה:

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

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

לצוותי פיתוח יש גם אפשרות לסנכרן מערכת עיצוב שכבר קיימת בקוד. בקלוד קוד (Claude Code) אפשר להשתמש בפקודה design-sync/ כדי למשוך רכיבים והגדרות קיימים במקום לבנות אותם מחדש מתוך מצגות או צילומי מסך.

מסך ה-Design System מרכז את כללי העיצוב של המותג במקום אחד

Design מיועד לתוצרים חזותיים שאפשר להמשיך לעבוד עליהם

Claude Design מתאים בין היתר למוקאפים, one-pagers, דפי נחיתה, Prototypes ועיצובים אינטראקטיביים. הוא משלב את השיחה עם Canvas, כלומר משטח עבודה שבו אפשר לבחור אלמנטים, להזיז אותם ולערוך את התוצר ישירות.

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

לדוגמה:

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

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

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

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

Docs, Slides ו-Design נמצאים כרגע בבטא וזמינים בתוכניות Pro, Max, Team ו-Enterprise. הם אינם זמינים כחלק מהתוכנית החינמית, למרות שמשתמשים חינמיים יכולים עדיין ליצור סוגים אחרים של Artifacts. בתוכניות Pro, Max ו-Team שלושת הכלים מופעלים כברירת מחדל. ב-Enterprise בעל הארגון צריך להפעיל כל אחד מהם.

יש גם הגדרה בסיסית נוספת שצריכה להיות פעילה, Code execution and file creation. ב-Pro וב-Max פתחו את התפריט דרך השם או ראשי התיבות שלכם, היכנסו ל-Settings > Capabilities ובדקו שהמתג Code execution and file creation מופעל.

תוודאו שהיכולת הזו זמינה ופעילה

ב-Team וב-Enterprise ההגדרה נשלטת ברמת הארגון. בעל החשבון צריך להיכנס ל-Organization settings > Capabilities ולוודא ש-Code execution and file creation מופעל. כדי להפעיל ספציפית את Docs, Slides או Design ב-Enterprise, נכנסים גם ל-Organization settings > Artifacts ומפעילים שם את הכלי הרצוי.

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

שיתוף, גיבוי ומגבלות שכדאי להכיר

מסמך חדש ב-Docs מתחיל כפרטי. בתוכניות Pro ו-Max אפשר לשתף אותו באמצעות קישור, והאדם שפותח את התוצר צריך חשבון קלוד פעיל. ב-Team וב-Enterprise אפשר לתת לאנשים ולקבוצות בארגון הרשאות צפייה או עריכה. נכון לעכשיו, Docs בתוכניות הארגוניות לא מאפשר שיתוף מחוץ לארגון ואין בו הרשאת "תגובות בלבד".

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

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

ארגונים עם דרישות אבטחה מסוימות צריכים לבדוק זמינות לפני שהם בונים על Docs. נכון לעכשיו Claude Docs אינו זמין לארגונים שמשתמשים ב-Customer-managed encryption keys ‏(CMEK), ב-Zero Data Retention ‏(ZDR) או בתצורת HIPAA-ready.

קחו בחשבון גם את מכסת השימוש

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

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

הדרך הטובה ביותר להתחיל

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

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

הפוסט אנטרופיק מאחדת את קלוד Chat ו-Cowork, ומכניסה גם מסמכים, מצגות ועיצוב לאותה שיחה הופיע ראשון בLet's AI בינה מלאכותית

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

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

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

פורמט קורות חיים תואם ATS

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

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

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

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

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

פרומפט שימושי:

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

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

כתבו את העובדות בעצמכם, ואז תנו ל-AI לשפר אותן

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

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

הנוסחה לתיאור הישג בתפקיד

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

פרומפט שימושי:

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

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

הנה דוגמה טובה לשימוש בנוסחה:

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

המספרים צריכים להגיע מכם, לא מהמודל.

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

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

אפשר למדוד השפעה במגוון דרכים

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

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

רק אחרי שאתם מספקים את הנתונים, בקשו ניסוח.

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

רשימת מיומנויות שכוללת "ChatGPT", "Claude" או "AI" לבדה כבר לא אומרת הרבה. בסקר של Resume Genius, כ-60% ממנהלי הגיוס אמרו שהם מעדיפים לבדוק, לדון או לראות הוכחה ליכולת AI של מועמד במקום להסתפק בטענה בקורות החיים.

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

לכן, אם השתמשתם ב-AI בעבודה, חברו את הכלי לתוצאה. במקום: "מיומנויות: ChatGPT, Claude", עדיף:

"קיצרתי את הכנת דוח משוב הלקוחות השבועי משעתיים ל-30 דקות באמצעות תהליך מבוסס Claude לסיווג וסיכום משובים."

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

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

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

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

לפרטים נוספים לחצו כאן >>

לפני שאתם שולחים, עברו על הרשימה הזאת

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

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

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

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

הפוסט איך לכתוב קורות חיים בעידן ה-AI הופיע ראשון בLet's AI בינה מלאכותית

1. העלו תמונה ותשנו אותה בלי לבנות הכול מחדש

אחד השיפורים המרכזיים ב-Images 2.5 הוא היכולת לעבוד מתמונת Reference, כלומר תמונת מקור שמשמשת את המודל כנקודת ייחוס.

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

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

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

לצילום מוצר:

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

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

איך מתחילים? בקשו בשפה טבעית ותעלו תמונת רפרנס דרך כפתור הפלוס (+)

2. השתמשו בספרייה ובתבניות מוכנות

מתוך גלריית ChatGPT אפשר לפתוח את תפריט New ולהתחיל מתמונה חדשה, מסמך, גיליון, מצגת או קובץ קיים. אפשר גם להעלות קבצים מהמחשב או לחבר שירותים כמו Google Drive, Box ו-Dropbox.

תפריט New מתוך הספרייה פותח מגוון אפשרויות

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

אזור Templates מציע תבניות מוכנות

3. התנסו עם תבניות ויזואליות

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

פרומפט לדוגמה:

"צור פוסטר לאירוע טכנולוגיה בשם Future Interface 2026, עם רקע שחור, טיפוגרפיה גדולה ונקייה, אלמנטים גיאומטריים בירוק וסגול והכיתוב October 22, Paris."

4. בקשו שינוי נקודתי והשאירו את כל היתר במקום

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

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

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

או:

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

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

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

יצרתי קולאז׳ בשפה טבעית ועכשיו אני יכול ״לשחק״ עם התוצאה

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

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

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

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

6. ציירו במקום להסביר עם Sketch

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

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

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

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

7. הוסיפו טקסט כחלק מהתמונה

ChatGPT Images יכול ליצור תמונות שכוללות טקסט, ו-Images 2.5 משפר גם את ההתמודדות עם פריסות מורכבות ואינפוגרפיקות. OpenAI מציינת גם שיפור בתמונות שמכילות מידע מהעולם האמיתי.

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

לדוגמה:

"צור פוסטר אנכי 4:5.
הכותרת שמופיעה בתמונה היא בדיוק: "DESIGN TOMORROW"
מתחתיה כתוב בדיוק: "October 22, Paris"
אל תוסיף טקסט נוסף.
עיצוב מינימליסטי, רקע קרם, טיפוגרפיה שחורה גדולה וצורה גיאומטרית אדומה בחלק התחתון."

אותה שיטה מתאימה גם להזמנות, שלטים, עטיפות, תמונות לסושיאל ואינפוגרפיקות.

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

לפרטים נוספים לחצו כאן >>

8. צרו תמונות עם רקע שקוף

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

פרומפט לדוגמה:

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

למוצר:

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

9. השתמשו ביחס התמונה שמתאים ליעד

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

לדוגמה:

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

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

10. נסו לתת לכל תמונת Reference תפקיד

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

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

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

11. נסחו בריף קצר במקום לחפש "פרומפט קסם"

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

למשל:

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

זה יכול להיות בסיס שימושי יותר מערימה של תיאורי סגנון כמו "cinematic, ultra detailed, 8K".

מה כדאי לנסות קודם

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

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

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

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

הפוסט ChatGPT Images 2.5: מדריך שימוש, יכולות חדשות ופרומפטים מומלצים הופיע ראשון בLet's AI בינה מלאכותית

קודם מבינים אם זו משימת חשיבה או משימת ביצוע

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

בממשקים של ChatGPT, קלוד (Claude) וג׳מיני (Gemini) מופיעים היום שמות שנראים לפעמים כמו שילוב בין תפריט גלידה, סדרת מדע בדיוני ורשימת קוד פנימית. אצל OpenAI אפשר לפגוש שמות כמו אסטרה (Astra), Sol ,Terra ו-Luna. אצל אנטרופיק (Anthropic) יש Fable, Opus, Sonnet ו-Haiku. אצל גוגל (Google) מופיעים Gemini Pro וגרסאות Flash שונות.

בורר המודלים של קלוד

הכלל הוא פשוט. כשאתם עדיין מנסים להבין את הגישה, תבחרו מודל חזק יותר. כשכבר יש תהליך ברור, תבחרו מודל מהיר וזול יותר. אפשר לחשוב על זה דרך שני סוגי שאלות. השאלה הראשונה היא “מה בכלל צריך לעשות, ולמה זו הדרך הנכונה?”. זו השאלה שמתאימה למודל החזק יותר, למשל Astra, Fable או Pro, בהתאם לכלי שבו אתם עובדים. השאלה השנייה היא “איך מריצים את אותו תהליך גם השבוע?”. זו כבר משימה שמתאימה למודל יעיל יותר, למשל Sol ,Sonnet או Flash.

בורר המודלים של צ׳אט ג׳יפיטי

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

בורר המודלים של ג׳מיני

מה עושים עם רמות ה-effort

לצד בחירת המודל, חלק מהכלים מאפשרים לבחור גם רמת effort, כלומר כמה מאמץ חישובי המודל ישקיע לפני שהוא עונה. בממשקים שונים זה יכול להופיע כ-Medium ,High ,Extra High ,Ultra או שמות דומים.

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

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

רמות שונות של מאמץ חישובי

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

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

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

פרומפט מתאים יכול להיראות כך:

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

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

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

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

בשבוע הבא כבר לא מסבירים הכול מחדש

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

למשל:

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

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

שלושה שימושים שאפשר לנסות השבוע

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

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

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

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

לפרטים נוספים לחצו כאן >>

אל תתנו יותר הרשאות ממה שהמשימה דורשת

כאשר מחברים AI למייל, יומן, Drive, מערכת CRM או כל כלי עבודה אחר, השאלה היא לא רק איזה מודל לבחור. צריך גם לחשוב מה מותר לו לראות ולעשות.

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

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

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

השאלה הקצרה שחוסכת הרבה בלבול

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

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

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

הפוסט איך לבחור מודל AI למשימות עבודה חוזרות הופיע ראשון בLet's AI בינה מלאכותית

מה בעצם השתנה

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

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

הגלריה החדשה, מחולקת לשתי לשוניות

לפני שמתחילים

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

1. צריך חשבון ChatGPT - התבניות זמינות בגלריה בכתובת https://chatgpt.com/images/. לפי מרכז העזרה של OpenAI, הן עדיין לא זמינות ב-Work mode.
2. כדאי להכין את התמונות מראש - רוב התבניות המעניינות עובדות על תמונה שאתם מעלים, לא על טקסט בלבד. תמונה ברורה, מוארת היטב ועם נושא מרכזי אחד תיתן תוצאה טובה בהרבה.
3. תתאזרו בסבלנות - למרות ההבטחה על שיפור המהירות, אצלנו כל תמונה לקחה מספר דקות. במהלך ההמתנה מוצג מד התקדמות באחוזים שגם זה שיפור משמעותי לממשק.

מד ההתקדמות החדש מראה לכם כמה נשאר

איך יוצרים תמונה מתבנית

1. נכנסים לעמוד התמונות: פותחים את chatgpt.com/images. בראש העמוד יש שדה בשם Describe a new image, ומתחתיו הגלריה.
2. בוחרים תבנית: גוללים בין הלשוניות ולוחצים על התמונה שאהבתם. אין צורך לחפש, פשוט בוחרים לפי הסגנון שמדבר אליכם.
3. מסתכלים על הפרומפט שנכנס אוטומטית: זה החלק שרוב האנשים מפספסים. ChatGPT מזין אוטומטית לשדה הכתיבה פרומפט ארוך באנגלית, שמפרט את הסגנון, סוג הקווים, הפריסה והאווירה. הפרומפט הזה ניתן לעריכה.
4. מעלים תמונה: לוחצים על הפלוס בפינת שדה הכתיבה ובוחרים את התמונה שלכם. היא תופיע כתמונה ממוזערת מעל הפרומפט.
5. מוסיפים את הבקשה לעברית: בסוף הפרומפט הקיים, בלי למחוק ממנו כלום, מוסיפים All text in Hebrew.
6. שולחים ומחכים: לוחצים על החץ הכחול. בשורת הכתיבה יש גם בורר איכות שמוגדר כברירת מחדל ל-Medium, ואפשר לשנות אותו לפי הצורך.

שלוש המילים שעושות את כל ההבדל

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

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

תבנית Palm reading, עם הוספה של שלוש מילים בסוף הפרומפט

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

מה קיבלנו בפועל

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

התמונה המקורית של ספייק

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

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

פוסטר בוטני: תבנית Infographic poster הפכה את ספייק ללוח מחקר בסגנון אטלס מדעי מהמאה ה-19, עם איור מרכזי ושישה איורי משנה. כל הטקסט בעברית, כולל "לוח מספר 1", "איור 4 דגם סימני הפנים" וטקסט אנכי בפינה.

תבנית Infographic poster, כולל טקסט אנכי בשוליים

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

קומיקס של "סופר ספייק" שנוצר בעזרת ChatGPT

שימו לב לפרט אחד: בתבנית הקומיקס לא כתבנו בכלל All text in Hebrew, אלא רק Super hero in Hebrew. ChatGPT הבין לבד שהכוונה היא שכל הקומיקס יהיה בעברית, ולא רק המילה "גיבור-על".

ארבעה טיפים שישפרו לכם את התוצאה

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

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

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

נסו את זה על תמונה אחת שלכם

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

הפוסט קומיקס, מדבקות וקריאה בכף יד: ChatGPT Images עובד גם בעברית הופיע ראשון בLet's AI בינה מלאכותית

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

לפרטים נוספים לחצו כאן >>

מה זה בעצם Sub-Agent

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

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

איך זה נראה בפועל?

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

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

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

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

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

מה שנשאר בסוף הוא התוצאה בלבד, לא כל הדרך המפרכת שהובילה אליה.

סוכן ראשי וסוכן משנה

איפה נכנס החיסכון בעלויות

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

הכוונה במקום סריקה עיוורת

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

המספרים שמאחורי ההחלטה

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

לבנות עובד משלכם: ה-QA Agent

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

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

לא להתבלבל: ההבדל בין Skills ל-Sub-agents

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

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

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

הבדל בין skills לsub agent

מתי בוחרים במה

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

שני צדדים של אותו מטבע

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

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

הפוסט Sub-Agents ב-Claude Code: העובד הזמני שחוסך לכם קונטקסט וכסף הופיע ראשון בLet's AI בינה מלאכותית

מי הגיע, בעצם

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

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

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

כל הבוטים חולקים מחשב ענן אחד

ומה בעצם יותר פשוט כאן

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

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

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

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

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

איך נראה יום איתו

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

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

איך מתקינים אותו?

נכנסים לאתר הרשמי, x.ai/bot, ולוחצים על הכפתור השחור Download for Windows. הקובץ יורד למחשב.

יש גרסה ל‑Windows כבר מההשקה, לא רק ל‑Mac. נתמך: Windows 10/11, Mac (Intel ו‑Apple Silicon), ו‑iPhone מ‑iOS 18. לא נתמך בשלב הזה: Android, Linux, ו‑iPad. אם אתם על Mac, הכפתור יראה אחרת. בחרו את הגרסה שמתאימה למחשב שלכם.

לוחצים על הכפתור השחור Download for Windows. אחרי הלחיצה הקובץ יורד למחשב

נפתח חלון Grok Bot Setup. כשההתקנה מסתיימת מופיע Completing Grok Bot Setup. משאירים את הסימון Run Grok Bot מסומן, ולוחצים Finish. האפליקציה נפתחת מיד.

השאירו ש-Run Grok Bot מסומן, ולחצו Finish

מסך אחד שכדאי לעצור בו

מסך פתיחה לבן. לוחצים Sign in, והדפדפן נפתח כדי לחבר חשבון. מי שכבר יש לו חשבון Grok או חשבון Cursor נכנס איתו. לא פותחים חשבון נוסף. מי שצריך חשבון חדש פותח עם שם ואימייל, או Google, GitHub או Apple. בדקו שזה החשבון שלכם, ולחצו Sign in. אם מופיע מישהו אחר, למטה יש sign in with another account.

לוחצים Sign in. הדפדפן ייפתח כדי לחבר את החשבון

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

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

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

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

הדפדפן שואל לפתוח את Grok Bot? לוחצים פתיחת Grok Bot. אל תלחצו ביטול - זה מבטל את החיבור.

לוחצים פתיחת Grok Bot. חוזרים לאפליקציה

נותנים לו שם, כמו לחבר

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

לפני שיוצרים בוט, שווה לפתוח Settings ולבדוק Usage & Billing. אם יש לכם כבר מנוי Cursor, Grok Bot כבר כלול בו. אם אין, רוכשים דרך המסך שנפתח. המחירים משתנים, לכן הולכים לפי מה שכתוב שם עכשיו.

כשיוצרים בוט בוחרים צבע וסמל, ובשדה Name כותבים שם פרטי. נועה, לא Research-GPT. ליד השם אפשר לכתוב במה הוא עוסק: מחקר, תפעול, מייל. כללים שתקפים תמיד שייכים לתיאור שלו. מה שקשור למשימה אחת הולך להודעה. לוחצים Get started.

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

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

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

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

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

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

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

עכשיו התור שלכם

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

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

הנה מדריך אינטראקטיבי חינמי שגם אותו גרוק בוט הכין : grok-first-bot.vercel.app.

הפוסט יש חבר חדש בשכונה: ככה מתחילים לעבוד עם Grok Bot הופיע ראשון בLet's AI בינה מלאכותית

מה בעצם קרה

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

אנתרופיק ציינה שש משפחות של נוזקות שזוהו בקמפיין: Vidar, ‏Lumma (המוכרת גם כ-LummaC2), ‏StealC, ‏RedLine ו-Acreed בווינדוס, ו-Atomic Stealer (המוכרת כ-AMOS) במספר קטן של מחשבי מק. אף אחת מהן אינה חדשה או ייחודית. אלה כלים מסחריים שנמכרים ומושכרים בשוק השחור כבר שנים.

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

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

למה אימות דו-שלבי לא עזר כאן

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

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

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

קלוד, קלוד קוד והקונסולה הם שלושה מקומות שונים

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

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

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

הפקודה usage/ בקלוד קוד פותחת את מסך הצריכה בלי לצאת מהטרמינל

Claude Console הוא ממשק נפרד לחלוטין, הזמין בכתובת platform.claude.com ומיועד למשתמשי ה-API. שם מנהלים מפתחות, צופים בצריכת טוקנים מפולחת ומשלמים לפי שימוש. חשוב להבין שמנוי Pro או Max אינו מכסה את השימוש בקונסולה. מדובר בשני מסלולי חיוב נפרדים, ולכן צריך לבצע שתי בדיקות שונות. שימוש בעוגיית סשן גנובה יתבטא בקלוד, ואילו שימוש במפתח API גנוב יופיע בקונסולה.

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

לפרטים נוספים לחצו כאן >>

לפני שמתחילים

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

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

שישה צעדים לבדיקה ולניקוי

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

מסך Usage מציג כמה מהמכסה נצרכה ומתי היא מתאפסת

2. פותחים את רשימת הסשנים הפעילים: בהגדרות בוחרים ב-Account ולא ב-Privacy. זו טעות נפוצה, משום שמסך Privacy נראה כמו המקום המתאים לנושאי אבטחה, אך למעשה הוא מרכז את הגדרות הנתונים: מה נשמר, מה מיוצא ומה עשוי לשמש לאימון. ניהול הסשנים נמצא תחת Account. במסך זה מופיעים שני חלקים: בחלק העליון Trusted devices, המציג את המכשירים שיכולים לשלוט במחשב שלכם באמצעות סשנים מרוחקים; ומתחתיו Active sessions, שבו נתמקד.

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

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

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

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

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

קלוד מבקש אישור לפני ניתוק סשן

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

מהאייקון שמשמאל לכתובת האתר נכנסים לקובצי ה-Cookie של הדומיין

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

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

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

מוחקים את הרשומות של claude.ai ושל a.claude.ai ולוחצים על בוצע

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

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

מי שעובד עם מפתחות API צריך צעד נוסף

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

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

מתפריט שלוש הנקודות אפשר לנטרל מפתח או למחוק אותו לצמיתות

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

איך פונים לאנתרופיק ומה כותבים להם

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

• לבעיה בחשבון קלוד עצמו: נכנסים ל-claude.ai, לוחצים על השם או ראשי התיבות בפינה השמאלית התחתונה, ובוחרים Get help.
• לבעיה במפתחות API או בקונסולה: נכנסים ל-platform.claude.com ופועלים באותו אופן. חלון התמיכה ייפתח בפינה הימנית התחתונה.

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

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

Subject: Unauthorized API usage on my account
I identified unauthorized usage on my account on [DATE]. My Console usage graph shows [NUMBER] tokens consumed in a single day, which is far outside my normal pattern. I did not generate this traffic. The key involved ends in [LAST 4 CHARACTERS]. I have already deleted the compromised key, created a new one, and scanned my machine. I am requesting a review of the charges from that period and a refund of any usage identified as unauthorized. Screenshots of the usage graph are attached.

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

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

ארבע הגדרות שמקטינות את הנזק מראש

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

תקרת הוצאה חודשית: בהגדרות, תחת Usage, מופיעה האפשרות Adjust limit, שפותחת מסך בשם Set monthly spend limit. במסך הזה מגדירים את סכום ההוצאה החודשי המרבי על קרדיטים, וההגדרה נכנסת לתוקף מיד. קיימת גם האפשרות Set to unlimited, אך מומלץ להימנע ממנה. תקרה נמוכה עשויה להיות ההבדל בין הפסד של עשרות דולרים להפסד של מאות.

תקרת ההוצאה החודשית נכנסת לתוקף מיד אחרי השמירה

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

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

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

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

ניקוי תקופתי של סשנים: פעם בחודש היכנסו ל-Active sessions ונתקו כל סשן שאינו בשימוש. סשן שלא עודכן במשך שבועות מגדיל את הסיכון ללא תועלת ממשית.

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

מסך Billing מציג את הכרטיס השמור, היתרה והחשבוניות

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

לפרטים נוספים לחצו כאן >>

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

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

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

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

בדיקה של שתי דקות שחשוב לא לדחות

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

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

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

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

רגע, מה קרה ל-NotebookLM?

אם חיפשתם את הכלי בשם שהכרתם ולא מצאתם אותו, לא טעיתם. ב-16 ביולי 2026 גוגל שינתה את שמו של NotebookLM ל-Gemini Notebook. זה אותו מוצר בדיוק, עם אותן מחברות ואותה כתובת, רק עם שם ולוגו חדשים. הקישורים הישנים ממשיכים לעבוד (כרגע לפחות). גוגל הסבירה שהאותיות LM, שמייצגות language model, לא אמרו הרבה לרוב 30 מיליון המשתמשים, ושהמוצר משתלב עמוק יותר במשפחת המוצרים של Gemini.

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

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

לפני שמתחילים

שלושה דברים שכדאי להכין מראש:

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

שלב 1: ההגדרה שקובעת אם זה יעבוד בעברית

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

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

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

ההגדרה שחייבים לשנות לפני הכל: Settings, ואז Output language

שלב 2: מקימים מחברת ומעלים את החומר

1. נכנסים ליצירת מחברת חדשה: בעמוד הפתיחה לוחצים על Create new notebook.

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

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

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

שלב 3: שלוש אפשרויות ולמה רק אחת מהן באמת מלמדת

כאן נמצא הלב של המדריך. בראש פאנל הצ'אט יש תפריט שמוביל למסך Configure chat, ובו שלושה כפתורים שמבטלים זה את זה: Default, Learning guide ו-Custom. גוגל מתארת את Learning guide כמתאים לתוכן חינוכי ולהבנת מושגים חדשים, ולכן ההנחה הטבעית היא שזה הכפתור שהופך את הכלי למורה.

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

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

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

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

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

אותה שאלה, הגדרה אחרת. במקום תשובה, שאלה שמובילה את הילד לחשוב

שלב 4: ההוראה שהופכת את הכלי למורה

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

אתה מורה פרטי לתלמיד כיתה ז'. ענה תמיד ורק בעברית.

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

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

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

בלי רשימות, בלי כותרות משנה, בלי בולטים. שיחה בלבד.

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

שלב 5: איך זה נראה בפועל

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

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

התגובה לתשובה שגויה: לא תיקון, אלא שאלה שמובילה לגילוי הטעות

שלב 6: כרטיסיות ובוחן ליום שלפני המבחן

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

1. Flashcards: לוחצים על האריח, בוחרים כמות כרטיסים ורמת קושי, ואפשר גם לכתוב נושא ספציפי. הסט שנוצר אצלנו כלל 50 כרטיסים. כל כרטיס נפתח בשאלה, לחיצה על See answer הופכת אותו, וכפתור Explain פותח הסבר מלא בצ'אט עם ציטוטים למקור.

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

תשובה שגויה בבוחן מקבלת הסבר בעברית למה היא לא נכונה, לא רק סימון

שלב 7: הפודקאסט לדרך לבית הספר

סקירת האודיו הופכת את החומר לשיחה בין שני מגישים. לוחצים על Audio Overview, בוחרים פורמט מתוך ארבעה (Deep dive לשיחה מעמיקה, Brief לתקציר, Critique לביקורת ו-Debate לוויכוח), ומוודאים ששדה Choose language מוגדר לעברית. גם כאן ברירת המחדל היא אנגלית.

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

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

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

איך יודעים שהוא לא ממציא

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

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

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

שלוש טעויות שכדאי להימנע מהן

• טעות 1: מדלגים על הגדרת שפת הפלט - זו הטעות הנפוצה ביותר, והיא זו שגורמת לאנשים להסיק בטעות שהכלי לא עובד טוב בעברית. כתבנו הנחיות בעברית מפורשות וקיבלנו כרטיסיות ובוחן באנגלית. רק אחרי שינוי ההגדרה ב-Settings הכל עבר לעברית.
• טעות 2: מסתפקים ב-Learning guide - השם מבטיח מורה, ההתנהגות בפועל היא הרצאה מסודרת שמציעה להמשיך. אם המטרה היא שהילד יחשוב ולא רק יקרא, צריך לעבור ל-Custom ולכתוב את ההוראה. ההגדרות מבטלות זו את זו, כך שאי אפשר לקבל את שתיהן יחד.
• טעות 3: מצפים לתשובות על מה שאין בחומר - הכלי עונה רק מתוך המקורות שהעלתם, וזו התכונה שהופכת אותו לאמין. שאלנו איך פוטוסינתזה קשורה להתחממות הגלובלית, נושא שלא הופיע בדף הסיכום, וקיבלנו עקיפה של השאלה. אם הילד צריך להרחיב מעבר לחומר, הוסיפו מקור נוסף דרך Add sources, למשל ערך מוויקיפדיה, במקום לצפות שהכלי ימלא את החסר לבד.

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

מה עדיין לא מושלם בעברית

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

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

מאיפה מתחילים?

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

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

הפוסט מורה פרטי בחינם ב-NotebookLM ושלוש טעויות שכדאי להימנע מהן הופיע ראשון בLet's AI בינה מלאכותית

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

קודם להבין מה אתם מנקים

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

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

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

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

הוראות שסותרות זו את זו בתוך אותה בקשה

התחילו במחיקה, לא בעריכה

בוריס צ׳רני (Boris Cherny), מי שמוביל את קלוד קוד, תיאר בסרטון של Y Combinator שיטת עבודה חדה יותר מ”לקצר קצת את הקובץ”. בכל פעם שמודל חדש יוצא, הצוות מוחק חלקים מה-system prompt, משכתב חלקים אחרים, משנה את סט הכלים וגם את ההנחיות של הכלים. הסיבה פשוטה: מה שתיקן בעיה במודל מלפני שלושה חודשים לא בהכרח מתאים למודל החדש.

אבל השיטה החשובה יותר היא ablation (מחיקה מבוקרת). צ׳רני מסביר שבמחקר הכוונה היא למחוק רכיב ולבדוק מה ההשפעה שלו. במקרה של קלוד קוד, זה אומר למחוק את כל ה-system prompt ואז להחזיר אותו שורה אחר שורה כדי להבין מה כל שורה באמת עושה. הם עושים דבר דומה גם לכלים: מסירים כלים, מוחקים קוד מה-harness, כלומר המעטפת שמחברת בין המודל, המוצר וההרשאות, ובודקים מה עדיין נחוץ.

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

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

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

השתמשו קודם, הוסיפו אחר כך

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

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

מוחקים, מריצים, ומחזירים רק הוראות שמתקנות כשל שחזר על עצמו

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

תחליפו כללים קשיחים בעקרונות פשוטים

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

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

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

אותה כוונה, ניסוח אחר

תנו לכלים להסביר את עצמם

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

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

אותו עיקרון נכון גם לכלים מסוכנים יותר. אם כלי משנה סביבת production, השם והתיאור שלו צריכים לומר זאת במפורש. ההוראות על אופן השימוש בכלי צריכות להופיע בתיאור הכלי, לא גם ב-CLAUDE.md, גם ב-system prompt וגם במסמך נפרד.

תעבירו תהליכים ארוכים ל-skills

CLAUDE.md צריך להכיל דברים שחשוב לדעת תמיד. הוא לא צריך להכיל כל תהליך עבודה אפשרי.

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

ב-CLAUDE.md אפשר להשאיר משפט קצר: “למשימות release השתמש ב-release skill”. את השלבים עצמם תשמרו בתוך הסקיל. ככה הקובץ הראשי נשאר קצר, והמידע המפורט עדיין זמין כשצריך אותו.

תשתמשו בדוגמאות חיות במקום עוד הסברים

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

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

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

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

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

לפרטים נוספים לחצו כאן >>

תבדקו את הזיכרון

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

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

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

צ’קליסט ניקוי לשימושכם

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

קודם בונים מחדש, אחר כך מסדרים

אם אתם משתמשים בקלוד קוד, אפשר להתחיל גם מפקודת doctor/, הפקודה שאנטרופיק מציינת ככלי לבדיקת סקילים וקבצי CLAUDE.md. אבל הסדר החשוב נשאר אותו סדר: למחוק בזהירות, להשתמש, לראות מה נשבר, ולהחזיר רק מה שבאמת נחוץ.

איפה לא לקצר מהר מדי

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

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

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

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

הפוסט החוקים החדשים להנדסת קונטקסט: איך לקצר הנחיות ולנקות CLAUDE.md בלי לפגוע בתוצאות הופיע ראשון בLet's AI בינה מלאכותית

למה כל 14 התמונות מציגות את אותו מוצר

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

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

מה השתנה ומה מאפשר את זה דווקא עכשיו

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

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

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

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

הפרומפט שיצר את המכונה שלנו:

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

תמונת המקור. כל 14 התמונות הבאות נוצרו ממנה

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

1. Exploded View: המוצר מתפרק באוויר

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

"פרק את המכונה ל-exploded view, כל החלקים מרחפים במרווחים שווים."

פקודת Exploded View. שימו לב שגם רשתות הפילטר הפנימיות הופרדו

2. Anatomy Of: כרזת אינפוגרפיקה עם כיתובים בעברית

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

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

פקודת Anatomy Of - כיתובים בעברית וכולם תקינים

3. Cutaway: חתך שחושף את הפנים

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

"חתך cutaway: חצי שלם, חצי חשוף עם הבוילר והצינורות."

פקודת Cutaway. דוד הנחושת והברזים נוספו על ידי המודל לבד

4. X-ray: המוצר כצילום רנטגן

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

"צילום רנטגן של המכונה, מבנה פנימי בכחול-לבן על שחור."

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

5. Blueprint: שרטוט הנדסי עם מידות

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

"הפוך לשרטוט blueprint, קווים לבנים על כחול, עם קווי מידה."

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

6. Knolling: כל החלקים בשורות ישרות

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

"סדר את כל חלקי המכונה ב-knolling, מבט מלמעלה, שורות ישרות."

פקודת Knolling. ארבע הרגליות בתחתית מסודרות במרווחים זהים

7. Hero Shot: צילום קמפיין

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

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

פקודת Hero Shot. אם אתם מוכרים מוצר, זו כנראה הפקודה שתשתמשו בה הכי הרבה

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

8. Isometric: המוצר בתוך סצנה איזומטרית

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

"איור איזומטרי של המכונה בפינת קפה, זווית 45 מעלות."

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

9. Miniature: עולם זעיר על המוצר

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

"דיורמה זעירה: בית קפה קטן על המכונה, אפקט tilt-shift."

פקודת Miniature. שם המותג הועתק גם לשלט של בית הקפה הזעיר

10. Claymation: המוצר מפלסטלינה

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

"בנה את המכונה מפלסטלינה, סגנון סטופ-מושן, טביעות אצבע."

פקודת Claymation

11. Vintage Ad: פוסטר פרסומת משנות ה-50

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

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

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

12. Sticker Sheet: דף מדבקות

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

"דף מדבקות של המכונה ואביזריה, קו מתאר לבן, רקע לבן."

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

13. Step Grid: תהליך שלם בתמונה אחת

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

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

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

14. Packaging: המוצר באריזה

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

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

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

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

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

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

שני המקרים שבהם ChatGPT הלך לאיבוד

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

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

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

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

המודל המשיך מהפלט הקודם שלו במקום לחזור לתמונת המקור

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

איפה זה לא עבד

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

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

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

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

מה באמת קרה כאן

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

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

ואם אתם רוצים ללמוד לעומק לעבוד עם מחוללי תמונות ועם שאר כלי ה-AI, קורס GenAI Master עובר על התהליך המלא.

הפוסט איך הופכים תמונת מוצר אחת ל-14 סגנונות שונים ב-ChatGPT הופיע ראשון בLet's AI בינה מלאכותית

הוא מייצר תשובה, לא שולף אותה ממגירה

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

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

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

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

אותו מנגנון - שתי תוצאות

הוא יודע הרבה, אבל לא הכול ולא תמיד את מה שצריך

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

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

המדריכים תמיד חינמיים, אבל אם בא לכם להתמקצע - יש גם קורס מקיף לבינה מלאכותית - GenAI Master

לפרטים נוספים לחצו כאן >>

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

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

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

מיקום קובע משקל

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

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

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

מחקר מ-2024, שנקרא Lost in the Middle, בדק איך מודלים משתמשים במידע בתוך הקשר ארוך. החוקרים מצאו שהביצועים היו טובים יותר כאשר המידע הרלוונטי הופיע בתחילת הקלט או בסופו, וירדו כאשר אותו מידע היה קבור באמצע.

מחקרים מאוחרים יותר הרחיבו את הבעיה. מחקר מ-2025 בשם Context Length Alone Hurts LLM Performance Despite Perfect Retrieval מצאה שגם כאשר המידע הרלוונטי זמין למודל, עצם הארכת הקלט יכולה לפגוע בביצועים במגוון משימות. מחקר נוסף מ-2025 בדק משימות של הקשר ארוך מעבר להתאמה מילולית פשוטה, וגם הוא מצא ירידה בביצועים ככל שההקשר מתארך.

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

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

ניסוח טוב יותר לא מחליף מקור

הוראות משפיעות על המודל, אבל לא שולטות בו לחלוטין

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

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

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

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

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

הוראה אחת ברורה מנצחת

בדרך כלל זו לא תקלה אחת

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

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

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

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

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

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

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

הפוסט ארבע תכונות שמסבירות איך מודלים ג'נרטיביים פועלים הופיע ראשון בLet's AI בינה מלאכותית

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

לפרטים נוספים לחצו כאן >>

למה מחיקת עמודת השם לא מספיקה

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

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

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

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

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

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

ארבע גישות שכדאי להכיר

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

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

לפני שמתחילים

מה צריך? גיליון אלקטרוני כמו Excel או Google Sheets, חשבון בכלי AI וכעשר דקות. אין צורך בהתקנות.

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

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

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

התהליך בשישה שלבים

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

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

3. מוסיפים כללי בטיחות מפורשים: כתובות אימייל רק בדומיין example.com, מזהי לקוח בפורמט CUST-0001, וללא מספרי טלפון אלא אם הם הכרחיים לבדיקה. אם חייבים לכלול טלפונים או מספרי זהות, משתמשים בערכי בדיקה ייעודיים שאינם עוברים ולידציה. בלי כללים ברורים, המודל עלול ליצור פרטים שנראים אמיתיים ואף להתלכד במקרה עם פרטים קיימים.

4. מריצים ומורידים כ-CSV: מבקשים במפורש קידוד UTF-8 with BOM, כדי שהעברית תיפתח בצורה תקינה ב-Excel.

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

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

הפרומפט שמייצר את הקובץ

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

צור קובץ CSV שמדמה ייצוא מ-CRM של חנות אונליין ישראלית, 500 שורות.

העמודות:
customer_id, age_group, region, registration_month, order_amount,
product_category, payment_method, customer_status

כללים:
- אין להשתמש בשמות, טלפונים או כתובות של אנשים אמיתיים.
- מזהה הלקוח בפורמט CUST-0001.
- כתובות מייל על הדומיין example.com בלבד.
- סכומים בשקלים, בטווח 50 עד 5,000, בהתפלגות מציאותית
  (רוב הרכישות בטווח הנמוך, מיעוט גבוה).
- אזורים: צפון, חיפה, מרכז, תל אביב, ירושלים, דרום.
- טווחי גיל בלבד, לא תאריכי לידה: 18-24, 25-34, 35-44, 45-54, 55+.
- חודש ושנה בלבד, לא תאריך מדויק.
- החזר CSV להורדה בקידוד UTF-8 with BOM.

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

אותו תהליך בקוד, עם Faker

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

from faker import Faker
import csv
import random

fake = Faker("he_IL")
Faker.seed(42)

regions = ["צפון", "חיפה", "מרכז", "תל אביב", "ירושלים", "דרום"]

with open("synthetic_customers.csv", "w", newline="", encoding="utf-8-sig") as file:
    writer = csv.writer(file)
    writer.writerow([
        "customer_id", "name", "email", "region", "age_group", "order_amount"
    ])

    for index in range(1, 501):
        writer.writerow([
            f"CUST-{index:04d}",
            fake.name(),
            f"customer{index}@example.com",
            random.choice(regions),
            random.choice(["18-24", "25-34", "35-44", "45-54", "55+"]),
            random.randint(50, 5000)
        ])

השורה Faker.seed(42) גורמת ל-Faker לייצר את אותם ערכים בכל הרצה, וזה שימושי כשבודקים מערכת ורוצים להשוות בין תוצאות. חשוב לשים לב שבדוגמה נעשה שימוש גם במודול random של Python. כדי שכל הקובץ יהיה זהה בכל הרצה, צריך לקבע גם אותו באמצעות random.seed(42). אחרת השמות יחזרו על עצמם, אך האזורים, קבוצות הגיל והסכומים עשויים להשתנות.

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

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

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

הנה פרומפט לדוגמה:

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

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

מה הסקריפט צריך לעשות:

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

2. לערבב את סדר השורות לפני שמקצים מזהה חדש, ורק אז לתת
   customer_id בפורמט CUST-0001. זה קריטי: בלי ערבוב, סדר השורות
   עצמו מאפשר לשחזר את הזהויות מול הקובץ המקורי.

3. להכליל מזהים עקיפים:
   - עיר -> אזור (צפון, חיפה, מרכז, תל אביב, ירושלים, דרום)
     לפי מיפוי אמיתי של ערים לאזורים, לא לפי טוקן.
   - תאריך_לידה -> קבוצת גיל: 18-24, 25-34, 35-44, 45-54, 55-64, 65+
   - תאריך_הצטרפות -> חודש ושנה בלבד (YYYY-MM)
   - סכום_רכישה_אחרונה -> להשאיר כמספר, אבל לעגל למאה הקרובה

4. הערת_שירות: להחליף בקטגוריה בלבד (משלוח, תשלום, מוצר, ביטול,
   שביעות רצון, אחר, ללא הערה) לפי מילות מפתח. לא להשאיר טקסט חופשי.

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

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

7. בסיום, הדפס דוח: כמה שורות עובדו, אילו עמודות נמחקו, כמה שורות
   תוקנו בבדיקת k-anonymity, וכמה ערכים ייחודיים נשארו בכל עמודה.

קרא ב-encoding utf-8-sig וכתוב ב-utf-8-sig.

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

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

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

• שמרו על קשרים בין טבלאות: אם אתם מייצרים טבלת לקוחות, טבלת הזמנות וטבלת פניות שירות, השתמשו באותו customer_id בכולן. בלי מזהה עקבי לא תוכלו לבדוק תהליכים שדורשים חיבור בין טבלאות.
• אל תשתמשו ב-XXXX כערך ממלא מקום: עמודה שמלאה באיקסים לא תעזור לבדוק מיון, סינון או חישוב. ערך דמה צריך להיות שימושי לצורך הבדיקה, ולא רק למלא שדה.
• השאירו כמה מקרי קצה בכוונה: לקוח ללא הזמנות, סכום חריג בגובהו או שדה ריק. אלה בדיוק המקרים שעלולים להפיל מערכות, ואם המאגר יהיה נקי מדי, הבאג יתגלה רק מול הלקוח.
• בדקו את שדות הטקסט החופשי בנפרד: חיפוש אחר @, אחר 05 ואחר המילה "קישור" בעמודת ההערות יכול לאתר דליפות ברורות. אל תסתפקו בחיפוש הזה בלבד, משום שמידע מזהה יכול להופיע בצורות נוספות.
• בדקו גם את שם הקובץ: קובץ בשם "לקוחות_חברת_כהן_סופי" חושף מידע עוד לפני שפותחים אותו.

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

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

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

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

מאיפה מתחילים כבר היום?

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

הפוסט איך מייצרים קובץ אקסל עם נתוני דמה ל-AI, לדאשבורדים ולבדיקות הופיע ראשון בLet's AI בינה מלאכותית

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

למה רוב הניסיונות לשפר תמונת מוצר עם AI נכשלים

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

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

מה אתם הולכים לקבל בסוף התהליך

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

לפני שמתחילים

הדרישות המקדימות מתחלקות לשניים, כי החלק השני של המדריך לא זמין לכולם.

1. לשלב התמונות צריך רק חשבון Google וגישה ל-Gemini. עבדנו כאן בגרסה החינמית לחלוטין, במודל Flash, בלי מנוי בתשלום. שווה לדעת שגוגל פיצלה את קו Flash לכמה מודלים, אז אם התוצאות אצלכם שונות כדאי לבדוק באיזה מודל אתם נמצאים דרך התפריט בתחתית תיבת הצ'אט.
2. לשלב הסרטון צריך חשבון Google Merchant Center פעיל עם פיד מוצרים. אנחנו הרצנו את זה על חשבון של חנות אמיתית שכבר עובדת. אם אין לכם חנות מקוונת עם פיד, השלב הזה פשוט לא יהיה זמין לכם, וזה בסדר: שלושת השלבים הראשונים אפשר לעשות גם בלי השלבים של הסרטון. חשוב גם לדעת שהפיצ'ר מסומן EXPERIMENT בממשק, כלומר גוגל עדיין מריצה אותו כניסוי והוא עשוי להשתנות, להיסגר או לא להופיע בכל החשבונות.

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

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

זווית נוספת של המוצר

שלב 1: מעלים את תמונות המקור ל-Gemini עם פרומפט קשיח

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

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

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

הדרישה החשובה ביותר: שמירה מוחלטת על המוצר המקורי.
יש לשמור בצורה מדויקת על:

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

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

שפר רק את איכות הצילום והפרזנטציה:

תאורת סטודיו מקצועית, רכה ומאוזנת
חדות גבוהה ופרטים ברורים
White Balance ניטרלי ומדויק
חשיפה מקצועית ללא אזורים שרופים
צל טבעי, רך ועדין מתחת למוצר
רקע לבן/אוף-ווייט נקי בסגנון צילום קטלוג מקצועי
הסרת הסביבה המשרדית, השולחן, החלונות, הכיסאות וכל האלמנטים שאינם חלק מהמוצר
מראה פרימיום, נקי ומודרני המתאים לחנות eCommerce איכותית
צילום פוטוריאליסטי לחלוטין, ללא מראה של CGI או רנדר תלת-ממד

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

Product fidelity is more important than beautification. Do not redesign, reinterpret, simplify, stylize, or modify the product in any way.

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

הפרומפט המלא עם שתי תמונות הרפרנס, במודל Flash של הגרסה החינמית

שלב 2: בודקים את התוצאה מול המקור

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

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

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

שלב 3: מנקים ומתקנים באיטרציות קצרות

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

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

אחרי ניקוי העטים והאלמנט האדום ושינוי קל של הזווית: תמונה ראשית נקייה לדף המוצר

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

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

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

בקשה של שלוש מילים מספיקה כשהעוגן כבר קיים בשיחה

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

שלב 5: הופכים תמונה אחת לסרטון 360 מעלות ב-Product Studio

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

נכנסים ל-Google Merchant Center ופותחים בתפריט הצדדי את Creative content ואז Product Studio. זה מסך שמרכז כמה כלי AI לתמונות מוצר, ביניהם החלפת רקע, הסרת רקע והגדלת רזולוציה.

לוחצים על Get started בכרטיס Animate images. שימו לב שהכרטיס מסומן NEW ושהמסך כולו מסומן EXPERIMENT.

הנתיב לפיצ'ר: Creative content ואז Product Studio ואז Animate images

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

Create a smooth 360° product video of this white mesh pen and pencil holder. Keep the product exactly unchanged in shape, color, proportions, mesh pattern, and details. Use a clean white studio background, soft professional lighting, subtle shadow, and keep the product centered throughout the full rotation. No text, no zoom, no redesign, no morphing.

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

העלאת התמונה והפרומפט לפני לחיצה על Generate

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

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

ארבע וריאציות מאותה בקשה. בוחרים את הסיבוב הכי יציב

חמישה טיפים שמשפרים את התוצאה משמעותית

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

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

1. טקסט על האריזה הוא נקודת התורפה - המוצר שבדקנו כאן הוא המקרה הקל: לבן, בלי לוגו ובלי מילה כתובה עליו. ברגע שיש על המוצר תווית, ובמיוחד תווית בעברית, הסיכוי שהמודל ישבש אותה גבוה מאוד, ופרומפט נאמנות לא פותר את זה. כתבנו בעבר על האתגר של שילוב טקסט עברי בתמונות AI, והמצב עדיין לא מושלם. אם המוצר שלכם ממותג, הריצו קודם בדיקה אחת ובדקו את התווית באיזור. אם היא נשברת, השתמשו בכלי רק להחלפת הרקע ושמרו על המוצר המקורי מהצילום.
2. נאמנות למוצר היא לא רק עניין אסתטי - תמונה שמציגה מוצר יפה יותר, גדול יותר או מוגמר יותר ממה שהלקוח יקבל בפועל היא בעיה מול חוק הגנת הצרכן, וגם עילה טובה להחזרות ולביקורות שליליות. כל רשימת האיסורים בפרומפט קיימת בדיוק בשביל זה, ולא רק כדי שהתמונה תיראה אמינה. עברו על התוצאה מול המוצר הפיזי לפני שאתם מעלים.
3. הפיצ'ר בניסוי והמכסות מוגבלות - Animate images מסומן EXPERIMENT, כלומר גוגל יכולה לשנות או לסגור אותו. במקביל, הגרסה החינמית של Gemini מגבילה את כמות יצירות התמונה ביום, אז אם אתם מריצים קטלוג שלם, פזרו את העבודה או שקלו מנוי. אם אין לכם Merchant Center בכלל, את שלב הסרטון אפשר להשלים בכלים אחרים ליצירת וידאו מתמונה, בדומה למה שהראינו במדריך על יצירת פרסומות מוצר מתמונה אחת.

מה זה אומר לעסק קטן שמוכר אונליין

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

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

הפוסט ככה מייצרים צילומי מוצר וסרטונים מקצועיים לחנות איקומרס מתמונה שצילמתם בטלפון הופיע ראשון בLet's AI בינה מלאכותית

ChatGPT can now remember your activity across the apps and websites on your computer.

With Computer History in the desktop app, future interactions feel more personalized and require less explanation. pic.twitter.com/WHZPxPp31R

— OpenAI (@OpenAI) August 13, 2026

קודם בודקים אם Computer History זמין לכם

האופציה זמינה, בשלב זה, רק באפליקציית הדסקטופ של ChatGPT למק, עבור משתמשי Pro, Business ו-Enterprise שתומכים בפיצ׳ר. הוא כבוי כברירת מחדל ודורש גם להפעיל את Memories, יכולת הזיכרון של ChatGPT.

משתמשי Pro יכולים לבחור להפעיל אותו בעצמם, בעוד שבסביבות Business ו-Enterprise מנהל סביבת העבודה צריך קודם לאפשר גישה, ורק לאחר מכן כל משתמש יכול להחליט אם להפעיל את הפיצ׳ר בחשבון שלו. Computer History לא זמין דרך גרסת הווב, דרך API או דרך Amazon Bedrock.

הנתיב לבדיקה באפליקציה הוא:

ChatGPT desktop app > Settings > Integrations > Computer history

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

בארגון, הנתיב למנהל הוא:

Workspace Settings > Permissions & roles > Enable Computer History

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

לשאול בלי לשחזר ידנית את כל רצף האפליקציות והמסמכים | OpenAI

איך מפעילים את Computer History

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

1. פתחו את אפליקציית ChatGPT במק.

2. עברו אל: Settings > Integrations > Computer history

3. בחרו: Turn on

4. קראו את ההסבר על פרטיות, הרשאות ואחסון מקומי.

5. אם תתבקשו, הפעילו את Memories (סקירה על הפיצ׳ר תמצאו כאן)

6. בחרו אילו אפליקציות ואתרים יכולים לתרום להיסטוריה.

7. אשרו את בקשות ההרשאה של macOS, אם הן מופיעות.

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

אל תאפשרו לו לראות הכול מהיום הראשון

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

הנתיב לניהול המקורות הוא: Settings > Computer history > Permissions

שם אפשר לבחור בין שתי גישות. אפשר להחריג אפליקציות ואתרים מסוימים באמצעות: Exclude these apps או Exclude these websites ואפשר לבחור גישה שמרנית יותר, שבה רק מקורות שהגדרתם מראש ייכללו בהיסטוריה: Include only these apps או Include only these websites.

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

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

מה אפשר לעשות עם זה ביום עבודה רגיל

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

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

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

לזהות מסמך לפי ההקשר שבו עבדתם עליו | OpenAI

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

איך בודקים מה נשמר ומה מוחקים

כדי לראות מה Computer History סיכם, נכנסים לציר הזמן.

הנתיב הוא: Settings > Computer history > History

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

סיכומי פעילות, אפליקציות, והצעות להפוך תהליך חוזר ל-Skill או לאוטומציה | OpenAI

כדי לשאול את ChatGPT על ההיסטוריה, השתמשו בנתיב: Settings > Computer history > History > Ask about your history

כדי למחוק היסטוריה, השתמשו באותו אזור: Settings > Computer history > History

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

איך עוצרים את האיסוף בלי לכבות הכול

לא חייבים לתת ל-Computer History לעבוד כל הזמן. אפשר לעצור ולחדש את האיסוף דרך ההגדרות או דרך שורת התפריטים של macOS.

הנתיב המהיר לעצירה הוא: macOS menu bar > ChatGPT icon > Computer History > Pause

כדי להמשיך איסוף: macOS menu bar > ChatGPT icon > Computer History > Resume

כדי לכבות את הפיצ׳ר לגמרי: Settings > Computer history ושם בוחרים בכיבוי Computer History.

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

כשעבודה חוזרת הופכת ל-Skill

אחת היכולות המעניינות של Computer History היא זיהוי תהליכים שחוזרים על עצמם. כאשר המערכת מזהה רצף עבודה חוזר, היא יכולה להציע להפוך אותו ל-Skill או לאוטומציה. Skill הוא בעצם סט הוראות או תהליך עבודה ש-ChatGPT או Codex יכולים להשתמש בו שוב, בלי שתצטרכו להסביר את כל השלבים מחדש.

לזהות תהליך שחוזר על עצמו ולהציע להפוך אותו ל-Skill לשימוש חוזר | OpenAI

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

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

Computer History שומר זמנית במק את זרם אירועי האינטראקציה, כדי ש-ChatGPT ו-Codex יוכלו להפוך אותם לזיכרונות ולסיכומי פעילות. לפי OpenAI, קבצי האירועים הזמניים נשמרים עד 48 שעות, וקבצי הזיכרון שנוצרים נשארים במחשב עד שמוחקים אותם.

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

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

זיכרון מקומי עדיין יכול להכיל מידע רגיש | OpenAI

מה עובר ל-OpenAI

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

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

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

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

לפרטים נוספים לחצו כאן >>

אם Computer History לא מתחיל לעבוד

אם האפשרות זמינה אצלכם אבל הפיצ׳ר לא מתחיל לפעול, כדאי לעבור לפי הסדר הבא: ודאו ש-Memories מופעל, עברו אל Settings > Computer history, בחרו באפשרות שמופיעה לפי מצב הפיצ׳ר: Finish setup, Resume או
Try again. אם ההגדרה עדיין לא זמינה, סגרו את אפליקציית ChatGPT ופתחו אותה מחדש.

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

לא כל יום העבודה צריך להפוך ל-Memory

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

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

הפוסט Computer History של ChatGPT: מדריך הפעלה, הרשאות, פרטיות ותקלות נפוצות הופיע ראשון בLet's AI בינה מלאכותית

טבלת ההזמנות שנעבוד איתה לאורך המדריך

למה זה עובד, ולמה זה מסוכן

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

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

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

לפני שמתחילים

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

• אקסל (כל גרסה) - גם Excel for the web החינמי מספיק לתרגול. הכל במדריך עובד גם ב-Google Sheets עם הבדלים קטנים, שנפרט בסוף.
• מודל שפה כלשהו (אפילו בגרסה החינמית) - הדוגמאות כאן צולמו מול ChatGPT, אבל Claude או Gemini יתנו תוצאה דומה. אין צורך ברישיון Microsoft 365 Copilot ואין צורך בשום תוסף.
• לא מעלים את קובץ האקסל למודל השפה - זו נקודה שחוזרת לאורך כל המדריך. בהרבה ארגונים העלאת קבצים לכלי AI חיצוני אסורה בנוהל או חסומה טכנית והשיטה כאן עובדת בדיוק למקרים האלו. אם אתם כן רוצים להבין מתי דווקא כדאי להעלות קובץ שלם לניתוח, כתבנו על כך בהרחבה במדריך על עבודה עם AI על קבצים ונתונים מספריים.

שלב 1: מתארים את הטבלה במקום להעלות אותה

המשימה שנפתור: כמה כסף גבתה הסוכנת דנה לוי במרץ 2026, רק מהזמנות שסומנו כ"שולם".

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

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

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

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

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

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

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

שלב 2: מנסחים את הבקשה

זה הפרומפט שנשתמש בו. שווה להעתיק אותו ולהחליף את מה שרלוונטי:

יש לי טבלת הזמנות באקסל. שורה 1 היא שורת הכותרות, והנתונים יושבים בשורות 2 עד 19. הנה הכותרות וכמה שורות ראשונות לדוגמה:

[כאן מדביקים].

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

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

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

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

הנוסחה שחזרה במקרה שלנו הייתה =SUMIFS(D2:D19,C2:C19,"דנה לוי",E2:E19,"שולם",A2:A19,">="&DATE(2026,3,1),A2:A19,"<"&DATE(2026,4,1)). מדביקים, מקבלים 10,200.

הנוסחה רצה בלי שגיאות ומחזירה 10,200

שלב 3: בודקים לפני שממשיכים

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

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

שימו לב לפרט קטן שמפיל אנשים: הסינון סינן סוכן וסטטוס, אבל לא תאריך. בצילום למטה שורת הסטטוס מציגה 34,650 על שמונה שורות, ובתוכן מסתתרות גם הזמנה מ-02/04 בסך 6,300 והזמנה מ-28/02 בסך 5,500. שתיהן לא שייכות למרץ. מחסירים אותן, ונשארים עם 22,850 שהם התשובה הנכונה. אפשר גם פשוט לסמן ידנית רק את שש שורות מרץ ולקבל את המספר הזה ישירות.

ספירה ידנית של אותן שורות בדיוק

הנוסחה אמרה 10,200. הספירה הידנית אומרת 22,850. יותר ממחצית הסכום האמיתי, 12,650 שקלים, נעלמו ואף אחד לא שם לב, אקסל לא הציג שגיאה. לא היה משולש אדום, לא הופיע #VALUE! ולא #REF!. מי שלא היה עוצר לבדוק היה שולח את המספר הזה לדוח.

שלב 4: הופכים את המודל לשותף לחקירה

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

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

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

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

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

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

במקרה שלנו הוא ביקש להריץ =COUNT(A2:A19), וגם ניסח תחזית מפורשת: יש 18 שורות, אז אם כל התאריכים תקינים התוצאה צריכה להיות 18, ואם תתקבל 15 זה מאשר את החשד. התוצאה הייתה 15.

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

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

שלב 5: מתקנים את הנתונים, לא את הנוסחה

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

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

הפתרון שקיבלנו: מסמנים את A2:A19, נכנסים לתפריט "נתונים", בוחרים "טקסט לעמודות", לוחצים "הבא" פעמיים, ובמסך השלישי בוחרים "תאריך" ומגדירים את הפורמט כ-DMY. שימו לב לנקודה הזו, כי אם תשאירו את ברירת המחדל MDY, התאריכים יתהפכו ו-07/03 יהפוך ל-3 ביולי.

חמישה צעדים, כולל הבחירה ב-DMY שרבים מפספסים

6. בודקים שוב. COUNT מחזירה עכשיו 18, והנוסחה המקורית קופצת מ-10,200 ל-22,850. בדיוק המספר שקיבלנו בספירה הידנית.

18 ו-22,850, בלי שנגענו בנוסחה

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

אותה שיטה, תקלה אחרת: הרווח שאי אפשר לראות

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

בטבלה שלנו מופיע הסוכן "יוסי כהן" בארבע שורות. אבל =COUNTIF(C2:C19,"יוסי כהן") מחזירה 1. בעיניים רואים ארבע, אקסל סופר אחת.

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

כשהמודל נותן תשובה נכונה ופתרון גרוע

בשלב הזה קיבלנו את הנוסחה =SUMPRODUCT(--ISNUMBER(SEARCH("יוסי כהן",C2:C19))), והיא אכן החזירה 4.

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

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

המודל עשה בדיוק את מה שביקשו ממנו: להחזיר 4. אף אחד לא אמר לו שהמטרה היא קובץ תקין. כשהתעקשנו, הוא הציע ניקוי אמיתי בעמודת עזר עם =TRIM(CLEAN(SUBSTITUTE(C2,CHAR(160)," "))), שמסירה רווחים מיותרים, תווי בקרה בלתי נראים, וגם רווח קשיח מהסוג שמגיע כשמעתיקים מדפדפן.

עמודת עזר שמנקה את השמות לפני שדורסים את המקור

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

הבדיקה האחרונה: =COUNTIF(C2:C19,"יוסי כהן"), אותה נוסחה פשוטה שהחזירה 1 בהתחלה, מחזירה עכשיו 4.

אותה נוסחה שנשברה בהתחלה, עכשיו על נתונים נקיים

טיפים שישפרו את התוצאה

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

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

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

עובדים בגוגל שיטס? כמעט הכל אותו הדבר

הפונקציות שהשתמשנו בהן, SUMIFS, COUNTIF, COUNT, LEN ו-TRIM, עובדות בשיטס באותו תחביר. שלושה הבדלים שכדאי להזכיר למודל: בשיטס אין "טקסט לעמודות" באותו מקום ובמקום זה משתמשים בתפריט "נתונים" ואז "פיצול טקסט לעמודות", מפריד הארגומנטים עשוי להיות נקודה-פסיק בהתאם להגדרות האזור, ולשיטס יש פונקציות ייחודיות כמו QUERY שלא קיימות באקסל ויכולות לפעמים לתת פתרון קצר יותר.

איך ליישם את זה בעבודה שלכם?

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

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

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

הפוסט נוסחאות אקסל בלי לדעת אקסל: המדריך המלא לעבודה עם מודל שפה הופיע ראשון בLet's AI בינה מלאכותית

סקיל הוא תיקייה, לא קובץ

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

סקיל טוב אינו רק קובץ הוראות

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

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

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

תשע קטגוריות, רעיון אחד שימושי

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

החלוקה של אנטרופיק מסבירה אילו סוגי ידע אפשר להפוך לסקיל

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

ארבעה כללים שקובעים אם סקיל בכלל יופעל

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

הטריגר עוזר למודל לדעת מתי להפעיל אותו

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

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

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

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

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

איך מתרגמים את זה לעבודה יומיומית

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

ארבעה סוגים: עושים, מעצבים, כללים ובודקים

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

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

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

הבודקים

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

האם מתקיימים תנאים שאפשר לאמת

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

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

קרא את המסמך המאושר המצורף.

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

כתוב לי צ'קליסט של חמש עד שמונה בדיקות.

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

בסיום הוסף את הצ'קליסט בתחתית הסקיל הקיים שלי כהוראה.

לאחר מכן מוסיפים לסקיל העושה (doer) את ההוראות הבאות:

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

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

הכללים (Rules)

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

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

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

ראיין אותי כדי לחלץ את הכללים שקיימים רק בראש שלי
לגבי המשימה: [תיאור המשימה].

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

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

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

מתי כלל צריך להפוך לסקיל נפרד

אל תתחילו מסקיל נפרד. התחילו משורה בתוך סקיל קיים.

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

כלל שחוזר בכמה תהליכים כבר צריך מקור אמת משלו

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

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

1. העבר אותם לסקיל חדש בשם: [שם]
2. כתוב לו תיאור שמציין בדיוק מתי יש להשתמש בו, במילים
   שמשתמש באמת יקליד.
3. עדכן את הסקילים [רשימה]: הסר מהם את הכללים הישנים,
   והחלף בשורה אחת שמפנה לסקיל החדש לפני כל פעולה רלוונטית.

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

איפה הבדיקה עדיין חלשה

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

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

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

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

אימות חזק באמת נשען על מקור חיצוני למדידה

איך מתחילים?

פתחו את רשימת הסקילים שלכם ותספרו כמה מהם עושים (doers), כמה מהם מעצבים (Formatters) וכמה מהם בודקים (Checkers). אם בחלק השלישי התשובה היא אפס, אתם כנראה במצב של רוב המשתמשים. כדי להתחיל, בחרו סקיל אחד שכבר עובד אבל עדיין דורש מעבר ידני, והורידו את תיקיית skill-hardening שבנינו עבורכם ומיועדת לשימוש חופשי.

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

כך בנויה תיקיית skill-hardening

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

הפוסט המדריך לבניית סקילים שבודקים את עצמם הופיע ראשון בLet's AI בינה מלאכותית

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

תוסף וורדפרס הוא לא בהכרח פרויקט גדול

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

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

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

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

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

כדי להמחיש את התהליך, נבנה תוסף בסיסי שעונה על צורך ברור: לדעת איזה שותף או ממליץ הביא ליד לאתר.

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

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

לפני שמבקשים מה-AI לכתוב קוד

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

לפני פתיחת הצ'אט, כדאי לענות על כמה שאלות פשוטות:

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

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

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

העיקרון החשוב: קודם אפיון, אחר כך קוד

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

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

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

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

סביבת האתר:
- WordPress 6.X
- PHP 8.X
- Elementor + Elementor Pro בגרסאות המותקנות באתר
- האתר בעברית ובכיוון RTL

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

התנהגות נדרשת:
1. במסך הניהול יהיה תפריט בשם "שותפים". לכל שותף יישמרו שם
   וקוד באנגלית. יהיה אפשר להוסיף, לערוך ולמחוק שותף.
2. כניסה לכתובת עם הפרמטר ?ref=CODE תשמור עוגייה ל-30 יום,
   רק אם הקוד קיים במערכת. קוד חדש יחליף את הקוד הקודם.
3. לאחר שליחת טופס Elementor Pro, ואם קיימת עוגייה תקינה,
   תישמר רשומה עם קוד השותף, שם הטופס, תאריך וכתובת העמוד.
4. במסך הדוח יוצגו מספר הלידים לכל שותף וטבלה מפורטת עם עימוד.

גבולות הגרסה הראשונה:
- ללא הרשמה עצמית של שותפים
- ללא אזור אישי
- ללא חישוב עמלות או תשלומים

דרישות טכניות:
- Plugin Header תקין וגרסה ברורה
- שימוש ב-register_activation_hook וב-dbDelta ליצירת הטבלה
- שימוש בקידומת הטבלאות של האתר
- Hook לטפסים: elementor_pro/forms/new_record
- בדיקת manage_options בכל פעולת ניהול
- nonce בכל פעולה שמשנה מידע
- sanitization לקלט ו-escaping לפלט לפי ההקשר
- שימוש ב-$wpdb->prepare בשאילתות שמכילות ערכים דינמיים
- תמיכה ב-UTF-8, בעברית וב-RTL
- טיפול בכשלי שמירה והצגת הודעה מתאימה למנהל

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

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

איך עוברים מהצ'אט לתוסף מותקן

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

את התוסף מעלים דרך לוח הבקרה: תוספים > הוספת תוסף > העלאת תוסף. בוחרים את קובץ ה-ZIP, מתקינים ומפעילים.

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

התקנה מוצלחת עדיין לא אומרת שהתוסף עובד

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

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

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

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

השלב שהופך הדגמה לתהליך עבודה אחראי

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

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

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

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

בדוק במיוחד:
- הרשאות לפני כל פעולת ניהול
- nonce בכל פעולה שמשנה מידע
- פעולות שינוי שאפשר להפעיל בטעות דרך GET
- שאילתות SQL וערכים דינמיים
- sanitization של קלט ו-escaping של פלט
- אימות מחדש של מידע מעוגיות ומכתובת URL
- תמיכה ב-UTF-8 ובעברית
- אזורי זמן ותאריכים
- טיפול בכשלי מסד נתונים ושגיאות שקטות
- תאימות לגרסאות WordPress, PHP והתוספים שצוינו

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

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

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

תהליך קצר שאפשר ליישם כמעט על כל תוסף קטן

אם מזקקים את המדריך, מתקבל תהליך בן שבעה שלבים:

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

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

טיפים שיחסכו זמן ותקלות

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

בקשו קובץ ZIP מוכן. כך מצמצמים טעויות בתיקיות, בשמות קבצים ובקידוד UTF-8.

ציינו את הרכיב שאליו מתחברים. ל-Elementor Pro, ל-Contact Form 7 ול-WPForms יש נקודות חיבור שונות. המילה "טופס" לבדה אינה מספיקה.

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

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

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

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

רעיונות טובים לתוסף ראשון

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

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

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

מה לא כדאי לבחור כפרויקט ראשון

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

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

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

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

אז עד כמה באמת קל לבנות תוסף בעזרת AI?

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

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

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

השאלה כבר אינה רק אם אפשר לבנות תוסף בעזרת AI. השאלה הטובה יותר היא: איזו פעולה קטנה באתר שלכם שווה להפוך לתוסף ראשון?

הפוסט תוסף וורדפרס משלכם ב-3 דקות, בלי לכתוב שורת קוד הופיע ראשון בLet's AI בינה מלאכותית

למה הריצה הידנית היא לא אוטומציה

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

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

מה נבנה כאן?

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

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

מה אתם צריכים בשביל להתחיל

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

שלב 1: מכינים את התווית ואת התיקייה

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

תווית חשבוניות בג'ימייל עם שלושה מיילים שיש בהם קבצי PDF מצורפים

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

Share ואז Copy link. המזהה של התיקייה מסתתר בתוך הכתובת שמתקבלת

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

שלב 2: פותחים פרויקט עצמאי

3. נכנסים ל-script.google.com ולוחצים New project: כאן יש הבדל מהמדריך הקודם, וכדאי לשים לב אליו. שם נכנסנו לעורך דרך התפריט Extensions בתוך הגיליון, כי הסקריפט היה צמוד לקובץ מסוים. הפעם אין קובץ אחד שהסקריפט שייך אליו, הוא עובד מול ג'ימייל ומול דרייב, ולכן פותחים אותו כפרויקט עצמאי.

פרויקט עצמאי, כי הסקריפט הזה לא שייך לקובץ מסוים

שלב 3: מבקשים מהמודל את הקוד

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

זה הפרומפט המלא שהשתמשתי בו (לא לשכוח לשנות את ה-ID של התיקייה שלכם):

אני עובד ב-Google Apps Script, בפרויקט עצמאי שנוצר דרך
script.google.com (לא מחובר לקובץ מסוים).

מה שקיים אצלי:
- תווית בג'ימייל בשם "חשבוניות" שאליה מגיעים מיילים עם קבצים
  מצורפים (בעיקר PDF)
- תיקייה בגוגל דרייב שה-ID שלה הוא FOLDER_ID_HERE

מה שאני צריך שהסקריפט יעשה בכל הרצה:
1. לחפש בג'ימייל שיחות שיש להן את התווית "חשבוניות" ואין להן
   את התווית "נשמר".
2. לעבור על ההודעות בכל שיחה ולקחת מהן את הקבצים המצורפים.
3. להתעלם מתמונות שמוטמעות בגוף המייל (חתימות ולוגואים),
   ובנוסף לדלג על כל קובץ שקטן מ-20KB.
4. בתוך התיקייה שנתתי, ליצור תת-תיקייה לפי חודש בפורמט
   YYYY-MM לפי תאריך המייל, וליצור אותה רק אם היא לא קיימת.
5. לשמור את הקובץ לתת-התיקייה של אותו חודש. אם כבר קיים שם
   קובץ באותו שם, להוסיף לשם מספר רץ כדי לא לדרוס.
6. רק אחרי ששמירת כל הקבצים של אותה שיחה הצליחה, להוסיף לשיחה
   את התווית "נשמר". אם התווית "נשמר" לא קיימת בחשבון, שהסקריפט
   ייצור אותה בעצמו.
7. אם לא נמצאה אף שיחה חדשה, לא לעשות כלום ולסיים בשקט.

דרישות נוספות:
- אם התווית "חשבוניות" לא קיימת בחשבון, לזרוק שגיאה עם הודעה
  ברורה באנגלית ולא לסיים בשקט. חשוב לי שההרצה תיכשל במקרה הזה.
- לטפל בכל שיחה בתוך try/catch נפרד, כך ששיחה בעייתית אחת
  לא תעצור את כל ההרצה. במקרה כזה לרשום לוג ולהמשיך לשיחה הבאה,
  ובלי לסמן "נשמר".
- להגביל כל הרצה ל-50 שיחות לכל היותר, כדי לא להתקרב למגבלת
  שש הדקות. אם היו יותר, לרשום את זה בלוג.
- אזור הזמן Asia/Jerusalem.
- Logger.log ברור: כמה שיחות נמצאו, כמה קבצים נשמרו, כמה קבצים
  דולגו ולמה, וכמה שיחות נכשלו.
- שם הפונקציה וההערות בקוד באנגלית.

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

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

1. הסעיף על התווית "נשמר" הוא המקבילה המדויקת לעמודת הסטטוס מהמדריך הקודם. בלעדיו, הסקריפט ישמור כל בוקר מחדש את אותן חשבוניות, ותוך שבוע תהיה לכם תיקייה עם שבעה עותקים של כל קובץ.
2. הסעיף על התקרה של 50 שיחות בהרצה קיים כי פונקציה ב-Apps Script נעצרת אחרי שש דקות. כשמריצים ידנית פעם אחת על שלושה מיילים זה לא רלוונטי. כשטריגר רץ על תיבה שהצטברו בה מאתיים מיילים לא מטופלים, זה כן.
3. והסעיף שדורש שהסקריפט יתריע לנו אם התווית לא קיימת הוא זה שנשתמש בו בסוף המדריך כדי לשבור את האוטומציה בכוונה ולראות מה קורה.

שלב 4: מדביקים, מגדירים אזור זמן, ומריצים ידנית

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

עורך Apps Script עם הקוד שהודבק ושם הפרויקט שמירת חשבוניות

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

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

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

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

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

בדרך תעברו גם במסך אדום שמודיע ש-Google hasn't verified this app, וממשיכים ממנו דרך Advanced. הסברנו את זה בהרחבה במדריך הקודם, ובקצרה: גוגל מאמתת רק אפליקציות שפורסמו לציבור, וסקריפט אישי שכתבתם לעצמכם לפני שתי דקות מעולם לא עבר אימות כזה ולא אמור לעבור.

שלב 5: בודקים שההרצה הידנית עבדה

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

חלון Execution log של Apps Script עם סיכום מוצלח של שלוש שיחות ושלושה קבצים שנשמרו

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

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

תת-התיקייה נוצרה לבד, בפורמט שמסתדר לפי סדר כרונולוגי

שלושה קבצי PDF של חשבוניות בתוך תיקיית 2026-08 בגוגל דרייב

שלב 6: מוסיפים את הטריגר

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

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

מסך Triggers ריק ב-Apps Script עם הכפתור Add Trigger

11. ממלאים את חלון ההגדרה: זה החלון החשוב ביותר במדריך:

• Choose which function to run: הפונקציה הראשית, במקרה שלנו saveInvoiceAttachmentsToDrive. שימו לב שהתפריט מציג את כל הפונקציות שבקובץ, כולל פונקציות עזר פנימיות, ובחירה שגויה כאן תיצור טריגר שרץ ולא עושה כלום.
• Choose which deployment should run: משאירים Head, כלומר תריץ תמיד את הגרסה האחרונה שנשמרה בעורך. זה מה שרוצים בסקריפט אישי.
• Select event source: Time-driven, כלומר לפי שעון.
• Select type of time-based trigger: כאן בחרנו Day timer.
• Select time of day: טווח של שעה, כאן בין אחת לשתיים בלילה. אין עומס על תיבת המייל בשעה הזו, ורוב החשבוניות של אתמול כבר הגיעו.

ההגדרה המלאה. שימו לב ל-GMT+03:00 מתחת לשעה, שמגיע מהגדרות הפרויקט

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

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

שש אפשרויות תזמון. רוב האנשים לא פותחים את התפריט הזה אף פעם

• Specific date and time להרצה חד-פעמית בתאריך ידוע. שימושי לתזכורת לאירוע מסוים.
• Minutes timer כל דקה, חמש, עשר, חמש עשרה או שלושים. מפתה, ומסוכן: הרצה כל דקה פירושה 1,440 הרצות ביום שרובן המוחלט לא ימצאו כלום. שמרו את זה לבדיקות בלבד, כמו שנעשה בעצמנו בשלב הבא.
• Hour timer כל שעה עד כל שתים עשרה שעות. מתאים לתהליכים שבאמת צריכים תגובה תוך כמה שעות.
• Day timer פעם ביום בטווח שעות שבוחרים. ברירת המחדל ההגיונית לרוב האוטומציות האישיות.
• Week timer ביום קבוע בשבוע. מצוין לדוחות סיכום.
• Month timer בתאריך קבוע בחודש. מתאים לתהליכי סוף או תחילת חודש.

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

שלב 7: ההגדרה שאף אחד לא נוגע בה וחבל

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

13. משנים ל-Notify me immediately: ההבדל הוא בין לגלות שהתהליך נפל תוך דקה לבין לגלות את זה למחרת. בתהליך שרץ פעם ביום, סיכום יומי אומר שיום שלם עובר בין הכשל להתראה. כשמדובר בחשבוניות אפשר לחיות עם זה, וכשמדובר בתהליך שאתם באמת נשענים עליו, פחות.

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

הטריגר קיים. מכאן והלאה הסקריפט רץ בלעדיכם

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

שלב 8: בואו נשבור את זה בכוונה

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

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

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

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

17. ההתראה מגיעה: תוך דקות נכנס לתיבה מייל מ-noreply-apps-scripts-notifications@google.com עם שורת הנושא Summary of failures ושם הפרויקט. בתוכו טבלה עם שעת הכשל, שם הפונקציה, סוג הטריגר, והודעת השגיאה המלאה.

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

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

18. מסתכלים במסך Executions: אייקון הרשימה בסרגל הצד מוביל למסך שמציג את כל ההרצות. כאן רואים את התמונה המלאה: הרצה אחת מסוג Editor עם סטטוס Completed, זו הידנית שלנו מקודם, ומתחתיה שתי הרצות מסוג Time-driven עם סטטוס Failed באדום. לחיצה על שורה פותחת את הלוג עם השגיאה המדויקת ואפילו את מספר השורה בקוד.

העמודה Type מבדילה בין מה שהרצתם ידנית לבין מה שהטריגר הריץ

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

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

ארבעה דברים שלא רואים במסך

1. טריגרים שייכים לחשבון, לא לקובץ - אם תעתיקו את הפרויקט או תשתפו אותו, הטריגרים לא יעברו איתו. מי שמקבל את הסקריפט מקבל קוד בלבד, וצריך להגדיר לעצמו טריגר משלו שירוץ בהרשאות שלו.
2. אין שום מנגנון שמונע כפילויות - אם תלחצו Add Trigger פעמיים על אותה פונקציה, גוגל תיצור שני טריגרים ולא תגיד מילה. בסקריפט שלנו זה יגרום לשתי הרצות מקבילות שרבות על אותם מיילים. כשמשהו מתנהג מוזר, המסך הראשון לבדוק הוא רשימת הטריגרים.
3. יש הבדל בין טריגר מותקן לטריגר פשוט - פונקציות כמו onEdit או onOpen רצות אוטומטית בלי שתגדירו כלום, אבל הן חיות בהרשאות מצומצמות ולא יכולות לשלוח מיילים או לגשת לשירותים אחרים. כשמישהו מספר לכם ש-onEdit שלו לא שולח מייל, זו הסיבה, והפתרון הוא להגדיר את אותה פונקציה כטריגר מותקן דרך אותו מסך Add Trigger.
4. לזמן הריצה יש תקרה יומית - בחשבון פרטי מדובר בכתשעים דקות ביום לכל הסקריפטים יחד, ובחשבון Workspace בכשש שעות. זה נשמע הרבה, ומספיק בקלות לתהליכים סבירים, אבל טריגר שרץ כל דקה על משימה כבדה יכול לשרוף את זה. בנוסף, מספר הטריגרים שאפשר להגדיר לסקריפט בודד מוגבל אף הוא. המספרים המדויקים מתעדכנים מדי פעם ומתפרסמים בדף המכסות הרשמי של גוגל.

טיפים שיחסכו לכם זמן

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

שתי אזהרות לפני שאתם מגדירים טריגר ראשון

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

מה לתזמן בשבוע הקרוב

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

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

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

הקוד המלא

לנוחיותכם, זה הקוד המלא שהתקבל מהמודל והורץ במדריך הזה. שימו לב להחליף בשורה הראשונה של ההגדרות את מזהה התיקייה בשלכם, ואת שמות התוויות בשמות שאתם משתמשים בהם. אנחנו ממליצים בכל זאת לייצר אותו בעצמכם דרך הפרומפט, כי הערך האמיתי הוא בשיטה ולא בקובץ הזה.

/**
 * Saves attachments from Gmail threads labeled "חשבוניות" into monthly
 * sub-folders (YYYY-MM) inside a given Drive folder, then marks the thread
 * with the "נשמר" label.
 *
 * Run manually from the editor: saveInvoiceAttachmentsToDrive
 */

// ===== Configuration =====
var ROOT_FOLDER_ID       = 'YOUR_FOLDER_ID_HERE';
var SOURCE_LABEL_NAME    = 'חשבוניות';
var DONE_LABEL_NAME      = 'נשמר';
var MIN_FILE_SIZE_BYTES  = 20 * 1024; // 20KB - anything smaller is skipped
var MAX_THREADS_PER_RUN  = 50;        // keeps a single run away from the 6-minute limit
var TIME_ZONE            = 'Asia/Jerusalem';


/**
 * Main entry point. Run this function manually from the editor.
 */
function saveInvoiceAttachmentsToDrive() {

  // The source label must exist. If it does not, fail loudly.
  var sourceLabel = GmailApp.getUserLabelByName(SOURCE_LABEL_NAME);
  if (!sourceLabel) {
    throw new Error(
      'Gmail label "' + SOURCE_LABEL_NAME + '" was not found in this account. ' +
      'Create the label in Gmail with this exact name (no extra spaces) and run again.'
    );
  }

  // Threads that carry the source label but were not processed yet.
  var query = 'label:"' + SOURCE_LABEL_NAME + '" -label:"' + DONE_LABEL_NAME + '"';

  // Fetch one extra thread so we can tell whether there is a backlog.
  var threads = GmailApp.search(query, 0, MAX_THREADS_PER_RUN + 1);

  // Nothing new: exit quietly, without creating labels or writing logs.
  if (threads.length === 0) {
    return;
  }

  var hasBacklog = threads.length > MAX_THREADS_PER_RUN;
  if (hasBacklog) {
    threads = threads.slice(0, MAX_THREADS_PER_RUN);
  }

  // Create the "done" label only once we know there is actual work to do.
  var doneLabel = GmailApp.getUserLabelByName(DONE_LABEL_NAME);
  if (!doneLabel) {
    doneLabel = GmailApp.createLabel(DONE_LABEL_NAME);
    Logger.log('Created missing Gmail label: "%s"', DONE_LABEL_NAME);
  }

  var rootFolder = DriveApp.getFolderById(ROOT_FOLDER_ID);

  // Cache of month folders, so we do not query Drive for the same month twice.
  var monthFolderCache = {};

  var stats = {
    threadsFound:    threads.length,
    threadsLabeled:  0,
    threadsFailed:   0,
    filesSaved:      0,
    skippedInline:   0,
    skippedTooSmall: 0
  };

  Logger.log('Found %s thread(s) to process.', stats.threadsFound);

  for (var t = 0; t < threads.length; t++) {
    var thread = threads[t];
    var subject = '(no subject)';

    // Each thread is isolated: a single bad thread must not stop the run.
    try {
      subject = thread.getFirstMessageSubject() || '(no subject)';
      var messages = thread.getMessages();
      var savedInThread = 0;

      for (var m = 0; m < messages.length; m++) {
        var message = messages[m];

        // Target month folder is derived from the date of the message itself.
        var monthKey = Utilities.formatDate(message.getDate(), TIME_ZONE, 'yyyy-MM');

        // Two reads: one including inline images, one without. The difference
        // tells us how many embedded images (signatures, logos) were dropped.
        var allParts    = message.getAttachments({ includeInlineImages: true,  includeAttachments: true });
        var attachments = message.getAttachments({ includeInlineImages: false, includeAttachments: true });
        stats.skippedInline += (allParts.length - attachments.length);

        for (var a = 0; a < attachments.length; a++) {
          var attachment = attachments[a];
          var originalName = attachment.getName() || 'attachment';
          var size = attachment.getSize();

          if (size < MIN_FILE_SIZE_BYTES) { stats.skippedTooSmall++; Logger.log('Skipped (under 20KB, %s bytes): "%s" | thread: "%s"', size, originalName, subject); continue; } var monthFolder = getOrCreateMonthFolder_(rootFolder, monthKey, monthFolderCache); var finalName = buildUniqueFileName_(monthFolder, originalName); monthFolder.createFile(attachment.copyBlob().setName(finalName)); stats.filesSaved++; savedInThread++; Logger.log('Saved: "%s" -> %s/', finalName, monthKey);
        }
      }

      // Reached only if every attachment in this thread was handled without
      // throwing. A thread with no qualifying attachments is also considered
      // done, so it is not re-scanned on every future run.
      thread.addLabel(doneLabel);
      stats.threadsLabeled++;
      Logger.log('Thread done (%s file(s) saved), labeled "%s": "%s"',
                 savedInThread, DONE_LABEL_NAME, subject);

    } catch (err) {
      // Not labeled, so this thread will be retried on the next run.
      stats.threadsFailed++;
      Logger.log('FAILED thread "%s": %s', subject, (err && err.message) ? err.message : err);
    }
  }

  // ===== Run summary =====
  Logger.log('--- Summary ---');
  Logger.log('Threads processed this run: %s', stats.threadsFound);
  Logger.log('Threads labeled "%s": %s', DONE_LABEL_NAME, stats.threadsLabeled);
  Logger.log('Threads failed (left unlabeled for retry): %s', stats.threadsFailed);
  Logger.log('Files saved: %s', stats.filesSaved);
  Logger.log('Files skipped - inline/embedded images: %s', stats.skippedInline);
  Logger.log('Files skipped - smaller than 20KB: %s', stats.skippedTooSmall);

  if (hasBacklog) {
    Logger.log('NOTE: the %s-thread cap was reached. More unprocessed threads remain - run again.',
               MAX_THREADS_PER_RUN);
  }
}


/**
 * Returns the YYYY-MM sub-folder inside the root folder, creating it only if
 * it does not already exist. Results are cached per run.
 *
 * @param {Folder} rootFolder Parent folder.
 * @param {string} monthKey   Folder name, e.g. "2026-08".
 * @param {Object} cache      Run-scoped cache object.
 * @return {Folder}
 */
function getOrCreateMonthFolder_(rootFolder, monthKey, cache) {
  if (cache[monthKey]) {
    return cache[monthKey];
  }

  var folder;
  var existing = rootFolder.getFoldersByName(monthKey);
  if (existing.hasNext()) {
    folder = existing.next();
  } else {
    folder = rootFolder.createFolder(monthKey);
    Logger.log('Created month folder: %s', monthKey);
  }

  cache[monthKey] = folder;
  return folder;
}


/**
 * Returns a file name that does not collide with an existing file in the
 * folder. "invoice.pdf" becomes "invoice (1).pdf", "invoice (2).pdf", etc.
 *
 * @param {Folder} folder   Target folder.
 * @param {string} fileName Desired file name.
 * @return {string}
 */
function buildUniqueFileName_(folder, fileName) {
  if (!folder.getFilesByName(fileName).hasNext()) {
    return fileName;
  }

  var dotIndex = fileName.lastIndexOf('.');
  var base = (dotIndex > 0) ? fileName.substring(0, dotIndex) : fileName;
  var ext  = (dotIndex > 0) ? fileName.substring(dotIndex)    : '';

  var counter = 1;
  var candidate = base + ' (' + counter + ')' + ext;

  while (folder.getFilesByName(candidate).hasNext() && counter < 1000) {
    counter++;
    candidate = base + ' (' + counter + ')' + ext;
  }

  return candidate;
}

הפוסט אוטומציה שרצה לבד: המדריך המלא לטריגרים ב-Google Apps Script הופיע ראשון בLet's AI בינה מלאכותית

לפני שמתחילים - מה צריך להכין

טיימלס Timeless, פלטפורמת הפגישות הישראלית, בנתה את עצמה סביב תפיסה של פעולה ולא של תיעוד בלבד. היא מזהה מחויבויות והחלטות תוך כדי השיחה, ומארגנת את מלוא ההיסטוריה של כל פרויקט לתוך חדר (Room) קבוע. החיבור לקלוד חושף את המבנה הזה לתשאול חופשי דרך פרוטוקול MCP, אותו תקן פתוח המגשר בין קלוד למקורות מידע חיצוניים.

לפני שניגשים לחיבור, כדאי לוודא שברשותכם שני מרכיבים בסיסיים:

1) חשבון Timeless פעיל: הגישה ל-MCP של Timeless שמורה למנויי המסלולים הגבוהים יותר, ולכן מומלץ לוודא שהמסלול שברשותכם כולל את היכולת הזו. אם אין לכם עדיין מנוי, ככה תעשו את זה:

2) חשבון קלוד: Timeless זמינה כקונקטור רשמי בספריית הקונקטורים של קלוד. יש לזכור שבמסלולי צוות וארגון, בעל ההרשאות בארגון נדרש לאשר את הקונקטור בטרם יוכלו חברי הצוות לחבר אותו אצלם.

חיבור Timeless לקלוד

ההגדרה הראשונית בקלוד

1) פתחו את ההגדרות: בתפריט הצד של קלוד, בחרו באפשרות ההתאמה האישית (Customize) ולאחר מכן לחצו על קונקטורים (Connectors).

לחצו על customize בתפריט הצידי

2) אתרו את Timeless: לחצו על סימן הפלוס (+) ובחרו ב- Browse connectors, או חפשו ישירות את Timeless ברשימה. מאחר שמדובר בקונקטור רשמי, אין צורך להזין כתובת שרת או פרטים טכניים כלשהם.

3) התחברו: לחצו על התחברות (Connect) הסמוך לTimeless. קלוד יפנה אתכם לתהליך אימות מהיר מול חשבון Timeless שלכם, בדרך כלל דרך חלון התחברות בדפדפן.

במסך Connectors מאתרים את Timeless ומתחברים

4) אשרו את ההרשאות: אשרו לקלוד לגשת לנתונים של Timeless, וזהו, מרגע זה הקונקטור מחובר לחשבון שלכם.

מתן הרשאה לקלוד

הפעלת הקונקטור בתוך שיחה

לאחר השלמת החיבור, הקונקטור אינו בהכרח פעיל אוטומטית בכל שיחה. כדי להפעילו, לחצו על סימן הפלוס בפינה השמאלית התחתונה של תיבת הצ'אט, בחרו בקונקטורים, וודאו שהמתג הסמוך לTimeless דלוק. מרגע זה קלוד יוכל לגשת לנתונים שלכם בכל פעם שהבקשה תצריך זאת.

וודאו שהמתג הסמוך לTimeless דלוק

למשתמשים במסלול Teams או Enterprise, השלב הזה יפעל רק לאחר שבעל ההרשאות בארגון הוסיף את הקונקטור דרך הגדרות הארגון. מדובר במנגנון בקרה מכוון, שנועד להבטיח שגישה לנתוני הפגישות של הצוות תאושר ברמה הניהולית.

מה אפשר לעשות אחרי החיבור?

כאן מתחיל החלק היישומי - מרגע שהקונקטור פעיל, קלוד מסוגל לבצע שלוש פעולות ליבה על הנתונים של Timeless: למשוך מסמך שנוצר בפגישה, לשלוף הקלטה של שיחה מסוימת, ולהציג את התמלול המלא של פגישה. סביב שלוש הפעולות הללו אפשר לבנות כמעט כל תשאול שתרצו.

פרומפטים מוכנים להעתקה:

שלוף לי את התמלול של הפגישה האחרונה שלי עם הלקוח, וסכם את שלוש ההחלטות המרכזיות שהתקבלו בה.

מצא כל שיחה מהחודש האחרון שבה דיברנו על תמחור, והוצא רשימה של כל הנקודות שהעלינו.

קח את המסמך שנוצר בפגישת האסטרטגיה של השבוע ונסח ממנו טיוטת מייל סיכום לצוות.

השימוש שמוציא מהחיבור את מלוא הערך

היכולת שפותחת אפשרויות חדשות באמת היא ההצלבה בין ידע חיצוני לבין הפגישות שלכם. אפשר לבקש מקלוד ליצור חדר חדש בTimeless ולאכלס אותו במקורות חיצוניים סביב נושא מסוים, למשל חמשת הפודקאסטים המובילים בתחום תמחור מוצרי AI. קלוד מאתר אותם, מתמלל, מסכם ומכניס אותם לחדר, ואותו חדר כבר מכיל את הפגישות שלכם ושל הצוות על אותו נושא בדיוק.

צור חדר בTimeless עם חמשת הפודקאסטים הטובים ביותר על תמחור מוצרי AI, ואז השווה בין מה שנאמר בהם לבין מה שאנחנו החלטנו בפגישות הצוות שלנו על אותו נושא.

התוצאה היא שני סוגי ידע המתכנסים למקום אחד: תובנותיהם של המומחים החדים ביותר בתחום, לצד מה שאתם עצמכם ניסחתם בפגישות. מכאן אפשר להפנות שאלות שחוצות את שני המקורות בעת ובעונה אחת, וזוהי בדיוק ההעמקה שנדרשת כאשר מבקשים להבין נושא לאשורו.

הערת אבטחה חשובה ביותר

קונקטור המחזיק בגישה לתמלולים ולהקלטות של הצוות שלכם הוא קונקטור בעל הרשאות רגישות. לפני שתחברו אותו, בדקו אילו הרשאות אתם מעניקים, בררו אם הקונקטור קורא מידע בלבד או גם מבצע פעולות, והתחילו מרמת ההרשאה הנמוכה ביותר האפשרית. בסביבה ארגונית, ההחלטה אילו קונקטורים מותרים ולאיזה מידע תינתן להם גישה צריכה להתקבל ברמת הניהול ולא באופן פרטני.

כמו כן, אם עדיין לא עשיתם את זה, מומלץ לכבות את אפשרות אימון המודלים של קלוד, כדי שהדאטה שלכם לא ידלוף החוצה.

מרגע שהידע הטמון בשיחות שלכם נעשה נגיש דרך קלוד, השאלה כבר אינה מה הכלי מסוגל לעשות, אלא מה תבחרו אתם לשאול. כל מה שנאמר אי פעם בחדר יושב מעתה זה לצד זה עם כל מה שהעולם יודע על אותו נושא. התחילו מפגישה אחת שאתם זוכרים שהתקבלו בה החלטות חשובות, ובקשו מקלוד לחלץ אתכן עבורכם. משם, הדרך אל שימושים מורכבים יותר קצרה בהרבה.

הפוסט המדריך לחיבור Timeless לקלוד – ניתוח ההקלטות והתמלולים שלכם הופיע ראשון בLet's AI בינה מלאכותית

סקיל טוב הוא נוהל עבודה. הוא מסביר למודל מתי להיכנס לפעולה, מה המשימה שלו, באיזה סדר לעבוד, איזה קבצים או כלים רלוונטיים, מתי צריך לעצור ולשאול ומה לבדוק לפני שמחזירים תוצאה. בתיעוד הרשמי של OpenAI, סקילים מתוארים כדרך לארוז הוראות, משאבים וסקריפטים כדי ש-ChatGPT ו-Codex יוכלו לבצע תהליך עבודה בצורה אמינה יותר. השאלה החשובה היא איך כותבים סקיל שהמודל באמת יודע להשתמש בו. כזה שמכוון אותו, נותן לו כללים ברורים בלי להפוך למסמך מסורבל, ומגדיל את הסיכוי לקבל תוצאה עקבית ואמינה גם כאשר הבקשות משתנות.

המדריכים תמיד חינמיים, אבל אם בא לכם להתמקצע - יש גם קורס קלוד קוד (Claude code) וסביבת אנטרופיק

לפרטים נוספים לחצו כאן >>

מה יש בתוך Skill?

ברמה הפשוטה ביותר, סקיל (Skill) הוא תיקייה שבמרכזה קובץ הוראות בשם SKILL.md. הקובץ הזה כולל לפחות את שם הסקיל, התיאור שלו והוראות העבודה הבסיסיות. אפשר לצרף אליו גם קבצים נוספים, כמו תבניות, מסמכי מדיניות, דוגמאות, נכסי מותג או סקריפטים לביצוע פעולות קבועות.

SKILL.md הוא הליבה. קבצי עזר, סקריפטים ונכסים מצטרפים רק כאשר הם נחוצים

הנקודה החשובה היא ש-ChatGPT ו-Codex לא מתחילים מקריאת כל ההוראות המלאות. הם רואים תחילה את השם והתיאור, ורק אם הסקיל נמצא מתאים לבקשה, ההוראות המלאות נטענות מתוך SKILL.md. לכן התיאור צריך להיות חד, וגוף ההוראות צריך להכיל רק מידע שבאמת נחוץ לביצוע העבודה.

התחילו ממטרה אחת ברורה

סקיל טוב מתחיל ממטרה ברורה. הוא יכול לכלול כמה פעולות, כל עוד הן שייכות לאותה משימה. למשל, סקיל לעריכת מאמרים טכנולוגיים יכול לשכתב, לפשט, לבדוק מבנה ולהציע כותרות. אלו פעולות שונות, אבל הן מובילות לאותה תוצאה: טקסט מגזיני ברור, מדויק ומתאים לפרסום.

לעומת זאת, סקיל שאמור לכתוב, לחקור, לעצב, לפרסם, לשלוח מיילים ולנהל משימות עלול להפוך במהירות למבולבל ולא צפוי. אם יש כמה תהליכים שונים, עדיף לפצל אותם לכמה סקילים ממוקדים. ככל שהמטרה ברורה יותר, קל יותר למודל להבין מתי הסקיל רלוונטי ומה נחשב תוצאה טובה.

התיאור הוא שער הכניסה

התיאור של הסקיל הוא לא טקסט שיווקי. השם והתיאור הם האותות המרכזיים שעוזרים למערכת להחליט אם הסקיל מתאים לבקשה. רק לאחר הבחירה בו, המערכת טוענת את ההוראות המלאות. תיאור כמו “עוזר בכתיבה” כמעט לא אומר כלום. כתיבה של מה? עבור מי? בעברית או באנגלית? האם מדובר בשכתוב, עריכה, כתיבה מאפס או בדיקת עובדות?

השם והתיאור עוזרים למערכת להחליט אם הסקיל מתאים לבקשה

תיאור טוב יהיה למשל: “עורך מאמרים וסקירות טכנולוגיות בעברית לקהל לא טכני. יש להשתמש בו כאשר המשתמש מבקש לכתוב, לשכתב, לפשט או לבדוק כתבה על AI וטכנולוגיה”.

כדאי לציין בתיאור גם את גבולות השימוש. אם הסקיל מיועד למאמרים טכנולוגיים מגזיניים, אפשר להבהיר שהוא אינו מיועד לכתיבה אקדמית, למסמכים משפטיים או לפוסטים שיווקיים קצרים. אל תשמרו את המידע הזה רק בתוך הוראות העבודה, משום שהמערכת צריכה להחליט אם להפעיל את הסקיל עוד לפני שהיא קוראת אותן.

גם תיאור טוב לא מבטיח שהסקיל יופעל בכל פעם. לכן כדאי לבדוק אותו מול בקשות אמיתיות ולראות אם הוא נכנס לפעולה בזמן הנכון.

כתבו תהליך, לא רשימת משאלות

סקיל צריך להסביר איך לבצע את העבודה מתחילתה ועד סופה. רצף פשוט יכול להיראות כך: קודם קוראים את החומר שסיפק המשתמש, מזהים את הנושא המרכזי ואת קהל היעד, בודקים אם חסר מידע חיוני, בונים מבנה, כותבים בשפה נגישה, ואז מבצעים בדיקת דיוק ובהירות.

רצף כזה מצמצם את הסיכוי שהמודל ידלג על שלב חשוב. הוא גם עוזר לו להבין מה קודם למה. למשל, לא כדאי לנסח מאמר מלא לפני שבודקים אם חסר מקור קריטי, ולא כדאי לעצב מצגת לפני שמבינים מה המסר המרכזי.

מצד שני, אין צורך לפרק כל פעולה קטנה. מודלים כבר יודעים לסכם, להשוות, לנסח ולארגן מידע. ההוראות צריכות להתמקד בדברים הייחודיים לתהליך שלכם: מה אסור לפספס, מה סדר העבודה, אילו החלטות חשובות, ואיך נראית הצלחה.

התאימו את רמת הפירוט למשימה

לא כל סקיל צריך להיכתב באותה רמת פירוט. במשימות שבהן קיימות כמה דרכים טובות להגיע לתוצאה, אפשר לתת למודל עקרונות ולהשאיר לו מקום לשיקול דעת. כתיבת מאמר, הצעת כותרות או בניית רעיון למצגת הן דוגמאות טובות לכך.

כאשר המשימה רגישה לטעויות או חייבת להתבצע תמיד באותה צורה, צריך להיות מדויקים יותר. למשל, שינוי שמות של מאות קבצים, חישוב תשלומים או הפקת מסמך לפי מבנה מחייב. במקרים כאלה כדאי להגדיר סדר פעולות ברור, תנאי עצירה ובדיקות, ולעיתים להשתמש בסקריפט קבוע.

משימה רגישה לטעויות דורשת תהליך מדויק, גבולות ובדיקות

המטרה היא לתת למודל את מידת החופש שמתאימה למשימה. יותר מדי חופש בתהליך רגיש יוצר טעויות. יותר מדי הוראות במשימה יצירתית עלולות להוביל לתוצאה נוקשה וחסרת חיים.

הגדירו תוצאה שאפשר לבדוק

הוראות כמו “תכתוב טוב”, “תעבוד מקצועי” או “תכין משהו איכותי” משאירות יותר מדי מקום לפרשנות. כדי לקבל תוצאה עקבית, צריך להגדיר מאפיינים שאפשר לבדוק.

במקום “כתבה טובה”, אפשר לבקש ״כתבה באורך 700 עד 900 מילים, בעברית פשוטה לקהל לא טכני, עם כותרת ראשית, כותרות משנה, הסבר קצר לכל מונח מקצועי, בלי להוסיף עובדות שלא הופיעו במקורות, ועם בדיקת דיוק בסוף״.

אותו עיקרון נכון גם למשימות אחרות. אם הסקיל בודק חוזים, הגדירו אילו סעיפים לחפש ומה נחשב חריגה. אם הוא יוצר מצגות, הגדירו מספר שקפים, מבנה, סגנון וקריטריונים לתוצאה מוכנה. איכות משתפרת כאשר היא מתורגמת להתנהגות ברורה.

הסבירו את ההיגיון רק כשזה עוזר

לפעמים כדאי להסביר למה כלל מסוים חשוב. למשל, “הסבר כל מונח מקצועי בפעם הראשונה שהוא מופיע, משום שהכתבה מיועדת לקוראים שאינם מגיעים מרקע טכנולוגי”. הסיבה עוזרת למודל להפעיל שיקול דעת גם במקרים שלא תיארתם מראש.

אבל סקיל הוא לא מאמר תיאורטי. אין צורך לפרט את כל תפיסת העולם שמאחורי המשימה. הסבר טוב הוא קצר, מעשי, ומחובר להחלטה שהמודל צריך לקבל בזמן העבודה.

קבעו מתי שואלים ומתי ממשיכים

סקילים רבים נכשלים לא מפני שהם לא יודעים לבצע את המשימה, אלא מפני שהם עוצרים יותר מדי או מנחשים יותר מדי. לכן כדאי להגדיר מתי חסר מידע שמצדיק שאלה. כלל טוב יכול להיות: ״אם חסר מידע שחיוני לביצוע המשימה, שאל עד שלוש שאלות קצרות. אם אפשר להתקדם באמצעות הנחה סבירה, ציין את ההנחה והמשך״.

כך מצמצמים עצירות מיותרות, בלי לעודד את המודל להמציא פרטים חשובים. אם קהל היעד חסר אך ברור מההקשר, אפשר להמשיך. אם חסר מקור שעליו נשענת טענה מרכזית, עדיף לעצור או לסייג.

תנו גבולות, אבל אל תהפכו אותם לגדר אינסופית

סקיל טוב צריך לדעת גם מה לא לעשות. למשל, לא להמציא נתונים או מקורות, לא לפרסם או לשלוח תוכן בשם המשתמש בלי אישור מפורש, לא למחוק קבצים קיימים, ולא להמשיך אם חסר מידע שעלול לשנות החלטה מהותית.

הגבולות צריכים להיות קשורים לסיכון אמיתי. רשימת איסורים ארוכה מדי עלולה להפוך את הסקיל לנוקשה, זהיר מדי או פחות שימושי. עדיף לבחור כמה כללים חדים שמונעים טעויות משמעותיות.

השתמשו בקבצים נלווים רק כשיש להם תפקיד

לא כל מידע צריך להיכנס למסמך ההוראות הראשי. סקיל יכול להיעזר גם במסמכי מדיניות, תבניות, דוגמאות לתוצרים רצויים, נכסי מותג או סקריפטים שחייבים לרוץ בצורה קבועה.

אם הסקיל יוצר הצעות מחיר, עדיף לשמור את התבנית כקובץ נפרד במקום לתאר את כל העיצוב בתוך ההוראות. אם הוא כותב בסגנון מערכת מסוים, אפשר לצרף דוגמאות טובות או מדריך סגנון.

הכלל פשוט: הוסיפו רק חומרים שהסקיל באמת צריך כדי לבצע את העבודה. עוד מידע לא תמיד משפר תוצאה. לפעמים הוא רק מקשה על המודל להבין מה חשוב.

הוסיפו בדיקה עצמית עם קריטריונים ברורים

בסוף התהליך, בקשו מהסקיל לבדוק את העבודה לפני שהוא מחזיר אותה. לא מספיק לכתוב “בדוק את עצמך”. צריך להגדיר מה לבדוק. לדוגמה, האם כל דרישות המשתמש קיבלו מענה, האם חסר מידע מהותי, האם נוספו טענות שלא ניתן לבסס, האם המבנה תואם לפורמט המבוקש, האם השפה מתאימה לקהל היעד, והאם יש חזרות או סתירות.

בדיקה כזאת לא מבטיחה שלמות, אבל היא משפרת את הסיכוי לתפוס טעויות לפני שהן מגיעות למשתמש.

המדריכים תמיד חינמיים, אבל אם בא לכם להתמקצע - יש גם קורס מקיף לבינה מלאכותית - GenAI Master

לפרטים נוספים לחצו כאן >>

איך מתחילים בפועל?

אפשר לבנות סקיל ידנית, אבל לרוב המשתמשים הדרך הנוחה יותר היא להיעזר בכלי יצירה מובנה. הדרך ליצירת Skill תלויה בממשק שבו עובדים וב-Skills הזמינים בחשבון. באפליקציית ChatGPT למחשב אפשר לפתוח את אזור ה-Skills ולבחור ב-Skill Creator. אפשר גם להקליד @ ולבחור אותו מתוך הרשימה, אם הוא מופיע בה.

ב-Codex CLI או בתוסף של Codex לסביבת הפיתוח אפשר לפתוח את רשימת ה-Skills באמצעות skills/, או להקליד $ ולבחור ב-Skill Creator. הקלדת skill-creator@ או skill-creator$ כטקסט רגיל לא תעבוד בכל ממשק.

אם Skill Creator אינו זמין, עדיין אפשר לבקש מהמודל להכין טיוטה לקובץ SKILL.md. לאחר מכן צריך לבדוק את המבנה, לאמת אותו ולהתקין את ה-Skill בדרך המתאימה לסביבת העבודה.

אם קל יותר להראות את העבודה מאשר להסביר אותה, אפשר להשתמש גם ב-Record & Replay. הכלי מקליט תהליך עבודה, בוחן את השלבים, ויוצר מהם טיוטה ראשונית של סקיל. גם במקרה כזה, העבודה לא נגמרת בהקלטה. צריך לעבור על ההוראות, לדייק את התיאור, להסיר מידע מיותר ולבדוק את הסקיל מול כמה בקשות אמיתיות.

אגב, אותו רעיון זמין גם בקלוד עם האפשרות להקלטת תהליך עבודה עם צילום מסך והנחיות דיבור והפיכתו לסקיל.

מי שמעדיף לבנות ידנית יכול להתחיל מתיקייה פשוטה עם קובץ SKILL.md, שבו מופיעים שם, תיאור והוראות. זה מספיק לסקיל בסיסי. קבצים נוספים, סקריפטים ותבניות כדאי להוסיף רק כאשר הם באמת משפרים את הביצוע.

בדקו את ה-Skill מול בקשות אמיתיות

אל תניחו שהסקיל עובד רק מפני שההוראות נראות טובות. צריך לנסות אותו בכמה מצבים: בקשה רגילה, בקשה שחסר בה מידע, בקשה מורכבת, בקשה מחוץ לתחום, ובקשה שבה שני כללים עלולים להתנגש.

כאשר הוא נכשל, אל תוסיפו אוטומטית עוד הוראות. קודם צריך להבין מה באמת קרה. אולי התיאור לא מפעיל אותו בזמן. אולי שלבי העבודה אינם ברורים. אולי חסרה תבנית. ואולי מדובר במקרה קצה שלא כדאי להכניס לתהליך המרכזי.

סקיל טוב משתפר בכל פעם שמזהים היכן התהליך נשבר ומתקנים את הנקודה המדויקת.

שמרו על הוראות שיחזיקו לאורך זמן

שמות מודלים, כפתורים, תפריטים ותכונות מוצר משתנים. אם פרט כזה אינו חיוני, לא כדאי לבנות עליו את הסקיל. עדיף להשתמש בניסוחים יציבים כמו “המודל הזמין שמתאים ביותר למשימה”, “הכלי הפעיל לעריכת מסמכים” או “ההנחיות המעודכנות שסיפק המשתמש”.

כאשר חייבים להשתמש בכלי מסוים, ציינו אותו במפורש והסבירו למה הוא נדרש. ההבחנה הזאת עוזרת לסקיל להישאר שימושי גם כאשר המערכת שסביבו משתנה.

חמשת המרכיבים שהופכים Skill לנוהל עבודה ברור

המבנה הפשוט של Skill טוב

אפשר לחשוב על סקיל כמערכת עם חמישה חלקים. זיהוי, שמסביר מתי להשתמש בו. מטרה, שמגדירה מה הוא אמור להפיק. תהליך, שמסביר איך לבצע את המשימה. גבולות, שקובעים מה אסור לעשות ומתי לעצור. ובדיקה, שמוודאת שהתוצאה מוכנה למסירה.

פרומפט מנחה את המודל בבקשה מסוימת. סקיל אורז דרך עבודה שלמה שאפשר להפעיל שוב, כולל ההוראות, הגבולות, הבדיקות והמשאבים הנלווים. כאשר הוא כתוב היטב, הוא לא מבטיח תוצאה זהה בכל הרצה, אבל הוא נותן למודל מסלול עבודה יציב יותר. זה מה שהופך אותו מכלי עזר נקודתי לנוהל שאפשר להתחיל לסמוך עליו.

הפוסט איך בונים Skill שעובד ב-ChatGPT? המדריך המלא שיהפוך הוראות כלליות לנוהל עבודה הופיע ראשון בLet's AI בינה מלאכותית

גוגל הציגה את Spark כסוכן ה-AI האישי שלכם בתוך אפליקציית ג'מיני (Gemini), פיצ'ר שנועד לנהל משימות מרובות שלבים מתחילתן ועד סופן. הרעיון הבסיסי פשוט: במקום לחזור שוב ושוב על אותה בקשה, אתם מגדירים מטרה - והסוכן דואג לביצוע. אבל מתחת לפשטות הזאת מסתתרת ארכיטקטורה שכדאי להבין לפני שנכנסים לעומק.

Credit: Google

מה זה בעצם Gemini Spark

הדרך הכי מדויקת לתאר את Spark היא דרך ההשוואה למצב Work של ChatGPT ול- Cowork בקלוד: שלושתם סוכני AI שיודעים לקחת משימה מורכבת ולבצע אותה עבורכם על פני כמה כלים ושלבים. כאן נמצא ההבדל המהותי: בעוד שחלק מהפתרונות רצים לוקאלית על המחשב שלכם, Spark רץ בתוך הענן של גוגל.

המשמעות המעשית גדולה - גוגל מציינת שהסוכן עובד ברקע גם אם הטלפון והמחשב כבויים. אתם מגדירים משימה, סוגרים את המחשב, והעבודה ממשיכה. זה הבדל בין כלי שתלוי במכשיר שלכם לבין שירות שחי בשרתים ופועל באופן עצמאי, תמיד תחת ההכוונה שלכם.

שלושת אבני הבניין: משימות, מיומנויות ותזמונים

כדי להבין איך Spark חושב, גוגל מפרקת אותו לשלושה מרכיבים שהיא מכנה "מה", "מתי" ו"איך". ההבחנה הזאת שימושית מאוד, כי היא מסבירה למה הסוכן מסוגל לעשות דברים שצ'אטבוט רגיל לא יכול.

המרכיב הראשון הוא המשימה (Task):  "תכנן ונהל לי את נסיעת העסקים ללונדון".

המרכיב השני הוא התזמון (Schedule):  אפשר לקבוע זמן קבוע, למשל "כל יום ראשון ב-9 בבוקר", או תנאי שמפעיל את המשימה, למשל "כשהטיסה שלי מתעכבת".

המרכיב השלישי הוא המיומנות (Skill): אוסף הוראות שאתם מלמדים את הסוכן כדי שידע לבצע פעולה חוזרת בדיוק כמו שאתם רוצים.

המיומנויות הן אולי החלק המעניין ביותר, כי הן בדיוק אותו רעיון שכבר קיים בקלוד וב-ChatGPT. אתם יכולים, למשל, לבקש מ-Spark לקרוא את חמישים המיילים האחרונים שכתבתם, להפוך אותם למדריך סגנון, ולשמור את זה כמיומנות שתופעל בכל פעם שתבקשו ממנו לנסח מייל. פעם אחת אתם מגדירים, ומשם והלאה הסוכן פשוט יודע.

לאילו אפליקציות Spark מתחבר

הכוח האמיתי של סוכן נמדד במה שהוא מסוגל לגעת בו. כאן Gemini Spark נשען על האקו סיסטם של גוגל, ומתחבר באופן טבעי לשורה ארוכה של שירותים. לפי גוגל, הסוכן יכול לפעול מול Google Workspace על כל רכיביו: ג'ימייל (Gmail), יומן, גוגל דוקס (Docs), שיטס (Sheets), סליידס (Slides), דרייב (Drive), Keep ו-Tasks. בנוסף, יש חיבור לשירותי החיפוש של גוגל, כולל חיפוש, מפות, טיסות ומלונות, וגם ל-YouTube.

החיבורים הללו כבויים כברירת מחדל. כדי להפעיל אותם צריך להיכנס להגדרות ולאשר כל אחד בנפרד, וזו החלטה מכוונת שנוגעת לפרטיות ולשליטה. ברגע שהם דלוקים, הסוכן יכול לחצות בין השירותים ולבצע משימה שנוגעת בכמה מהם בבת אחת: לקרוא מייל, לחלץ ממנו פרט, לרשום אותו ב-Sheets וליצור תזכורת ביומן, הכול ברצף אחד.

מעבר לאפליקציות של גוגל

Spark לא נעצר בגבולות של גוגל. גוגל מפרטת שהסוכן מתחבר גם למספר אפליקציות צד שלישי, ביניהן קנבה (Canva), דרופבוקס (Dropbox),  Instacart, OpenTable ו-Zillow. משתמשים מנוסים שימו לב: אפשר להוסיף גם חיבורי אפליקציות מותאמים אישית, מה שפותח את הדלת לשילוב כלים חיצוניים דרך ממשק מוגדר.

הדפדוף בענן ובמחשב שלכם

אחת היכולות שמייחדות את Spark היא הדפדוף האוטומטי. הסוכן יכול לגלוש ברשת כדי לבצע משימות כמו קניות, הזמנת נסיעות או שריון מקום במסעדה. באמצעות שתי דרכים: דפדפן מרוחק שרץ בענן, שמאפשר למשימה להמשיך גם כשהמחשב סגור, ודפדפן מקומי, ה-Chrome שעל המכשיר שלכם, שנותן לסוכן גישה לאותם אתרים שאליהם אתם מחוברים. אם תסגרו את המחשב באמצע משימה שרצה בדפדפן המקומי, Spark עשוי לעבור לדפדפן המרוחק כדי להשלים אותה.

מה צריך כדי להשתמש, ואיפה זה זמין

כאן חשוב לדייק, כי סביב ההשקה נוצר בלבול. הגישה ל-Spark אינה פתוחה לכולם. לפי גוגל, נכון לשלב הזה נדרש להיות בן 18 ומעלה, להתחבר לאפליקציה עם חשבון גוגל אישי (חשבונות עבודה או לימודים עדיין לא נתמכים), ולהחזיק במנוי Google AI Pro או Ultra. בנוסף צריך שההגדרה Keep Activity תהיה פעילה.

הזמינות הגיאוגרפית גם היא מוגבלת. הפיצ'ר זמין בכל מקום שבו אפליקציות ג'מיני נתמכות, למעט האזור הכלכלי האירופי (האיחוד האירופי לרבות איסלנד, ליכטנשטיין ונורווגיה), ניגריה, שוויץ ובריטניה. מבחינת פלטפורמות, בשלב זה Spark עובד באפליקציה לנייד, באפליקציה ל-Mac ובאתר של ג'מיני בדפדפן. חשוב לשים לב שהמידע על תנאי הזמינות משתנה במהירות ככל שגוגל מרחיבה את הגישה, כך שכדאי לבדוק את הפרטים העדכניים ישירות במקור.

הצד השני של האוטונומיה

סוכן שפועל בשמכם, נכנס למיילים, גולש ברשת ומבצע פעולות, הוא כלי עוצמתי אבל גם כזה שדורש זהירות. גוגל עצמה לא מסתירה את זה ומגדירה את Spark כפיצ'ר ניסיוני בשלבי פיתוח מוקדמים, שהפיקוח שלכם עליו חיוני.

הסיכון המרכזי שגוגל מדגישה נקרא הזרקת פקודות (Prompt Injection). זהו מצב שבו תוכן חיצוני, כמו אתר, מייל או מסמך, מכיל הוראות זדוניות שמוסתרות מכם אבל גלויות לסוכן. אם הסוכן קורא את ההוראות האלה תוך כדי משימה, הוא עלול להתפתות לבצע פעולות לא מכוונות, למשל לשלוח מידע פרטי החוצה. כדי להתגונן, Spark מתוכנן לבקש את אישורכם לפני פעולות מסוימות כמו שליחת הודעות, שינוי נתונים או ביצוע רכישות, ולעצור ולבקש שתשתלטו על הדפדפן כשנדרש להזין סיסמאות או פרטי תשלום.

ההמלצה המעשית שעולה מכל זה ברורה: אל תזינו מידע רגיש כמו פרטי התחברות או תשלום ישירות לתוך שרשור המשימה, ואל תתזמנו משימות שאתם לא לגמרי בנוח איתן. הפיקוח האנושי הוא לא תוספת אלא חלק מהותי מהאופן שבו הכלי אמור לעבוד.

למה זה מסמן מגמה רחבה יותר?

לבדו, Spark מצטייר כעוד פיצ'ר בשורת ההכרזות של גוגל. אבל התמונה משתנה כשמצרפים אותו אל מצב Work של ChatGPT ואל Cowork של קלוד. תוך חודשים ספורים, שלוש החברות שמובילות את התחום התכנסו לאותה הבנה: הדור הבא של העוזרים החכמים לא יסתכם במענה על שאלות, אלא בסוכנים שלוקחים משימה שלמה ומריצים אותה מקצה לקצה.

ההבדל בין גוגל לאחרים נמצא במיקום - בזמן שחלק מהמתחרים מריצים את הסוכן קרוב למשתמש, גוגל מהמרת על הענן שלה ועל האינטגרציה העמוקה עם האקו סיסטם של Workspace. מי שכבר חי בתוך ג'ימייל, דרייב ויומן של גוגל, יקבל סוכן שמכיר את כל השטח הזה מבפנים. השאלה שנשארת פתוחה היא לא אם סוכנים כאלה יהפכו לחלק מהשגרה, אלא באיזו מהירות נלמד לסמוך עליהם מספיק כדי לסגור את המחשב ולתת להם לעבוד.

הפוסט Gemini Spark: הסוכן האישי של גוגל שרץ בענן 24/7 הופיע ראשון בLet's AI בינה מלאכותית

המדריכים תמיד חינמיים, אבל אם בא לכם להתמקצע - יש גם קורס וייב קודינג אקספרס Vibe Coding Express

לפרטים נוספים לחצו כאן >>

אז מה זה בכלל MCP?

פרוטוקול MCP, ראשי תיבות של Model Context Protocol, הוא סטנדרט תעשייתי מתפתח שמחבר בין כלי בינה מלאכותית למוצרים אחרים. הרעיון פשוט: כשלאפליקציה יש שרת MCP, כל כלי בינה מלאכותית יכול לתפקד כלקוח של אותו שרת ולהשתמש באפליקציה ישירות בשם המשתמש.

הזרימה עובדת כך. מישהו מבקש מ-ChatGPT או מקלוד לבצע פעולה שהאפליקציה שלכם יודעת לטפל בה. העוזר החכם פותח את שרת ה-MCP של האפליקציה וקורא רשימה בשפה פשוטה של כל מה שהיא יכולה לעשות: להגיש הוצאה, ליצור הצעת מחיר, להפיק דוח. הוא בוחר את הפעולה שמתאימה לבקשה, מעביר אותה לאפליקציה, וזו מבצעת את העבודה ומחזירה תוצאה. מכיוון שמדובר בפרוטוקול משותף, שרת MCP אחד הופך את התוכנה שלכם לתואמת לרוב כלי הבינה המלאכותית בבת אחת, בלי לבנות אינטגרציה נפרדת לכל אחד.

מה אפשר לעשות עם זה בפועל?

את הכלים שבניתם ב-Lovable אתם יכולים עכשיו להפעיל ישירות מתוך ChatGPT, קלוד וכלי בינה מלאכותית אחרים (בדומה לחיבורי mcp מוכרים אחרים). כל מה שצריך הוא לבקש מ-Lovable להפעיל את אינטגרציות הסוכן על האפליקציות הפומביות שכבר פרסמתם. מרגע שהחיבור פעיל, נפתחות כמה קטגוריות שימוש עיקריות.

הציוץ הרשמי של Lovable

המשתמשים שלכם יכולים למשוך נתונים מהאפליקציה לצורך ניתוח ודיווח, למשל "פרקו לי את ההוצאות של השבוע לפי ספק". הם יכולים להפעיל תהליכי עבודה שלמים מתוך העוזר החכם, כמו קידום אוטומטי של הזמנות לשלב הנכון. והם יכולים להפעיל את המומחיות שהטמעתם באפליקציה, למשל להעביר טיוטה דרך מסגרת עבודה שבניתם ולקבל משוב.

שימו לב!  כל כלי בשרת ה-MCP מייצג פעולה בודדת מהאפליקציה. אם ניקח פורטל לקוחות, Lovable עשויה להציע כלי לקריאה בלבד שמציג בקשות פתוחות, כלי שיוצר בקשה חדשה, וכלי שבודק את סטטוס הבקשה. כשלקוח שואל את העוזר החכם שלו אם יש בקשות שממתינות לו, העוזר מזהה שהכלי המתאים הוא זה שמציג בקשות פתוחות, קורא לו ומחזיר תשובה עם נתונים חיים מהאפליקציה.

סוגי אפליקציות שמתאימים לחיבור

אינטגרציות סוכן עובדות הכי טוב כשהאפליקציה מכילה נתונים, תהליכי עבודה, ידע או מומחיות שחוזרת על עצמה. מערכת ניהול קשרי לקוחות יכולה לחשוף כלים למציאת לקוח, עדכון שלב עסקה וניסוח מעקב. כלי להצעות מחיר יכול לייצר הצעה מתוך מפרט או להשוות אפשרויות. פורטל לקוחות יכול לאפשר הגשת מסמכים ובדיקת סטטוס. לוחות מחוונים יכולים לתחקר מדדים ולסכם מגמות, ומאגרי ידע יכולים לחפש מאמרים ולשלוף מדיניות מדויקת.

מה כבר בונים עם זה?

בשלב הגישה המוקדמת התגלה דפוס ברור של אפליקציות תפעוליות שמוסיפות שרתי MCP כדי שעוזרים חכמים יוכלו לקדם עבודה. פלטפורמת יוצרים ב-Lovable מסייעת למשתמשים שלה לבחון הצעות ולהגיב עליהן ישירות מ-ChatGPT. אנשי שיווק מריצים טיוטות דרך "המוח השיווקי" של הצוות כדי לראות איך הן ייקלטו מול פרסונות קונים ואם הן תואמות להנחיות המותג. צוותי מכירות מתחברים לכלים ייעודיים בקנה מידה גדול: בניית תיקי ROI, הפקת הצעות מחיר ותחקור צנרת העסקאות שלהם.

איך זה עובד ואיך בונים

ההיגיון שמאחורי החיבור נובע ממגבלה בסיסית. אנשים משתמשים באפליקציה על ידי לחיצה על כפתורים, מילוי טפסים ומעבר בין מסכים. עוזר בינה מלאכותית לא יכול ללחוץ, ולכן הוא זקוק לרשימה של פעולות שהוא יכול לקרוא להן במקום. הרשימה הזו היא בדיוק מה ששרת MCP מספק.

Lovable יוצרת ומארחת את השרת עבורכם. אתם מפעילים את האינטגרציה על אפליקציה שפורסמה פומבית, והמערכת מייצרת שרת MCP, מציעה סט כלים לפי מה שהאפליקציה עושה, שואלת מי יורשה לקרוא להם - משתמשים מחוברים או כל אחד - ומגדירה את האימות בהתאם. הכלים המוצעים הם נקודת פתיחה בלבד: אפשר לבקש מ-Lovable להוסיף, להסיר, לשנות שם או לעדכן אותם בכל רגע. לפני שמשהו עולה לאוויר אתם עוברים על הכלים ועל הגדרות הגישה, מפרסמים, ומקבלים קישור MCP לשיתוף. המשתמשים מוסיפים אותו לעוזר החכם שלהם כמחבר מותאם אישית, מתחברים אם נדרש, ומתחילים.

נקודה חשובה: האינטגרציה רצה על האפליקציה החיה שפרסמתם, לא על עותק. שום דבר לא משתנה עבור מי שכבר משתמש באפליקציה בדרך הרגילה. כשאתם משנים את האפליקציה או את הכלים, פרסמו שוב, והמשתמשים יצטרכו לרענן את המחבר כשמוסיפים, מסירים או משנים שם של כלי.

מה צריך לדעת לפני שמתחילים

לפני שמוסיפים אינטגרציה, כדאי לוודא שהאפליקציה עומדת בכמה תנאים. ראשית, היא חייבת להיות מפורסמת פומבית, שכן קישור ה-MCP הופך זמין רק אחרי פרסום. שנית, נדרש בקאנד שיריץ את האינטגרציה ויחבר משתמשים, בין אם דרך Lovable Cloud ובין אם דרך פרויקט Supabase מחובר. אתר חזית בלבד ללא מסד נתונים או מנגנון התחברות לא יכול לארח אינטגרציית סוכן. מי שחיבר פרויקט Supabase משלו יצטרך להפעיל בו שרת הרשאות OAuth 2.1, בעוד שאפליקציות Lovable Cloud כבר מגיעות עם ההגדרה הזו.

ולא כל אפליקציה שיכולה לקבל אינטגרציה באמת צריכה אחת. Lovable מציעה כלים אך לא מחליטה עבורכם אם החיבור שווה, וכדאי לשקול זאת בעצמכם. לאפליקציה שהערך שלה חזותי או אינטראקטיבי בעיקרו, כמו משחק או אתר תיק עבודות, החיבור עשוי לתרום מעט. גם אתר סטטי בלי פעולה משמעותית, או כלים שהם איטיים, יקרים או מסוכנים להרצה כפולה, הם סימן שכדאי להימנע. שווה לזכור שאין ברירת מחדל של הגבלת קצב או תקרת הוצאה, ולכן חשוב לחשוף פעולות שצורכות משאבים בתשלום רק כשהאפליקציה כבר אוכפת מגבלות שימוש והרשאות בעצמה.

כמה זה עולה?

המודל הכלכלי כאן ישיר. קריאה לכלי עולה בדיוק כמו הפעולה שמאחוריה, מכיוון שכל קריאה מריצה את לוגיקת הבקאנד הרגילה של האפליקציה. פעולות מסד נתונים, שימוש ב-Lovable Cloud, פיצ'רים מבוססי בינה מלאכותית ושירותי צד שלישי נספרים ומחויבים בדיוק כמו שימוש ישיר באפליקציה. Lovable לא גובה עמלה נפרדת על אירוח האינטגרציה, על פרסומה או על קריאות הכלים עצמן. ההפעלה או השינוי של אינטגרציה צורכים קרדיטים רגילים של בנייה, ומספרם תלוי באפליקציה ובהיקף העבודה הנדרש.

מעבר לפרטים הטכניים, מסתתר כאן שינוי בדרך שבה אנשים צורכים תוכנה. במקום לקפוץ בין אפליקציות נפרדות כדי לבצע משימות, יותר ויותר משתמשים פשוט פונים לעוזר החכם שלהם, שמחובר ליומן, למסמכים ולמערכת הלקוחות ומבצע עבורם עבודה מקצה לקצה. אם הכיוון הזה יתבסס, השאלה שכל מי שבונה מוצר יצטרך לשאול היא לא רק "איך נראית האפליקציה שלי", אלא "האם היא בכלל צריכה מסך". וזו שאלה ששווה להתחיל לחשוב עליה כבר עכשיו.

הפוסט Lovable מכניסה את האפליקציות שלכם ישר לתוך הצ'אט הופיע ראשון בLet's AI בינה מלאכותית

שני כפתורים, שתי החלטות שונות

ב-Claude Code (ובקלוד בכלל) יש שתי הגדרות שנראות דומות אבל עושות דברים שונים לגמרי: איזה מודל להשתמש בו, ובאיזו רמת מאמץ. הבנת ההבדל ביניהן יכולה לחסוך לכם זמן וכסף, ולתת לכם תוצאות טובות יותר.

מה זה בעצם "מודל"?

תחשבו על מודל כמו על מומחה עם רמת ידע וכישורים קבועה מראש. כשהמודל "מתאמן", הוא סופג כמות עצומה של ידע והופך למעין "מוח" קפוא - הידע שבו לא משתנה יותר. כשאתם שולחים הודעה, אתם לא מלמדים את המודל משהו חדש, אתם רק "מכוונים" אותו להשתמש בידע שכבר יש לו בצורה הרלוונטית לבקשה שלכם.

זו הסיבה שאם תיתנו למודל תיעוד על ספרייה חדשה שהוא לא מכיר, הוא יוכל להשתמש בזה לצורך המשימה הנוכחית - אבל הוא "ישכח" את זה ברגע שהשיחה תסתיים. זה נקרא לתת לו הקשר (context), לא ללמד אותו.

מודלים ״גדולים״ יותר (כמו Opus) הם בדרך כלל יותר "חכמים" ומסוגלים להתמודד עם בעיות מורכבות ולא ברורות. מודלים ״קטנים״ יותר (כמו Sonnet) שנחשב לג׳נרליסט יותר מאשר מומחה, הם מצוינים למשימות שגרתיות ופשוטות יותר, ועולים פחות.

מה זה "רמת מאמץ"?

כאן ההפתעה: רמת מאמץ היא לא רק "כמה זמן המודל חושב". היא קובעת כמה עבודה בסך הכול המודל עושה על המשימה: כמה קבצים הוא קורא, כמה הוא בודק ומאמת את העבודה שלו, וכמה הוא ממשיך לבד לפני שהוא חוזר אליכם לשאול שאלה. ברמת מאמץ גבוהה, המודל יקרא יותר קבצים, יבדוק דברים בעצמו ויתקדם יותר לפני שהוא פונה אליכם. ברמת מאמץ נמוכה, הוא יעדיף לשאול אתכם שאלות ולקבל הכוונה במקום "לבזבז" משאבים על ניסיון להבין דברים בכוחות עצמו.

משימה קונקרטית אחת בשני מסלולים | Anthropic

מתי לבחור מה?

ברוב המקרים כדאי להשאיר את ברירת המחדל (default) ולא להתעסק עם הכפתורים בכל משימה. במקום זאת, כדאי לחשוב על ההגדרות כהעדפה כללית, לפי סוג העבודה שאתם עושים בדרך כלל - לא להחליט מחדש בכל פעם. כשמשהו לא הצליח, תשאלו את עצמכם שאלה אחת פשוטה: "המודל לא ניסה מספיק, או שהוא פשוט לא ידע מספיק?"

איך בוחרים נכון? | Anthropic

אם התשובה היא "לא ידע מספיק" - כלומר, נתתם לו את כל המידע הדרוש, הוא באמת ניסה, ועדיין טעה - הפתרון הוא לעבור למודל גדול יותר. זה מתאים לבאגים עמומים, תחומים לא מוכרים, או החלטות ארכיטקטורה מורכבות.

אם התשובה היא "לא ניסה מספיק" - כלומר הוא דילג על קובץ, לא הריץ בדיקות, או עזב משימה בחצי הדרך - הפתרון הוא להעלות את רמת המאמץ, לא להחליף מודל.

דוגמה שעוזרת להבין

בואו נשתמש במטאפורה נחמדה: תארו לעצמכם שלושה אנשי מקצוע - מומחה-על עם ניסיון נדיר (המודל הגדול ביותר), מומחה טוב (מודל בינוני), ואיש כללי מוכשר (מודל קטן וזול). רמת המאמץ היא כמה זמן אתם נותנים לכל אחד מהם לעבוד על הבעיה שלכם.

מומחה-על שמקבל רק חמש דקות עדיין יכול לזהות דבר שאף אחד אחר לא היה שם לב אליו, בגלל הניסיון העצום שלו - אבל הוא לא יקרא את כל הקוד שלכם בעיון. לעומת זאת, איש כללי מוכשר שמקבל אחר צהריים שלם יקרא הכול, יבדוק הכול, ויבין את הקוד הספציפי שלכם לעומק - אבל בלי אותה "תחושת בטן" שמגיעה מניסיון של פתרון בעיות דומות בעבר.

אף שילוב לא "הכי טוב" באופן מוחלט - זה תלוי במשימה שלפניכם.

חיסכון בעלויות

מודלים גדולים יותר עולים יותר לכל "יחידת עבודה" (טוקן). לכן, למשימות שגרתיות, מודל קטן ברמת מאמץ מתאימה יכול להגיע לתוצאה זהה בעלות נמוכה משמעותית. אבל למשימות מורכבות ומרובות-שלבים, מודל קטן עלול "להתאמץ" הרבה ועדיין לא להגיע לרמת האיכות שמודל גדול משיג במספר צעדים קטן יותר - כך שבפועל העלות הכוללת של המודל הגדול יכולה לצאת דווקא זולה יותר, ובמקרים מסוימים המודל הקטן בכלל לא מגיע לפתרון.

משימה פשוטה מול משימה מורכבת | Anthropic

במשימה פשוטה (משמאל), מודל קטן וגדול מגיעים לתוצאה דומה - ואין סיבה לשלם יותר. במשימה מורכבת (מימין), הפער נפתח: המודל הגדול מגיע לאיכות גבוהה יותר, ורמת המאמץ קובעת כמה רחוק כל מודל 'מוכן ללכת' על הדרך לשם.

שני כללים לזכור

כשמשהו לא עבד כמו שציפיתם: תחילה בדקו אם סיפקתם הקשר מספיק ברור (הוראות, קבצים רלוונטיים). אם כן וזה עדיין נכשל, שאלו אם זו הייתה בעיית ידע (עברו למודל גדול יותר) או בעיית מאמץ (העלו את רמת המאמץ). ומעבר לזה - פשוט תתחילו מברירת המחדל, ותתאימו רק כשיש לכם באמת סיבה טובה לכך.

הפוסט איך לבחור מודל ורמת מאמץ ב-Claude Code הופיע ראשון בLet's AI בינה מלאכותית

התוצר הסופי: תוסף אישי שמופיע בעמוד התוספים של כרום כמו כל תוסף אחר, בלי שעבר דרך החנות

מה זה בעצם תוסף אישי, ולמה זה שונה מתוסף מהחנות

תוסף שמותקן מחנות התוספים של כרום הוא כמו רהיט שקניתם בחנות רהיטים. מישהו תכנן אותו לקהל רחב, הוא עבר בקרת איכות, הוא ארוז ומוכן, והוא מתאים בגדול לחדר שלכם. תוסף אישי שאתם טוענים מתיקייה במחשב הוא כמו מדף שהרכבתם לבד בדיוק למידות של הנישה בקיר. אף אחד לא בדק אותו, אף אחד אחר לא יכול להשתמש בו, ואם תזיזו את התיקייה הוא יפסיק לעבוד. בתמורה, הוא מתאים בדיוק לצורך שלכם, נבנה בעשרים דקות, ולא דורש חשבון מפתח, תשלום או אישור.

המנגנון שמאפשר את זה נקרא Load unpacked, טעינת תוסף לא-ארוז. במקום להעלות קובץ חתום לחנות, אתם מצביעים על תיקייה במחשב, וכרום מריץ את מה שיש בה. זו לא דלת אחורית ולא פרצה, זה מסלול רשמי שכרום מיועד למפתחים, ואין שום מניעה שתשתמשו בו לצרכים אישיים.

שווה להבדיל את זה משכבת התוספים החדשה של חברות ה-AI. כלים כמו Claude for Chrome או Codex בכרום מכניסים סוכן AI כללי שיודע לקרוא דפים ולפעול בהם לפי בקשה בשפה חופשית. מה שנעשה כאן הוא הפוך: פונקציה אחת קטנה, צפויה לחלוטין, שרצה בלי אינטרנט, בלי מודל ובלי עלות לכל הפעלה. שני הדברים שימושיים, אבל למשימות שונות.

הדוגמה: תוסף שמהפך את כיוון הדף

הצורך שממנו התחלנו הוא פרקטי ומוכר לכל מי שעובד בעברית. חלק מהממשקים המרכזיים שאנחנו עובדים בהם יומיומית בנויים כ-LTR, וטקסט עברי בתוכם נראה שבור. במקום לחכות שהאתר יתקן את זה, התוסף הופך את הכיוון של הדף כולו בלחיצה, ומחזיר אותו בלחיצה נוספת.

לפני ההפעלה: סרגל הצד בשמאל, כפתורי תיבת הקלט מסודרים לפי כיוון אנגלי

אחרי לחיצה על Alt+R: סרגל הצד עבר לימין וכל הפריסה התהפכה

שימו לב למה שקורה בתמונה השנייה גם בסימני הפיסוק. סימן השאלה בכותרת עבר לתחילת השורה, והנקודה בשורת הכתב הקטן בתחתית הדף עברה גם היא. זו התנהגות נכונה של הדפדפן בהינתן כיוון RTL, והיא בדיוק הסיבה שהתוסף עוזר לטקסט עברי. באותה נשימה, זו גם הסיבה שהוא הופך טקסט אנגלי לפחות קריא. התוסף הזה הוא מתג, לא שיפור חד-כיווני.

לפני שמתחילים

הרשימה קצרה בכוונה, כי זה כל היופי בשיטה הזו:

• דפדפן כרום מעודכן, במחשב (לא בטלפון נייד).
• גישה לצ'אט AI שיודע לכתוב קוד - Claude, ChatGPT או Gemini יעשו את העבודה.
• תיקייה אחת ריקה במחשב, במקום שלא תמחקו בטעות - שימו לב שהתיקייה חייבת להישאר במקומה כל עוד התוסף פעיל.
• עורך טקסט כלשהו - Notepad מספיק, אין צורך ב-Node, אין שלב בנייה ואין ספריות להתקין.

מה שלא נדרש: ידע בתכנות, חשבון מפתח בגוגל, תשלום, או הבנה מוקדמת של איך תוספים עובדים. את הידע הזה תרכשו תוך כדי, מהקוד שתקבלו.

השלבים המלאים

1. מגדירים את הצורך במשפט אחד: לפני שאתם פותחים צ'אט, נסחו לעצמכם בדיוק מה התוסף אמור לעשות ובאיזה רגע הוא מופעל. בדוגמה שלנו: "להפוך את כיוון הדף כולו בין RTL ל-LTR ובחזרה, כמתג, בהפעלה מקיצור מקלדת או מכפתור". ניסוח שלא עומד במשפט אחד הוא בדרך כלל סימן ששני תוספים מתחבאים בבקשה אחת, ואז עדיף לפצל.

2. כותבים פרומפט עם דרישות טכניות מפורשות: זה השלב שקובע אם תקבלו תוסף עובד או קוד שנראה נכון ולא רץ. את הפרומפט המלא שהשתמשנו בו תמצאו בסעיף הבא, ואחריו הסבר למה כל דרישה בו נמצאת שם.

3. יוצרים תיקייה ושומרים את הקבצים: המודל יחזיר לכם 4 קבצים (במקרה של התוסף שלנו). פתחו תיקייה, ושמרו כל קובץ בשם המדויק שקיבלתם, כולל הסיומת. הקובץ manifest.json הוא הקריטי, כי הוא זה שמצהיר בפני כרום מה התוסף הזה ומה הוא מבקש לעשות. אם שמרתם אותו בטעות כ-manifest.json.txt, כרום פשוט לא יזהה את התיקייה כתוסף.

תיקיית התוסף במחשב עם 4 קבצים: background.js, manifest.json, popup.html ו-popup.js

4. מפעילים מצב מפתח בכרום: הקלידו בשורת הכתובת chrome://extensions ולחצו Enter. בפינה הימנית העליונה של העמוד תראו מתג בשם Developer mode. הפעילו אותו. ברגע שתעשו זאת, יופיע בראש העמוד שורת כפתורים חדשה שלא הייתה שם לפני כן.

5. טוענים את התיקייה: לחצו על Load unpacked בפינה השמאלית העליונה, ובחרו את התיקייה שיצרתם בשלב 3. חשוב: בחרו את התיקייה עצמה, לא קובץ בתוכה. אם הכל תקין, התוסף יופיע מיד ברשימה עם השם והתיאור שהגדרתם במניפסט.

עמוד chrome://extensions עם חצים אדומים שמסמנים את מתג Developer mode בימין ואת כפתור Load unpacked בשמאל

6. בודקים את הקיצור: עברו לכתובת chrome://extensions/shortcuts וודאו שהקיצור מקלדת שהגדרתם רשום מול התוסף שלכם. אם השדה ריק, סימן שהקיצור התנגש עם קיצור קיים והדפדפן לא שיבץ אותו. אתם יכולים להקליד שם קיצור אחר ישירות, בלי לגעת בקוד.

7. מריצים על דף אמיתי: פתחו אתר כלשהו, ולחצו על הקיצור במקלדת, אם הגדרתם גם כפתור בפופאפ, נסו גם אותו. הפעלה בשני המסלולים היא בדיקה חשובה, כי היא מוודאת ששניהם באמת מפעילים את אותה לוגיקה ולא רק אחד מהם עובד.

הפופאפ של התוסף: כפתור ותזכורת לקיצור המקלדת

8. מתקנים בסבב שני: אם משהו לא עבד, אל תתקנו את הקוד לבד. חזרו לצ'אט, תארו בדיוק מה קרה, והדביקו את הודעת השגיאה אם יש. בעמוד התוספים, קישור בשם service worker ליד התוסף פותח את הקונסולה שלו ומראה שגיאות. זה המקום שממנו מעתיקים את השגיאה בחזרה לצ'אט.

הפרומפט המלא

זה הפרומפט שהוליד את התוסף. הוא ארוך, וזו לא במקרה, העתיקו אותו כבסיס, והחליפו את סעיף "מה התוסף צריך לעשות" במה שאתם רוצים:

אני רוצה לבנות תוסף כרום קטן לשימוש אישי, שאטען אותו כתיקייה מקומית (Load unpacked). אני לא מפרסם אותו בחנות.

מה התוסף צריך לעשות: להפוך את כיוון הדף כולו בין RTL ל-LTR ובחזרה, כ-toggle. בכל הפעלה מוצג טוסט צף קטן בראש הדף עם שם המצב החדש ("RTL" או "LTR"), שנעלם מעצמו אחרי כשנייה וחצי. שתי דרכי הפעלה: קיצור המקלדת Alt+R, וכפתור בפופאפ.

דרישות טכניות, אנא הקפד עליהן:

1. Manifest V3. ארבעה קבצים בלבד: manifest.json, background.js, popup.html, popup.js. בלי אייקונים, בלי ספריות חיצוניות, בלי שלב build.

2. הרשאות: permissions הוא ["activeTab", "scripting"] וזה הכל. אין host_permissions, אין content_scripts, אין tabs, אין storage. אני רוצה שכרום לא יציג על התוסף את האזהרה על קריאה ושינוי נתונים בכל האתרים.

3. אל תשתמש ב-content script קבוע. הזרק את הקוד לדף רק ברגע ההפעלה, דרך chrome.scripting.executeScript עם target של הטאב הפעיל. שני מסלולי ההפעלה צריכים לקרוא לאותה פונקציה מוזרקת, בלי לשכפל קוד.

4. הקיצור דרך chrome.commands עם suggested_key של Alt+R, ומאזין chrome.commands.onCommand ב-background.js. לא keydown, כי אני רוצה שהקיצור יופיע ב-chrome://extensions/shortcuts ושאוכל לשנות אותו שם.

5. ההיפוך עצמו: קרא את המצב הנוכחי מתג <html> וכתוב גם את המאפיין dir וגם את style.direction. הלוגיקה צריכה להסיק את המצב מהדף עצמו בכל הפעלה, בלי לשמור מצב בשום מקום, כדי שגם אם המשתמש רענן את הדף התוסף לא יתבלבל.

6. הטוסט: אלמנט div עם מזהה ייחודי, position: fixed, z-index גבוה מאוד, ועיצוב בסגנונות inline בלבד כדי שה-CSS של האתר לא ישפיע עליו. הגדר עליו במפורש direction ו-text-align משלו, כדי שההיפוך של הדף לא יהפוך גם אותו. אם טוסט קודם עדיין על המסך, הסר אותו לפני שאתה מוסיף חדש, כדי שהם לא יצטברו בלחיצות מהירות.

7. בדפים שכרום חוסם בהם הזרקה (chrome://, חנות התוספים, צפיין ה-PDF) הקריאה תיכשל. עטוף אותה כך שהכישלון לא יזרוק שגיאה לא מטופלת. שום קריסה, שום התראה.

8. הפופאפ: כפתור אחד, ובלחיצה עליו התוסף מבצע את אותו היפוך על הטאב הפעיל והפופאפ נסגר.

בנוסף:

- הוסף הערות בעברית בכל בלוק בכל אחד מהקבצים, כדי שאני אבין מה כל חלק עושה. אני רוצה להיות מסוגל לקרוא את הקוד לבד

למה הפרומפט הזה עבד

אם תעיפו מבט בפרומפט תראו שהוא כמעט לא עוסק בשאלה מה התוסף עושה. משפט אחד מסביר את התכלית, ושמונה סעיפים מסבירים את האילוצים. זה ההבדל המרכזי בין פרומפט שמייצר קוד עובד לפרומפט שמייצר קוד שנראה משכנע. אלה העקרונות שאפשר לקחת מכאן לכל תוסף אחר:

• מספר הקבצים כאילוץ מוצהר: בקשה חופשית לבניית תוסף מקבלת בדרך כלל מבנה תיקיות, קובץ CSS נפרד, תיקיית אייקונים ולפעמים גם הצעה להתקין ספרייה. הכתבת "4 קבצים בלבד" מכריחה את המודל לפתרון מינימלי, וכשיש 4 קבצים אתם באמת יכולים לקרוא את כולם.
• הרשאות בשלילה, לא רק בחיוב: הסעיף לא רק אומר מה כן, אלא מפרט מה אין. בלי זה, מודל יוסיף כמעט תמיד host_permissions על כל האתרים, כי זה פותר בעיות מראש. המחיר הוא שכרום יציג על התוסף אזהרה שהוא יכול לקרוא ולשנות את הנתונים שלכם בכל האתרים, על תוסף שכל תפקידו להפוך כיוון טקסט.
• קביעת מנגנון ולא רק תוצאה: הבקשה לא הייתה "שיהיה קיצור מקלדת" אלא "קיצור דרך chrome.commands, לא keydown". שתי הדרכים נותנות קיצור עובד, אבל רק אחת מהן מופיעה בעמוד הקיצורים של כרום ומאפשרת לשנות אותה בלי לגעת בקוד. הבחירה הזו לא הייתה מתקבלת מעצמה.
• מקרי קצה מוגדרים מראש: שני סעיפים בפרומפט מוקדשים לדברים שנשברים. טוסטים שמצטברים בלחיצות מהירות, והזרקה שנכשלת בעמודי מערכת של כרום. אלה בדיוק הדברים שמתגלים רק בשימוש אמיתי, ואם מציינים אותם מראש חוסכים סבב תיקונים.
• בקשה להערות בעברית: זו לא בקשה אסתטית. תוסף שאתם מריצים בדפדפן שלכם בלי בקרת איכות של אף גורם הוא קוד שאתם אחראים עליו. הערות בעברית בכל בלוק הן מה שהופך את הקוד למשהו שאתם יכולים לקרוא ולבדוק, ולא לקופסה שחורה שסומכים עליה.
• בקשה להגבלות בסוף התשובה: הסעיף האחרון מבקש מהמודל למנות במפורש מה התוסף לא יכול ואיפה הוא יישבר. זה הופך את המודל מספק פתרונות לגורם שגם מסמן את הגבולות, וזה מידע שאחרת הייתם מגלים לבד, בדרך הקשה.

מי שרוצה להעמיק בדיוק בשכבה הזו של ניסוח דרישות ואילוצים ימצא הרחבה שלמה במדריך להנדסת פרומפטים.

מה עוד אפשר לבנות באותה שיטה

התוסף הספציפי הזה הוא פחות מעניין מהתבנית שהוא מדגים. כל אחד מהרעיונות הבאים הוא תוסף בסדר גודל דומה, 4 קבצים ופרומפט אחד, שאפשר לבנות באותו זמן ובאותה שיטה. שימו לב שהם לא זמינים להורדה בכוונה. בניית אחד כזה לבד לוקחת פחות זמן מחיפוש תוסף מוכן בחנות, ומשאירה אתכם עם קוד שאתם מבינים ויכולים לשנות:

• הסתרת פיד המלצות: תוסף שמסתיר את פיד הסרטונים המומלצים ביוטיוב או את הפיד המרכזי בלינקדאין, כדי שתגיעו לאתר, תעשו את מה שבאתם לעשות ותצאו.
• ניקוי טקסט להעתקה: כפתור שמעתיק את הטקסט הנבחר בלי עיצוב, בלי קישורים ובלי תווים סמויים שנדבקים מדפים.
• זמן קריאה: תוסף שמחשב את מספר המילים בדף ומציג בפינה הערכת זמן קריאה, לפני שאתם מתחילים.
• הגדלת גופן באתר אחד: יש אתר ספציפי עם טקסט קטן מדי? תוסף שמגדיל את הגופן רק שם, בלי לשנות את הזום בכל הדפדפן.
• טבלה לקובץ: תוסף שמזהה טבלאות בדף ומוריד אותן כקובץ .csv, במקום סימון ידני והדבקה שמתפרקת.
• הדגשת מספרים: בדפים עם הרבה נתונים, תוסף שמסמן בצבע כל סכום כספי או אחוז, כדי שהעין תמצא אותם מהר.

הכיוון הזה, של בניית כלים קטנים לשימוש עצמי במקום חיפוש מוצר מוכן, הוא בדיוק מה שהתחום שנקרא וייב קודינג פתח בפני מי שלא מתכנת. ולפרספקטיבה על הגבול העליון של השיטה, שווה לראות מה קרה כששני יזמים ישראלים לקחו את אותו רעיון של תוסף לניהול צ'אט והפכו אותו למוצר מלא. גם שם ההתחלה הייתה צורך אישי אחד.

שלוש אזהרות שחשוב להכיר לפני שאתם טוענים קוד לדפדפן

אף אחד לא בדק את הקוד הזה - תוסף מהחנות עובר סקירה של גוגל. תוסף שאתם טוענים מתיקייה לא עובר כלום. הוא רץ בדפדפן שבו אתם מחוברים לבנק, למייל ולמערכות העבודה. לכן שני כללים לא מתפשרים: קראו את המניפסט וודאו שההרשאות בו הן מה שביקשתם ולא יותר, ואל תטענו תיקיות קוד שקיבלתם ממישהו אחר בוואטסאפ. השיטה הזו בטוחה כשאתם מבינים את מה שאתם מריצים, וזו בדיוק הסיבה שהפרומפט דורש הערות בעברית ומספר קבצים מינימלי.

ההרשאות המצומצמות הן גם הגבלה אמיתית - הבחירה ב-activeTab ו-scripting בלבד היא מה שמונע מכרום להציג אזהרה על התוסף, אבל היא באה עם מחיר: התוסף יכול לגעת בדף רק ברגע שאתם מפעילים אותו במפורש, ורק בטאב שפעיל אז. הוא לא יכול לפעול מעצמו על כל דף שנטען, ולא יכול לזכור שהפעלתם אותו. אחרי ריענון דף, הכיוון חוזר למקורי. עבור תוסף אישי זו לרוב עסקה טובה, אבל אם אתם רוצים התנהגות אוטומטית קבועה, זו ארכיטקטורה שונה שדורשת הרשאות רחבות יותר ואזהרה מוצגת בכרום.

יש דפים שבהם זה לא יעבוד או ייראה שבור - כרום חוסם הזרקת קוד בעמודי המערכת שלו, בחנות התוספים ושם לחיצה על הקיצור לא תעשה כלום. בנוסף, היפוך כיוון הוא שינוי חזותי בלבד. באתרים שבנויים על מיקום מוחלט של אלמנטים, או שיש בהם אייקונים עם כיוון מובנה כמו חצים, ההיפוך יזיז דברים למקומות לא צפויים. באתרים מסוימים התוצאה תהיה פחות קריאה מהמקור, לא יותר. זה תוסף שנועד לפתור מצב ספציפי, לא לשפר כל דף באינטרנט.

הצעד הראשון הוא לא הקוד

אם אתם מגיעים לכאן ומחפשים מאיפה להתחיל, אל תתחילו מהצ'אט. פתחו מסמך ריק, וכתבו בו במשך שבוע כל פעם שמשהו בדפדפן מפריע לכם. לחיצה שאתם עושים חמש פעמים ביום, כפתור שמוסתר במקום לא הגיוני, טקסט שאתם מעתיקים ומנקים ידנית. בסוף השבוע תסתכלו על הרשימה ותבחרו את הפריט שחוזר הרבה. את הפריט הזה תנסחו במשפט אחד, תעטפו בשמונה סעיפי אילוצים בסגנון הפרומפט שכאן, ותקבלו תוסף. בהצלחה!

הפוסט ככה בונים תוסף כרום אישי עם AI הופיע ראשון בLet's AI בינה מלאכותית

שני סוגים של שכחה

בין סשנים, קלוד קוד לא בהכרח זוכר את מה שלא שמרתם לו במקום מסודר. אם אתמול הסברתם לו מה מטרת הפרויקט, איזה סגנון אתם רוצים, באיזה קבצים לא לגעת ומה כבר החלטתם, אל תניחו שהוא יזכור הכול לבד.

בתוך הסשן, הבעיה אחרת. חלון הקונטקסט הולך ומתמלא. חלון הקונטקסט הוא כמות המידע שקלוד (claude) מסוגל להחזיק “בראש” באותו רגע. מה שנקרא זיכרון לטווח קצר. כל קובץ שהוא קורא, כל פקודה, כל תשובה, כל שאלה צדדית, וגם חיבור לכלים חיצוניים, תופסים מקום.

חלון הקונטקסט הוא זיכרון לטווח קצר של המודל

כשהחלון מתמלא, העבודה יכולה להישחק. לא תמיד בבת אחת. לפעמים הוא פשוט נהיה פחות חד, חוזר לנקודות שכבר נסגרו, או שוכח החלטה קטנה שהייתה חשובה.

בין סשנים, אל תסמכו על זיכרון מקרי

אם יש משהו שאתם מסבירים לקלוד שוב ושוב, הוא לא צריך להישאר בתוך שיחה. הוא צריך לעבור לזיכרון קבוע. יש שלוש דרכים עיקריות לעשות את זה:

גלובלי ופרויקטלי

הראשונה היא קבצי CLAUDE.md. אלה קבצים שאתם כותבים, וקלוד קורא בתחילת העבודה. תחשבו עליהם כמו פתק שאתם משאירים לו על השולחן לפני שהוא מתחיל. יש שני סוגים שימושיים של CLAUDE.md:

1. הגלובלי מתאים להעדפות שנכונות לכם תמיד. למשל: תציג תוכנית לפני שינוי גדול, אל תמחק קבצים בלי אישור, תכתוב בעברית פשוטה, תסביר בקצרה לפני ביצוע.

2. הפרויקטלי מתאים לדברים שנכונים רק לפרויקט מסוים. למשל מה מטרת הפרויקט, מי הקהל, איזה סגנון לשמור, אילו תיקיות חשובות, ומה כבר הוחלט.

זיכרון גלובלי וזיכרון פרויקטלי

חשוב לא לכתוב הוראות שסותרות זו את זו. זה לא קסם של “הקובץ הפרויקטלי תמיד מנצח”. בפועל Claude קורא כמה שכבות של הוראות, והוראות ספציפיות יותר בדרך כלל מקבלות יותר משקל. אבל אם תבלבלו אותו, הוא עלול לבחור לא נכון. הכלל הפשוט הוא כזה: בגלובלי כותבים מי אתם ואת סגנון וצורת העבודה שלכם. בפרויקטלי כותבים את המציאות של הפרויקט.

Auto Memory הוא עוזר, לא מנהל

השכבה השנייה היא Auto Memory. כאן Claude Code יכול לשמור לעצמו זיכרונות תוך כדי עבודה. למשל, אם אתם מתקנים אותו כמה פעמים ואומרים ששמות הקבצים צריכים להיות בעברית, הוא יכול ללמוד את זה. אם אתם מזכירים לו שוב ושוב לא לגעת בתיקיית תמונות מקוריות, גם את זה הוא יכול לשמור.

אבל השליטה שלכם כאן חלקית. אפשר לבקש ממנו “תשמור את זה לזיכרון”, והוא יכול לעשות את זה, אבל זו עדיין המלצה. הוא מחליט מה נראה לו חשוב לשמור ואיך לנסח את זה. לכן, כלל קריטי לא משאירים ל-Auto Memory. כלל קריטי כותבים ב-CLAUDE.md.

ומה לגבי ״מוח שני״

יש גם דרך שלישית, שמתאימה לפרויקטים גדולים יותר: ״מוח שני״. זה לא פיצ׳ר מיוחד של קלוד קוד. זו מערכת ידע שאתם מנהלים בעצמכם. זה יכול להיות Obsidian, Notion, Google Docs, תיקיית מסמכי Markdown או כל מקום מסודר אחר שאפשר לנהל בו קבצי טקסט.

שם אפשר לשמור מקורות, החלטות, רעיונות, סיכומי פגישות, שאלות פתוחות, טיוטות ותובנות.

הטעות היא לדחוף הכול לתוך CLAUDE.md. הקובץ הזה צריך להיות קצר ומעשי. הוא אומר לקלוד מה חשוב לדעת בתחילת העבודה. את שאר החומר אפשר לתת לו לקרוא לפי צורך.

במילים פשוטות, CLAUDE.md הוא פתק עבודה. Auto Memory הוא הזיכרון שהוא כותב לעצמו. מוח שני הוא הארכיון שאתם מנהלים.

קונטקסט בתוך הסשן

גם אם סידרתם זיכרון בין סשנים, עדיין צריך לנהל את הסשן עצמו. תחשבו על חלון הקונטקסט כמו שולחן עבודה. בתחילת היום השולחן נקי. אחר כך אתם מניחים עליו מסמכים, פתקים, גרסאות, רעיונות, שאלות ותיקונים. בשלב מסוים הכול עדיין שם, אבל כבר קשה לראות מה חשוב. זה מה שקורה לסשן ארוך מדי.

לכן כדאי להתרגל להסתכל על מד הקונטקסט. בממשק שבו הוא מופיע, הוא מראה כמה מחלון הקונטקסט כבר תפוס. אם לוחצים עליו, אפשר לראות מה תופס מקום. ב-CLI אפשר להשתמש גם בפקודה context/. לא צריך לבדוק את זה כל שתי דקות. אבל מדי פעם, במיוחד אחרי עבודה ארוכה, כדאי להציץ.

מד הקונטקסט והאפשרות לדחוס את הזיכרון עם פקודת compact/

מתי להתחיל לדאוג

אל תחכו שהחלון יתמלא. כלל אצבע טוב הוא להתחיל ״לארוז״ את הסשן סביב 60% שימוש בקונטקסט. זה לא מספר קסם ולא חוק רשמי. זו המלצה זהירה. אפשר לעבוד גם מעבר לזה, אבל ככל שהסשן מתמלא, גדל הסיכוי שקלוד יהיה פחות ממוקד.

יש כאן גם עניין של עלות. ככל שהקונטקסט גדול יותר, קלוד צריך לעבד יותר טוקנים בכל פנייה. כלומר, השיחה יכולה להיות איטית יותר ויקרה יותר. ניהול קונטקסט לא רק משפר איכות - הוא גם יכול לחסוך לכם כסף.

לפני משימה גדולה, תכננו

אחד ההרגלים הכי חשובים הוא לא לתת לקלוד לרוץ ישר לביצוע. לפני משימה גדולה, השתמשו ב-Plan Mode או בפקודה plan/. במצב הזה הוא קודם מציע תוכנית, ורק אחרי אישור שלכם מתחיל לשנות דברים.

למשל: תעבור על הקבצים ותציג לי תוכנית בלבד. אל תשנה כלום לפני שאני מאשר, או לדוגמה: תקרא את הטיוטה ותציע מבנה משופר. אל תשכתב עדיין. אם אתם עוסקים במחקר: תבדוק אילו חומרים יש בתיקייה ותציע איך לסדר אותם. אל תשנה שמות קבצים לפני אישור. אם אתם רוצים לעשות שינויים באתר: תסביר מה צריך לשנות בעמוד לפני שאתה משנה אותו בפועל.

לפעמים עדיף לעשות את התכנון הראשוני בכלל בצ׳אט רגיל של קלוד, ורק אחרי שהכיוון ברור להעביר את העבודה לקלוד קוד. ככה לא מנפחים את הסשן בקבצים ובניסיונות מוקדמים.

לדחוס לפני שמאוחר מדי

כשסשן נהיה ארוך, השתמשו ב-compact/. כמו שראינו קודם, הפקודה הזו מסכמת את השיחה כדי לפנות מקום בקונטקסט. אבל אל תריצו אותה סתם. דחיסה טובה היא בחירה של מה חשוב לשמור, לא ניסיון לשמור הכול.

במקום רק compact/, כתבו:

compact/ סכם את הסשן, אבל שמור במיוחד את ההחלטות שקיבלנו, מה כבר ניסינו, מה נשאר פתוח ומה הצעד הבא.

בכתיבה: compact/ שמור את הטון שבחרנו, המבנה שאושר, ומה לא להחזיר לטיוטה.

במחקר: compact/ שמור את המקורות החשובים, המסקנות, והטענות שעדיין צריך לבדוק.

אם לא תדחסו בזמן, קלוד קוד עשוי לבצע דחיסה אוטומטית כשהקונטקסט מתקרב למגבלה. זה שימושי, אבל אז הוא מחליט לבד מה חשוב. עדיף שאתם תכוונו אותו.

מה זה btw/

באמצע עבודה תמיד יש שאלות קטנות: מה הייתה הכותרת הקודמת, למה פסלנו רעיון מסוים, איזה קובץ היה המקורי. אם שואלים הכול בשיחה הראשית, זה מלכלך את ההיסטוריה. בשביל זה יש btw/.

למשל: btw/ מה הייתה הכותרת שאהבנו קודם?

btw/ למה החלטנו לא להשתמש במבנה ההוא?

זו שאלה צדדית שלא אמורה להעמיס על הסשן הראשי.

משימות כבדות שולחים לסוכן משנה

יש משימות שממלאות את הסשן מהר: מעבר על הרבה קבצים, מחקר רחב, בדיקת אתר שלם, חיפוש כפילויות, או ניסיון להבין איך פרויקט בנוי. במקום להעמיס את הכול על השיחה הראשית, בקשו מקלוד לשלוח subagent.

למשל: שלח סוכן נפרד שיעבור על תיקיית המאמרים ויחזור רק עם כפילויות והמלצות לסידור. אל תשנה קבצים.

או, שלח סוכן נפרד שיבדוק איזה עמודים באתר לא מעודכנים ויחזור עם רשימה קצרה.

או, שלח סוכן נפרד שיעבור על חומרי המחקר ויחזור עם חמש התובנות המרכזיות.

הרעיון פשוט: אתם צריכים את המסקנות, לא את כל החיפוש בתוך הסשן הראשי.

סשן חדש זה פתרון מצוין

לפעמים לא צריך לדחוס. צריך להתחיל סשן חדש. אם עברתם לנושא אחר, אם קלוד מתבלבל, אם השיחה מלאה ניסיונות שלא עבדו, או אם הוא ממשיך להתייחס לגרסה ישנה, עצרו.

אפשר לבקש: סכם לי מה עשינו, מה החלטנו, מה נשאר פתוח ומה הצעד הבא, כדי שאוכל להמשיך בסשן חדש. אחר כך פותחים נקי וממשיכים מהסיכום.

מה כדאי שתקחו מכאן?

בין סשנים, תנו ל-Claude זיכרון מסודר: CLAUDE.md גלובלי, CLAUDE.md פרויקטלי, Auto Memory, ובפרויקטים גדולים גם ״מוח שני״.

בתוך הסשן, נהלו את הקונטקסט: עקבו אחרי המד, התחילו לארוז סביב 60%, תכננו לפני ביצוע, השתמשו ב-compact/, שאלו שאלות צדדיות עם btw/, ושלחו סוכני משנה למשימות כבדות.

קלוד קוד עובד הרבה יותר טוב כשלא מתייחסים אליו כמו לצ׳אט. הוא צריך סביבת עבודה מאורגנת, זיכרון מסודר, וקונטקסט נקי מספיק כדי להמשיך לחשוב ״צלול״ ולבצע את המשימות שהטלתם עליו על הצד הטוב ביותר.

הפוסט איך עובדים נכון עם הזיכרון של קלוד קוד הופיע ראשון בLet's AI בינה מלאכותית

מה זה בעצם Apps Script

Apps Script היא סביבת פיתוח של גוגל שרצה על השרתים של גוגל עצמה. היא מבוססת על JavaScript, אבל החלק המעניין הוא לא השפה אלא הגישה: לסקריפט שאתם כותבים יש חיבור ישיר ומובנה לגוגל שיטס, ג'ימייל, דרייב, קלנדר, דוקס וגוגל פורמס. אין צורך במפתחות API, אין הרשמה לשירות חיצוני, ואין שרת שצריך לתחזק.

שלושה דברים שכדאי להבין לפני הכל:

• זה חינם - לכל בעל חשבון גוגל, כולל חשבון פרטי, יש גישה מלאה.
• הקוד רץ בענן, לא במחשב שלכם - אפשר לסגור את המחשב והאוטומציה תמשיך לעבוד.
• הקוד רץ בהרשאות שלכם - זו העוצמה שלו וגם הסיכון שלו, ונחזור לזה בהמשך.

בהשוואה לכלי אוטומציה מוכרים כמו Make או Zapier, ההבדל המרכזי הוא מודל העלות. שם משלמים מנוי חודשי ולעיתים גם לפי כמות פעולות. כאן אין מנוי, אין ספירת פעולות, ויש גישה פשוטה ומהירה לשירותי גוגל.

מה אפשר לעשות עם זה

כמה דוגמאות לתהליכים שאפשר לבנות, כולם מבוססים רק על שירותי גוגל ובלי שום כלי חיצוני:

• לשלוח מיילים אוטומטית על בסיס נתונים בטבלה, בדיוק מה שנבנה במדריך הזה
• לשמור קבצים מצורפים מהמייל לתיקייה מסודרת בדרייב לפי חודש או לפי שולח
• לייצר מסמכי Word או PDF מתבנית, כשכל שורה בטבלה הופכת למסמך משלה
• לתייג, לארכב או לנקות מיילים בג'ימייל לפי כללים שאתם מגדירים
• להוסיף תפריט מותאם אישית בתוך גוגל שיטס עם כפתורים שמריצים תהליכים
• לקחת תשובות מטופס גוגל ולהפוך אותן למשימה, למייל אישור או לשורה במערכת
• למשוך נתונים משירות חיצוני, למשל שער מטבע או נתוני מזג אוויר, ולעדכן איתם גיליון
• להריץ כל אחד מאלה לפי לוח זמנים קבוע, בלי שאף אחד יפתח מחשב

ומה אי אפשר: המגבלות שכדאי להכיר מראש

Apps Script הוא לא שרת אמיתי ויש לו מספר מגבלות:

• זמן ריצה מוגבל - פונקציה בודדת נעצרת אחרי שש דקות, וזה נכון גם בחשבון פרטי וגם בחשבון Workspace עסקי. זו מגבלה קשיחה שאי אפשר להרחיב, ולכן עיבוד של עשרות אלפי שורות בבת אחת פשוט לא יסתיים.
• מכסת שליחת מיילים יומית - מאה נמענים ביום בחשבון פרטי, ואלף וחמש מאות בחשבון Workspace. שימו לב שהספירה היא לפי נמענים ולא לפי הודעות, כך שמייל אחד לחמישים אנשים עולה חמישים. לדיוור המוני זה לא הכלי.
• זמן ריצה יומי כולל לתהליכים מתוזמנים - כתשעים דקות ביום בחשבון פרטי, וכשש שעות בחשבון Workspace.
• תזמון הוא בערך ולא בדיוק - טריגר שמוגדר לשמונה בבוקר ירוץ אי שם בין שמונה לתשע, ולא בשמונה ואפס דקות. לתהליכים שדורשים דיוק לשנייה זה לא מתאים.
• אין תגובה בזמן אמת - Apps Script מצוין לתהליכים שרצים כל כמה שעות, ופחות מתאים למשהו שצריך להגיב תוך שנייה.

המספרים האלה משתנים מדי פעם, וגוגל מפרסמת אותם בדף המכסות הרשמי. השורה התחתונה: לתהליכים אישיים ועסקיים בקנה מידה סביר זה יותר מספיק, ולמערכות כבדות צריך משהו אחר.

כאן נכנס ה-AI

עד כאן תיארנו כלי שדורש כתיבת קוד. הנקודה של המדריך הזה היא שאתם לא הולכים לכתוב אותו. מודלי שפה כמו קלוד, שממילא כבר יודע לעבוד מול שירותי גוגל, כותבים Apps Script ברמה גבוהה מאוד, מהסיבה הפשוטה שזו סביבה ותיקה, מתועדת היטב, ועם המון קוד לדוגמה. מה שנשאר לכם הוא לא הידע הטכני אלא היכולת לתאר בדיוק מה אתם רוצים ומה יש אצלכם על המסך. זה כל ההבדל, וזה גם החלק שרוב האנשים עושים לא נכון.

לפני שמתחילים

מה שצריך כדי לעבור את המדריך:

• חשבון גוגל כלשהו, פרטי או עסקי
• גיליון גוגל שיטס עם הנתונים שרוצים לעקוב אחריהם
• גישה לקלוד או למודל שפה אחר (חינמי או בתשלום)
• כרבע שעה

שלב 1: בונים את הטבלה

כל האוטומציה שנבנה מתבססת על טבלה אחת פשוטה עם ארבע עמודות:

• עמודה A, "מה מתחדש" - שם הפריט
• עמודה B, "תאריך" - מתי הוא מתחדש
• עמודה C, "ימים מראש" - כמה ימים לפני התאריך תרצו לקבל התרעה
• עמודה D, "סטטוס" - נשארת ריקה, הסקריפט ימלא אותה בעצמו

עמודה C היא הלב של האוטומציה שלנו. היא מאפשרת לכל שורה התרעה בתאריך הרצוי. על חידוש ביטוח מספיק שבוע מראש, על טסט שנתי אולי שבועיים, ועל חידוש דומיין תרצו חודש שלם.

הטבלה שממנה הכל מתחיל: ארבע עמודות, בלי נוסחאות ובלי הגדרות מיוחדות

נקודה טכנית קטנה: ודאו שהתאריכים בעמודה B הם באמת תאריכים ולא טקסט. הדרך הכי מהירה לבדוק היא להסתכל על היישור בתוך התא. תאריך אמיתי נצמד לימין התא באופן אוטומטי. אם התאריכים אצלכם נצמדים לצד השני, כדאי להיכנס ל-File ואז Settings, לוודא שה-Locale ואזור הזמן מוגדרים נכון, ואז להקליד את התאריכים מחדש.

שלב 2: פותחים את עורך הסקריפטים

מתוך הגיליון עצמו, לוחצים על תפריט Extensions ובוחרים Apps Script. שימו לב שנכנסים דווקא מכאן ולא דרך כתובת חיצונית, כי ככה הסקריפט מחובר לגיליון הזה ויודע לקרוא ממנו נתונים בלי שום הגדרה נוספת.

Extensions ואז Apps Script, מתוך הגיליון עצמו

נפתחת לשונית חדשה עם עורך קוד ובתוכו שלוש שורות ריקות. זה בדיוק הרגע שבו רוב האנשים סוגרים את החלון - אך אין מה לפחד ואנחנו נעבור את זה ביחד!

המסך שמרתיע. מכאן והלאה רק מדביקים

שלב 3: מנסחים את הבקשה למודל

זה החלק החשוב ביותר במדריך. שימו לב שרוב הפרומפט שלמטה הוא לא בקשה אלא תיאור עובדתי של מה שקיים על המסך: שם הלשונית, אילו עמודות יש, מה יש בכל אחת, ומאיזו שורה מתחילים הנתונים. הסיבה פשוטה. המודל כותב Apps Script מצוין, אבל הוא לא רואה את הגיליון שלכם. בקשה בסגנון "תכתוב לי סקריפט שישלח תזכורות מטבלה" תייצר קוד תקין לחלוטין שפונה לעמודות הלא נכונות.

אני עובד ב-Google Apps Script, בפרויקט שמחובר לגיליון גוגל שיטס
(נפתח דרך Extensions ואז Apps Script מתוך הגיליון).

מבנה הגיליון:
- שם הלשונית: Sheet1
- שורה 1 היא שורת כותרות
- עמודה A: "מה מתחדש" (טקסט)
- עמודה B: "תאריך" (תאריך אמיתי, לא טקסט)
- עמודה C: "ימים מראש" (מספר שלם)
- עמודה D: "סטטוס" (ריק, או המילה "נשלח")
- הנתונים מתחילים בשורה 2 ונמשכים עד סוף הטבלה

מה שאני צריך שהסקריפט יעשה בכל הרצה:
1. לעבור על כל השורות מ-2 ומטה.
2. לדלג על כל שורה שבעמודה D כבר כתוב "נשלח", ועל כל שורה ריקה.
3. לחשב כמה ימים נשארו מהיום עד התאריך בעמודה B.
4. אם מספר הימים שנשארו קטן או שווה למספר שבעמודה C, ובו זמנית
   התאריך עוד לא עבר, לצרף את השורה לרשימת התזכורות.
5. אם נמצאה לפחות תזכורת אחת, לשלוח מייל אחד מרוכז לכתובת
   your-email@example.com שמכיל את כל הפריטים.
6. אחרי שליחה מוצלחת בלבד, לכתוב "נשלח" בעמודה D בכל אחת
   מהשורות שנכללו במייל.
7. אם לא נמצאה אף תזכורת, לא לשלוח כלום ולסיים בשקט.

דרישות נוספות:
- כל תוכן המייל בעברית, כולל הנושא. שם הפונקציה והערות בקוד באנגלית.
- אזור הזמן הוא Asia/Jerusalem. תקפיד שחישוב הימים יהיה לפי
  תחילת היום ולא לפי שעה מדויקת, כדי שלא ייפול ביום.
- תאריכים במייל בפורמט DD/MM/YYYY.
- לכל פריט במייל: מה מתחדש, התאריך, וכמה ימים נשארו.
- להוסיף לוג ברור עם Logger.log על כמה שורות נבדקו וכמה נשלחו.
- לעטוף את השליחה ב-try/catch, ואם השליחה נכשלה לא לסמן "נשלח".

תן לי פונקציה אחת ראשית שאפשר להריץ ידנית מהעורך, ותסביר לי
בסוף בשורה אחת מה שם הפונקציה שצריך לבחור בתפריט Run.

שני סעיפים בפרומפט שווים תשומת לב מיוחדת, כי בלעדיהם האוטומציה מעצבנת במקום לעזור. סעיף 2 וסעיף 6 יחד הם מה שגורם למערכת לזכור מה כבר נשלח. בלעדיהם תקבלו את אותה תזכורת בדיוק כל בוקר מחדש, ותכבו את כל התהליך אחרי שלושה ימים.

שלב 4: מדביקים ושומרים

מעתיקים את הקוד שהמודל החזיר, חוזרים לעורך, מוחקים לגמרי את שלוש השורות שהיו שם ומדביקים במקומן. לא מוסיפים מתחת. אחר כך לוחצים על אייקון השמירה, ובהזדמנות הזו נותנים שם לפרויקט במקום Untitled project.

הקוד בעורך אחרי ההדבקה. אף שורה ממנו לא נכתבה ידנית

שלב 5: מריצים ומאשרים הרשאות

בסרגל העליון בוחרים את שם הפונקציה, במקרה שלנו sendUpcomingReminders, ולוחצים Run. כאן מגיע השלב שמפיל הכי הרבה אנשים. גוגל תעצור אתכם ותבקש אישור, כי הסקריפט מבקש לקרוא את הגיליון ולשלוח מייל בשמכם.

בקשת ההרשאה הראשונה. מכאן ממשיכים ב-Review permissions

לוחצים על Review permissions, בוחרים את החשבון, ואז מופיע מסך אדום למדי שמודיע ש-Google hasn't verified this app. זה נראה מפחיד וזה לגמרי תקין. גוגל מאמתת רק אפליקציות שפורסמו לציבור הרחב, וסקריפט אישי שכתבתם לעצמכם לפני שתי דקות מעולם לא עבר אימות כזה ולא אמור לעבור. כדי להמשיך לוחצים על Advanced ואז על השורה התחתונה שמתחילה ב-Go to, ומאשרים.

שווה לעצור כאן לרגע. האישור הזה הוא אמיתי ומשמעותי, והוא נותן לקוד גישה לתיבת המייל ולקבצים שלכם. כשמדובר בקוד שאתם ייצרתם בעצמכם לצורך שאתם מבינים, זה בסדר גמור. כשמדובר בסקריפט שמישהו שלח לכם בוואטסאפ, זו כבר החלטה אחרת לגמרי.

שלב 6: בודקים שזה עבד

אחרי ההרצה נפתח בתחתית המסך חלון Execution log, וזה המקום היחיד שאליו חוזרים כשרוצים לדעת מה קרה. במקרה שלנו הוא מדווח שנבדקו שש שורות ונמצאו שלוש תזכורות.

הלוג מדווח בדיוק מה קרה: שש שורות נבדקו, שלוש תזכורות נשלחו

והמייל מגיע לתיבה, עם שלושת הפריטים ועם מספר הימים שנותר לכל אחד.

התוצאה בתיבת המייל

וכאן החלק שמוכיח שהלוגיקה באמת עובדת ולא סתם שלחה הכל: המקדמה למס הכנסה, שרחוקה שמונה עשר ימים והוגדרה עם התרעה של שלושה ימים בלבד, לא נכנסה למייל. הטסט השנתי, שרחוק אחד עשר ימים והוגדר עם התרעה של ארבעה עשר, כן נכנס. עמודה C עושה בדיוק את מה שהתכוונו.

במקביל, שלוש השורות שנשלחו קיבלו את הסימון "נשלח" בעמודה D, והשאר נשארו ריקות. מכאן, כל הרצה נוספת תדלג עליהן.

הטבלה אחרי ההרצה. הסקריפט סימן בעצמו מה כבר טופל

שלב 7: הופכים את זה לאוטומציה אמיתית

עד עכשיו הרצנו ידנית, וזו עדיין לא אוטומציה. ההפיכה לתהליך שרץ לבד היא הדבר הקצר ביותר בכל המדריך: בסרגל הצד השמאלי של העורך יש אייקון שעון מעורר בשם Triggers. נכנסים אליו, לוחצים על Add Trigger, בוחרים את הפונקציה שלנו, מגדירים Time-driven ואז Day timer ושעה, ושומרים.

מהרגע הזה הסקריפט רץ כל בוקר בעצמו, בודק את הטבלה, ושולח מייל רק אם באמת יש מה לשלוח. אתם לא צריכים לפתוח כלום. נרחיב על תזמונים, על סוגי טריגרים נוספים ועל מה שקורה כשטריגר נכשל במדריך נפרד. בינתיים, אם נושא התהליכים שרצים בלעדיכם מעניין אתכם, כדאי לקרוא גם על הפעלת משימות מרחוק דרך קלוד.

טיפים שיחסכו לכם זמן

• כשמשהו לא עובד, אל תנחשו - פתחו את Execution log, העתיקו את הודעת השגיאה במלואה, והדביקו אותה בחזרה למודל באותה שיחה שבה קיבלתם את הקוד. הוסיפו משפט על מה שראיתם בפועל, ובקשו את הקובץ המלא המתוקן ולא רק את החלק ששונה. זו הלולאה שמחליפה את הידע לתכנת, והיא עובדת גם כשאין לכם מושג מה כתוב בקוד.
• תארו מבנה, לא רק רצון - שמות עמודות, אותיות, שם הלשונית, מאיזו שורה מתחילים. זה מה שמפריד בין קוד שעובד לקוד שנראה מצוין ופונה למקום הלא נכון.
• שנו בקטן - אחרי שהגרסה הראשונה עובדת, בקשו שיפור אחד בכל פעם והריצו שוב. שינוי אחד שנשבר קל לאתר, חמישה שינויים ביחד כבר לא.
• התחילו ממשהו שלא מוחק - אוטומציה ראשונה שקוראת נתונים ושולחת מייל היא בטוחה. אוטומציה ראשונה שמוחקת מיילים או קבצים היא דרך מהירה לצרות.

לפני שאתם רצים לבנות

שתי אזהרות שחשוב שיישארו איתכם:

סקריפט מקבל את ההרשאות שלכם - הקוד רץ בשם החשבון שלכם ויכול לקרוא מיילים, למחוק קבצים ולשלוח הודעות בשמכם. לכן קוד שאתם מייצרים לעצמכם דרך מודל שפה, לצורך שאתם מבינים, הוא סיפור אחד. קוד מוכן שהגיע ממקור לא מוכר הוא סיפור אחר. אם אתם לא בטוחים מה קוד מסוים עושה, הדביקו אותו למודל ובקשו הסבר בעברית פשוטה לפני שאתם מריצים.

אל תבנו על זה מערכת עסקית קריטית לעסק - Apps Script מצוין לתהליכים אישיים וצוותיים בקנה מידה סביר. הוא לא מיועד להיות התשתית של מערכת שהעסק לא יכול לתפקד בלעדיה.

מה הלאה

מה שבנינו כאן הוא לא באמת מערכת תזכורות. זה תבנית. אותו תהליך בדיוק, עם שינוי בטבלה ובפרומפט, יכול לשלוח סיכום שבועי של משימות פתוחות, להתריע על לקוחות שלא שילמו, להזכיר לצוות למלא דוח שעות, או לעקוב אחרי כל דבר אחר שיושב אצלכם בגיליון ומחכה שמישהו יסתכל עליו.

קחו טבלה אחת שאתם כבר מנהלים, שאלו את עצמכם מה הייתם רוצים שיקרה איתה לבד כל בוקר, ותארו את זה למודל בדיוק כמו בפרומפט שלמעלה. הסקריפט הראשון שלכם ירוץ תוך רבע שעה.

ואם התיאבון נפתח, זו בדיוק נקודת הכניסה לעולם שלם של תהליכים שרצים לבד. אפשר להמשיך מכאן לסוכנים מנוהלים של קלוד, ומי שרוצה ללמוד את זה בצורה מסודרת ומעשית מוזמן לקורס קלוד קוד של Let's AI, שמיועד גם למי שאין לו רקע טכני.

הקוד המלא

לנוחיותכם, זה הקוד המלא שהתקבל והורץ במדריך הזה. שימו לב להחליף את כתובת המייל בשורה הראשונה בכתובת שלכם. אנחנו ממליצים בכל זאת לייצר אותו בעצמכם דרך הפרומפט, כי הערך האמיתי הוא בשיטה ולא בקובץ הזה.

/**
 * Main function - checks Sheet1 for upcoming items and sends a single
 * consolidated reminder email for all items due within their configured
 * lead time. Run this manually from the Apps Script editor, or attach
 * a time-driven trigger to it.
 *
 * Column B ("date") is supported in two forms:
 *  - a real Date object (as returned by Sheets when the cell is a true date)
 *  - a text string in DD/MM/YYYY format (as returned when the cell content
 *    is actually stored as text, even if it displays like a date)
 */
function sendUpcomingReminders() {
  var RECIPIENT_EMAIL = 'your-email@example.com';
  var TIMEZONE = 'Asia/Jerusalem';
  var SHEET_NAME = 'Sheet1';
  var STATUS_SENT = 'נשלח';

  var sheet = SpreadsheetApp.getActiveSpreadsheet().getSheetByName(SHEET_NAME);
  if (!sheet) {
    Logger.log('Sheet "' + SHEET_NAME + '" not found.');
    return;
  }

  var lastRow = sheet.getLastRow();
  if (lastRow < 2) {
    Logger.log('No data rows found. Rows checked: 0, reminders sent: 0.');
    return;
  }

  // Read columns A:D from row 2 to the last row
  var numRows = lastRow - 1;
  var range = sheet.getRange(2, 1, numRows, 4);
  var values = range.getValues();

  // Compute "today" at midnight in the target timezone for a clean day-based diff
  var todayStr = Utilities.formatDate(new Date(), TIMEZONE, 'yyyy-MM-dd');
  var today = new Date(todayStr + 'T00:00:00');

  var reminders = []; // { rowIndex, title, dateObj, daysLeft }
  var rowsChecked = 0;

  for (var i = 0; i < values.length; i++) {
    var rowNumber = i + 2; // actual sheet row number
    var title = values[i][0];
    var dateValue = values[i][1];
    var daysAhead = values[i][2];
    var status = values[i][3];

    // Skip empty rows (no title and no date)
    if (!title && !dateValue) {
      continue;
    }

    rowsChecked++;

    // Skip rows already marked as sent
    if (status && String(status).trim() === STATUS_SENT) {
      continue;
    }

    // Determine the value type and parse it into a real Date accordingly
    var targetDate = null;
    var valueType = '';

    if (dateValue instanceof Date && !isNaN(dateValue.getTime())) {
      // Case 1: real Date object
      valueType = 'Date object';
      var dateStr = Utilities.formatDate(dateValue, TIMEZONE, 'yyyy-MM-dd');
      targetDate = new Date(dateStr + 'T00:00:00');

    } else if (typeof dateValue === 'string' && dateValue.trim() !== '') {
      // Case 2: text string, expected format DD/MM/YYYY
      valueType = 'text string';
      var trimmed = dateValue.trim();
      var match = trimmed.match(/^(\d{1,2})\/(\d{1,2})\/(\d{4})$/);

      if (match) {
        var day = parseInt(match[1], 10);
        var month = parseInt(match[2], 10);
        var year = parseInt(match[3], 10);

        // Basic validity check before constructing the date
        if (month >= 1 && month <= 12 && day >= 1 && day <= 31) {
          var candidate = new Date(year, month - 1, day);
          // Verify the constructed date matches the input (guards against e.g. 31/02)
          if (candidate.getFullYear() === year &&
              candidate.getMonth() === month - 1 &&
              candidate.getDate() === day) {
            targetDate = candidate;
          }
        }
      }

      if (!targetDate) {
        Logger.log('Row ' + rowNumber + ' skipped: value type is ' + valueType +
          ' ("' + dateValue + '") but does not match DD/MM/YYYY format.');
        continue;
      }

    } else {
      // Case 3: neither a Date nor a usable string (empty, number, etc.)
      valueType = (dateValue === '' || dateValue === null) ? 'empty' : typeof dateValue;
      Logger.log('Row ' + rowNumber + ' skipped: invalid or missing date (value type: ' + valueType + ').');
      continue;
    }

    Logger.log('Row ' + rowNumber + ': date value type detected as ' + valueType + '.');

    var msPerDay = 24 * 60 * 60 * 1000;
    var daysLeft = Math.round((targetDate.getTime() - today.getTime()) / msPerDay);

    var leadDays = Number(daysAhead);
    if (isNaN(leadDays)) {
      Logger.log('Row ' + rowNumber + ' skipped: invalid "days ahead" value.');
      continue;
    }

    // Date must not have passed (daysLeft >= 0) and must be within the lead window
    if (daysLeft >= 0 && daysLeft <= leadDays) {
      reminders.push({
        rowNumber: rowNumber,
        title: title,
        dateObj: targetDate,
        daysLeft: daysLeft
      });
    }
  }

  Logger.log('Rows checked: ' + rowsChecked + ', reminders found: ' + reminders.length);

  if (reminders.length === 0) {
    Logger.log('No reminders to send. Exiting quietly.');
    return;
  }

  // Build the email content in Hebrew
  var subject = 'תזכורות: פריטים מתקרבים';
  var bodyLines = [];
  bodyLines.push('שלום,');
  bodyLines.push('');
  bodyLines.push('להלן רשימת הפריטים המתקרבים:');
  bodyLines.push('');

  for (var j = 0; j < reminders.length; j++) {
    var item = reminders[j];
    var formattedDate = Utilities.formatDate(item.dateObj, TIMEZONE, 'dd/MM/yyyy');
    var daysLabel = item.daysLeft === 0 ? 'היום' : (item.daysLeft + ' ימים');
    bodyLines.push('- ' + item.title + ' | תאריך: ' + formattedDate + ' | נותרו: ' + daysLabel);
  }

  bodyLines.push('');
  bodyLines.push('הודעה זו נשלחה אוטומטית.');

  var body = bodyLines.join('\n');

  // Send the email, wrapped in try/catch so a failure never marks rows as sent
  try {
    MailApp.sendEmail(RECIPIENT_EMAIL, subject, body);
    Logger.log('Email sent successfully to ' + RECIPIENT_EMAIL + '.');
  } catch (err) {
    Logger.log('Failed to send email: ' + err.message);
    return;
  }

  // Mark the included rows as sent only after a successful send
  for (var k = 0; k < reminders.length; k++) {
    sheet.getRange(reminders[k].rowNumber, 4).setValue(STATUS_SENT);
  }

  Logger.log('Rows checked: ' + rowsChecked + ', reminders sent: ' + reminders.length);
}

הפוסט Google Apps Script: מה זה ומה אפשר לעשות איתו? הופיע ראשון בLet's AI בינה מלאכותית

מה זה בכלל סקיל?

סקיל הוא אוסף הוראות שמלמד את Claude איך לבצע משימה מסוימת בדרך שאתם מעדיפים. הוא יכול להגדיר איזה קבצים לבדוק, איך לקבל החלטות, באיזה סדר לבצע את השלבים ומה צריך להופיע בתוצאה הסופית. לאחר ששומרים אותו, Claude יכול להשתמש בו שוב במשימות דומות.

Record a Skill חוסך את הצורך לתאר את כל התהליך במסמך או לכתוב את קבצי הסקיל באופן ידני. ההקלטה משמשת כחומר הגלם שממנו Claude בונה את ההוראות.

זה גם ההבדל המרכזי בינו לבין כלי שמקליט מאקרו. מאקרו בדרך כלל זוכר סדר קשיח של לחיצות. כאן Claude צופה בתהליך ומנסה להבין את מטרת העבודה ואת הכללים שמאחוריה. עדיין חשוב לבדוק את התוצאה, משום שאין הבטחה שהוא יבין נכון כל טעות, חריגה או החלטה שלא הסברתם.

לפני שמתחילים

נכון ל-27 ביולי 2026, Record a Skill זמין בתוך Cowork באפליקציית Claude למחשבי Mac, למנויי Pro, Max ו-Team. הוא לא זמין כרגע בצ'אט הרגיל, ב-Windows או בתוכניות Free ו-Enterprise. כדאי גם לעדכן את אפליקציית Claude לגרסה האחרונה לפני שמתחילים.

בהקלטה הראשונה macOS עשויה לבקש שתי הרשאות:

1. הרשאת Screen Recording, כדי ש-Claude יוכל לראות את המסך.

2. הרשאת Accessibility, כדי שיוכל לזהות פעולות עכבר ומקלדת.

הרשאות מסך, עכבר ומקלדת

ייתכן שתצטרכו להפעיל מחדש את האפליקציה לאחר אישור ההרשאות.

הכינו את סביבת העבודה

לפני ההקלטה, פתחו מראש את הקבצים ואת האפליקציות הדרושים, סגרו חלונות, שיחות וקבצים שאינם קשורים למשימה, הכינו דוגמה פשוטה ומייצגת והגדירו לעצמכם מהי התוצאה הרצויה. רשמו בצד החלטות שחשוב להסביר במהלך העבודה. המטרה היא לא לבצע הצגה מושלמת. המטרה היא לתת ל-Claude דוגמה ברורה שקל ללמוד ממנה.

ככה מקליטים סקיל, צעד אחר צעד

1. פותחים את Cowork: פתחו את אפליקציית Claude במחשב Mac ועברו למצב Cowork. הפיצ'ר נמצא רק בתוך Cowork ולא בתוך שיחת Claude רגילה. לחיצה על הפלוס (+) בתיבת השיחה תפתח לכם את האפשרויות הבאות:

אפשר להגיע להקלטה גם דרך: Customize > Skills > Add > Record your screen.

2. מתחילים הקלטה: אחרי שבחרתם באפשרות Record a skill, תבחרו את המיקרופון דרכו אתם מדברים ולאחר מכן לחצו על Start recording.

בחירת מיקרופון ותחילת הקלטה (שימו לב לאזהרות!)

3. משאירים את המיקרופון פתוח: הקול שלכם הוא חלק חשוב מההדגמה. Claude יכול לראות שלחצתם על תא מסוים, אבל הוא לא בהכרח יודע מדוע בחרתם דווקא בו. ההסבר הקולי מוסיף את ההיגיון שאי אפשר לראות על המסך. במקום לומר: עכשיו אני לוחץ כאן, עדיף לומר: עכשיו אני בודק את תאריך הקבלה. אם התאריך שייך לחודש הקודם, אני מעביר אותה לדוח של החודש הקודם. ככה Claude לומד כלל שאפשר ליישם גם על קבצים אחרים.

4. מבצעים את המשימה כרגיל: עבדו בקצב טבעי והסבירו כל החלטה חשובה. בכל שלב נסו לענות בקול על שלוש שאלות: מה אני עושה? למה אני עושה את זה? מה צריך לקרות במקרים שונים? סרגל ההקלטה יציג שהצילום פעיל וכמה שלבים נקלטו. ההקלטה יכולה להימשך בערך עשר דקות. כאשר נשארת כדקה, תופיע ספירה לאחור. אם הזמן ייגמר, החומר שנקלט עד אותו רגע יישלח ל-Claude באופן אוטומטי. לכן עדיף להתחיל מתהליך קצר וממוקד. משימה ארוכה אפשר לפצל לכמה סקילים.

5. מסיימים את ההקלטה: לאחר שסיימתם את התהליך, לחצו על Done. לחיצה על Discard תמחק את ההקלטה בלי ליצור ממנה סקיל.

לחצו על Done לסיום ההקלטה

6. בודקים מה Claude למד: לאחר סיום ההקלטה, Claude פותח משימת Cowork ומנתח את מה שראה ושמע. לאחר מכן תופיע אחת משתי הצעות: סקיל חדש שאפשר לשמור או עדכון לסקיל קיים, כאשר Claude מזהה דמיון לתהליך שכבר שמרתם. פתחו את אזור Content וקראו את ההוראות שנוצרו. בדקו אם Claude הבין נכון את מטרת המשימה, את סדר העבודה, את החריגים ואת מבנה התוצאה. רק לאחר הבדיקה לחצו על Save או על Update.

7. מריצים את הסקיל על דוגמה חדשה: לאחר השמירה, הסקיל מופיע תחת Customize > Skills. כדי להשתמש בו, בקשו מ-Claude לבצע את המשימה וציינו את שם הסקיל כאשר הדבר נחוץ. לדוגמה: השתמש בסקיל "מנהל הוצאות" ועבד על הקבלות שבתיקייה הזו. Claude משתמש בשם ובתיאור של הסקיל כדי להבין מתי הוא רלוונטי. אין צורך להסתמך על פקודת לוכסן קבועה, אלא אם היא מופיעה אצלכם בממשק.

דוגמה מעשית: בניית סקיל לטיפול בקבלות

נניח שבכל סוף חודש אתם עוברים על קבלות ומכינים טבלה עבור מנהל החשבונות. במהלך ההקלטה אפשר לומר:

בכל קבלה אני מחפש את שם הספק, התאריך, הסכום הכולל והמע"מ. לאחר מכן אני משייך קטגוריה. אם אני לא בטוח בקטגוריה, אני לא מנחש אלא מסמן "נדרשת בדיקה". בסיום אני יוצר טבלה עם שורה אחת לכל קבלה ומוסיף עמודה עם שם הקובץ המקורי.

ההסבר הזה מלמד את Claude הרבה יותר מסדרה של לחיצות. הוא מגדיר איזה נתונים חשובים, כיצד להתמודד עם חוסר ודאות ואיך צריכה להיראות התוצאה. לאחר שמירת הסקיל, תנו לו תיקייה חדשה עם קבלות אחרות. בדקו לפחות:

• קבלה רגילה וברורה.
• קבלה שחסר בה פרט.
• ספק חדש שלא הופיע בהקלטה.
• מסמך שאינו קבלה.
• מקרה שבו הקטגוריה אינה ברורה.

הקלטה אחת מציגה דוגמה אחת. הבדיקות מגלות אם Claude באמת למד את הכלל.

שלושה דברים שישפרו את ההקלטה

1. דברו על ההחלטות, לא על תנועות העכבר. Claude רואה היכן לחצתם. מה שחסר לו הוא ההיגיון. הסבירו מדוע בחרתם באפשרות מסוימת, מה גורם לכם לדלג על שלב ואילו פרטים משנים את ההחלטה.

2. הכינו את המשימה מראש. פתחו את כל הקבצים לפני תחילת ההקלטה. בחרו דוגמה שמייצגת את העבודה הרגילה וודאו שאפשר לסיים אותה בתוך מגבלת הזמן. הכנה קצרה תמנע מההקלטה להתמלא בחיפושים, המתנות ומעברים שאינם קשורים לתהליך.

3. הסבירו כאילו אתם מדריכים עובד חדש. אל תניחו שדברים מובנים מאליהם. משפט כמו "כאן אני בודק שהסכום בטבלה זהה לסכום בחשבונית" נותן ל-Claude כלל ברור. לחיצה שקטה על שני קבצים אינה מסבירה מה הוא אמור להשוות.

ומה קורה כאשר יש קונקטור?

קונקטורים מאפשרים ל-Claude לגשת לשירותים מחוברים, לקרוא מהם מידע ולבצע בהם פעולות בהתאם להרשאות שהענקתם. לדוגמה, הוא יכול לעבוד עם Google Drive, Slack או Calendar דרך החיבור המתאים. ייתכן ש-Claude ישתמש בקונקטור במקום לחזור על ניווט ידני בממשק. זו יכולה להיות דרך יציבה יותר לביצוע המשימה.

ועדיין, לא כדאי להניח שכל לחיצה תוחלף אוטומטית בקונקטור. פתחו את הסקיל שנוצר ובדקו באילו כלים הוא מתכנן להשתמש. ודאו גם שהקונקטור מחובר ושההרשאות שלו מתאימות לפעולות הנדרשות.

שתי אזהרות שחשוב להכיר

קודם כל, ההקלטה רואה ושומעת הכול. בזמן ההקלטה נלכדים המסך, הלחיצות, ההקלדה והקול שלכם. אל תציגו סיסמאות, פרטי תשלום, מידע רפואי, שיחות פרטיות או מסמכים רגישים. סגרו התראות וחלונות שאינם חלק מהמשימה. בעיקרון, קבצי הווידאו והשמע עצמם אינם נשמרים לאחר העיבוד. עם זאת, צילומי מסך מההדגמה נשמרים בתוך משימת Cowork ויישארו שם עד שתמחקו את המשימה.

דבר שני, סקיל יכול לבצע פעולות אמיתיות. Cowork מסוגל לקרוא קבצים, להשתמש באפליקציות, להריץ קוד ולבצע פעולות דרך כלים מחוברים. פעולה שכותבת, שולחת, מוחקת או משנה מידע מסוכנת יותר מפעולה שקוראת מידע בלבד. Anthropic ממליצה על פיקוח אנושי במשימות רגישות, משום ש-Claude עדיין עלול לטעות.

בפעמים הראשונות, תתחילו ממשימה שהטעות בה הפיכה, תעבדו על עותק של הקבצים, אל תתנו לו למחוק או לשלוח שום דבר אוטומטית, תבדקו את התוצאה לפני אישור פעולות.

לאיזה משימות הפיצ'ר מתאים?

Record a Skill מתאים במיוחד לתהליכים ברורים שחוזרים על עצמם: מיון קבצים, הכנת דוחות קבועים, חילוץ נתונים ממסמכים, בדיקות איכות, שינוי פורמטים, ארגון תיקיות, הכנת מסמכים לפי תבנית וביצוע תהליך קבוע בכמה אפליקציות. הוא פחות מתאים למשימות שבהן כל מקרה דורש שיקול דעת מקצועי עמוק, לפעולות כספיות רגישות או לתהליכים שבהם טעות אחת יכולה לגרום לנזק שקשה לתקן.

להפוך ידע שנמצא אצלכם בראש לכלי שאפשר להפעיל

הערך של Record a Skill נמצא במשימות הקטנות שנשארו ידניות מפני שבניית אוטומציה עבורן הרגישה מוגזמת. עכשיו אפשר להציג ל-Claude את העבודה כפי שהיא מתבצעת בפועל, להסביר את ההיגיון ולשמור את התהליך לשימוש חוזר.

התחילו במשימה אחת קצרה שאתם מבצעים שוב ושוב. הקליטו אותה, קראו את הסקיל שנוצר ובדקו אותו על כמה דוגמאות חדשות. אם הוא מצליח להתמודד גם עם המקרים השונים, חסכתם לעצמכם עבודה שחזרה בכל שבוע והפכתם את הידע שהיה אצלכם בראש לכלי שאפשר להפעיל שוב.

ודרך אגב, אנטרופיק (Anthropic) לא היו הראשונים לצאת עם פיצ׳ר כזה. מי שעובדים עם אפליקציית Codex של OpenAI יכולים להשתמש כבר מיוני 2026 בפיצ'ר דומה בשם Record & Replay. מדגימים תהליך פעם אחת, ו-Codex הופך אותו לסקיל שאפשר להפעיל שוב. במדריך שלנו תמצאו את כל מה שצריך כדי להתחיל.

הפוסט המדריך ל-Record a Skill: מקליטים פעם אחת ו-Claude לומד את המשימה הופיע ראשון בLet's AI בינה מלאכותית