Memory Bank в Cline: как настроить память проекта

Короткий ответ на вопрос «Memory Bank в Cline: как настроить память проекта»: Memory Bank — это методология документации. Вы копируете набор инструкций в файл правил, просите Cline «initialize memory bank», и агент ведёт шесть markdown-файлов, которые читает в начале каждой задачи. Ниже — структура, шаги, цикл и диагностика.

Что такое Memory Bank и чем он не является

В документации Cline Memory Bank описан как методология документации, которая превращает Cline из ассистента без состояния в постоянного партнёра по разработке: через структурированные markdown-файлы Cline «помнит» детали проекта между сессиями. Официальный блог проекта называет его набором пользовательских инструкций, созданным сообществом.

Ключевое следствие: в интерфейсе нет тумблера «включить память». Память появляется, когда выполнены два условия — в проекте лежат файлы memory-bank/, а в правилах Cline записано требование их читать. Без правил файлы останутся обычными документами, которые агент откроет только по прямой просьбе.

Второе следствие касается ожиданий. Memory Bank хранит знания о проекте в текстовом виде, поэтому его качество равно качеству ваших записей. Пустой activeContext.md даст тот же результат, что и его отсутствие.

Третье: методология переносима. В FAQ документации Cline сказано, что Memory Bank работает с любым ИИ, который умеет читать документы; команды могут отличаться, подход сохраняется. Это удобно, если вы используете несколько инструментов.

Наконец, Memory Bank отвечает на вопрос «что это за проект и где мы остановились». Ответ на вопрос «какой код был в файле на прошлом шаге» даёт другой механизм — об этом ниже.

Структура каталога memory-bank и роль файлов

Документация Cline приводит иерархию из шести основных файлов. Каждый отвечает за свой слой знаний, и файлы надстраиваются друг над другом.

Документация Cline отдельно отмечает, что activeContext.md меняется чаще всего, а progress.md служит для отслеживания вех. Дополнительные файлы и папки внутри memory-bank/ разрешены, когда они помогают организовать материал: описание сложной функции, спецификация интеграции, документация API, стратегия тестирования, процедура деплоя.

Практический порядок заполнения: начните с короткого projectbrief.md и дайте структуре вырасти. Документация Cline советует именно такой старт — базовый бриф, а детализация появляется по мере работы.

Инициализация: команда initialize memory bank

Быстрая настройка по документации Cline состоит из трёх шагов: скопировать инструкции, добавить их в файл правил Cline (например, .clinerules/memory-bank.md) и попросить Cline «initialize memory bank».

Разберём каждый шаг.

Первый. Текст инструкций опубликован на странице документации Memory Bank. Это готовый блок для вставки, менять в нём ничего не нужно.

Второй. Файл правил кладётся в каталог .clinerules/ или .cline/rules/ в корне проекта. Имя memory-bank.md выбрано для наглядности; подойдёт любое осмысленное.

Третий. Фраза «initialize memory bank» запускает создание начальной структуры для нового проекта. Cline предложит черновики файлов, которые вы правите под себя.

Отдельная команда «update memory bank» запускает полный просмотр и обновление документации. Команда «follow your custom instructions» говорит Cline прочитать Memory Bank и продолжить с того места, где вы остановились.

Если проект уже существует, после инициализации перечитайте projectbrief.md: по шаблону вендора это источник истины о границах проекта, поэтому цели и рамки в нём стоит сверить и поправить самому.

Рабочий цикл: чтение перед задачей, обновление после изменений

Цикл состоит из двух тактов.

Перед задачей Cline читает файлы Memory Bank. В тексте инструкций вендора это сформулировано жёстко: агент обязан прочитать все файлы памяти в начале каждой задачи. На практике вы либо полагаетесь на правило, либо явно пишете «follow your custom instructions» в начале сессии.

После значимых изменений память обновляется. Документация Cline перечисляет четыре повода: обнаружен новый проектный паттерн, реализовано значимое изменение, пользователь запросил «update memory bank», контекст требует уточнения. При запросе на обновление агент обязан просмотреть все файлы.

Частоту обновлений документация Cline описывает так: после значимых вех или смены направления, а при активной разработке — каждые несколько сессий. Рутинное управление контекстом можно оставить автоматическому сжатию, а ручное «update memory bank» приберечь для важных контрольных точек.

Практическое правило для activeContext.md: обновляйте его после каждой сессии. Это самый дешёвый способ не потерять нить работы.

Memory Bank, checkpoints и контекстное окно

Это три разных механизма, и путаница между ними порождает большинство разочарований.

Документация Cline объясняет связь так: у каждой модели есть контекстное окно, которое ограничивает объём обрабатываемой информации, и по мере работы оно заполняется историей диалога, содержимым файлов и результатами инструментов. Memory Bank помогает сохранить важные знания, когда нужно освободить место.

Ручной порядок действий при заполнении окна: попросить «update memory bank», начать новый разговор, попросить «follow your custom instructions». Знания остаются в файлах, и работа продолжается в свежей сессии. Документация Cline добавляет, что с этим помогают встроенные слэш-команды /newtask и /smol.

Checkpoints решают другую задачу: они возвращают код к прежнему состоянию. Знания о проекте они не хранят.

Шаблон правил вендора

Ниже — дословный текст инструкций со страницы документации Cline (docs.cline.bot/best-practices/memory-bank). Это шаблон вендора.

# Cline's Memory Bank

I am Cline, an expert software engineer with a unique characteristic: my memory resets completely between sessions. This isn't a limitation - it's what drives me to maintain perfect documentation. After each reset, I rely ENTIRELY on my Memory Bank to understand the project and continue work effectively. I MUST read ALL memory bank files at the start of EVERY task - this is not optional.

## Memory Bank Structure

The Memory Bank consists of core files and optional context files, all in Markdown format. Files build upon each other in a clear hierarchy:

### Core Files (Required)
1. `projectbrief.md`
   - Foundation document that shapes all other files
   - Created at project start if it doesn't exist
   - Defines core requirements and goals
   - Source of truth for project scope

2. `productContext.md`
   - Why this project exists
   - Problems it solves
   - How it should work
   - User experience goals

3. `activeContext.md`
   - Current work focus
   - Recent changes
   - Next steps
   - Active decisions and considerations
   - Important patterns and preferences
   - Learnings and project insights

4. `systemPatterns.md`
   - System architecture
   - Key technical decisions
   - Design patterns in use
   - Component relationships
   - Critical implementation paths

5. `techContext.md`
   - Technologies used
   - Development setup
   - Technical constraints
   - Dependencies
   - Tool usage patterns

6. `progress.md`
   - What works
   - What's left to build
   - Current status
   - Known issues
   - Evolution of project decisions

### Additional Context

Create additional files/folders within memory-bank/ when they help organize:
- Complex feature documentation
- Integration specifications
- API documentation
- Testing strategies
- Deployment procedures

## Documentation Updates

Memory Bank updates occur when:
1. Discovering new project patterns
2. After implementing significant changes
3. When user requests with **update memory bank** (MUST review ALL files)
4. When context needs clarification

REMEMBER: After every memory reset, I begin completely fresh. The Memory Bank is my only link to previous work. It must be maintained with precision and clarity, as my effectiveness depends entirely on its accuracy.

Комментарий к шаблону: в тексте прямо сказано, что память модели сбрасывается между сессиями и что чтение всех файлов в начале каждой задачи обязательно. Это и есть механизм, который заставляет агента обращаться к документации.

Чек-лист: память подхватывается в новой сессии

Проверка занимает несколько минут и не требует специальных инструментов.

1. Убедитесь, что папка memory-bank/ лежит в корне проекта и содержит заполненные файлы.
2. Убедитесь, что файл правил присутствует в проекте и включён в панели правил.
3. Начните новый разговор.
4. Напишите «follow your custom instructions».
5. Попросите пересказать текущий фокус и следующие шаги.
6. Сверьте ответ с содержимым activeContext.md.
7. Попросите назвать стек и ограничения, сверьте с techContext.md.
8. Внесите тестовое изменение в activeContext.md и повторите шаги с третьего по пятый.

Если на шаге 5 агент отвечает общими словами о проекте, не опираясь на ваши записи, память не подхватилась. Если ответы совпадают с файлами, механизм работает.

Полезно провести такую проверку после каждой крупной правки структуры: она показывает, какие файлы агент читает, а какие игнорирует.

Диагностика: правило не срабатывает

Документация Cline по правилам даёт набор мест, где чаще всего теряется инструкция.

Когда существуют и рабочие, и глобальные правила, Cline объединяет их, а при конфликте приоритет получают правила рабочего пространства. Глобальное правило работает вместе с проектным файлом Memory Bank и добавляет к нему свои инструкции, поэтому при необъяснимом поведении отключите глобальные правила тумблером в панели правил и повторите проверку. По умолчанию глобальные правила лежат в ~/Documents/Cline/Rules на macOS и Linux/WSL и в Documents\Cline\Rules на Windows; Cline также просматривает ~/.cline/rules и ~/Cline/Rules.

Условные правила используют YAML frontmatter с ключом paths — массивом glob-шаблонов. Правило активируется, когда совпадает любой шаблон с любым файлом в контексте. В контекст попадают пути из вашего сообщения, открытые вкладки, видимые файлы, файлы, которые Cline правил, и файлы, которые он собирается править. Отсюда практический совет из документации: указывайте пути явно — «обнови src/services/user.ts» надёжно срабатывает, а «обнови сервис пользователя» может не сработать.

Глобальные инструкции или файл правил проекта

Документация Cline отвечает на этот вопрос прямо: подходит любой вариант. Пользовательские инструкции действуют глобально во всех проектах. Файл правил Cline привязан к проекту и хранится в репозитории, поэтому его легко передать коллегам.

Практический выбор выглядит так. Личные предпочтения — стиль коммитов, привычные сокращения, общие требования к тестам — удобно держать глобально. Всё, что описывает конкретный проект, живёт в файле правил рядом с кодом.

Документация Cline добавляет третий вариант: условные правила позволяют включать инструкции Memory Bank только при работе с файлами memory-bank/. Тогда текст инструкций не занимает контекст во время обычных правок кода.

Полезно помнить, что правила расходуют токены контекста. Документация Cline советует держать их краткими, разбивать по темам — отдельный файл для стиля, отдельный для тестов, отдельный для архитектуры — и ссылаться на внешнюю документацию вместо копирования целых руководств.

Частые вопросы

Memory Bank — это встроенная функция Cline?

Нет. Это методология документации из markdown-файлов и набора инструкций. В документации Cline она описана как методология, а в блоге проекта — как набор пользовательских инструкций, созданный сообществом. Работает она за счёт того, что файлы лежат в проекте, а правила требуют их читать.

Куда положить файл правил Memory Bank?

В корень проекта, в каталог .clinerules/ или .cline/rules/. Обе схемы поддерживаются в VS Code, Desktop и CLI, и обе папки просматриваются, если присутствуют. Имя файла выбирается свободно, например memory-bank.md.

Почему Cline не читает memory-bank в новой сессии?

Проверьте три вещи: включён ли тумблер правила в панели правил, лежит ли файл правил в .clinerules/ или .cline/rules/ в корне проекта, нет ли противоречащей инструкции в глобальном правиле. При конфликте приоритет у правил рабочего пространства. Начните сессию фразой «follow your custom instructions».

Как часто обновлять файлы памяти?

После значимых вех или смены направления, а при активной разработке — каждые несколько сессий. Файл activeContext.md обновляйте после каждой сессии. Рутинное управление контекстом можно оставить автоматическому сжатию.

Чем Memory Bank отличается от README?

Документация Cline поясняет: Memory Bank даёт структурированную документацию, рассчитанную на управление контекстом ИИ, и выходит за рамки одного README. В него входят файлы активного контекста и отслеживания прогресса, которые меняются часто.