Промптинг больше не равен красивому тексту
Слово "prompt" всё ещё вызывает в голове картинку удачно подобранной фразы, после которой модель начинает отвечать правильно. В 2026 году это представление скорее мешает. Рабочий prompt - это часть исполняемого контракта между вашим кодом и моделью, и его поведение определяют далеко не только слова инструкции.
На результат влияет всё сразу: какая выбрана модель, как расставлены по приоритету системные и пользовательские сообщения, что попало в контекст, какой схемой описан ответ, какие доступны tools, какое у сессии состояние, какие стоят лимиты и какой код окружает вызов. Поменяйте любую из этих деталей - и "тот же" prompt поведёт себя иначе. Поэтому красивый текст сам по себе больше ничего не гарантирует: он лишь одна из переменных контракта.
Удобно держать в голове форму, к которой сводится почти любой prompt - от классификатора до агента.
- Цель
- Контекст
- Модель
- Tools
- Проверка
Каждая стадия отвечает за свой вопрос. Цель - что вообще нужно сделать: роль в продукте, границы, порядок принятия решений и условия, при которых модель обязана отказаться. Контекст - из чего решать: запрос пользователя, найденные документы, история, состояние, результаты tools и примеры. Модель превращает цель и контекст в ответ, tools дают ей руки, а проверка решает, можно ли этому ответу верить и что с ним делать дальше. Пропустите любую стадию - и дыру придётся затыкать в другом месте, обычно дороже.
Если свернуть это в три части, которыми вы реально управляете, получится вот что.
- Instruction - что сделать. Цель, роль в продукте, границы, порядок принятия решений и условия отказа. Это единственная часть, которую многие и называют "промптом", хотя она только треть картины.
- Context - из чего решать. Запрос пользователя, найденные документы, история, состояние, результаты tools и примеры. Модель не знает ничего, чего нет в контексте, - поэтому качество ответа упирается в качество того, что вы в него положили.
- Runtime - что реально разрешено. Схемы, permissions, таймауты, max steps, подтверждения, валидация и наблюдаемость. Это не текст, а код и инфраструктура вокруг модели, и именно они держат обещания, которые слова дать не могут.
Отсюда главная формула книги, к которой мы будем возвращаться в каждой главе.
Главная формула. Prompt задаёт вероятностное поведение. Код и инфраструктура задают обязательные границы. Нельзя заменить permission check фразой "не раскрывай чужие данные".
Разница принципиальная. Инструкция словами - это просьба, которую модель выполнит с некоторой вероятностью. Проверка прав в коде - это гарантия, которая срабатывает всегда. Как только цена ошибки выходит за пределы неудобства, обязательные границы переезжают из текста в код, а prompt перестаёт быть единственной линией обороны.
Наконец, полезно с самого начала различать три уровня систем - дальше вся книга по сути про выбор между ними.
- Один вызов. Владелец - одна модель. Типичный результат: классификация, извлечение, ответ по найденному контексту. Самый дешёвый и предсказуемый уровень, с него стоит начинать всегда.
- Workflow. Владелец - код. Фиксированная цепочка с route, parallel и loop, где условия ветвления описаны явно. Порядок надёжно выражает код, а не уговоры модели.
- Agent. Владелец - модель внутри harness. Динамический выбор шагов и tools в установленных пределах. Максимум гибкости и максимум риска, оправдан только когда путь решения заранее неизвестен.
Эти три уровня - не лестница, по которой обязательно подниматься. Чаще правильный ход обратный: взять самый простой уровень, который проходит проверку, и усложнять только под давлением реальных требований. С этого правила начинается инженерный промптинг, и к нему мы вернёмся в главе про выбор простейшей системы.
Нужно гарантировать, что пользователь не увидит чужие данные. Чем это обеспечить?