Контекст — это новый кэш: 12 промтов, которые возвращают ИИ в русло вашего проекта

Контекст — это новый кэш: 12 промтов, которые возвращают ИИ в русло вашего проекта

Каждый, кто работал с LLM над реальным репозиторием, знает этот момент. Открываешь новый чат, просишь добавить поле в DTO — и получаешь код, который обращается к UserService, хотя у вас давно AccountService. Или модель «вспоминает» версию библиотеки, которой в package.json нет уже полгода. Это не галлюцинация в чистом виде — это потеря контекста.

Проблема фундаментальна. У больших языковых моделей нет памяти между сессиями: контекстное окно — это и есть вся «оперативная память». Anthropic в документации к Claude прямо описывает эффект «lost in the middle»: информация в середине длинного промта усваивается хуже, чем в начале и конце. Поэтому «просто закинуть весь репозиторий» не работает — работает управляемое восстановление контекста.

Ниже — 12 промтов трёх уровней: базовые (для одной сессии), продвинутые (для повторяющихся задач) и экспертные (для команд и больших монорепозиториев). Все проверены на практике, синтаксис и подходы — реальные, без выдуманных стандартов.

Базовый уровень: перезапуск сессии

1. «Карта проекта» перед началом работы

Задача: модель не знает структуру вашего кода.

Промт:

Ты — senior-разработчик, который только что присоединился к проекту.
Ниже — вывод `tree -L 3 -I 'node_modules|.git'` и содержимое 3 ключевых файлов.
Составь карту: (1) точки входа, (2) слои архитектуры,
(3) где лежит бизнес-логика, (4) что выглядит как legacy.
Не предлагай рефакторинг — только опиши, что видишь.

Результат: таблица «слой → директория → назначение», по которой вы дальше ссылаетесь: «работаем в слое domain».

2. Сброс контекста без потери решений

Задача: чат разросся, модель начинает «плыть».

Промт:

Сожми наш диалог в ADR (Architecture Decision Record) по формату:
Контекст → Решение → Альтернативы → Последствия.
Сохрани все принятые имена функций, схемы БД и отвергнутые варианты.
Выведи в Markdown, который я вставлю в новый чат.

Результат: 1–2 экрана вместо 50 сообщений. Классический приём «compaction», который Anthropic рекомендует для длинных агентных сессий.

3. Фиксация версий и ограничений

Задача: модель генерирует код под устаревший API.

Промт:

Зафиксируй стек: Python 3.12, FastAPI 0.111, SQLAlchemy 2.0 (async), Pydantic v2.
Правило: любые импорты и сигнатуры — только из этих версий.
Если сомневаешься в API — скажи «нужна проверка», не выдумывай.

Результат: исчезают pydantic.BaseSettings (переехал в pydantic-settings) и declarative_base из старого стиля.

Продвинутый уровень: контекст как артефакт

4. Контекстный манифест в репозитории

Задача: каждый новый чат начинается с нуля.

Промт:

Сгенерируй файл CONTEXT.md для корня репозитория:
- назначение проекта (2 предложения)
- стек и версии
- 5 ключевых модулей и их зона ответственности
- соглашения: именование, обработка ошибок, тесты
- чего НЕ делать (известные грабли)
Формат — короткие секции, максимум 80 строк.

Результат: файл, который вы вставляете первым сообщением. Ссылайтесь на него как на источник правды.

5. Извлечение контракта из документации

Задача: есть OpenAPI-спека и README, но модель их игнорирует.

Промт:

Ниже — фрагмент openapi.yaml. Извлеки контракт эндпоинта /orders:
метод, path-параметры, тело запроса, коды ответов, схему ошибок.
Верни в виде TypeScript-типов. Ничего не добавляй от себя.

Результат: типы, которые совпадают со спекой, а не с фантазией модели. OpenAPI-спецификация — официальный стандарт (openapis.org).

6. Восстановление после «я переписал всё»

Задача: агент удалил рабочий код.

Промт:

Ты потерял контекст. Вот `git diff HEAD~1` — что изменилось.
Верни предыдущее поведение функции X, сохранив новые тесты.
Объясни построчно, почему каждое изменение было ошибкой.

Результат: откат + обучающий разбор. Работает с любым Git-хостом; синтаксис git diff HEAD~1 универсален.

7. Сжатие логов для контекста

Задача: 3 ГБ логов не влезают ни в одно окно.

Промт:

Вот 200 строк stderr. Сгруппируй по уникальным сигнатурам ошибок,
отсортируй по частоте, для топ-3 укажи стек вызовов и гипотезу причины.
Формат: таблица «сигнатура

| частота | вероятная причина».

Результат: таблица вместо простыни. Пайплайн «grep → cluster → prompt» описан в инженерных блогах многих команд.

Экспертный уровень: контекст для команды

8. RAG по документации без векторной БД

Задача: нужен поиск по внутренним докам.

Промт:

Ты — retrieval-слой. Я задаю вопрос, ты отвечаешь ТОЛЬКО цитатами
из приложенных документов с указанием файла и строки.
Если ответа нет — пиши «не найдено». Не додумывай.

Результат: цитатное цитирование вместо пересказа. Такой «grounded» режим снижает галлюцинации; сам приём описан в документации по grounding у крупных провайдеров.

9. Синхронизация нескольких агентов

Задача: два агента правят один монорепозиторий.

Промт:

Ты — агент B. Вот журнал изменений агента A за последний час.
Перед любым изменением проверь: не конфликтует ли оно с A.
Выведи список пересечений файлов и предложи порядок мержа.

Результат: список конфликтов до записи на диск. Идея — из практик координации multi-agent систем (см. работы по LLM-агентам, например, обзоры arXiv по multi-agent orchestration).

10. Контекст для ревьюера

Задача: ревьюер не понимает, зачем PR.

Промт:

По diff и названию ветки сгенерируй PR-описание:
проблема → подход → что НЕ вошло → как тестировать.
Ссылайся на строки diff в формате file:line.

Результат: описание, которое экономит 10 минут ревьюеру. Формат соответствует рекомендациям Google Engineering Practices по code review.

11. Восстановление контекста из тикетов

Задача: проект живёт 3 года, история — в Jira.

Промт:

Вот 30 закрытых тикетов по модулю billing.
Выдели паттерны: какие баги повторяются, какие решения отвергались.
Сформируй «инженерную память» модуля в 20 строк.

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

12. Метрика качества контекста

Задача: понять, помогает ли промт.

Промт:

Оцени, сколько информации из моего контекста ты реально используешь:
перечисли, какие факты повлияли на ответ, какие проигнорированы.
Дай оценку полноты 0–100 и список пробелов.

Результат: обратная связь по самому промту. Приём self-critique описан в исследовании «Self-Refine» (arXiv:2303.17651).

Сводная таблица

Выводы

Восстановление контекста — не про «более умную модель», а про дисциплину: превращать неявное знание проекта в явные артефакты (CONTEXT.md, ADR, контракты, сжатые логи). Начните с трёх базовых промтов — карта проекта, сброс контекста и фиксация версий. Через неделю вы заметите, что агент перестал «забывать» архитектуру.

Дальше — автоматизируйте: держите CONTEXT.md в репозитории, обновляйте ADR, просите self-critique. Контекст — это новый кэш: его нужно инвалидировать и прогревать сознательно. Попробуйте первый промт на своём проекте прямо сегодня и посмотрите, сколько «галлюцинаций» окажется обычной потерей контекста.