Deep Dive: איך לבנות למידה מתמשכת לקלוד קוד

בפוסט הקודם סיפרתי על הלופ: learn → build → use → systematize → deploy.

עכשיו אסביר לעומק את ה-/command שבניתי ואת המתודולוגיה שהוא מבוסס עליה.

הבעיה

LLMs לא זוכרים.

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

זה בזבוז. הידע הזה שווה משהו.

הפתרון: Retrieval Layer

במקום לשנות את המודל (fine-tuning), בונים שכבה שצוברת ידע מובנה.

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

Snapshots - ההקשר

Snapshot = תמונת מצב של תהליך שלם.

בעבודה שלי עם קלוד קוד, snapshot זה השיחה המלאה - הבעיה שהתחלתי ממנה, מה ניסינו, מה נכשל, מה עבד בסוף. לא רק התשובה הסופית - כל הדרך.

במחקר שוק, snapshot זה סבב מחקר שלם - השאלה ששאלתי, מה חיפשתי, אילו מקורות בדקתי, מה מצאתי.

למה זה חשוב?

בלי הקשר, תובנה לבד לא מספיקה. “השתמש ב-async לקריאות DB” - מתי? תמיד? רק במקרים מסוימים? ה-snapshot שומר את הסיפור המלא כדי שאפשר יהיה להבין מתי התובנה רלוונטית.

Claims - התובנות המזוקקות

Claim = משפט אחד ברור שאפשר לאמת או להפריך.

לא “עבדנו על הפרויקט ותיקנו כמה באגים”. כן: “useEffect cleanup רץ לפני ה-effect הבא, לא ב-unmount”.

למה מזקקים?

כי מידע גולמי לא שימושי לטווח ארוך. שיחה של שעה עם קלוד יכולה להכיל 3 תובנות אמיתיות. השאר - קונטקסט, ניסויים, שגיאות. ה-claims הם מה ששווה לזכור.

איך קלוד מחליט מה לשמור?

הוא מחפש:

• פתרונות טכניים שעבדו (באג שתוקן, pattern שהצליח)
• הפתעות - משהו שהתנהג אחרת ממה שציפיתי
• טעויות שכדאי להימנע מהן
• כלים או ספריות שהתגלו כשימושיים

מה שהוא לא שומר:

• דברים גנריים מדי (“קוד צריך להיות נקי”)
• דברים ספציפיים מדי לפרויקט אחד בלי ערך כללי
• ניסיונות שנכשלו בלי תובנה למה

Sources - המקור והאמינות

Source = מאיפה הגיעה התובנה.

תובנה שעלתה מפרויקט אמיתי בפרודקשן ≠ תובנה מניסוי קטן.

תובנה שחזרה ב-3 פרויקטים שונים ≠ תובנה שמצאתי פעם אחת.

למה זה משנה?

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

למה צריך את שלושתם?

• Snapshot בלי claims = הרבה מידע, קשה למצוא את העיקר
• Claims בלי snapshot = תובנות תלושות, בלי הקשר מתי להשתמש
• Claims בלי sources = לא יודעים כמה לסמוך על התובנה

השלושה ביחד = ידע מובנה שאפשר לחפש, לאמת, ולהשתמש בו.

העיקרון המרכזי: Repetition = Confidence

תובנה שמופיעה פעם אחת? אולי רלוונטית.

תובנה שחוזרת 4 פעמים בפרויקטים שונים? כנראה אמיתית ושימושית.

זה הלב של המערכת. לא רק לשמור - לחזק מה שחוזר.

איך העיקרון הופך למתודולוגיה?

העיקרון פשוט: חזרה = אמינות. אבל איך מיישמים את זה?

כל claim מקבל מונה:

• seen_count - כמה פעמים ראינו את התובנה הזו
• first_seen - מתי פעם ראשונה
• last_seen - מתי לאחרונה
• confidence - רמת האמינות

חוקי שדרוג:

• seen_count 1 → confidence: low (ראיתי פעם אחת, אולי מקרי)
• seen_count 2-3 → confidence: medium (חוזר, כנראה משהו בזה)
• seen_count 4+ → confidence: high (חוזר הרבה, כנראה אמיתי)

למה 4 ולא 10?

כי רוב התובנות האמיתיות יופיעו 2-5 פעמים בעבודה רגילה. אם דורשים 10, רוב הידע לעולם לא יגיע ל-high confidence. הסף צריך להיות מציאותי.

מה קורה כשיש חזרה?

קלוד מזהה ש-claim חדש דומה לקיים. במקום לשמור כפילות:

### [REINFORCED] useEffect cleanup runs before the next effect
- Already in: 2024-12-10-react-patterns.json
- Updating: seen_count 1→2, confidence low→medium
- Adding source: "dashboard-project"

ה-claim הקיים מתעדכן. לא נוצר חדש.

מה קורה כשיש סתירה?

לפעמים claim חדש סותר משהו שכבר שמרנו:

### [CONTRADICTS] Use sync DB calls for simple scripts
- Conflicts with: "Always use async for DB calls" (confidence: medium)
- Context matters: async for production, sync OK for scripts

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

• לעדכן את הקיים?
• לשמור את שניהם (כי הקונטקסט שונה)?
• לבחור אחד?

הסתירות הן הזדמנות. הן מראות שהתובנה המקורית לא הייתה מדויקת מספיק. “Always use async” הופך ל-”Use async for production, sync OK for scripts”. הידע משתכלל.

מה קורה כש-claim לא חוזר?

כרגע - כלום. הוא נשאר עם confidence נמוך.

אפשר להוסיף לוגיקה של “decay” - אם claim לא חזר שנה, להוריד confidence. אבל התחלתי בלי זה כי זה מוסיף מורכבות. Keep it simple, שפר בהמשך.

איך זה עובד בפועל

יצרתי /command לקלוד קוד שמיישם את זה. בסוף כל שיחה משמעותית, אני מריצה /learn וקלוד עובר על מה שעשינו.

הזרימה:

שלב 1: טעינת ידע קיים קלוד קורא את כל הקבצים מ-~/.claude/knowledge/. עכשיו הוא יודע מה כבר למדנו בעבר.

שלב 2: חילוץ תובנות מהשיחה קלוד עובר על השיחה ומחפש:

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

שלב 3: השוואה לקיים לכל תובנה שחילץ, קלוד בודק:

• NEW - לא ראינו את זה → שומר עם seen_count: 1, confidence: low
• REINFORCED - כבר קיים → מעדכן seen_count, אולי מעלה confidence
• SIMILAR - דומה אבל לא זהה → שואל: למזג? לשמור שניהם?
• CONTRADICTS - סותר משהו קיים → מציג לבדיקה

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

שלב 5: שמירה קבצי JSON מאורגנים לפי נושא ותאריך.

המבנה של כל תובנה

{
  "statement": "משפט אחד ברור",
  "category": "technical|solution|pattern|tool|warning",
  "confidence": "low|medium|high",
  "seen_count": 1,
  "first_seen": "2024-12-17",
  "last_seen": "2024-12-17",
  "sources": ["project-name"],
  "context": "מתי/למה זה שימושי",
  "tags": ["tag1", "tag2"]
}

דוגמה מלאה: מהשיחה לידע

יום ראשון - פרויקט Dashboard

עבדתי עם קלוד על באג ב-React. אחרי שתיקנו, הרצתי /learn:

## Extracted Insights

### [NEW] useEffect cleanup function runs before the next effect, not on unmount
- Category: technical
- Will save with: confidence=low, seen_count=1
- Tags: #react #hooks #useEffect
- Context: Caused memory leak in subscription handling

### [NEW] React StrictMode runs effects twice in development
- Category: warning
- Will save with: confidence=low, seen_count=1
- Tags: #react #debugging
- Context: Explains duplicate API calls in dev mode

נשמר לקובץ 2024-12-17-react-hooks.json.

שבוע אחרי - פרויקט אחר

באג דומה בפרויקט אחר. הרצתי /learn:

## Extracted Insights

### [REINFORCED] useEffect cleanup function runs before the next effect
- Already in: 2024-12-17-react-hooks.json
- Updating: seen_count 1→2, confidence low→medium
- Adding source: "analytics-dashboard"

### [NEW] Custom hooks should return cleanup functions when using subscriptions
- Category: pattern
- Will save with: confidence=low, seen_count=1
- Tags: #react #hooks #custom-hooks

עכשיו יש לי:

• תובנה אחת ב-medium confidence (חזרה פעמיים)
• שתי תובנות ב-low confidence (חדשות)

חודש אחרי

אותה תובנה על useEffect עולה שוב. עכשיו היא seen_count: 3, עדיין medium. עוד פעם אחת והיא תהיה high confidence.

הידע מצטבר ומתחזק.

למה זה עובד

המודל לא משתנה. המערכת סביבו מתחכמת.

בלי המערכת:

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

עם המערכת:

• תובנות מצטברות
• מה שחוזר מתחזק
• סתירות מתגלות ומתבררות

זה “poor man’s continuous learning” - בלי fine-tuning, בלי תשתיות מורכבות. רק retrieval חכם + מבנה נתונים פשוט.

השקעה קטנה, תשואה גדולה: להריץ /learn בסוף שיחה לוקח דקה. אחרי חודש יש לי ידע מצטבר שחוסך שעות.

הקוד המלא

מה זה ה-/command?

זו הוראה לקלוד קוד שאומרת לו איך לחלץ ולשמור תובנות מהשיחה.

העיקרון המרכזי: Repetition = Confidence

הזרימה:

1. טוען ידע קיים - קורא כל הקבצים מ-~/.claude/knowledge/
2. מחלץ תובנות מהשיחה - מחפש: פתרונות טכניים, באגים שתוקנו, patterns, כלים חדשים, טעויות להימנע מהן
3. משווה לקיים - לכל תובנה בודק:
   • NEW - חדש לגמרי → שומר עם seen_count: 1, confidence: low
   • REINFORCED - כבר קיים → מעלה seen_count, אולי מעלה confidence
   • SIMILAR - דומה אבל שונה → שואל אותך: למזג? לשמור שניהם?
   • CONTRADICTS - סותר משהו קיים → מסמן לבדיקה
4. מציג לך מה מצא - לפני שמירה
5. שומר - קבצי JSON עם מבנה אחיד

חוקי שדרוג confidence:

• seen_count 1 → low
• seen_count 2-3 → medium
• seen_count 4+ → high

הנה ה-/command המלא. שימו אותו ב-.claude/commands/learn.md:

# /learn - Extract and save insights from conversation

You are an insight extraction agent with reinforcement learning.
Extract learnings and STRENGTHEN existing knowledge when claims repeat.

## Core Principle

**Repetition = Confidence.** When the same insight appears multiple times
across conversations, it becomes MORE reliable. Don't skip duplicates - reinforce them!

## JSON Schema

{
  "insights": [
    {
      "statement": "Clear, single-sentence insight",
      "category": "technical|solution|pattern|tool|warning",
      "confidence": "low|medium|high",
      "seen_count": 1,
      "first_seen": "2024-12-17",
      "last_seen": "2024-12-17",
      "sources": ["project-name"],
      "context": "Brief context of when/why this is useful",
      "tags": ["tag1", "tag2"]
    }
  ]
}

## Instructions

### Step 1: Load existing knowledge
Read ALL files from `~/.claude/knowledge/*.json`. Build a map of all existing statements.

### Step 2: Extract insights from conversation
Look for:
- Technical insights (how something works)
- Problem solutions (bugs fixed, issues resolved)
- Best practices discovered
- New tools/libraries/patterns learned
- Mistakes to avoid

### Step 3: Compare each insight against existing

| Found | Action |
|-------|--------|
| NEW (never seen) | Add with seen_count: 1, confidence: low |
| REINFORCED (same fact exists) | Update existing: seen_count++, last_seen=today, maybe upgrade confidence |
| SIMILAR (related but different) | Ask user: merge, keep both, or skip |
| CONTRADICTS (conflicts with existing) | Flag for user review |

**Confidence upgrade rules:**
- seen_count 1 → confidence: low
- seen_count 2-3 → confidence: medium
- seen_count 4+ → confidence: high

### Step 4: Present results to user

### Step 5: Apply updates
- **NEW insights**: Save to new file `~/.claude/knowledge/YYYY-MM-DD-{topic}.json`
- **REINFORCED insights**: Update the EXISTING file where the insight lives
- **SIMILAR/CONTRADICTS**: Apply user's decision

### Step 6: Summary
Show what changed:
Saved: 2 new insights
Reinforced: 1 existing insight (confidence: low → medium)
Skipped: 1 duplicate

## Quality Guidelines
- Each insight should be **self-contained**
- Be **specific** not generic
- Include **actionable** information
- Tag appropriately for future search

הלופ חוזר

learn → build → use → systematize → deploy

---

שאלות? תגובות? אשמח לשמוע מה עובד לכם.