Вопрос «как написать промпт для нейросети» почти никогда не задают с чистого листа. Его задают, когда запрос отправлен, ответ получен и он не годится: слишком общий, не в том формате, с выдуманными фактами или оборванный на середине фразы. Эта статья про работу с уже написанным промптом: как разобрать его по симптомам ответа, что менять первым, как заставить модель переписать промпт за вас и как убедиться, что новая версия работает не один раз.
Базовая структура запроса и готовые шаблоны разобраны отдельно: что такое промпт-инжиниринг и как писать промпты. Здесь первое, что нужно сделать, это перестать переписывать промпт целиком. Типичная ошибка: ответ не понравился, пользователь стирает всё и сочиняет запрос заново. Меняется десяток вещей сразу, результат опять не тот, и понять, какая правка помогла, а какая испортила, невозможно.
Рабочая последовательность из четырёх шагов: определить по характеру плохого ответа, чего не хватило; внести одно изменение; прогнать промпт на пяти-десяти реальных входах; зафиксировать прошедшую проверку версию с датой и моделью. Документация Anthropic добавляет золотое правило: покажите промпт коллеге с минимумом контекста и попросите выполнить инструкцию. Если он растеряется, растеряется и модель.
Симптом плохого ответа почти однозначно указывает на дыру в запросе. Идти от результата быстрее, чем перечитывать свой текст в надежде заметить неточность.
| Что видно в ответе | Чего не хватает промпту | Что добавить |
|---|---|---|
| Ответ подходит любой компании, ничего конкретного | Критериев, по которым результат считается годным | Список: что обязано быть в тексте, что запрещено, чем годный результат отличается от негодного |
| Формат не тот: сплошной абзац вместо таблицы, лишнее вступление | Образца вывода | Один заполненный пример нужной структуры прямо в запросе |
| Модель уверенно называет факты, которых нет | Источника и разрешения не знать | Данные в теле запроса плюс разрешение отвечать «в материалах этого нет» |
| Ответ обрывается на середине предложения | Ничего, упёрлись в лимит вывода | Разбить задачу на части или поднять лимит, подробности ниже |
| Часть инструкций выполнена, часть проигнорирована | Разделения инструкций и данных | Развести блоки маркерами, чтобы длинный входной текст не читался как продолжение указаний |
| Тон и подача не те, хотя формально всё верно | Примеров нужного стиля | Три-пять образцов вместо описания стиля словами |
Число примеров не произвольное: Anthropic рекомендует от трёх до пяти и просит делать их разнообразными, иначе модель подхватывает не тот признак. Там же предлагается приём: попросить модель оценить ваши примеры на релевантность и разнообразие и дописать недостающие.
Отдельно про запреты: документация Anthropic советует формулировать, что делать, вместо того что не делать. «Не используй многоточия» работает хуже, чем «ответ прочитает синтезатор речи, а он не знает, как произносить многоточия». Объяснение модель обобщает на соседние случаи, голый запрет не обобщает ничего.
Оборванный ответ чаще всего означает, что генерация упёрлась в потолок длины. Переписывать промпт бессмысленно: потолок задаёте не вы, а модель и интерфейс.
По документации Anthropic, у Claude Opus 5, Claude Sonnet 5 и Claude Fable 5 максимальный вывод составляет 128 тысяч токенов при контекстном окне в 1 миллион, у Claude Haiku 4.5 это 64 тысячи токенов вывода и 200 тысяч контекста.
Цифры API не переносятся на веб-интерфейсы: там лимиты на порядки жёстче. В документации Yandex AI Studio указано прямо: максимальное количество токенов в ответе в Playground равно 1000, а максимальная длина промпта для генерации изображений составляет 500 символов. Курс токена даёт документация GigaChat: в среднем один токен состоит из 3-4 символов, точное количество считается запросом POST /tokens/count. То есть тысяча токенов в песочнице Yandex это порядка трёх-четырёх тысяч знаков, никак не десять.
Практически: если ответ обрывается стабильно, дробите задачу. Не «напиши двадцать описаний товаров», а пять запросов по четыре. Через API поднимайте параметр максимальной длины ответа и смотрите поле причины завершения. У GigaChat отдельно документирован случай, когда генерация прервана не длиной, а темой: ответ содержит «choices.finish_reason»: «blacklist», и это не лечится ни лимитом, ни формулировками.
После диагностики возникает соблазн внести сразу пять правок. Не вносите: иначе вы не узнаете, какая сработала, и потащите в следующие промпты балласт, который ничего не даёт, но занимает контекст и деньги. Порядок правок по убыванию отдачи:
Пятый пункт пропускают чаще всего, а промпты растут накоплением: через месяц системный промпт весит две страницы, половина которых противоречит второй половине.
Промпт не обязательно писать руками. Модель составляет промпты для себя лучше большинства пользователей: она знает, в каком виде инструкция ей удобна. Приём называется мета-промптинг, и Anthropic выпустила его готовым рецептом: ноутбук metaprompt.ipynb в наборе Claude Cookbook, запускается в Google Colab.
Вы описываете задачу обычными словами («ответить на жалобу клиента»), перечисляете переменные для подстановки («ПИСЬМО_КЛИЕНТА», «НАЗВАНИЕ_КОМПАНИИ») и получаете шаблон. Внутри мета-промпта лежат пять развёрнутых примеров инструкций (ответ по базе знаний, сверка двух формулировок, ответ по документу со ссылками, разбор задачи по шагам, работа с функциями) и несколько жёстких правил: переменные с длинными значениями идут до указаний по работе с ними, для сложных задач предписано сначала подумать в отдельном служебном блоке, а при запросе оценки обоснование требуется раньше самой оценки.
Тот же приём работает в чате. Плохо: «напиши мне промпт для описаний товаров». Хорошо, четырьмя строками:
Последний пункт даёт больше всего пользы: модель называет пробелы, о которых вы не подумали. Не задана аудитория, не указано, что делать при пустом входе, не оговорён язык ответа. Второй режим мета-промптинга это разбор неудачного запроса: вложите в чат промпт, ответ и объяснение, чем ответ плох, и попросите не переписать его, а перечислить причины расхождения.
Кроме мета-промптинга есть инструменты у самих вендоров. Знать их стоит хотя бы затем, чтобы не платить внешнему сервису за то же самое.
Состав и названия таких инструментов меняются от релиза к релизу: сверяйтесь с документацией вендора, а не со статьями годичной давности, включая эту.
Сервисов, обещающих превратить кривой запрос в идеальный, много. Перед тем как отдавать им текст, проверьте четыре вещи.
Отдельная ловушка это библиотеки готовых промптов: чужой промпт написан под чужие данные и критерии приёмки, забирать из него имеет смысл структуру, а не текст.
Главная причина, по которой отлаженный промпт разваливается в работе: его проверили на одном входе. На нём он и работает. На втором, где данные короче или содержат пустое поле, начинается разнобой.
Минимальная процедура: соберите от пяти до десяти реальных входов, обязательно включив крайние случаи. Самый короткий, самый длинный, вход с пропущенными полями, вход на другом языке, заведомо мусорный. Прогоните промпт по всему набору без правок между запусками, отметьте негодные результаты и правьте по симптомам из таблицы выше. После каждой правки прогоняйте набор целиком, а не только сломанный вход, иначе почините одно и незаметно сломаете другое.
Это не самодеятельность: документация OpenAI советует строить тесты и наборы проверок, измеряющие поведение промпта, чтобы отслеживать качество при доработке и при смене версии модели. Для нетехнической команды это обычная таблица: вход, ожидаемый результат, фактический, отметка «годно или нет», дата и версия модели.
Прошедшая проверку версия не должна жить в истории чата. Варианты по возрастанию надёжности: системный промпт или пользовательская инструкция в чате, если промпт нужен вам одному; сохранённый проект с прикреплёнными файлами, если есть постоянный контекст вроде регламента или гайда по тону; файл в репозитории, если промптом пользуется команда, и это единственный вариант с историей правок.
Рядом с текстом записываются дата проверки, модель с точным идентификатором версии, набор входов и ответственный за обновление. Про идентификатор: в документации Anthropic указано, что каждый идентификатор модели это закреплённый снапшот, а с поколения 4.6 они стали бездатными, но остались снапшотами, а не указателями на «самую свежую» модель. Запись «проверено на Claude» без версии бесполезна до первого обновления.
У промпта нет обратной совместимости. Вендоры меняют поведение моделей, и часть обязательных когда-то приёмов становится вредной или перестаёт работать. Примеры из документации Anthropic по миграции:
Вывод практический: смена версии модели это повод прогнать набор проверочных входов целиком. Тесты нужны не в момент написания промпта, а в момент, когда под вами меняют модель.
Часть времени тратится впустую потому, что диагноз поставлен неверно. Переделка запроса не поможет в четырёх случаях. Первый: модели неоткуда взять ответ, данные о прайсе, остатках и клиентах внутри неё не лежат. Второй: ответ упирается в лимит длины, лечится архитектура задачи, а не текст. Третий: задача требует действий, а не текста, то есть сходить в CRM, создать задачу, отправить письмо. Четвёртый: нужна стабильность на тысячах однотипных запросов, тут кроме промпта нужны проверки на выходе, обработка отказов и мониторинг.
Промпт отлажен, а дальше нужен работающий процесс
Соберём контур целиком: подача ваших данных в модель, проверки на выходе, обработка ошибочных ответов, мониторинг качества. С фиксацией версий промптов и набором тестов, по которому видно, что после обновления модели ничего не сломалось.
Почти всегда это лимит длины вывода. У Claude Opus 5 и Claude Sonnet 5 предел составляет 128 тысяч токенов, у Claude Haiku 4.5 это 64 тысячи, а в песочнице Yandex AI Studio максимум ответа равен 1000 токенов, то есть около 3-4 тысяч знаков при среднем токене в 3-4 символа.
Да, это мета-промптинг. У Anthropic есть готовый рецепт: ноутбук metaprompt.ipynb из Claude Cookbook, который по описанию задачи и списку переменных возвращает шаблон промпта. В чате приём работает так же, если попросить вернуть только текст промпта.
Документация Anthropic рекомендует от трёх до пяти и подчёркивает, что примеры должны быть разнообразными и покрывать крайние случаи, иначе модель подхватит не тот признак.
Меняется поведение моделей, а не только качество. Предзаполнение ответа ассистента перестало поддерживаться с моделей Claude 4.6 и возвращает ошибку 400, параметр budget_tokens на моделях 4.7 и новее тоже отдаёт 400, а с Claude Opus 4.7 сменился токенизатор.
Минимум пять, лучше десять, и это должны быть реальные данные. В набор включаются самый короткий вход, самый длинный, вход с пустыми полями и заведомо мусорный. После каждой правки набор прогоняется целиком.