Почему твой ИИ каждый раз начинает с нуля, а мой помнит всё за полгода

Почему обычный чат каждый раз начинает с нуля

Открой ChatGPT, объясни ему свой проект, серверы, любимый стиль кода — а завтра в новом чате всё это придётся объяснять заново. У большинства чатов память живёт только внутри одного диалога: кончился контекст или закрыл вкладку — и накопленное знание испарилось. Да, есть «memory»-фичи, которые запоминают пару фактов о тебе, но это короткие заметки, а не рабочая база знаний.

В итоге ты каждый день заново вводишь ассистента в курс дела. Это и есть режим «вопрос → ответ»: спросил — получил ответ — связь оборвалась. Полезно, но это справочник, а не коллега, который помнит, что вы делали вместе вчера, неделю и полгода назад.

Память на файлах — и почему это меняет всё

Claude Code — это агент, который работает прямо в твоих папках и умеет читать и писать файлы. Поэтому его память — не магия внутри модели, а обычные текстовые файлы у тебя на диске. Их можно открыть, прочитать глазами, поправить руками, положить в git. Память видимая и под твоим контролем.

Конструкция держится на трёх слоях:

Грубая аналогия: CLAUDE.md — это памятка «как мы тут работаем», которую сотрудник перечитывает каждое утро. memory/ — это его картотека заметок по делам. А MEMORY.md — оглавление этой картотеки: чтобы найти нужную заметку, не читая все подряд.

Как это устроено внутри — цикл «прочитал → поработал → записал»

Цикл памяти простой и повторяется каждую сессию. Понимая его, ты перестаёшь воспринимать память как чёрный ящик.

CLAUDE.md — правила, которые грузятся каждую сессию

Это самый важный файл. Положи его в корень проекта — и его содержимое будет в контексте всегда. Сюда пишут не факты-однодневки, а устойчивые правила игры: стек, договорённости, стиль, запреты, ссылки на ключевые места. Держи его коротким и плотным — каждая строка тратит контекст.

/CLAUDE.md — каркас правил проекта

# Проект: reels-bot

## Что это
Бот автопостинга Reels в Instagram + автоответы по кодовым словам.

## Стек и где что лежит
- Python 3.11, прод на Mac (живой токен только тут)
- Публикация — прямой 3-шаг через pub_mac.py (НЕ через очередь)
- Видео кладём на NL-CDN, RU-origin Meta отвергает

## Правила (ОБЯЗАТЕЛЬНЫ)
- Все отчёты и скрипты — в ~/brain/, НЕ в /tmp и НЕ на Desktop
- Перед визуальной работой читать design/DESIGN-SYSTEM.md
- После задачи — фиксировать выводы в memory/ + строку в MEMORY.md

## Память
Индекс знаний — в memory/MEMORY.md. Recall по описаниям файлов.

Система memory/ и индекс MEMORY.md

Факты живут не одной свалкой, а отдельными файлами по темам в папке memory/. У каждого файла сверху — небольшой блок метаданных (frontmatter): тип, дата, краткое описание. По этим описаниям агент и понимает, какую заметку открыть под задачу.

Анатомия одного факта-файла

memory/feedback_telethon-no-setdc.md

---
type: feedback
date: 2026-06-01
title: Telethon: не вызывать set_dc на залогиненной сессии
summary: client.session.set_dc() на живой сессии → ключ revoke
links: [[tma-bot]], [[infra-secrets]]
---

# Что произошло
Вызов set_dc() на залогиненной сессии Telethon отзывает ключ —
сессия умирает молча, переавторизация не помогает.

# Правило
НИКОГДА не дёргать set_dc() на уже авторизованной сессии.
Нужен другой DC — создавать новую сессию с нуля.

Четыре рабочих типа заметок

Индекс MEMORY.md — карта, а не свалка

Индекс — это оглавление: одна строка на каждый факт-файл с коротким описанием и ссылкой. Агент читает индекс целиком, а сами файлы — выборочно, под задачу. Поэтому индекс должен быть плотным: одна строка ≈ одна мысль.

memory/MEMORY.md — индекс (фрагмент)

# Память

## Главные правила
- [[feedback_telethon-no-setdc]] — не звать set_dc на живой сессии
- [[reference_design-system]] — читать перед визуальной работой
- Все файлы и отчёты → ~/brain/ (НЕ /tmp, НЕ Desktop)

## Проекты
- [[project_reels-bot]] — автопостинг Reels, прод на Mac
- [[project_ig-platform]] — multi-tenant SaaS, app на сервере

## Инфраструктура
- [[infra_servers]] — список серверов и доступов
- Пароли/токены — в ~/.secrets/ (НЕ в git, НЕ в индексе)

Как это выглядит на дистанции в полгода

Один файл — мелочь. Но память растёт каждую сессию, и за полгода это превращается в живую базу знаний. Вот порядок цифр из реальной памяти, накопленной такой системой:

В этой базе агент помнит какие серверы, какие проекты, какие дизайн-скиллы, где лежит важная информация — и, главное, зачем всё это делается. Появляется конкретная цель, из которой он выстраивает работу. Это и отличает «справочник» от «сотрудника».

Что НЕ стоит писать в память и как не раздуть индекс

Главная угроза большой памяти — не нехватка фактов, а мусор. Раздутый индекс агент читает каждую сессию, и если он засорён — recall тупеет, а контекст тратится впустую.

Чек-лист «настрой память за вечер»

Минимальная рабочая система собирается за один присест. Делай по порядку:

1. Создай CLAUDE.md в корне проекта. Впиши 5–10 строк: что за проект, стек, где что лежит, 2–3 жёстких правила.
2. Добавь в правила строку про память: «после задачи фиксируй важные выводы отдельным файлом в memory/ и строкой в MEMORY.md».
3. Заведи папку memory/ и в ней пустой индекс MEMORY.md с парой заголовков-разделов (Правила / Проекты / Инфра).
4. Запиши 3 первых факта — по одному типа project, feedback, reference. С frontmatter сверху (type, date, summary).
5. Пропиши их в индекс — по одной строке-описанию со ссылкой [[имя]].
6. Положи всё под git — память версионируется, откатывается и не теряется. Секреты — в .gitignore.
7. Проверь recall: начни новую сессию и спроси то, что записал. Если ответил по факту из памяти — система работает.

• CLAUDE.md с правилами лежит в корне и подгружается на старте
• В правилах есть инструкция дописывать выводы в память
• Есть папка memory/ с индексом MEMORY.md
• Минимум 3 факта с frontmatter и ссылками в индексе
• Секреты НЕ в памяти, всё под git