Reasoning-модели сломали мой промпт-инжиниринг. Год переучиваюсь

Вторник, час ночи. Сижу пишу промпт чтобы вытащить из 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-промпта.

Под задачу — свой набор

Хочется одной таблицы. Так быстрее перечитать через полгода когда я снова всё забуду.

Сейчас самая частая ошибка которую я ловлю у себя и у клиентов — пытаться написать один промпт на всё. «Универсальный системный, ты helpful assistant и умеешь всё». Не работает. Один класс задач — один шаблон. У меня в репозиториях лежит не один CLAUDE.md а несколько: общий, для подсистемы, отдельный для тестов. Так и пишутся.

Когда промпт-инжиниринг вообще не нужен

Иногда не нужен.

Распарсить JSON, написать unit-тест на чистую функцию, перевести с русского на английский — reasoning-модель решит с минимальным промптом. Любое усложнение тут оверхед. Тратит токены, тормозит, и ещё иногда ухудшает результат.

Правило: начинаешь с минимума. Усложняешь только если минимум не справился. Не наоборот.

И отдельно. Иногда плохой ответ — это не проблема промпта. Это проблема того что я сам толком не знаю чего хочу. Никакой промпт это не починит. Сначала формулировка, потом инструмент.

К чему всё идёт

Я думаю в следующем году появятся модели которые сами пишут себе промпты под задачу. Уже сейчас есть meta-prompting штуки, где одна модель оптимизирует промпт для другой. Когда станет нормой — привычная роль «промпт-инженера» сожмётся до уровня «постановщика задачи».

И тогда главным навыком будет не «как написать промпт», а «как правильно сформулировать вопрос». То есть то что всегда было главным, просто без шумного слоя.

Если у вас сейчас лежит пара любимых промптов со множеством примеров и развёрнутым CoT — попробуйте их укоротить. Не на десять процентов. Процентов на семьдесят-восемьдесят. Сравните. У меня после такого упражнения часть промптов сжалась с 2000 токенов до 150. Качество либо то же, либо лучше.

В общем я и сам ещё переучиваюсь. Через полгода может половина моих новых техник тоже сдохнет, и я снова буду сидеть ночью на кухне с этим же выражением лица.

Кстати, было бы интересно услышать чьи привычки в работе с моделями последние месяцы тоже посыпались. У меня ощущение что не я один.