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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

בהצלחה!