הפוסט הקודם טען ש-CLAUDE.md מיועד רק לקבועים. אז מה כן שייך ל-memory? פתחתי את כל 5 קבצי ה-memory שפעילים כרגע בפרויקט הזה וביצעתי בהם ביקורת אחד-אחד — מה נשאר, מה צריך למחוק, ואיפה באמת עובר הגבול בין CLAUDE.md ל-memory.
הפוסט הקודם טען ש-CLAUDE.md צריך להכיל רק את מה ש-Claude לא יכול לראות מקריאת הקוד. קורא שאל מיד: ומה לגבי memory? memory זה גם הקשר — מה באמת ההבדל?
הרבה אנשים עם הזמן מתייחסים ל-memory כמו "הרחבת גיבוי" של CLAUDE.md — דוחפים לתוכו כל מה שעולה בראש. ככל שעובר הזמן, memory תופח, Claude קורא אותו בכל שיחה, והחלטות מתקבלות על בסיס מידע שהתיישן.
הפוסט הזה מדלג על ההגדרות המופשטות. פתחתי את כל 5 קבצי ה-memory שפעילים כרגע בפרויקט הזה וביצעתי עליהם ביקורת אחד-אחד — מה נשאר, מה הולך, ומה לא היה צריך להיכתב מלכתחילה. תוך כדי, השאלה CLAUDE.md מול memory עונה על עצמה.
השאלה המועילה אינה "לאן זה הולך" — אלא "כמה זמן חיה האינפורמציה הזאת, ומי מעדכן אותה."
feedback_commits — לחכות שאני אומר "commit" לפני שעושים commit
feedback_article_authenticity — אסור לבדות מאמרי שטח
project_i18n_strategy — ההחלטה "לשחרר את כל השפות בבת אחת"
project_howdev_plan — תוכנית בלתי-גמורה ל-how2claude.dev
project_article_workflow — צינור הפרסום של מאמרים
מקובצים לפי סוג.
הגוף קצר: "don't auto-commit, wait for user to confirm."
זה סוג ה-memory עם ה-ROI הגבוה ביותר. תיקון אחד → קבוע בכל השיחות הבאות.
מדוע לא ב-CLAUDE.md? כי זה לא כלל של פרויקט — זו הרגל עבודה אישי שלי. אם תורם אחר יצטרף לפרויקט, הוא לא בהכרח חייב לקיים את אותו הכלל. CLAUDE.md הוא ברמת הצוות. memory הוא "ביני לבין Claude".
מדוע לא לחזור על זה בתחילת כל שיחה? כי memory נשמר בין שיחות. כש-Claude יעזור לי שבוע הבא, הוא עדיין יזכור.
הטריגר ברור: תיקנתי משהו פעם אחת ואני רוצה שהתיקון יחזיק לנצח.
הגוף של ה-memory הזה ספציפי באופן חריג:
ב-2026-04-16, כשכתבתי את סיום הסדרה multi-agent, בדיתי סיפור על "שלושה Agent-ים הבונים פיצ'ר webhook"... הכל בדיוני. המשתמש שאל "זה אמיתי או המצאה" — זה רף שונה משני המאמרים הקודמים (המתודולוגיים)...
הנקודה: שדה Why אינו עיקרון מופשט — הוא אירוע ספציפי + תאריך + מה קרה.
מדוע לכתוב ככה? בעוד חצי שנה, "מאמרי שטח דורשים חומר אמיתי" ככלל מופשט יבלבל אותי — מתי זה נקבע, למה? אבל "4-16, בדיתי סיפור על agent ונתפסתי" מעורר זיכרון מיידי ומאפשר לי לשפוט במקום האם הכלל עדיין חל.
זאת הרשומה ה"כבדה" ביותר מתוך 5 שלי. זה לא רק כלל — זה תיק אירוע שגם Claude וגם אני יכולים לפנות אליו.
התוכן: מדוע הפרויקט הזה השיק את כל השפות בבת אחת בצורה אגרסיבית — עלות התרגום דרך Claude כמעט 0 דולר, ותיעוד רשמי באנגלית בלבד הוא חלון ההזדמנות המרכזי.
את זה לא רואים מהקוד. הקוד מראה רק 19 קבצי locale. למה 19, למה בבת אחת, למה יפנית וקוריאנית בעדיפות גבוהה — כל זה נמצא בראש שלי.
memory מזקק את ה"החלטה שבראש" למשהו בר-קיימא, כדי ש-Claude כשיציע פיצ'ר בעתיד יוכל לשאול: האם זה מתנגש עם האסטרטגיית i18n?
לא כלל תפעולי (לא נכנס ל-CLAUDE.md). רקע אסטרטגי (נכנס ל-memory).
הזמני ביותר מבין הקבוצה: תוכנית מימוש של 9 קבצים לאתר המפתחים how2claude.dev, נגמרת ב-"להמשיך בשיחה הבאה".
סוג ה-memory המסוכן ביותר — הופך בקלות ל-memory-זומבי. אתה מסיים את העבודה ושוכח למחוק; בפעם הבאה Claude מתייחס אליו כעדיין פעיל ומייעץ על בסיס תוכנית מיושנת ("עוד לא עשית step 3").
memory כזה זקוק ל-מנגנון יציאה מפורש: ברגע ש-how2claude.dev יעלה, אני חייב למחוק את הרשומה ידנית.
צפיפות המידע הגבוהה ביותר. בהתחלה חשבתי שזה המועיל ביותר — עד שקראתי בעיון:
/write-article ו-/publish-article → להסתכל ב-.claude/commands/, זהוdocs/drafts/ הופך את זה לברור.claude/publish-config.jsonClaude יכול להסיק את כל זה מקריאת הקוד.
הדבר היחיד ש-memory באמת מספק הוא הבלוק האחרון: "Accounts (production): zh → @how2claude, en → @howtoclaude" — וזה כבר מיושן. השיחה האחרונה הראתה שבפרודקשן זה בפועל zh=@howtoclaude. memory תפס תמונת מצב מלפני כמה ימים; הוא כבר סטה מהמציאות.
מסקנה: 90% מה-memory הזה צריכים ללכת. החלק שכדאי לשמור ("להשתמש ב-kamal כדי לברר חשבונות בזמן אמת") מתאים יותר ל-CLAUDE.md — או טוב יותר, לאף מקום, כי חשבונות שמקובעים ב-memory יסתו שוב.
1. התפקיד האמיתי של memory הוא לפתוח חדרים ש-Claude לא יכול להיכנס אליהם.
2. אם Claude יכול לקרוא את זה מהקוד, אל תכניס את זה ל-memory.
אותו עיקרון כמו במאמר הקודם על CLAUDE.md. נתיבי קבצים, כתובות API, מבנה תיקיות — שאלות שהקוד עונה עליהן. לדחוף את זה ל-memory כי אין חשק להריץ grep זה להמר שהמידע לא ישתנה לעולם.
3. memory מתכלה.
project_article_workflow הוא ההוכחה — נכתב לפני כמה ימים, והמידע על החשבונות כבר שגוי. ככל ש-memory מבוגר יותר, כך הוא פחות אמין. ביקורת סדירה > הוספה אינסופית.
4. שדה Why הוא מה שמציל אותך.
השווה בין שתי רשומות feedback שלי:
feedback_article_authenticity: "4-16, בדיתי סיפור במאמר multi-agent" → בעוד חצי שנה אני יכול לשפוט מיד אם הכלל עדיין תקף.feedback_commits: רק "user wants to review" → בעוד חצי שנה אני לא בטוח איזה תיקון ספציפי יצר אותו.השני חלש בהרבה. עקרונות מופשטים לא שורדים — אף אחד לא זוכר מדוע נכפו.
כשמופיע מידע חדש, שאל שלוש שאלות:
השאלה השלישית היא המלכודת. רוב הדברים ה"לא משתנים" שאתה רוצה לרשום ניתנים בפועל להסקה מהקוד — פשוט לא בא לך ש-Claude יריץ grep שוב.
אחרי מעבר אחד, כמה דברים בולטים:
project_article_workflow ניתן להסקה מהקוד. זאת הרשומה שצריכה את הניתוח הכי רציני.project_howdev_plan הוא העברה זמנית — תיאורטית צריך להיות לו מנגנון יציאה.project_i18n_strategy היא החלטה אסטרטגית — שווה לבדוק מחדש בעוד כמה חודשים.feedback_commits חלש; צירוף אירוע ספציפי יחזק אותו.תצפית צדדית: התפלגות הסוגים שלי היא feedback×2 + project×3, בלי אף סוג user או reference. כלומר עדיין לא אמרתי ל-Claude "מי אני" או "מאילו מערכות חיצוניות אני קורא מצב". כנראה זאת המנה הבאה שצריך לכתוב.
המלכודת הגדולה ביותר של memory אינה "מה שהייתי צריך לכתוב ולא כתבתי". היא "מה שכתבתי וכעת התיישן". עם 5 רשומות, סטייה אחת מספיקה — Claude משתמש בשקט במידע מיושן כדי להחליט, ולא יסמן לך את הסטייה.
ב-5 שלי אני כבר רואה כמה דברים ששווה לזוז איתם. ואצלך?