Сложный промпт с нуля

До этого момента каждый приём жил отдельно. В реальном промпте для продукта или командного шаблона они нужны все сразу — и вопрос в том, в каком порядке их складывать и что можно выбросить. В этом уроке — рекомендованная структура сложного промпта, два разобранных примера и способ довести промпт до рабочего состояния.

Структура из девяти элементов

Оригинальный туториал предлагает каркас из десяти элементов; последний — предзаполнение ответа — на современных моделях не используется, поэтому у нас их девять. Не каждому промпту нужны все. Рабочий подход: сначала собрать промпт со всеми элементами и добиться, чтобы он работал, потом убирать по одному и смотреть, что ломается.

1. Контекст задачи. Кто модель и какая у неё общая цель. «Ты — ассистент поддержки сервиса доставки, отвечаешь клиентам в чате». Ставится в начало, обычно в системный промпт.
2. Тон. Если важен. «Дружелюбно, коротко, без канцелярита». Часто заменяется примерами.
3. Подробное описание задачи и правила. Что именно делать, чего не делать, что делать в спорных случаях. Здесь же — «выход» на случай незнания: «если вопрос не про сервис — вежливо скажи, что помочь не можешь». Это самый длинный элемент, и его стоит показать коллеге по золотому правилу.
4. Примеры. Один или несколько идеальных ответов в <example>. Особенно важны краевые случаи и то, как должно выглядеть рассуждение, если оно есть.
5. Входные данные. Документы, история диалога, обращение — каждое в своём теге. Длинные документы — ближе к началу промпта, до инструкций.
6. Непосредственная задача. Что нужно сделать прямо сейчас с этими данными. Обычно в конце, после всех данных: «Ответь на последнее сообщение клиента».
7. Шаги рассуждения. «Сначала в <thinking> определи тему обращения и найди в <faq> подходящий пункт, потом отвечай». См. «Рассуждение по шагам».
8. Формат ответа. Теги, JSON, длина, что делать с вступлениями.
9. Повтор ключевого правила (по желанию). Если промпт длинный, одно самое важное правило можно повторить в конце — модели лучше запоминают начало и конец.

Порядок важен для некоторых элементов: контекст — раньше, данные — раньше вопроса, вопрос и формат — ближе к концу. Остальное можно двигать.

Пример 1: ассистент поддержки

Разделим на системный промпт (постоянная часть) и сообщение (переменная).

[system]
Ты — ассистент поддержки сервиса доставки еды, отвечаешь клиентам
в чате приложения от имени команды поддержки. Твоя цель — решить
вопрос клиента или объяснить, что будет дальше.

Тон: дружелюбный, короткий, без канцелярита и без восклицаний.
Обращайся на «вы».

Правила:
- Отвечай только на вопросы про заказы, доставку, оплату и приложение.
  На другие темы вежливо скажи, что не можешь помочь.
- Опирайся только на <faq>. Если ответа там нет, скажи, что передашь
  вопрос оператору, и не придумывай сроки, суммы и правила.
- Не проси персональные данные, кроме номера заказа.
- Если клиент злится, сначала признай проблему, потом решай.

<faq>
…
</faq>

<examples>
<example>
Клиент: Где мой заказ? Уже час жду
Ассистент: Понимаю, час — это долго. Напишите, пожалуйста, номер заказа
(он в разделе «Мои заказы»), я проверю, где курьер.
</example>
<example>
Клиент: А вы можете порекомендовать хороший фильм на вечер?
Ассистент: С фильмами не подскажу — я помогаю только с заказами и
доставкой. Если что-то с заказом, пишите, разберёмся.
</example>
</examples>

Перед ответом в <thinking> определи: тема обращения, есть ли ответ
в <faq>, нужен ли номер заказа. Ответ клиенту дай в <reply>,
не длиннее трёх предложений.

[user]
<history>
…предыдущие сообщения, если есть…
</history>

<message>
Списали деньги, а заказ в приложении не появился
</message>

Ответь на сообщение клиента.

Здесь есть всё: контекст (1), тон (2), правила с выходом (3), примеры (4), данные — FAQ и история (5), задача (6), шаги (7), формат (8). Обратите внимание, что тег <reply> даёт программе способ вытащить ответ клиенту, отбросив <thinking>.

Пример 2: ревью кода для обучения

Второй пример из туториала — бот, который читает код и подсказывает исправления, не решая задачу за человека. Порядок элементов здесь другой: данных мало, правил много.

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

Правила:
1. Ищи ошибки: логические, краевые случаи, исключения, проблемы
   с читаемостью. Стиль отмечай только если он мешает пониманию.
2. Для каждой ошибки объясни, что пойдёт не так и при каких входных
   данных, но не давай готовое исправление. Задай наводящий вопрос.
3. Если код корректен, так и скажи и предложи один способ его улучшить.
4. Не выдумывай поведение библиотек; если не уверен, напиши,
   что стоит проверить в документации.

<code language="python">
def print_multiplicative_inverses(x, n):
    for i in range(n):
        print(x / i)
</code>

Сначала в <analysis> пройди по коду построчно и выпиши подозрительные
места. Потом в <feedback> дай разработчику замечания: нумерованный
список, в каждом пункте — что не так и наводящий вопрос.

В этом коде деление на ноль на первой итерации (range начинается с нуля) и, вероятно, ошибка в логике: мультипликативные обратные считаются иначе. Хороший ответ укажет оба места и спросит «с какого числа начинается range(n)?», а не выдаст исправленный код.

Как доводить промпт до рабочего

Соберите тестовый набор: пять-десять реальных входов, включая сложные и пограничные. Без набора вы будете оценивать промпт «на глаз» по одному примеру, а это ничего не значит.

Начните с полной структуры. Если что-то не работает, посмотрите, какого элемента не хватает: модель выдумывает — нет выхода в правилах; формат плавает — нет примеров или тега; ответ не по теме — вопрос слишком далеко от данных.

Потом сокращайте. Уберите тон — если примеры держат его сами, элемент лишний. Уберите шаги рассуждения — если на тестовом наборе точность не упала, они не нужны на этой задаче. Короткий промпт дешевле, быстрее и понятнее команде.

Меняйте одно за раз и держите таблицу результатов, как договорились в первом уроке.