Промпт-инжиниринг 2026: что устарело с приходом reasoning-моделей

Полгода назад взял старый промпт. Тот самый, отлаженный за два года — с развёрнутым chain-of-thought, тремя few-shot примерами, ролью «опытного инженера с 15 лет опыта», пошаговой схемой рассуждения. Запустил на reasoning-модели в режиме высокого мышления ^[1].

Результат — хуже, чем у минимального промпта.

Минимальный промпт был тупой: вход, ожидаемый формат вывода, одно ограничение. Без героики. И он выиграл.

Тогда я понял: половина моего арсенала, накопленного на GPT-4 и Claude 3.5, против reasoning-моделей работает плохо. Что-то откровенно вредит. Что-то стало лишним. А что-то — что я делал по остаточному принципу — наоборот, теперь важнее всего.

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

Что вообще произошло

В 2025-2026 пошла волна reasoning-моделей: o-серия от OpenAI, Claude Opus 4.7 в high thinking, GPT-5.5 с высоким мышлением, Gemini 3 thinking. Они отличаются от классических LLM одним: внутри ответа модель прокручивает chain-of-thought сама. Без подсказки. Без «подумай шаг за шагом». Без структурированной мной схемы.

Это меняет всё.

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

Что умерло

Не «совсем умерло», но даёт слабые или отрицательные результаты на reasoning-моделях.

Не получалось у меня сразу выкинуть всё это. Привычка. Когда модель давала плохой ответ — первое желание было добавить больше промпта. Подсказать. Развернуть. Это срабатывало раньше.

Сейчас — чаще ухудшает.

Особенно интересно с role-play. Раньше «ты — крутой алгоритмист, реши задачу как для google interview» правда улучшало ответ. Теперь reasoning-модель из такого вступления вытягивает не качество, а тональность. Начинает писать как герой LeetCode-форума — пафосно, с восклицаниями, без сути. Не та эстетика, не тот результат.

Что выжило и стало важнее

Парадоксально, но самые скучные техники — про чёткость и ограничения — выросли в значимости.

1. Контракт результата

Главное теперь. Что хочешь на выходе — конкретно. Не «дай хороший отчёт», а «дай таблицу из 5 строк, столбцы X/Y/Z, без пояснений до и после».

Reasoning-модель отлично решает, как добраться до ответа. Но не должна угадывать что считать ответом.

Раньше я мог написать «опиши проблемы в коде» и получал что-то вменяемое. Сейчас на этой формулировке модель может дать развёрнутое эссе на три экрана — потому что её внутреннее мышление пошло вглубь, а ограничений на формат не было. Чёткий контракт типа «ответь списком из 3-5 пунктов, каждый с описанием в 1 предложение» меняет всё.

2. Системные промпты вместо user-prompts

CLAUDE.md, system message в API, инструкция субагенту. Стабильные правила работы — туда. User-prompt — только задача дня.

Это разделение раньше казалось эстетическим. На reasoning-моделях стало структурным: системный слой почти полностью определяет поведение ^[2], user-слой — только конкретный запрос. Если вы каждый раз в user-prompt пишете «ты helpful assistant, отвечай по-русски, не давай советов по медицине…» — это место для system, не для user.

3. Constraints — что нельзя

«Не используй сторонние библиотеки», «не меняй файлы за пределами /src», «не предлагай решения, требующие downtime больше 5 минут». Negative constraints reasoning-модель уважает сильнее, чем classical-модели. У последних бывало — игнорировали «не делай Y» и делали Y. Сейчас работает почти всегда.

Хорошая практика — давать 2-4 constraint, не больше. Слишком много ограничений модель воспринимает как фоновый шум.

4. Few-shot для формата, не для логики

Один пример — какой формат вывода. Два примера — если формат сложный. Дальше — не надо.

Раньше я давал 5-6 примеров, чтобы научить модель решать класс задач. Сейчас reasoning-модель учится логике ^[3] из одного примера, а лишние только тянут контекст и сбивают её на «копирование» вместо «обобщения».

Few-shot теперь — это про шаблон ответа. Не про то, как решать.

5. Persona как функциональная роль

«Ты — security-аудитор, ищущий уязвимости в этом коде» — работает. «Ты — гениальный программист с 20 лет опыта ^[4], и ты любишь elegant решения» — не работает.

Разница — функция vs комплимент. Reasoning-модель воспринимает первое как ограничение точки зрения ^[5] (полезно). Второе — как мотивационное вступление (мусор).

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

6. Structured output

JSON Schema, XML с тегами, markdown с фиксированной разметкой. Когда вывод парсится — это критично.

Раньше можно было сказать «выведи в виде JSON», и модель часто промахивалась — с кавычками, или добавляла комментарии до и после блока кода. Сейчас structured-output (через API-параметр или явный prompt-контракт с XML-тегами) работает стабильно. У Anthropic есть отдельный механизм для этого, у OpenAI — JSON-mode и function calling, у других провайдеров — свои аналоги. Используйте, если парсите.

Без structured-output на reasoning-моделях боль ^[6] — они любят давать развёрнутые ответы, и парсер в продакшене ломается.

7. Forced disagreement — отдельная категория

Reasoning-модели по умолчанию ещё сильнее склонны соглашаться, чем классические. Внутреннее «думанье» помогает им находить логику за моими тезисами и обосновывать их, вместо того чтобы оспорить.

Чтобы превратить помощника в критика, нужен явный контракт: «найди 3 проблемы», «представь, что это код конкурента», «оцени уверенность по шкале 1-10». Без этого — получаешь зеркало своих гипотез, причём убедительно зеркалящее.

Это отдельная тема, в неё можно нырять глубоко. Если коротко — стандартное «критикуй» сейчас не работает, нужны квалификаторы и роли.

Под задачу — свой инструмент

Промпт-инжиниринг 2026 — это не один универсальный подход. Под класс задачи свой набор техник.

Самая распространённая ошибка ^[7], которую я ловлю у себя и у других — пытаться писать промпт, который сработает для всего сразу. Универсальный системный промпт «ты helpful assistant и умеешь всё» — это анти-паттерн. Один класс задач — один шаблон.

Это, кстати, причина почему у меня в репозиториях лежит не один CLAUDE.md, а несколько: общий, специфичный для подсистемы, отдельный для тестов. Каждый — под класс задач.

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

Иногда — просто не нужен.

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

Принцип: начинай с минимума. Добавляй промпт только когда минимум не справляется. Не наоборот.

И ещё. Иногда плохой результат — это не проблема промпта, а проблема задачи. Если ты не можешь чётко сформулировать чего хочешь, никакой промпт это не починит. Сначала разберись в задаче, потом пиши промпт.

Что в 2027

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

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

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

Это весь промпт-инжиниринг 2026, как я его понимаю на сегодня. Через полгода, возможно, половина моих новых техник тоже умрёт. Это нормально — поле такое.