Context Engineering

Context Engineering — дисциплина проектирования и управления контекстом, который передаётся AI-модели для получения точных и воспроизводимых результатов. В отличие от разовых промптов, Context Engineering — системная практика: стандарты, шаблоны и процессы, обеспечивающие стабильное качество AI-вывода.

Термин возник как реакция на «Prompt Engineering» — практику создания эффективных промптов. Context Engineering расширяет её: важен не только текст промпта, но и весь контекст — примеры, структура запроса, прикладываемые данные, порядок информации.

---

Почему контекст важнее промпта

Модель видит только то, что передано в её контекстное окно. Промпт — часть контекста, но не единственная. Что ещё входит в контекст:

• System prompt (роль, инструкции, ограничения)

• Примеры ввода-вывода (few-shot examples)

• Прикладываемые документы, код, данные

• История диалога

• Структура и порядок информации

• Метаданные (дата, версия, окружение)

Пример: один и тот же вопрос «Найди баги в этом коде» даёт разный результат в зависимости от того, передан ли контекст команды (стайлгайд, архитектура, типичные ошибки проекта) или нет.

---

Компоненты контекста

System Prompt

Задаёт роль, поведение и ограничения модели. Для QA-задач:

Ты — старший QA-инженер с 10-летним опытом тестирования веб-приложений.
Когда тебе передают код или требования, ты:
1. Ищешь потенциальные дефекты
2. Предлагаешь тест-кейсы в формате Given/When/Then
3. Явно указываешь граничные условия
4. Отвечаешь по-русски, используя технические термины на английском

Few-Shot примеры

Примеры ввода и желаемого вывода — самый мощный инструмент управления поведением модели:

Пример 1:
Вход: функция деления двух чисел
Выход:
- Позитивный: 10 / 2 = 5
- Негативный: деление на ноль → исключение
- Граничные: очень большие числа, отрицательные числа

Пример 2:
Вход: форма регистрации с полями email и пароль
Выход: [детальные тест-кейсы]

Retrieval-Augmented Context (RAC)

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

• Документация на функцию, которую тестируем

• История дефектов в этом компоненте

• Требования к тестируемому модулю

• Стайлгайд команды

Структура и порядок

Порядок информации в контексте влияет на качество ответа. Принцип: самое важное — в начале и в конце (эффект primacy и recency). Чёткая структура (заголовки, списки) помогает модели выделить ключевые части.

---

Context Engineering в QA-практике

Шаблоны контекста для типовых задач

Генерация тест-кейсов по требованию

## Задача
Сгенерируй тест-кейсы для следующего требования.

## Стандарт формата
Каждый тест-кейс:
- ID: TC-[номер]
- Название: [краткое описание]
- Предусловия: [состояние системы]
- Шаги: [нумерованный список]
- Ожидаемый результат: [конкретный, проверяемый результат]
- Тип: [позитивный / негативный / граничный]

## Требование
[ВСТАВИТЬ ТРЕБОВАНИЕ]

## Контекст системы
[ВСТАВИТЬ: технологический стек, ограничения, смежные функции]

Анализ кода на дефекты

## Роль
Ты проводишь security и quality ревью кода.

## Что искать
1. OWASP Top 10 уязвимости
2. Необработанные исключения
3. Граничные условия без валидации
4. Race conditions
5. Memory leaks

## Код для анализа
[ВСТАВИТЬ КОД]

## Контекст
Язык: [Python/Java/JS]
Фреймворк: [название и версия]
Этот код: [что делает, с чем взаимодействует]

Анализ баг-репорта

## Задача
Проанализируй баг-репорт и предложи:
1. Возможные корневые причины
2. Дополнительные шаги для воспроизведения
3. Смежные области для регрессионного тестирования

## Баг-репорт
[ВСТАВИТЬ БАГИ]

## Контекст
Версия: [X.X.X]
Окружение: [staging/production]
Последние изменения: [если известно]

---

Принципы качественного контекста

1. Минимальная достаточность

Передавайте только релевантную информацию. Избыточный контекст «разбавляет» фокус модели и может привести к игнорированию ключевых деталей.

Плохо: передать весь файл кода, когда нужен анализ одной функции Хорошо: передать функцию + её зависимости + интерфейс

2. Конкретность над общностью

❌ «Найди проблемы в коде»
✅ «Найди уязвимости SQL-инъекций и необработанные null-pointer ошибки в этом коде»

3. Явные ограничения

Указывайте, что модель НЕ должна делать:

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

4. Версионирование контекста

Шаблоны контекста — артефакты команды. Они должны:

• Храниться в репозитории

• Версионироваться вместе с кодом

• Проходить ревью при изменении

• Иметь changelog

Шаблон контекста для генерации тест-кейсов — такой же командный стандарт, как шаблон баг-репорта или тест-кейса. Вложите время в его создание один раз и используйте постоянно.

---

Context Window Management

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

Стратегии

Стратегия	Описание	Когда применять
Chunking	Разбивка на части, обработка по очереди	Анализ большого файла
Summarization	Сжатие истории диалога	Длинные сессии
Selective inclusion	Добавление только релевантных файлов	Анализ конкретной фичи
RAG (Retrieval-Augmented Generation)	Динамический поиск релевантных фрагментов	Большие кодовые базы

Приоритеты при нехватке контекста

1. Задача и инструкции (критично)

2. Прямой объект анализа (код, требование)

3. Примеры ожидаемого формата

4. Дополнительный контекст (история, зависимости)

---

Context Engineering vs Prompt Engineering

Аспект	Prompt Engineering	Context Engineering
Фокус	Формулировка запроса	Весь контекст модели
Масштаб	Разовый промпт	Системная практика
Артефакты	Текст промпта	Шаблоны, библиотеки, стандарты
Версионирование	Редко	Обязательно
Тестирование	Интуитивно	Структурировано
Воспроизводимость	Непоследовательная	Высокая

---

Тестирование контекста

Контекстные шаблоны нуждаются в тестировании так же, как код:

Что тестировать

• Стабильность: один и тот же контекст → стабильный формат вывода

• Полнота: все необходимые элементы присутствуют в выводе

• Соответствие формату: вывод соответствует ожидаемой структуре

• Граничные случаи: что происходит при пустых или минимальных входных данных

• Регрессия: обновление модели не ухудшило качество вывода

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

Метрика	Описание
Точность	% выводов, соответствующих ожиданиям
Полнота	% требуемых элементов, присутствующих в выводе
Форматное соответствие	% выводов в правильном формате
Стабильность	Вариация качества между запусками

---

Применение в QA-команде

Создание библиотеки контекстов

qa-prompts/
├── test-design/
│   ├── generate-test-cases.md
│   ├── boundary-analysis.md
│   └── risk-analysis.md
├── defect-analysis/
│   ├── root-cause-analysis.md
│   └── regression-scope.md
├── documentation/
│   ├── bug-report-review.md
│   └── test-plan-review.md
└── CHANGELOG.md

Процесс обновления

1. QA-инженер обнаруживает, что шаблон даёт неточный результат

2. Создаёт issue с примером плохого вывода

3. Предлагает улучшение шаблона

4. Команда проводит ревью

5. Обновлённый шаблон тестируется на наборе эталонных случаев

6. Публикуется с changelog

---

Источники

• Anthropic — Prompt Engineering Guide — официальное руководство по работе с контекстом

• Simon Willison — Prompt Injection and Context Attacks — риски управления контекстом

• LangChain — RAG Documentation — реализация Retrieval-Augmented Generation