«Промпт - это код, написанный на естественном языке. И у него есть свои синтаксис, отладка и лучшие практики.»
Без хорошего промпта LLM выдаёт кашу. В продакшене нужны предсказуемые, структурированные ответы (JSON, XML, конкретные поля), которые можно парсить и передавать дальше в систему.
Этот раздел - о том, как писать промпты, которые работают.
Хороший промпт - это не просто «вопрос». Это структурированный набор элементов.

Золотое правило
Чёткий промпт - половина успеха. Чем меньше двусмысленностей, тем предсказуемее ответ.
Мы разобрали, из каких частей состоит хороший промпт: роль, контекст, инструкция, формат вывода. Но есть один элемент, который кардинально меняет поведение модели - примеры.
Можно вообще не давать примеров (zeroshot), дать один (oneshot) или несколько (fewshot). Сколько нужно - зависит от сложности задачи. Начинайте с малого, добавляйте по необходимости. И никогда не давайте десять примеров там, где хватило бы трёх.
Эти термины описывают, сколько примеров вы даёте модели перед вопросом.

Пример few-shot для извлечения сущностей
Извлеки из текста дату, сумму и контрагента.
Текст: "10.05.2025 оплатили 5000 руб ООО Ромашка"
Ответ: {"date": "2025-05-10", "amount": 5000, "counterparty": "ООО Ромашка"}
Текст: "15 мая получили 100000 от Иванова"
Ответ: {"date": "2025-05-15", "amount": 100000, "counterparty": "Иванов"}
Текст: "вчера перевели 750 на карту Сбер"
Ответ: {"date": "2025-05-16", "amount": 750, "counterparty": "Сбер"}
Теперь: "22.05.2025 оплата 3200 руб Поставщик-М"
Ответ: ...
Практическое правило
Начинайте с zero-shot. Если ошибается - добавьте один пример. Если всё ещё плохо - 3–5 примеров. Больше 10 - вы выбрали не ту задачу или не ту модель.
Примеры помогают модели понять формат, но не заставляют её думать. Если задача требует логики, расчётов или планирования, прямое «дай ответ» приводит к угадыванию.
Нужно попросить модель показать ход рассуждений. Это ChainofThought (CoT). Цена - больше токенов, качество - несравненно выше. Когда без CoT никак, а когда это избыточно?
Проблема
Модели плохо справляются с многошаговыми рассуждениями, если просить ответ сразу. Они «гадают», а не «думают».
Решение
Попросить модель показать ход рассуждений перед ответом.
Как выглядит CoT в промпте
Реши задачу, показывая каждый шаг рассуждения.
Задача: В классе 25 учеников. 40% - девочки. Сколько мальчиков?
Шаг 1: Найдём количество девочек. 25 × 40% = 25 × 0.4 = 10.
Шаг 2: Вычтем девочек из общего числа. 25 - 10 = 15.
Ответ: 15.
Когда CoT обязателен
· Математические задачи
· Логические рассуждения
· Планирование (агенты, последовательность действий)
· Сравнение и анализ
Цена: Больше токенов (иногда в 3–5 раз). Но качество растёт пропорционально.
Модель научилась рассуждать, но её ответы всё ещё звучат как безликий информатор. А ваша компания - живая, с характером, с правилами общения. Ответ должен быть не только правильным, но и звучать как ваш.
Tone of Voice (TOV) - это голос бренда в устах LLM. Профессионально, но не сухо. На «ты» или на «вы». С эмодзи или без. Всё это задаётся в промпте, и это не опция, а обязательный пункт чек-листа.
LLM может отвечать по-разному. Задача - добиться, чтобы ответы звучали как голос вашей компании.

Как задать TOV в промпте
Ты - ассистент банка для МСБ. Твой тон: профессиональный, но не сухой.
Не используй канцелярит («вышеуказанный», «надлежащий»).
Обращайся на «ты» к клиенту.
Если клиент расстроен - прояви эмпатию, но не переходи в панибратство.
Не используй эмодзи в официальных ответах.
Длина ответа - 2-3 предложения на простой вопрос.
Но даже когда вы задали тон, модель может внезапно отказаться отвечать. «Я не могу ответить на этот вопрос» - и всё. Это не баг, а встроенная защита (alignment).
Модель сама цензурирует себя, чтобы не генерировать опасный контент. Важно уметь отличать такую самоцензуру от ошибки или нехватки контекста. А ещё лучше - предусмотреть свои фильтры на входе и выходе.
Даже без ваших фильтров модель может отказаться отвечать. Это встроенная система безопасности (alignment).

Как отличить самоцензуру от ошибки

Мы договорились о роли, добавили примеры, рассуждения, тон и научились отличать самоцензуру. Теперь самое важное для инженера: выход должен быть машинночитаемым.
Никаких «ну, как бы, я думаю...» - только JSON, чёткие поля, предсказуемая схема. Структурированные выходы (JSON mode, грамматически управляемая генерация) - это мост от разговорного ИИ к production-коду.
В продакшене нужны не красивые тексты, а предсказуемые форматы.
JSON mode - модель гарантирует, что ответ можно распарсить как JSON. Поддерживается большинством современных провайдеров.
json
{
"answer": "Ваш ответ здесь",
"confidence": 0.95,
"sources": ["документ_1.pdf", "документ_2.pdf"]
}
Ещё надёжнее - грамматически управляемая генерация (outlines, llama.cpp). Вы задаёте регулярное выражение или схему, и модель физически не может сгенерировать ничего, кроме корректного формата.
Структурированные выходы - это хорошо, но есть способы гарантированно сломать промпт. Спросить «Напиши мне эссе про...» без ограничения длины.
Смешать инструкцию и контекст в одном абзаце. Забыть указать, что делать, если модель не знает ответа. Это антипаттерны. Их легко избежать, если знать, на что обращать внимание.

Зная антипаттерны, легко превратить знание в действие.
Перед тем как отправить промпт в продакшен, пробегитесь по чеклисту: роль задана? инструкция однозначна? формат выхода указан? CoT добавлен для логических задач? ТОV соответствует бренду? Вот восемь пунктов, которые спасут вас от 90% проблем.
Перед отправкой в продакшен проверьте:
· Роль задана? Модель знает, кем она должна быть?
· Инструкция однозначна? Нет двусмысленностей и противоречий?
· Контекст добавлен? Вся нужная информация есть?
· Примеры (few-shot) добавлены? Если задача сложная - 2–5 качественных примеров
· CoT добавлен? Если нужна логика - «думай шаг за шагом»
· Формат вывода указан? JSON, строка, список - явно
· Ограничения и запреты прописаны? Чего модель не должна делать?
· TOV соответствует бренду? Формально, дружелюбно, с эмодзи - решили?
Промпт написан, структура задана, тон выверен. Как мы узнаем, что он действительно работает лучше предыдущей версии?
На глаз? «Мне кажется, модель стала умнее» - это не инженерный подход. Нужны цифры. Нужны метрики. Нужно уметь сравнивать модели, отслеживать деградацию после дообучения и честно отвечать руководству, стоит ли переходить с GPT4 на локальную модель. Это область оценки и бенчмаркинга. И здесь свои ловушки: публичные тесты часто врут, а человеческая оценка дорога. Найдём практический баланс.