מה זה Projects החדש בקלוד קוד
ב-17 בספטמבר 2026 אנתרופיק שינו את המשמעות של Projects בקלוד קוד. עד אז פרויקט היה בעיקר תיקייה: קבצי רקע, הוראות, וכמה שיחות שאתם פתחתם בעצמכם ותחזקתם בראש. מהגרסה הזאת פרויקט הוא שיחה ראשית אחת שמתפקדת כמו מנהל פרויקט.
אתם מחברים ריפו, נותנים יעד בשפה חופשית, והשיחה הראשית מפרקת אותו לכמה שיחות-משנה שרצות במקביל בענן. כל אחת מהן היא session מלא של קלוד קוד, עם עותק וברנץ’ משלה. הן מריצות בדיקות, פותחות PRs, והשיחה הראשית מדווחת לכם מה הסתיים, מה תקוע ובאיזה סדר למזג.
הכותרת הרשמית של ההכרזה מסכמת את זה טוב: “Projects redesigned: from folder to conversation”.
המבנה: מי עושה מה
| רכיב | התפקיד שלו |
|---|---|
| השיחה הראשית | מקבלת את היעד, קובעת היקף, מחליטה לכמה שיחות לפצל, עוקבת אחרי ההתקדמות ומרכזת את התוצאות. זה ה-Coordinator. |
| שיחת-משנה (thread) | session מלא של קלוד קוד בענן, עם עותק וברנץ’ משלו. מריץ בדיקות ופותח PR. |
| Overview | הלוח שמראה מה מוכן לסקירה, מה ממתין לכם, מה עדיין רץ ומה בהמתנה. |
| הזיכרון | משותף לכל השיחות. החלטה שנפלה בשיחה אחת לא צריכה להיאמר שוב בשנייה. |
זה לא סתם יצירה אוטומטית של work trees
זאת ההשוואה שהכי מבלבלת, אז שווה לחדד. לפי התיעוד של אנתרופיק: worktree נותן לכל session מקומי עותק עבודה משלו של הריפו, כדי ששתי ריצות על המחשב שלכם לא ידרסו אחת את השנייה. שיחות-משנה בענן לא צריכות את זה בכלל, כל אחת משכפלת את הריפו לסנדבוקס משלה ועובדת על ברנץ’ משלה.
במילים אחרות: ה-work trees מפרידים בין העובדים. השיחה הראשית היא זאת שמנהלת אותם.
איך מתחילים
-
- פותחים פרויקט חדש בקלוד קוד ומחברים אליו את הריפו (או כמה ריפואים, אם היעד חוצה מוצרים).
-
- מגדירים את היעד בשפה חופשית, לא משימה בודדת, אלא התוצאה שאתם רוצים.
-
- קלוד מציע לכם חלוקה לשיחות. עוברים עליה לפני שמאשרים: זאת הנקודה היחידה שבה זול לתקן.
-
- בוחרים מודל ורמת מאמץ בנפרד לשיחה הראשית ולשיחות העבודה.
-
- נותנים לזה לרוץ. נכנסים לשיחה בודדת רק כשה-Overview מסמן שהיא ממתינה לכם.
התבנית: הדבר שבשבילו באתם
העתיקו את הבלוק הזה לשיחה הראשית של הפרויקט, מלאו אותו, ושלחו. שלושת החלקים הם בדיוק שלוש הנקודות שנופלות בלעדיהם: יעד מעורפל, חלוקת אחריות שלא הוגדרה, ותוצרים שאף אחד לא בדק.
1. הגדרת יעד
## יעד
<מה צריך להיות נכון כשזה נגמר - תוצאה, לא משימה>
## למה עכשיו
<מה שבור / מה חוסם היום>
## מה אסור לשבור
- משתמשים קיימים
- <חוזה API / סכמה / אינטגרציה>
## הגדרת סיום
- כל הבדיקות עוברות בכל ריפו שנגעתם בו
- PR פתוח לכל ריפו, עם תיאור מה השתנה ולמה
- רשימת סדר מיזוג מוצעת
2. חלוקת אחריות
אל תתנו לקלוד לפצל לבד בלי גבולות. כתבו את הגבולות מראש:
## חלוקה לשיחות
thread-1 repo: api אחראי על: <...> לא נוגע ב: <...>
thread-2 repo: web אחראי על: <...> לא נוגע ב: <...>
thread-3 repo: mobile אחראי על: <...> לא נוגע ב: <...>
## קבצים משותפים
<כל קובץ שיותר משיחה אחת עלולה לגעת בו - תנו אותו לשיחה אחת בלבד>
## סדר
<מה חייב להתמזג לפני מה, ולמה>
החלק של קבצים משותפים הוא זה שחוסך לכם merge conflicts. שתי שיחות שנוגעות באותו קוד ייפגשו בסוף כקונפליקט רגיל בדיוק כמו שני מפתחים.
3. בדיקת התוצרים של כל שיחה
בקשו מהשיחה הראשית דוח בפורמט קבוע. אחרת תקבלו פסקה חופשית ותצטרכו לקרוא את כל ה-PRs בעצמכם:
## דוח סיום - שיחה אחת בכל שורה
| שיחה | ריפו | PR | בדיקות | מה נשאר לי לעשות |
לכל שיחה, ענה בנפרד:
1. מה השתנה בפועל (קבצים, לא כותרות)
2. איזו בדיקה מוכיחה שזה עובד
3. מה לא נבדק ולמה
4. במה השיחה הזאת נוגעת שגם שיחה אחרת נוגעת בה
דוגמה מהתיעוד הרשמי
אנתרופיק נותנים בדיוק את הדוגמה הזאת: מחברים את הריפואים של ה-API, האתר והמובייל, ומגדירים יעד להוציא משימוש endpoint ישן בגרסה 1. קלוד פותח שיחה לכל ריפו, מעביר את הקריאות, מריץ את הבדיקות, פותח PRs, ואז אומר לכם אילו מהם צריך למזג קודם.
שימו לב מה עשתה הדוגמה הזאת נכון: היעד חוצה שלושה ריפואים, אבל הוא יעד אחד, לא שלוש משימות. זה בדיוק ההבדל בין לתת לשיחה הראשית לעבוד לבין לפתוח שלוש שיחות בעצמכם.
טיפים
- יעד אחד לפרויקט. שני יעדים שלא קשורים זה שני פרויקטים, אחרת הזיכרון המשותף מתחיל לעבוד נגדכם.
- השאירו את השיחה הראשית על מודל חזק, ואת שיחות העבודה השחורה על מודל זול ומאמץ נמוך. אפשר לבחור בנפרד.
- עברו על החלוקה שקלוד מציע לפני האישור. תיקון בשלב הזה עולה משפט; תיקון אחרי שלוש שיחות רצות עולה שלוש הרצות.
- קובץ משותף: לשיחה אחת בלבד. זה הכלל היחיד שמונע את רוב הקונפליקטים.
- נכנסים לשיחה בודדת רק כשה-Overview מסמן שהיא ממתינה לכם. לפתוח שיחות סתם זה לחזור להיות מנהל הפרויקטים.
- בקשו דוח בפורמט קבוע. בלי זה אתם קוראים PRs ידנית וביטלתם את כל הרווח.
- שיחה שנתקעה על מכסה ממתינה וממשיכה לבד כשהמכסה מתאפסת, לא צריך לפתוח אותה מחדש.
מגבלות ועלויות: מה לדעת לפני
| נושא | מה זה אומר בפועל |
|---|---|
| בבטא | בגרסת בטא ציבורית למנויי Pro ו-Max שמשתמשים בשיחות ענן. עדיין לא בתוכניות Team ו-Enterprise. |
| מכסת שימוש | פרויקט שורף מכסה מהר יותר משיחה בודדת, כי כל שיחת-משנה היא session מלא. התקרה הנוכחית היא 200 שיחות חדשות ביום על פני כל הפרויקטים. |
| עלות נסתרת | שיחה שסיימה מתעוררת ומוציאה שוב כש-CI נופל או כשמגיעה הערת סקירה ב-PR. |
| merge conflict | שתי שיחות שנגעו באותו קוד ייפגשו כקונפליקט רגיל, בדיוק כמו כל PR אחר. הפיצול לא מבטל את זה. |
| רק בענן | השיחות רצות בענן. הרצה על המכונה שלכם מוכרזת כמשהו שמגיע בקרוב. |
| לא בטרמינל | אין תמיכה ב-CLI בטרמינל ואין שיחות מקומיות בשלב הזה. |
| עבודה לא מקומטת | הסנדבוקס נעצר בין תורות, ועבודה שלא נשמרה ב-commit עלולה ללכת לאיבוד. תנו לשיחות לעשות commit. |
| משתמש אחד | פרויקט שייך למשתמש אחד, ואין בקרות ארגוניות בתקופת הבטא. |
לינקים
- ההכרזה הרשמית: claude.com/blog/projects-redesigned
- ציוץ ההכרזה: x.com/claudeai
- התיעוד של קלוד קוד: docs.claude.com