Практическое руководство по инжинирингу контекста для AI-ассистентов

Каждый раз, когда вы начинаете новую сессию чата с AI-ассистентом для программирования (будь то Cursor, Claude Code, Windsurf или Cortex Code), вы по сути начинаете с нуля.

Ассистент не знает, что, например, ваша команда использует Streamlit для создания веб-приложений. Он не знает, что вы предпочитаете иконки Material вместо эмодзи. И он не в курсе того конфликта портов, из-за которого три месяца назад вы перешли с 8501 на 8505.

Поэтому вам приходится повторяться. Сессию за сессией.

Инструменты мощные, но при этом забывчивые. И пока вы не закроете этот разрыв в памяти, именно вы остаетесь человеком в контуре, вручную управляющим состоянием, которое в принципе можно было бы автоматизировать.

Реальность без состояния у LLM

LLM вас не запоминают. Каждая новая беседа — это чистый лист, и так устроено по архитектуре, а не случайно.

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

Теперь посмотрим на технические различия между краткосрочной и долгосрочной памятью:

• Краткосрочная память: то, что AI помнит в рамках одной сессии. Она находится в контекстном окне и включает текущий диалог, открытые файлы и недавние действия. После закрытия чата все это исчезает.

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

Без долгосрочной памяти вы сами становитесь этим слоем памяти: копируете и вставляете контекст, собираете его заново, повторно объясняете соглашения и отвечаете на одни и те же уточняющие вопросы, на которые уже отвечали вчера и позавчера.

Очевидно, что это не масштабируется.

Нарастающая цена повторений

Рассмотрим, как со временем накапливаются издержки из-за отсутствия постоянной памяти. Но сначала посмотрим, как это выглядит на практике:

Без постоянного контекста:

С постоянным контекстом (файл правил):

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

Качество кода, сгенерированного AI, напрямую зависит от качества переданного ему контекста. Без памяти каждая сессия начинается «с нуля». С памятью ассистент опирается на уже накопленные знания. Разница со временем только усиливается.

Инжиниринг контекста как недостающий слой

Это подводит нас к тому, что специалисты называют инжинирингом контекста (context engineering) — систематическим формированием слоя информации, необходимой AI для надежного выполнения задач.

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

Если промпт-инжиниринг сосредоточен на том, чтобы задавать правильные вопросы, то инжиниринг контекста гарантирует, что у AI есть все необходимое для правильного ответа.

Правда в том, что универсального решения здесь нет. Зато есть спектр подходов, которые можно условно разделить на четыре уровня — от простых к сложным, от ручных к автоматическим.

Уровень 1: файлы правил проекта

Самый простой и надежный подход — файл Markdown в корне проекта, который AI-ассистент может читать автоматически.

Это явная память. Вы явно фиксируете важную информацию в Markdown-файле:

Ваш AI-ассистент читает этот файл в начале каждой сессии. Повторять одно и то же больше не требуется.

Преимущество этого подхода — контроль версий. Такие файлы хранятся вместе с кодовой базой. Когда новый участник команды клонирует репозиторий, ассистент сразу понимает, как в проекте принято работать.

Уровень 2: глобальные правила

Файлы правил проекта решают задачу проектных соглашений. Но что делать с личными предпочтениями — теми, которые вы переносите из проекта в проект?

Большинство инструментов для AI-программирования поддерживают глобальную настройку:

– Cursor: Settings → Cursor Settings → Rules → New → User Rule

– Claude Code: ~/.claude/CLAUDE.md и ~/.claude/rules/*.md для модульных глобальных правил

– Windsurf: global_rules.md через Settings

– Cortex Code: на данный момент поддерживает только проектные файлы AGENTS.md, без глобальных правил

Глобальные правила должны быть концептуальными, а не техническими. Они описывают ваш способ мышления и коммуникации, а не выбор конкретного фреймворка. Пример:

Обратите внимание, чего здесь нет: ни Streamlit, ни Python, ни каких-либо конкретных технологий. Эти принципы применимы независимо от задачи — пишете ли вы пайплайн обработки данных, веб-приложение или CLI-инструмент.

Технические соглашения должны находиться в правилах проекта, а стиль коммуникации и подход к разработке — в глобальных правилах.

Замечание о развивающихся стандартах

Вы можете встретить навыки, оформленные в виде файлов SKILL.md. Формат навыков агента (Agent Skills) — это развивающийся открытый стандарт, который постепенно получает поддержку в различных инструментах.

В отличие от правил, навыки можно переносить между проектами и агентами. Они описывают, как выполнять конкретные задачи, а не какие соглашения соблюдать.

Это различие важно: файлы правил (AGENTS.md, CLAUDE.md и др.) задают поведение, тогда как файлы навыков (SKILL.md) описывают процедуры.

Уровень 3: неявные системы памяти

Что, если бы вам вообще не приходилось ничего записывать? Что, если бы система просто наблюдала?

Именно это обещают такие инструменты, как Pieces. Он работает на уровне операционной системы, фиксируя, над чем вы работаете: фрагменты кода, вкладки браузера, активность в файлах и экранный контекст. Затем он связывает все это воедино с учетом временного контекста. И через девять месяцев вы можете спросить: «Что это была за настройка st.navigation(), которую я использовал для многостраничного дашборда?» — и система ее найдет.

Некоторые инструменты размывают границу между явной и неявной памятью. Например, автопамять Claude Code (~/.claude/projects/<project-folder>/memory/) автоматически сохраняет проектные паттерны, выводы из отладки и ваши предпочтения по мере работы. Вы не пишете эти заметки сами — это делает Claude.

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

Model Context Protocol (MCP)

Некоторые инструменты неявной памяти предоставляют свои данные через MCP (Model Context Protocol) — открытый стандарт, который позволяет AI-ассистентам для программирования подключаться к внешним источникам данных и инструментам.

Вместо того чтобы каждый AI-инструмент создавал собственные интеграции, MCP дает общий интерфейс. Когда инструмент памяти отдает контекст через MCP, любой ассистент с поддержкой MCP — Claude Code, Cursor и другие — может получить к нему доступ. Например, ваша сессия в Cursor может подтянуть контекст из активности в браузере за прошлую неделю. Границы между инструментами начинают постепенно стираться.

Уровень 4: собственная инфраструктура памяти

Для команд со специфическими потребностями можно построить собственный слой памяти. Но здесь важно трезво оценивать соотношение сложности и пользы.

Такие сервисы, как Mem0, предоставляют API памяти, специально разработанные для приложений на базе LLM. Они берут на себя самые сложные задачи: извлечение воспоминаний из диалогов, устранение дублей, разрешение противоречий и учет временного контекста.

Если нужен больший контроль, можно использовать векторные базы данных вроде Pinecone или Weaviate. Они хранят эмбеддинги, то есть числовые представления текста, отражающие его семантический смысл, для вашей кодовой базы, документации и прошлых разговоров. Но это уже низкоуровневая инфраструктура. В этом случае вам самим нужно строить пайплайн извлечения: разбивать текст на фрагменты, генерировать эмбеддинги, выполнять поиск по сходству и подставлять релевантный контекст в запросы. Этот подход называется Retrieval-Augmented Generation (RAG).

Большинству разработчиков это не понадобится, но командам, которые создают внутренние инструменты, такой подход может быть полезен. Сохранение организационного знания в формате, с которым AI способен работать через запросы, дает вполне реальное конкурентное преимущество.

Создание собственного слоя памяти

Если вы не знаете, с чего начать, начните с этого:

1. Создайте файл правил (CLAUDE.md, AGENTS.md или .cursor/rules/ — в зависимости от используемого инструмента) в корне проекта

2. Добавьте туда ваш стек, соглашения и часто используемые команды

3. Начните новую сессию и посмотрите на разницу

Вот и все. Цель не в том, чтобы добиться идеальной памяти. Задача — снизить трение настолько, чтобы помощь AI действительно ускоряла рабочий процесс.

Несколько принципов, о которых стоит помнить:

• Начните с уровня 1. Один файл правил проекта уже дает ощутимую пользу. Не усложняйте систему, пока возникающее трение не оправдывает дополнительную сложность.

• Добавляйте уровень 2, когда видите повторяющиеся паттерны. Как только замечаете, что одни и те же предпочтения повторяются в разных проектах, переносите их в глобальные правила.

• Держите глобальные правила на уровне концепций. Стиль коммуникации и требования к качеству кода должны находиться в глобальных правилах. Технические соглашения — в правилах проекта.

• Используйте систему контроля версий для файлов правил. Они должны храниться вместе с кодовой базой. Когда кто-то клонирует репозиторий, AI-ассистент сразу понимает, как устроена работа в проекте.

• Регулярно пересматривайте и очищайте правила. Устаревшие правила чаще создают путаницу, чем приносят пользу. Обновляйте их так же, как обновляете код.

• Давайте AI возможность предлагать изменения. После продуктивной сессии попросите ассистента кратко сформулировать, чему он «научился».

Что касается более продвинутых уровней: неявная память (уровень 3) мощная, но сильно зависит от конкретных инструментов и пока находится в стадии развития. Собственная инфраструктура (уровень 4) дает максимальный контроль, но требует значительных инженерных вложений. Большинству команд это не нужно.

Куда все это движется

Память становится базовой возможностью инструментов для разработки с использованием AI, а не второстепенной функцией.

MCP постепенно получает широкое распространение. Инструменты неявной памяти развиваются. Все крупные AI-ассистенты для программирования добавляют поддержку постоянного контекста. При этом сами LLM, скорее всего, останутся stateless («без состояния»). Это не недостаток, а особенность. Зато инструменты, которые их оборачивают, вовсе не обязаны быть такими же. Чат без состояния — это временный артефакт ранних этапов развития инструментов, а не фундаментальное ограничение.

OpenClaw доводит эту идею до логического предела. Его агенты работают с изменяемыми файлами памяти (SOUL.md, MEMORY.md, USER.md), которые описывают личность, долгосрочные знания и предпочтения пользователя. Агент читает их при запуске и может изменять по мере обучения. Это крайняя форма инжиниринга контекста: память, которая эволюционирует автономно. Насколько это вдохновляет или пугает — зависит от вашей готовности доверять автономии.

Главная задача практиков — не выбрать «идеальную» систему памяти, а понять, что контекст — это ресурс. И, как любой ресурс, им можно управлять осознанно.

Каждый раз, когда вы повторяете одно и то же AI-ассистенту, вы платите своего рода «налог». Каждый раз, когда вы один раз фиксируете соглашение и больше его не объясняете, вы инвестируете в накопительный эффект. Эти выгоды растут со временем, но только если есть инфраструктура, которая их поддерживает.

Постоянная память становится частью AI-инструментов. На момент написания этой статьи (11 апреля 2026) Anthropic уже фактически добавила поддержку функции памяти в Claude.

Если тема LLM уже упирается для вас не в «поиграться», а в рабочие ограничения, приходите на открытые уроки от преподавателей Otus. Уроки бесплатные: можно будет познакомиться с экспертами, задать вопросы и понять, насколько формат обучения подходит под ваши задачи.

• 30 апреля в 20:00. «Поиск в базе знаний: где векторы ошибаются, а графы помогают»
  Разберёте, как работает семантический поиск, почему похожий текст не всегда дает правильный ответ и где помогают графовые подходы. Записаться

• 20 мая в 20:00. «Что надо знать про работу LLM моделей»
  Разберёте архитектуру Transformers, механизм генерации текста и базовый сценарий локального развёртывания LLM. Записаться

А если вам нужно системное и глубокое погружение в тему внедрения ИИ на основе LLM в проект или сервис, обратите внимание на практический курс «LLM-инженер».