פירוק משימה גדולה לצעדים ש-AI מבצע היטב

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

מאת צוות Core-Code · עודכן ב-2026-06-03.

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

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

מחקר על פירוק דינמי של משימות הראה שחלוקה מותאמת לצעדים הורידה את שיעור השגיאה (pass@10) בעד 10.5% לעומת ניסיון לפתור הכול במהלך אחד (DISC, arXiv 2025). זה הגיוני: צעד קטן הוא מרחב ניחוש קטן, ולכן פחות מקום לטעות.

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

לעומק (למתקדמים): כל טוקןטוקן(Token)טוקן (token) הוא יחידת הטקסט הבסיסית שמודל AI מעבד — בערך מילה או חלק ממילה. המודל קורא וכותב בטוקנים, חלון ההקשר נמדד בטוקנים, והתמחור לרוב לפי טוקנים. כאלף טוקנים ≈ 750 מילים באנגלית (פחות בעברית). שה-AI מייצר מותנה בקודמיו. בבקשה אחת ענקית, החלטה שגויה מוקדמת "מרעילה" את ההקשר וכל ההמשך נבנה על בסיס רעוע, בלי שום נקודת עצירה לתיקון. פירוק מכניס checkpoints אנושיים בין צעדים: אתם מאמתים את המצב, מתקנים אם צריך, ורק אז נותנים ל-AI בסיס נקי להמשיך ממנו. ככה "extreme decomposition + error correction" מאפשר לבצע אפילו שרשראות ארוכות מאוד בלי שהטעויות יצטברו.

באיזה סדר לבצע? בואו נסדר תהליך אמיתי

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

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

Put in order

סדרו את תת-המשימות של פיצ'ר 'מועדפים'

0 מתוך 4 סודרו

• להגדיר את מבנה הנתונים: איפה נשמר ה-favorite (שדה / טבלה) ומה המפתח
• לכתוב את הלוגיקה: פונקציות addFavorite / removeFavorite / isFavorite
• לחבר את הממשק: כפתור לב שקורא ללוגיקה ומשנה מצב
• להוסיף בדיקות: לוודא שהוספה, הסרה ושמירה עובדות כצפוי

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

איך בונים בקשה ממוקדת לתת-משימה אחת?

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

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

Build a prompt

בונים פְּרוֹמְפְּט שלב אחר שלב

שלב 1 מתוך 3

כתוב פונקציות לניהול מועדפים... ▍

1הקשר

• א...בקובץ הקיים favorites.js, שמשתמש כבר ב-store הקיים שלנו ל-state
• ב...איפשהו בפרויקט, איפה שנוח לך

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

תרגול מהיר: לזהות צעד שצריך לפצל

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

Checkpoint

איזו מהבקשות הבאות היא תת-משימה אחת בריאה (ולא שתיים בתחפושת)?

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

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

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