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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

На английском языке

# Stack – Python 3.12+ with Streamlit – Snowflake for data warehouse – Pandas for data wrangling – Built-in Streamlit charts or Altair for visualization # Conventions – Use Material icons (:material/icon_name:) instead of emojis – Wide layout by default with sidebar for controls – @st.cache_data for data, @st.cache_resource for connections – st.spinner() for long operations, st.error() for user-facing errors # Commands – Run: streamlit run app.py [7] –server.port 8505 – Test: pytest tests/ -v – Lint: ruff check .

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

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

Уровень 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 ^[5], без глобальных правил

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

На английском языке

# Response Style – Brief responses with one-liner explanations – Casual, friendly tone – Present 2-3 options when requirements are unclear # Code Output – Complete, runnable code with all imports – Always include file paths – No inline comments unless essential # Coding Philosophy – Readability over brevity – Simple first, optimize later – Convention over innovation

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

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

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

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

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

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

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

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

Именно это обещают такие инструменты, как Pieces ^[14]. Он работает на уровне операционной системы, фиксируя, над чем вы работаете: фрагменты кода, вкладки браузера, активность в файлах и экранный контекст. Затем он связывает все это воедино с учетом временного контекста. И через девять месяцев вы можете спросить: «Что это была за настройка 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: собственная инфраструктура памяти

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

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

Если нужен больший контроль, можно использовать векторные базы данных вроде Pinecone ^[17] или 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 ^[18] доводит эту идею до логического предела. Его агенты работают с изменяемыми файлами памяти (SOUL.md, MEMORY.md, USER.md), которые описывают личность, долгосрочные знания и предпочтения пользователя. Агент читает их при запуске и может изменять по мере обучения ^[19]. Это крайняя форма инжиниринга контекста: память, которая эволюционирует автономно. Насколько это вдохновляет или пугает — зависит от вашей готовности доверять автономии.

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

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

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

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

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

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

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