Вторник, час ночи. Сижу пишу промпт чтобы вытащить из 40 PDF-ок с актами нужные поля в JSON. Задача рутинная, у меня под неё лежит проверенный шаблон. Развёрнутый CoT, три few-shot примера, роль «опытный финансовый аналитик с 15 лет опыта». Раньше работал как часы.
Закидываю в GPT-5.5 с высоким мышлением. Получаю мусор. Половина полей не та, формат сломан, в выводе развёрнутое рассуждение которое я не просил.
Думаю ладно, заглючило. Прогоняю ещё раз. То же самое.
Удаляю промпт целиком. Пишу заново, тупо: «вытащи из приложенного текста поля X, Y, Z в виде JSON, никаких пояснений». Десять строк. Запускаю.
Работает.
Минут десять сижу пялюсь в монитор. Я только что выкинул в помойку три года накопленного арсенала. И минимальный промпт сделал лучше.
Так а что вообще произошло
Я полез копать. И вот что нашёл.
В 2025-2026 пошла волна reasoning-моделей. o-серия, Opus 4.7 в high-thinking, GPT-5.5 с высоким мышлением, Gemini 3 thinking. Принципиальное отличие от старых LLM такое: внутри ответа модель сама прокручивает chain-of-thought. Без подсказки. Без «подумай шаг за шагом». Без моих умных схем.
Раньше я был типа инструктором, учил модель как думать. Сейчас она думает без меня. И вот это «без меня» меня и порвало.
Половина старых техник стали бессмысленными или вредят. Особенно те где я лез прямо в процесс рассуждения.
Что начало сыпаться первым
Сильнее всего пострадал мой любимый длинный CoT-промпт. Типа «сначала проанализируй задачу, потом выпиши ключевые сущности, потом построй гипотезу, потом проверь её на edge cases, потом выдай ответ». На GPT-4 это давало плюс десять-пятнадцать процентов к точности на сложных задачах, я мерил.
На reasoning-модели тот же промпт даёт минус пять-семь процентов. Потому что модель и так делает примерно то же самое внутри. А мой промпт сверху это второй слой мышления, который конфликтует с первым.
Дальше посыпалась эмоциональная role-play. «Ты гениальный программист с двадцатью годами опыта, ты любишь elegant решения». Раньше работало, я сам не понимал почему но факт. Сейчас модель из такого вступления вытягивает не качество, а тон. Начинает писать как герой LeetCode-форума, пафосно, с восклицаниями. Налажал, переписал.
Чуть менее очевидно но тоже сдохло: тяжёлый few-shot для логики. Шесть-семь примеров одной и той же задачи чтобы научить модель решать класс. Раньше — стандартная техника. Сейчас модель и так знает класс, а лишние примеры её сбивают на копирование, теряется обобщение.
Ну и весь жанр «многословное вступление о важности задачи». Раньше я думал что это мотивирует модель. Сейчас понимаю что просто жгу токены.
А что наоборот выросло
Тут начинается интересное. Самые скучные техники, на которые я раньше тратил минут пять промпта, теперь оказались чуть ли не главными.
Первое и главное — контракт результата. Что хочешь на выходе, конкретно. Не «дай хороший отчёт», а «таблица из пяти строк, столбцы такие-то, пояснений до и после не надо». Reasoning-модель отлично решит как добраться до ответа. Она не должна угадывать что я считаю ответом.
Я сейчас ловлю себя на том что половина моего нового промпта это про выход. Что в каком формате, какой длины, чего точно не должно быть. Раньше я тратил на это две строчки, сейчас полпромпта.
Второе — системные промпты вместо user-prompts. CLAUDE.md, system message в API, инструкции субагенту. Стабильные правила работы — туда. В user остаётся только конкретная задача. Это разделение раньше казалось чисто эстетическим. Сейчас структурное. Системный слой почти полностью определяет поведение, user — только запрос дня.
Если у вас в каждом user-промпте написано «ты helpful assistant, отвечай по-русски, не давай советов по медицине» — это место не для user. Это в system.
Третье, и оно меня лично спасает — констрейнты. Что нельзя. «Не используй сторонние библиотеки», «не меняй файлы вне /src», «не предлагай решения с downtime больше пяти минут». Старые модели иногда забивали на «не делай Y» и делали Y. Reasoning-модели уважают негативные констрейнты на удивление честно.
Только не больше 3-4 ограничений за раз. Если завалить — становится фоновым шумом.
Четвёртое — few-shot всё ещё нужен, но не для того. Один пример формата. Два если формат сложный. Дальше не надо. Reasoning-модель учится логике из одного примера, а лишние тянут её в копирование вместо обобщения. Раньше я давал шесть примеров чтобы научить классу задач. Сейчас даю один пример чтобы показать формат ответа.
Не «как решать», а «как оформить решение». Звучит мелко, на качество влияет сильно.
Пятое — persona работает но не та. «Ты security-аудитор который ищет уязвимости в этом коде» — работает. «Ты гениальный программист с двадцатью годами опыта» — не работает. Разница простая, функция против комплимента. Первое — это ограничение точки зрения, полезно. Второе — мотивационное вступление, мусор.
Шестое, тут чисто техническое — structured output. JSON Schema, XML с тегами, markdown с фиксированной разметкой. Если вывод парсится — must have. Раньше можно было написать «выведи как JSON» и модель часто промахивалась, добавляла комментарии до и после блока, ломала кавычки. Сейчас structured-output через API-параметр или явный prompt-контракт с XML работает стабильно.
Если ваш парсер падает на ответах от модели — почти всегда лечится переходом на structured-output, а не очередным переписыванием user-промпта.
Под задачу — свой набор
Хочется одной таблицы. Так быстрее перечитать через полгода когда я снова всё забуду.
Класс задачи | Что в промпте главное | Что выкинуть |
|---|---|---|
Код | Минимум промпта, максимум контекста файлов через тулзы агента | Длинные размышления в самом промпте |
Анализ данных | Schema на вход и выход, констрейнты на форматы и единицы | «Сделай красивую статистику» без метрик |
Планирование | Decomposition вопросом «разбей на 5-7 шагов с estimate», констрейнты на ресурсы | Философию про важность задачи |
Критика и ревью | Forced disagreement, confidence score 1-10 | Просьбу «дай обратную связь», модель ответит вежливо и бесполезно |
Коммуникация | Persona как функция (юрист, клиент, инженер), tone constraints | Эмоциональные модификаторы типа «жёстко» |
Сейчас самая частая ошибка которую я ловлю у себя и у клиентов — пытаться написать один промпт на всё. «Универсальный системный, ты helpful assistant и умеешь всё». Не работает. Один класс задач — один шаблон. У меня в репозиториях лежит не один CLAUDE.md а несколько: общий, для подсистемы, отдельный для тестов. Так и пишутся.
Когда промпт-инжиниринг вообще не нужен
Иногда не нужен.
Распарсить JSON, написать unit-тест на чистую функцию, перевести с русского на английский — reasoning-модель решит с минимальным промптом. Любое усложнение тут оверхед. Тратит токены, тормозит, и ещё иногда ухудшает результат.
Правило: начинаешь с минимума. Усложняешь только если минимум не справился. Не наоборот.
И отдельно. Иногда плохой ответ — это не проблема промпта. Это проблема того что я сам толком не знаю чего хочу. Никакой промпт это не починит. Сначала формулировка, потом инструмент.
К чему всё идёт
Я думаю в следующем году появятся модели которые сами пишут себе промпты под задачу. Уже сейчас есть meta-prompting штуки, где одна модель оптимизирует промпт для другой. Когда станет нормой — привычная роль «промпт-инженера» сожмётся до уровня «постановщика задачи».
И тогда главным навыком будет не «как написать промпт», а «как правильно сформулировать вопрос». То есть то что всегда было главным, просто без шумного слоя.
Если у вас сейчас лежит пара любимых промптов со множеством примеров и развёрнутым CoT — попробуйте их укоротить. Не на десять процентов. Процентов на семьдесят-восемьдесят. Сравните. У меня после такого упражнения часть промптов сжалась с 2000 токенов до 150. Качество либо то же, либо лучше.
В общем я и сам ещё переучиваюсь. Через полгода может половина моих новых техник тоже сдохнет, и я снова буду сидеть ночью на кухне с этим же выражением лица.
Кстати, было бы интересно услышать чьи привычки в работе с моделями последние месяцы тоже посыпались. У меня ощущение что не я один.