TL;DR
Context Engineering — это методология, которая переключает фокус с текста промпта на полноту контекста вокруг него. Вместо одного запроса вы собираете «пакет контекста» из пяти типов информации с фиксированным приоритетом: что является авторитетным документом, что — примером, что — ограничением, что — критерием оценки, что — просто фоновой информацией. Каждый тип имеет свой ранг, и при конфликте побеждает более высокий.
Главный инсайт: большинство повторных итераций с AI происходит не из-за плохого промпта, а из-за неполного контекста. Вы пишете «сделай коммерческое предложение» — получаете болванку. Пишете ещё раз с уточнением — получаете чуть лучше. На третий раз наконец добавляете реальные данные, требования клиента и свои стандарты — и получаете нормальный результат. Три итерации просто потому, что нужная информация не попала в первый запрос. При этом ваш промпт всегда является наименее приоритетным элементом — он запускает взаимодействие, но не управляет результатом.
Метод решает это через две вещи: пять ролей для классификации всего, что вы передаёте AI, и четырёхэтапный конвейер (Ревьюер → Дизайн → Строитель → Аудитор) для сложных задач, где один запрос — заведомо недостаточен.
Схема метода
ПАКЕТ КОНТЕКСТА (для каждого запроса):
Роль 1 — Авторитет (Authority): что управляет результатом → ТЗ, план, требования
Роль 2 — Пример (Exemplar): как должно выглядеть → образец, предыдущий отчёт
Роль 3 — Ограничение (Constraint): что нельзя / что критично → лимит слов, запреты
Роль 4 — Рубрика (Rubric): как оценивать → чеклист, критерии приёмки
Роль 5 — Метаданные (Metadata): контекст запроса → ваш промпт, дедлайн, имена
ПРИОРИТЕТ при конфликте: Авторитет > Пример > Ограничение > Рубрика > Метаданные
КОНВЕЙЕР (для сложных / многосессионных задач):
ЭТАП 1 — Ревьюер: что есть, что нужно, где пробелы → структурированная оценка
ЭТАП 2 — Дизайн: что и как строить → план / архитектура / структура (= Авторитет)
ЭТАП 3 — Строитель: создаём по плану → готовый результат
ЭТАП 4 — Аудитор: проверяем соответствие плану → список правок + куда вернуть
Каждый этап — отдельный запрос (или сессия для больших проектов).
Для простых задач: достаточно Строитель или Строитель + Аудитор.
Пример применения
Задача: Николай — B2B-продажник SaaS-компании. Ему нужно написать коммерческое предложение под конкретного клиента — крупную дистрибьюторскую сеть. Раньше он давал ChatGPT задание «напиши КП», получал шаблон-болванку, переписывал три раза. Теперь он собирает пакет контекста.
Промпт:
Ты — Строитель. Твоя задача — создать коммерческое предложение строго по плану ниже.
Ты не интерпретируешь требования и не принимаешь архитектурных решений —
они уже приняты. Твоя задача — исполнение.
=== АВТОРИТЕТ (приоритет 1 — управляет всем) ===
ПЛАН КП:
1. Заголовок: конкретная боль клиента, не название продукта
2. Текущая ситуация клиента: 2 абзаца, факты
3. Что мы предлагаем: без пассивного залога, без "решений"
4. Три конкретных результата с цифрами
5. Кейс похожего клиента: объём, срок, ROI
6. Следующий шаг: одно действие, не "свяжитесь с нами"
Требования: без слов "синергия", "экосистема", "инновационный".
Объём — не более 600 слов.
=== ПРИМЕР (приоритет 2) ===
Образец тона: [вставить абзац из лучшего вашего КП или КП конкурента, который нравится]
=== ОГРАНИЧЕНИЯ (приоритет 3) ===
- Нельзя упоминать конкурентов по имени
- Нельзя обещать сроки без согласования с менеджером
- Клиент — дистрибьютор, не конечный потребитель
=== РУБРИКА (приоритет 4 — как оценивать результат) ===
Хорошее КП: клиент с первого абзаца понимает, про что это и зачем ему читать дальше.
Плохое КП: начинается с "наша компания основана в..."
=== МЕТАДАННЫЕ (приоритет 5 — мой контекст) ===
Клиент: ООО "Торговый Дом Восток", дистрибьютор бытовой техники, 47 региональных складов
Наш продукт: система управления складскими остатками, интеграция с 1С
Боль клиента (по итогам звонка): расхождение данных между складами и 1С — до 12%
Контактное лицо: Антон Серов, коммерческий директор
Дедлайн отправки: пятница
Результат: Модель создаст КП, которое строго следует шестипунктовому плану — он как Авторитет перебивает любые попытки модели "творчески интерпретировать" структуру. Запрещённые слова и ограничения соблюдены. Тон выровнен по примеру. Если модель отклоняется (добавляет раздел, которого нет в плане, или пишет "наша компания") — это не интерпретация, это ошибка. Затем тот же пакет отправляете в Аудитор: «Сверь КП с планом. Найди каждое отклонение».
Почему это работает
Слабость LLM: модель не знает, что из переданного вами — главное. Если вы написали «сделай покороче» в конце промпта, а в начале прикрепили ТЗ на 15 страниц с требованием детального раздела — модель вполне может выбрать «покороче». Она следует последнему или самому явному сигналу, а не самому авторитетному.
Что модель умеет хорошо: следовать явным, структурированным инструкциям. Если вы прямо объяснили, что является управляющим документом, — она будет ему следовать. Конфликт «ТЗ vs промпт» исчезает, как только вы явно объявляете приоритет.
Как метод использует это: роли и приоритеты убирают неоднозначность. Модель не угадывает — вы прямо говорите «это Авторитет, он обгоняет всё остальное». Четырёхэтапный конвейер убирает другую проблему: попытку решить одним запросом задачу, которая требует сначала понять требования, потом спроектировать, потом сделать, потом проверить.
Рычаги управления: - Объём пакета → для простых задач достаточно Авторитет + Метаданные. Рубрику и Пример добавляйте для задач с высокими требованиями к качеству - Этапы конвейера → для письма или короткого документа — только Строитель. Для отчёта, предложения, статьи — полный цикл с Ревьюером и Аудитором - Operator Authority (подробнее ниже) → одноразово формализуйте свои стандарты и включайте в каждый чат
Шаблон промпта
Универсальный пакет контекста
Ты — {роль: Ревьюер / Дизайнер / Строитель / Аудитор}.
{Описание задачи для этого этапа одним предложением}.
=== АВТОРИТЕТ (приоритет 1) ===
{ТЗ / требования / план / дизайн-документ — то, что управляет результатом}
=== ПРИМЕР (приоритет 2) ===
{Образец формата, тона, структуры — прошлый хороший вариант или эталон}
=== ОГРАНИЧЕНИЯ (приоритет 3) ===
{Чего нельзя. Технические требования. Жёсткие условия.}
=== РУБРИКА (приоритет 4) ===
{Как выглядит хороший результат. Чеклист. Критерий приёмки.}
=== МЕТАДАННЫЕ (приоритет 5) ===
{Контекст задачи: имена, даты, фон, мой запрос}
Что подставлять:
- {роль} — Строитель подходит для большинства задач; Аудитор — когда нужна проверка готового текста
- АВТОРИТЕТ — сюда идут ТЗ клиента, ваш план, согласованная структура. Если конкурирует с промптом — побеждает
- ПРИМЕР — один абзац хорошего текста в нужном тоне работает лучше длинных объяснений
- РУБРИКА — формулируйте от противного: «плохой вариант выглядит так: ...»
- МЕТАДАННЫЕ — сюда уходит ваш обычный промпт
Operator Authority: постоянный документ ваших стандартов
Отдельный мощный инструмент из этой же методологии. Создаёте один раз — используете в каждом чате.
=== МОИ СТАНДАРТЫ (Operator Authority v{номер версии}) ===
Стиль письма:
- {запрещённые слова и обороты: "синергия", "инновационный", пассивный залог и т.д.}
- {требования к тону: деловой / живой / без корпоративщины}
Формат:
- {предпочтения по структуре, заголовкам, длине}
Приоритеты:
- Точность > скорость
- Конкретика > обобщения
- {ваши специфичные правила}
Этот документ — Авторитет. Он перекрывает любые противоречащие ему инструкции в запросе.
Создаёте такой файл, сохраняете, вставляете в начало каждого нового чата. Модель прекращает угадывать ваши стандарты по паттернам исправлений.
🚀 Быстрый старт — вставь в чат:
Вот шаблон Context Engineering с пятью ролями контекста.
Адаптируй под мою задачу: {твоя задача}.
Задавай вопросы, чтобы заполнить каждую секцию.
[вставить шаблон выше]
LLM спросит про Авторитет (что является управляющим документом), пример нужного формата, ограничения и критерии оценки — потому что без них пакет контекста будет неполным и итерации неизбежны.
Почему это работает (механика)
LLM обрабатывает весь контекст одновременно. Когда в тексте присутствуют конкурирующие инструкции, модель не знает, какая важнее — она делает статистическую ставку. Чаще всего выбирает последнее по тексту или наиболее явное. Явное объявление приоритетов убирает эту неопределённость: вы буквально говорите «секция АВТОРИТЕТ перекрывает всё». Это не магия — это структурированная инструкция, которой модель следует, потому что она однозначна.
Четырёхэтапный конвейер работает по принципу разделения ответственности. Смешивать в одном запросе «разберись в требованиях + придумай структуру + напиши + проверь» — это как давать одному человеку одновременно роль аналитика, архитектора, исполнителя и тестировщика. Каждая роль требует разного фокуса и разных критериев качества. Разделяешь — получаешь качественнее на каждом шаге.
Ограничения
⚠️ Оверхед для простых задач: Полный пакет из пяти ролей и четырёх этапов оправдан для сложных или повторяющихся задач. Для вопроса «переведи этот абзац» — избыточно. Автор честно говорит: если задача умещается в один диалог и ошибка не требует структурного переосмысления — достаточно Строителя без всего конвейера.
⚠️ Одиночный источник данных: Исследование основано на 200 взаимодействиях одного оператора без контрольной группы. Это наблюдение, не контролируемый эксперимент. Автор честно это называет. Результаты убедительны логически — но не доказаны статистически на независимых выборках.
⚠️ Качество Авторитета = качество результата: Метод сдвигает ответственность с промпта на документы-Авторитеты. Плохо написанное ТЗ, переданное как Авторитет, даст плохой результат — и теперь уже с высоким приоритетом. Мусор на входе с пометкой «это управляет всем» — мусор с усиленным влиянием на выходе.
⚠️ Метаданные-парадокс требует перестройки мышления: Осознать, что ваш текстовый промпт — наименее приоритетный элемент, поначалу неочевидно. Пользователи по привычке всё важное лепят в промпт, а не в Авторитет.
Как исследовали
Автор собрал 200 задокументированных взаимодействий с четырьмя AI-инструментами (Claude, ChatGPT, Cowork, Codex) за четыре месяца в реальной профессиональной работе — документы, код, исследования. Никаких специально созданных тестовых наборов: живые задачи из практики.
Сравнение простое: неструктурированные взаимодействия (baseline, 50 случаев) против структурированных с полным пакетом контекста (200 случаев). Измерялось количество итераций до приемлемого результата и процент задач, принятых с первого раза. Результат: среднее число итераций сократилось с 3,8 до 2,0, принятие с первой попытки выросло с 32% до 55%. При разрешённых итерациях финальный успех — 91,5%.
Интересная деталь: 72% итераций в неструктурированных взаимодействиях были вызваны неполным контекстом — не плохим промптом, а просто отсутствием нужной информации. Это и есть главный вывод: большинство повторных запросов — это запросы на то, что вы могли дать сразу. Исследователь также параллельно проверил методологию на производственной системе с 2 132 тикетами — результаты согласуются.
Главное ограничение, которое автор сам называет: это один оператор, один датасет, нет контрольной группы. Это честная observational study, не RCT.
Оригинал из исследования
Таблица ролей контекстного пакета (оригинал):
Role | Priority | Definition | Example
-----------|----------|-------------------------------------------------|---------------------------
Authority | 1 | Grants permission, establishes boundaries, | Requirements document,
| | defines success criteria | design constraint, approval
| | | signature
Exemplar | 2 | Provides patterns or examples for the desired | Previous report, template,
| | output format | successful artifact
Constraint | 3 | Specifies limits, forbidden paths, technical | Word limit, format
| | requirements | specification, API version
Rubric | 4 | Defines evaluation criteria and quality | Definition of done,
| | standards | assessment checklist,
| | | quality gate
Metadata | 5 | Contextual information about the request | Project name, stakeholder
| | and requestor | name, deadline
Контекст: Автор демонстрирует применение системы приоритетов при конфликте элементов — например, когда промпт (приоритет 5) говорит «сделай на 5 страниц», а требования клиента (приоритет 1) указывают 15 страниц с 8 разделами. Авторитет побеждает.
Адаптации и экстраполяции
1. Адаптация: Operator Authority как «файл о себе» для каждого нового чата
Самая мощная практическая идея из статьи — и она не требует полного конвейера.
💡 Для любого регулярного использования ChatGPT/Claude: одноразово создай документ со своими стандартами и вставляй его в начало каждого нового чата. Это устраняет итерации типа «нет, не так» — потому что «как надо» теперь есть до первого ответа.
=== МОЙ РАБОЧИЙ СТАНДАРТ ===
Это — Авторитет. Он перекрывает любые мои дальнейшие инструкции,
которые ему противоречат.
Стиль текстов:
- Без слов: "синергия", "экосистема", "инновационный", "нарратив"
- Без пассивного залога где можно обойтись без него
- Короткие предложения. Один абзац — одна мысль.
- Обращение к читателю — "вы" (строчная), не "Вы"
Формат по умолчанию:
- Заголовки — конкретные, не абстрактные ("Как сократить цикл продаж", не "О продажах")
- Списки только когда пунктов 3+
- Длина ответа — не более {лимит} слов если не прошу подробно
Подход:
- Конкретика > обобщения. Если пишешь "большой эффект" — дай пример.
- Не начинай ответы с комплиментов и вводных фраз
Контекст обо мне:
- {Профессия / роль}
- {Аудитория, для которой я обычно пишу}
- {Специфика моей сферы, которую важно учитывать}
2. Техника: Мгновенный Аудитор без полного конвейера
🔧 Добавь Аудитора в конце любого запроса → получишь самопроверку в одном ответе
[ваш обычный запрос с пакетом контекста]
После того как создашь результат — пройди по нему как Аудитор:
Сверь с АВТОРИТЕТОМ пункт за пунктом.
Найди каждое отклонение.
Исправь или укажи почему отклонение оправдано.
Это работает потому, что модель симулирует смену роли внутри одного запроса. Не так точно, как полноценный отдельный этап — но для большинства задач достаточно.
3. Экстраполяция: Context Engineering + Chain-of-Thought для сложного анализа
Роль Ревьюера из конвейера хорошо комбинируется с Chain-of-Thought (явным пошаговым рассуждением) для задач, где важно не пропустить скрытые требования:
Ты — Ревьюер. Прочитай материал ниже и ответь пошагово:
Шаг 1: Что здесь есть (факты, данные, договорённости)
Шаг 2: Что явно требуется (сформулировано)
Шаг 3: Что неявно требуется (подразумевается, но не сказано)
Шаг 4: Где пробелы (чего не хватает для выполнения задачи)
Шаг 5: Какие конфликты (противоречия в требованиях)
Результат — структурированная оценка для следующего этапа.
=== МАТЕРИАЛ ===
{текст: бриф, переписка, ТЗ, встреча}
Этот Ревьюер-промпт работает самостоятельно для любого брифа или ТЗ — без остального конвейера.
Ресурсы
Context Engineering: A Practitioner Methodology for Structured Human-AI Collaboration Elias Calboreanu — Swift North AI Lab, The Swift Group, LLC, Maryland, USA Контакт: ecalboreanu@theswiftgroup.com | ORCID: 0009-0008-9194-0589
Связанные источники, упомянутые в работе: - Andrej Karpathy о context engineering (июнь 2025) — [twitter/X] - Tobi Lütke (Shopify CEO) о context engineering - Simon Willison — расширение фреймворга - Sahoo et al. — обзор 44 работ по промптингу (39 техник) - Schulhoff et al. — таксономия 58 техник промптинга - Mei et al. — обзор 1400+ работ по контекстным системам с машинной стороны - Anthropic, Google, LangChain — гайды по context engineering