Что класть в memory? Аудит моих 5 записей, по одной

Предыдущий пост утверждал, что в CLAUDE.md должно быть только то, что Claude не может увидеть, читая код. Читатель тут же спросил: а как же memory? Memory — это тоже контекст, так в чём реальная разница?

Многие со временем начинают относиться к memory как к «резервному расширению» CLAUDE.md — сваливают туда всё, что приходит в голову. Со временем memory разбухает, Claude читает его каждую сессию, и решения принимаются на устаревшей информации.

Этот пост пропускает абстрактные определения. Я открыл все 5 файлов memory, которые сейчас живут в этом проекте, и проаудитировал их один за другим — что остаётся, что идёт в мусор, а что вообще не стоило писать. По ходу вопрос CLAUDE.md vs memory отвечает сам на себя.

Разница в одной строке

• CLAUDE.md попадает в system prompt каждой сессии. Статичный. Для инвариантов.
• memory Claude сам читает и обновляет. Динамичный. Для фактов, которые меняются, или отдельных событий, которые стоит сохранить.

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

Мои 5 файлов memory

feedback_commits               — ждать, пока я скажу "commit", и только тогда коммитить
feedback_article_authenticity  — практические статьи нельзя выдумывать
project_i18n_strategy          — решение «выпустить все языки одновременно»
project_howdev_plan            — незавершённый план для how2claude.dev
project_article_workflow       — пайплайн публикации статей

Сгруппируем по типу.

Тип A: Одна поправка становится вечным правилом (feedback_commits)

Тело короткое: "don't auto-commit, wait for user to confirm."

Самый высокий ROI среди типов memory. Одна поправка → постоянна в каждой будущей сессии.

Почему не в CLAUDE.md? Это не правило проекта — это моя личная рабочая привычка. Если к проекту подключится другой контрибьютор, ему не обязательно следовать тому же правилу. CLAUDE.md — на уровне команды. Memory — «между мной и Claude».

Почему не повторять в начале каждого разговора? Потому что memory сохраняется между сессиями. Когда Claude будет помогать мне на следующей неделе, он всё ещё будет это помнить.

Триггер чистый: я поправил один раз и хочу, чтобы поправка сохранялась вечно.

Тип B: Дело об инциденте с датой (feedback_article_authenticity)

Тело этого memory необычно конкретно:

2026-04-16, когда я писал финал серии multi-agent, я выдумал историю о «трёх Agent'ах, строящих webhook-фичу»... всё выдумано. Пользователь спросил «это реально или придумано?» — это другой уровень ожиданий, чем у двух предыдущих (методологических) статей...

Суть: поле Why не абстрактный принцип — это конкретное событие + дата + что произошло.

Почему так написано? Через полгода «практическим статьям нужен реальный материал» как абстрактное правило меня озадачит — когда это зафиксировали, почему? А «4-16, выдумал историю про agent и попался» вызывает мгновенное воспоминание и позволяет на месте судить, применимо ли правило.

Это самая «тяжёлая» запись из моих 5. Это не просто правило — это дело об инциденте, к которому могут обращаться и Claude, и я.

Тип C: Контекст стратегического решения (project_i18n_strategy)

Содержание: почему этот проект агрессивно запустил все языки одновременно — стоимость перевода через Claude ~$0, и английская официальная документация — ключевое окно возможностей.

Этого не видно из кода. Код показывает только 19 файлов локали. Почему 19, почему одновременно, почему японский и корейский в приоритете — всё это живёт у меня в голове.

Memory кристаллизует это «решение в голове» в нечто устойчивое, чтобы Claude, когда позже будет предлагать фичу, мог спросить: конфликтует ли это со стратегией i18n?

Это не операционное правило (не в CLAUDE.md). Это стратегический фон (в memory).

Тип D: Передача между сессиями (project_howdev_plan)

Самый временный из всех: план реализации из 9 файлов для сайта разработчиков how2claude.dev, заканчивается словами «продолжить в следующей сессии».

Самый опасный тип memory — легко превращается в зомби-memory. Закончил работу, забыл удалить; в следующий раз Claude считает его актуальным и советует на основе устаревшего плана («вы ещё не сделали step 3»).

Таким memory нужен явный механизм выхода: в момент, когда how2claude.dev будет запущен, мне придётся удалить эту запись вручную.

Тип E: Та, которую надо удалить (project_article_workflow)

У этой самая высокая плотность информации. Сначала думал, это самая полезная — пока не прочитал внимательно:

• Существование /write-article и /publish-article → посмотреть .claude/commands/, готово
• Структура каталога draft (meta.json + lang.md) → docs/drafts/ делает это очевидным
• API URL → лежит в .claude/publish-config.json
• Список slug'ов category/series → в seed-файле

Claude может вывести всё это, читая код.

Единственное, что memory действительно даёт, — последний блок: "Accounts (production): zh → @how2claude, en → @howtoclaude" — и это уже устарело. В прошлой сессии оказалось, что в продакшене на самом деле zh=@howtoclaude. Memory зафиксировал снимок нескольких дней назад; он уже разъехался с реальностью.

Вывод: 90 % этого memory должно уйти. Часть, которую стоит сохранить («использовать kamal, чтобы опрашивать аккаунты вживую»), лучше подходит для CLAUDE.md — или, ещё лучше, нигде, потому что захардкоженные в memory аккаунты всё равно снова разъедутся.

Четыре вывода

1. Настоящая задача memory — открывать комнаты, в которые Claude не может войти.

• Не может войти в мою голову → стратегия, предпочтения, причины
• Не может войти в сессию прошлой недели → что я в тебе поправил
• Не может войти в провал трёхмесячной давности → конкретное событие + дата

2. Если Claude может прочитать это в коде, не помещай это в memory.

Тот же принцип, что и в предыдущей статье про CLAUDE.md. Пути к файлам, URL API, структура каталогов — всё это вопросы, на которые отвечает код. Запихивать в memory, чтобы не делать grep ещё раз, — это ставка на то, что информация никогда не изменится.

3. Memory ветшает.

project_article_workflow — доказательство: написано пару дней назад, информация об аккаунтах уже неверна. Чем старше memory, тем меньше ей можно доверять. Регулярный аудит > бесконечные добавления.

4. Поле Why — это то, что вас спасает.

Сравните два моих feedback'а:

• Why у feedback_article_authenticity: «4-16, я выдумал историю в статье multi-agent» → через полгода я могу мгновенно оценить, применимо ли правило.
• Why у feedback_commits: только «user wants to review» → через полгода я не уверен, какая конкретная поправка его породила.

Второй заметно слабее. Абстрактные принципы не выживают — никто не помнит, зачем их вводили.

Дерево решений: CLAUDE.md vs memory vs ничего

Когда появляется новая информация, задайте три вопроса:

1. Может ли Claude вывести это из кода? Да → не пишите ничего.
2. Должны ли этому следовать все контрибьюторы? Да → CLAUDE.md.
3. Изменится ли это со временем? Да → memory (с конкретным Why + How to apply).

Третий вопрос — ловушка. Большинство «неизменных» вещей, которые хочется записать, на самом деле выводимы из кода — просто не хочется, чтобы Claude снова делал grep.

Что я вижу после аудита

После прохода несколько вещей бросаются в глаза:

• 90 % project_article_workflow выводимо из кода. Этой записи нужна самая серьёзная операция.
• project_howdev_plan — временная передача; в теории у неё должен быть механизм выхода.
• project_i18n_strategy — стратегическое решение; стоит пересмотреть через пару месяцев.
• Why у feedback_commits слабый; привязать конкретное событие сделает его устойчивее.

Побочное наблюдение: моё распределение типов — feedback×2 + project×3, и ноль типов user или reference. Значит, я ещё не сказал Claude, «кто я» или «из каких внешних систем я считываю состояние». Вероятно, это следующая партия к написанию.

Заключение

Главная ловушка memory — не «что я должен был записать, но не записал». А «что я записал, и оно теперь устарело». При 5 записях достаточно одного смещения — Claude молча использует устаревшую информацию для решений и не сообщит вам о смещении.

В моих 5 я уже вижу несколько вещей, которые хочется подвинуть. А в ваших?