Глава 1

Промптинг больше не равен красивому тексту

Слово "prompt" всё ещё вызывает в голове картинку удачно подобранной фразы, после которой модель начинает отвечать правильно. В 2026 году это представление скорее мешает. Рабочий prompt - это часть исполняемого контракта между вашим кодом и моделью, и его поведение определяют далеко не только слова инструкции.

На результат влияет всё сразу: какая выбрана модель, как расставлены по приоритету системные и пользовательские сообщения, что попало в контекст, какой схемой описан ответ, какие доступны tools, какое у сессии состояние, какие стоят лимиты и какой код окружает вызов. Поменяйте любую из этих деталей - и "тот же" prompt поведёт себя иначе. Поэтому красивый текст сам по себе больше ничего не гарантирует: он лишь одна из переменных контракта.

Удобно держать в голове форму, к которой сводится почти любой prompt - от классификатора до агента.

  1. Цель
  2. Контекст
  3. Модель
  4. Tools
  5. Проверка

Каждая стадия отвечает за свой вопрос. Цель - что вообще нужно сделать: роль в продукте, границы, порядок принятия решений и условия, при которых модель обязана отказаться. Контекст - из чего решать: запрос пользователя, найденные документы, история, состояние, результаты tools и примеры. Модель превращает цель и контекст в ответ, tools дают ей руки, а проверка решает, можно ли этому ответу верить и что с ним делать дальше. Пропустите любую стадию - и дыру придётся затыкать в другом месте, обычно дороже.

Если свернуть это в три части, которыми вы реально управляете, получится вот что.

  • Instruction - что сделать. Цель, роль в продукте, границы, порядок принятия решений и условия отказа. Это единственная часть, которую многие и называют "промптом", хотя она только треть картины.
  • Context - из чего решать. Запрос пользователя, найденные документы, история, состояние, результаты tools и примеры. Модель не знает ничего, чего нет в контексте, - поэтому качество ответа упирается в качество того, что вы в него положили.
  • Runtime - что реально разрешено. Схемы, permissions, таймауты, max steps, подтверждения, валидация и наблюдаемость. Это не текст, а код и инфраструктура вокруг модели, и именно они держат обещания, которые слова дать не могут.

Отсюда главная формула книги, к которой мы будем возвращаться в каждой главе.

Главная формула. Prompt задаёт вероятностное поведение. Код и инфраструктура задают обязательные границы. Нельзя заменить permission check фразой "не раскрывай чужие данные".

Разница принципиальная. Инструкция словами - это просьба, которую модель выполнит с некоторой вероятностью. Проверка прав в коде - это гарантия, которая срабатывает всегда. Как только цена ошибки выходит за пределы неудобства, обязательные границы переезжают из текста в код, а prompt перестаёт быть единственной линией обороны.

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

  • Один вызов. Владелец - одна модель. Типичный результат: классификация, извлечение, ответ по найденному контексту. Самый дешёвый и предсказуемый уровень, с него стоит начинать всегда.
  • Workflow. Владелец - код. Фиксированная цепочка с route, parallel и loop, где условия ветвления описаны явно. Порядок надёжно выражает код, а не уговоры модели.
  • Agent. Владелец - модель внутри harness. Динамический выбор шагов и tools в установленных пределах. Максимум гибкости и максимум риска, оправдан только когда путь решения заранее неизвестен.

Эти три уровня - не лестница, по которой обязательно подниматься. Чаще правильный ход обратный: взять самый простой уровень, который проходит проверку, и усложнять только под давлением реальных требований. С этого правила начинается инженерный промптинг, и к нему мы вернёмся в главе про выбор простейшей системы.

Проверка знаний

Нужно гарантировать, что пользователь не увидит чужие данные. Чем это обеспечить?

Ссылки