Skip to content
Recursive Loops·6 min·עברית

מפת רקורסיית הלופים של Claude Code

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

מפת רקורסיית הלופים של Claude Code

מה מקבלים

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

למי זה מתאים

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

1. המפה כולה

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

תיבה להעתקה
/schedule
  -> /goal
    -> workflow
      -> 3 worktrees
        -> judge
          -> response
            -> stop

2. השכבה הראשונה: טריגר זמן

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

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

3. השכבה השנייה: יעד ותנאי עצירה

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

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

4. השכבה השלישית: workflow לכל באג

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

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

5. השופט בוחר לפי ראיות

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

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

6. תבנית מוכנה להעתקה

תיבה להעתקה
/schedule every hour:
Scan <feedback source> for new bug reports created since the previous run.

/goal:
Do not finish this run until every report found in this run is:
1. triaged,
2. assigned an action,
3. answered with current status.

For each confirmed bug:
1. Reproduce it and save the evidence.
2. Create three isolated worktrees.
3. Ask each worktree for a different fix.
4. Run the same tests against all three fixes.
5. Ask an adversarial judge to compare correctness, risk, and maintainability.
6. Apply only the winning fix.
7. Re-run tests and write the response.

Stop when:
- every report has a recorded outcome,
- required tests pass,
- no unresolved high-risk finding remains,
- or max_attempts is reached.

Limits:
- max_attempts: 3
- max_parallel_worktrees: 3
- write_access: only inside isolated worktrees
- production_changes: require explicit approval

7. צ׳קליסט בטיחות לפני ההרצה

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

8. טעויות שמפרקות את המנגנון

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

איך להשתמש בזה עכשיו

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

AI-native products, workshops, and automations. Built from everywhere.

© 2026 Daniel Goldman