Проблема не в модели — в контракте
Большинство разочарований в ИИ рождается из неявного контракта: вы думаете, что попросили одно, а модель услышала другое. Модель не «понимает» в человеческом смысле — она предсказывает продолжение по статистике. Чем меньше неопределённости в запросе, тем выше вероятность попадания в цель.
Откровенный промт — это запрос, где контекст, ограничения и критерий успеха заданы явно. Никаких «сделай хорошо», «напиши красиво» или «подумай как эксперт». Только факты, структура и проверяемые условия.
Типичный неявный запрос
«Напиши письмо клиенту, чтобы он оплатил счет»
Откровенный аналог
«Напиши напоминание об оплате счета №1245 от 12.03 на 45 000 руб. Тон: деловой, уважающий, без давления. Укажи срок — 3 рабочих дня. Добавь реквизиты из приложения. Длина — до 120 слов. Тема письма: «Счёт №1245 — напоминание об оплате»»
Четыре столпа откровенного промта
Контекст — не преамбула, а данные
Модель не знает вашего проекта, если вы не расскажете. Дайте ровно столько контекста, чтобы решение стало однозначным: роль, аудитория, формат, ограничения, примеры входа/выхода. Лишнее — шум, малого — подсказки к гаданию.
Ограничения — рамка, в которой рождается свобода
Длина, стиль, структура, запрещённые слова, обязательные элементы, формат выхода (JSON, markdown, plain text). Жёсткие ограничения исключают галлюцинации формата и заставляют модель сфокусироваться на сути.
Критерий успеха — как проверить результат без прочтения
Опишите тест, который пройдёт хороший ответ: «JSON валиден и содержит поля id, title, status», «письмо не длиннее 120 слов, есть тема, призыв к действию в последней строке». Это превращает оценку из субъективной в бинарную.
Примеры — самый точный способ передать интуицию
Один-два пары «вход — идеальный выход» заменяют страницы инструкций. Модель копирует паттерн, а не интерпретирует слова. Для сложных задач — 3-5 примеров, покрывающих граничные случаи.
Шаблон «Контекст — Задача — Ограничения — Примеры — Формат»
Универсальная скелетная структура для любых задач
Три паттерна, покрывающих 80% рабочих задач
Паттерн 1 — Структурированная выжимка
Из хаоса — в схему
Когда на входе — неструктурированный текст (звонок, письмо, статья, логи), а на выходе нужны факты в заданной схеме.
Ключевые приёмы
- Явно перечислите типы сущностей и их поля
- Требуйте enum для категорий (high/med/low)
- Добавляйте инструкцию: «Если информации нет — пиши null, не выдумывай»
- Пример вход/выход на 2-3 похожих кейса
Паттерн 2 — Итеративный уточняющий диалог
Модель спрашивает — вы отвечаете
Для задач, где контекст невещается полностью: стратегия, архитектура, сложный текст. Модель должна выявить пробелы перед генерацией.
Когда работает лучше всего
- Результат дорогой ошибки (юридические, мед, код)
- Много неявных предпочтений заказчика
- Нужно «прочувствовать» бренд/голос
- Сложная иерархия решений
Паттерн 3 — Самооценка и рефлексия
Модель проверяет себя по вашим критериям
Добавьте в промт этап самопроверки. Модель генерирует, затем оценивает по чек-листу, исправляет, возвращает финал. Снижает галлюцинации формата и логические провалы.
Ограничение
Увеличивает расход токенов ~1.5-2×. Используйте там, где цена ошибки выше цены токенов.
Совет: для рутинных задач — вынесите самопроверку в системный промт, а в пользовательском оставьте только вызов: «Сделай и самопроверь».
Отладка: когда промт не работает
1 Синдром «умного стажера»
Модель делает то, что вы попросили буквально — а не то, что вы имели в виду. Она не «глупая», у неё нет контекста вашего бизнеса.
Лекарство: добавьте в контекст 3-5 фактов о бизнесе, аудитории, бренде. Проверьте: если дать этот промт новичку в компании — он поймёт задачу?
2 Конфликт ограничений
«Подробно, но коротко», «креативно, но строго по регламенту», «как эксперт, но простым языком». Модель выбирает компромисс, который устраивает никого.
Лекарство: рангуйте ограничения: «Приоритет 1 — точность фактов. Приоритет 2 — длина до 200 слов. Приоритет 3 — живой тон». Или разбейте на два промта: черновик → правка.
3 Дрейф формата
Модель начинает выдавать валидный JSON, а через 3-й запрос — оборачивает в markdown, добавляет комментарии, меняет названия полей.
Лекарство: жесткая схема выхода + инструкция «Только JSON, без markdown, без комментариев, имена полей ровно как в примере». Для API — используйте function calling / structured output.
4 Потеря контекста в длинных диалогах
Модель «забывает» соглашения из начала диалога, начинает противоречить себе.
Лекарство: периодически повторяйте ключевые ограничения в контексте. Лучше — выносите неизменные правила в системный промт, а переменные — в пользовательский. Для критических задач — каждый запрос автономен (все контекст + правила в одном сообщении).
Персональная библиотека: от хаоса к системе
1 Именование — по задаче, а не по модели
extract-decisions-from-meeting лучше, чем gpt4-summary-v2. Задачи живут дольше моделей. Версионируйте: v1.3 в метаданных файла.
2 Храните пары: промт + эталонный результат
Для каждого промта сохраняйте 1-2 «золотых» примера входа и идеального выхода. При смене модели или обновлении промта — прогоняете по эталонам. Регрессия видна сразу.
3 Разделяйте системный и пользовательский слои
Системный: роль, бренд-голос, глобальные запреты, формат самопроверки. Пользовательский: конкретная задача, входные данные, параметры текущего запуска. Меньше копипаста — меньше дрейфа.
4 Регулярная «уборка» раз в квартал
Удалите промты, которые не использовались 3 месяца. Объедините дубликаты. Обновите примеры под актуальные кейсы. Библиотека — не музей, а рабочий инструмент.
Чек-лист перед отправкой
- Контекст содержит только релевантные факты (роль, аудитория, бренд, ограничения)
- Задача сформулирована как инструкция исполнителю, а не пожелание
- Есть жёсткие ограничения: длина, формат, запреты, обязательные элементы
- Критерий успеха позволяет проверить результат бинарно (да/нет)
- Примеры (1-3 пары) покрывают типичные и граничные случаи
- Формат выхода описан схемой или примером, без двусмысленностей
- Нет конфликтующих инструкций без явного приоритета
- Промт понятен новичку в вашей команде без доп. объяснений
