Урок 3. Процесс: как доводить промпт до рабочего состояния

В уроке 1 мы разобрали приёмы промптинга. В уроке 2 честно навалили все эти приёмы в один медицинский промпт — «вслепую», просто потому что так положено. Приёмы знать нужно, но этого мало. Нужен ещё процесс: понимание, в каком порядке принимать решения и как понять, что промпт стал лучше, а не просто длиннее.

Что такое промпт-инжиниринг

Промпт-инжиниринг — ремесло составления инструкций, которые дают от модели нужный результат. По сути это проектирование и доработка текстового входа: вы формулируете задачу для Claude так, чтобы он понял её однозначно.

Зачем это вообще нужно:

• Раскрыть возможности модели. Хорошо собранный промпт заметно поднимает качество — модель берёт задачи, которые на слабом промпте разваливались.
• Перевести намерение в текст. У вас в голове есть цель, у модели — только ваши слова. Промпт-инжиниринг закрывает этот разрыв.
• Сэкономить ресурсы. Аккуратный промпт тратит меньше токенов: дешевле и быстрее — а в проде это видно в счёте.

Чем он отличается от «просто спросить»

Назовём «базовым промптингом» обычный вопрос модели или простую инструкцию. Промпт-инжиниринг — процесс осознанный и более сложный. Разница по четырём осям:

• Сложность. Базовый промптинг — обычно один ход и простой запрос. Инжиниринг — многоходовые диалоги, сложные инструкции, продуманная структура входа и выхода.
• Точность. Базовый промпт может быть размытым и давать нестабильный результат. Для разового вопроса это нормально, но в проде так работать нельзя. Инженерный промпт точен и почти не оставляет места для трактовок.
• Итеративность. Базовый промпт — разовое действие. Инжиниринг — систематическое тестирование, анализ и улучшение промпта во времени.
• Масштабируемость. Цель — промпт, который держит широкий разброс входов и сценариев, а не только тот пример, на котором вы его писали.

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

Цикл: шесть шагов

Хотелось бы сесть за чистый лист и с первого раза написать идеальный промпт. В реальности так не бывает: промпт-инжиниринг — итеративный процесс создания, проверки и доработки. Вот последовательность, по которой стоит идти.

1. Шаг 0. Определить задачу и критерий успеха. Что именно должно быть на выходе и по какому признаку вы поймёте, что ответ хороший. Критерий должен быть проверяемым: не «нормальное саммари», а «строго 5 пунктов, каждый ≤ 20 слов, все факты есть во входном тексте, ничего лишнего».
2. Шаг 1. Собрать тестовые примеры. Разнообразный набор входов, покрывающий типовые сценарии и краевые случаи: очень короткий вход, очень длинный, с пропущенными полями, на другом языке, с мусором. Собирайте их до того, как написан промпт.
3. Шаг 2. Написать черновой промпт. Первая версия, которая внятно формулирует конечную цель. Хорошо, если в неё уже заложены знакомые приёмы: обозначить задачу, дать ключевую информацию, задать структуру. Но не привязывайтесь: финальная версия будет мало похожа на черновик.
4. Шаг 3. Прогнать на тестах и найти проблемы. Запустить промпт на подготовленных входах, посмотреть ответы и оценить их. Оценивать можно по-разному: кодом (проверка формата, наличие полей), экспертом-человеком или другой моделью в роли судьи.
5. Шаг 4. Поставить диагноз и выбрать приём. Не улучшать наугад. Для каждой найденной проблемы понять, почему она возникает; поискать подходящий приём промптинга; выбрать самые перспективные.
6. Шаг 5. Внести правки — по одной. Реализовать выбранные приёмы в промпте. Если правок несколько, вносите их по очереди: иначе не понять, какая помогла, а какая всё сломала.
7. Шаг 6. Повторить. Прогнать обновлённый промпт по тем же тестам, сравнить результаты, проверить, ушла ли исходная проблема — и не появились ли новые. Дальше по кругу, пока качество не станет достаточным.

Обратите внимание на порядок: сначала критерий и тесты, потом промпт. Соблазн всегда обратный — начать с текста промпта, а «проверить» его на одном примере, который случайно оказался под рукой. Так вы получаете промпт, отлично работающий ровно на одном входе, и никакого способа понять, стало лучше или хуже после правки. Тесты — это ваш измерительный прибор; без него итерации превращаются в перебор формулировок по ощущениям.

Метрики на прогоне

Когда вы «оцениваете ответы», полезно держать в голове четыре вопроса. Они превращают расплывчатое «вроде норм» в конкретный список проблем.

• Точность. Ответы корректные и по делу?
• Стабильность. Модель ведёт себя одинаково на разных входах? Что происходит на краевых случаях?
• Полнота. В ответе есть вся требуемая информация?
• Следование инструкциям. Все указания выполнены — формат, ограничения, запреты?

Каждый провал по такому вопросу — это уже конкретная проблема, для которой можно искать причину и подбирать приём. «Модель врёт в третьем пункте» и «модель игнорирует лимит в 20 слов» лечатся совсем по-разному.

И про модели. Смена модели — тоже переменная, и её стоит менять отдельно от промпта. Разумная стратегия: отладить промпт на быстрой и дешёвой claude-haiku-4-5, а если упираетесь в потолок рассуждений — прогнать те же тесты на claude-sonnet-5 или claude-opus-5 и сравнить. Тесты у вас уже есть, сравнение будет честным.

Упражнения

Возьмите свою реальную задачу — ту, которую вы правда хотите отдать модели. Если своей нет, используйте задачу из урока 2: извлечение структурированных данных из медицинской записи.

Упражнение 3.1 — Критерий успеха и тестовые кейсы

Не пишите промпт. Сначала сформулируйте проверяемый критерий успеха для своей задачи и соберите 5–7 тестовых входов: типовые случаи плюс минимум два краевых.

КРИТЕРИЙ УСПЕХА
1. Ответ — валидный JSON, обёрнутый в теги <result>...</result>.
2. Ключи ровно: age, symptoms, medications, follow_up.
3. Каждое значение дословно опирается на текст записи; ничего придуманного.
4. Если поля в записи нет — значение null, а не догадка.
5. Никакого текста до и после блока <result>.

ТЕСТОВЫЕ ВХОДЫ
1. Типовая полная запись — все четыре поля есть.
2. Запись без назначений (проверяем null).
3. Запись, где возраст указан косвенно: «пациентка 1979 г. р.».
4. Очень длинная запись с историей за 3 визита (проверяем, берёт ли последний).
5. Запись с сокращениями и опечатками врача.
6. Краевой: пустой текст.
7. Краевой: текст не про пациента вовсе (проверяем, не выдумает ли).

Упражнение 3.2 — Один цикл целиком

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

ЧЕРНОВИК: «Извлеки из записи возраст, симптомы,
назначения и план наблюдения. Верни JSON.»

ПРОГОН — что сломалось:
- тест 2: вместо null модель написала «не указано» → нарушен формат;
- тест 7: модель выдумала пациента → нарушена точность;
- тесты 1–5: перед JSON идёт фраза «Конечно! Вот результат:»
  → нарушено следование инструкциям.

ДИАГНОЗ:
- про null нигде не сказано — модель импровизирует;
- нет инструкции на случай «данных нет вообще»;
- не задан жёсткий формат вывода, модель по привычке
  добавляет вежливое вступление.

ПРАВКА №1 (только одна): задать точную оболочку вывода —
«Верни ТОЛЬКО блок <result>{...}</result>, без
вступлений и пояснений».

ПОВТОРНЫЙ ПРОГОН: вступления ушли на всех тестах;
null и выдумка на тестах 2 и 7 остались → это следующая правка.

Что запомнить

• Промпт-инжиниринг — не озарение, а цикл: критерий → тесты → черновик → прогон → диагноз → правка → повтор.
• Сначала критерий успеха и тестовые входы, только потом текст промпта. Без измерительного прибора итерации бессмысленны.
• Тесты должны включать краевые случаи, иначе промпт развалится ровно там, где вы его не смотрели.
• Оценивайте по четырём вопросам: точность, стабильность, полнота, следование инструкциям.
• Диагностируйте причину перед тем, как править. Вносите изменения по одному и сравнивайте на тех же тестах.
• Цель — повторяемость: промпт должен держать разброс входов, а не один удачный пример.