Час ночи, задача на извлечение полей из 40 PDF-файлов в JSON — и проверенный трёхлетний шаблон выдаёт мусор. Удалить промпт целиком и написать десять строк вместо развёрнутого chain-of-thought оказалось единственным решением. Именно с этого эпизода начинается год переучивания, который описывает разработчик и промпт-инженер в своём материале на Habr.
Reasoning-модели — o-серия OpenAI, Claude Opus 4.7 в режиме high-thinking, GPT-5.5 с высоким мышлением, Gemini 3 thinking — устроены иначе, чем классические LLM. Внутри каждого ответа модель самостоятельно прокручивает chain-of-thought: анализирует задачу, строит гипотезы, проверяет граничные случаи. Без явной инструкции «подумай шаг за шагом». Это означает, что промпт, который раньше учил модель думать, теперь накладывается поверх уже идущего мышления и создаёт конфликт.
| Класс задачи | Что в промпте главное | Что выкинуть |
|---|---|---|
| Код | Минимум промпта, максимум контекста файлов через тулзы агента | Длинные размышления в самом промпте |
| Анализ данных | Schema на вход и выход, констрейнты на форматы и единицы | «Сделай красивую статистику» без метрик |
| Планирование | Decomposition вопросом «разбей на 5–7 шагов с estimate», констрейнты на ресурсы | Философию про важность задачи |
| Критика и ревью | Forced disagreement, confidence score 1–10 | Просьбу «дай обратную связь» — модель ответит вежливо и бесполезно |
| Коммуникация | Persona как функция (юрист, клиент, инженер), tone constraints | Эмоциональные модификаторы типа «жёстко» |
Результат измерим. Развёрнутый CoT-промпт, который на GPT-4 давал плюс 10–15% к точности на сложных задачах, на reasoning-модели даёт минус 5–7%. Эмоциональная ролевая установка — «ты гениальный программист с двадцатью годами опыта, ты любишь elegant решения» — перестала влиять на качество и начала влиять на тон: модель пишет пафосно, с восклицаниями, в стиле LeetCode-форума. Few-shot из шести-семи примеров, который раньше обучал модель целому классу задач, теперь тянет её в копирование вместо обобщения.
Эмоциональные роли («гениальный программист с 20 годами опыта») смещают тон, а не качество ответа.
На смену этим техникам пришли другие — и они значительно скучнее. Первое — контракт результата: точное описание того, что должно быть на выходе. Не «дай хороший отчёт», а «таблица из пяти строк, столбцы такие-то, пояснений до и после не надо». Reasoning-модель сама разберётся, как добраться до ответа, — она не должна угадывать, что считается ответом. По наблюдению автора, сейчас половина нового промпта — это описание выхода.
Второе — чёткое разделение системного промпта и пользовательского запроса. Стабильные правила поведения (язык ответа, ограничения по теме, стиль) уходят в system message или CLAUDE.md, в user остаётся только конкретная задача. Раньше это казалось эстетическим предпочтением, теперь — структурным требованием.
Третье — негативные констрейнты. «Не используй сторонние библиотеки», «не меняй файлы вне /src», «не предлагай решения с downtime больше пяти минут». Reasoning-модели соблюдают такие ограничения значительно надёжнее, чем предыдущее поколение. Важная оговорка: не больше трёх-четырёх ограничений за раз, иначе они превращаются в фоновый шум.
Few-shot не исчез, но поменял функцию. Один пример — максимум два — нужен не чтобы научить логике, а чтобы показать формат ответа. Разница принципиальная: не «как решать», а «как оформить решение».
Persona тоже работает, но только функциональная. «Ты security-аудитор, который ищет уязвимости в этом коде» — ограничение точки зрения, полезно. «Ты гениальный программист» — мотивационное вступление, мусор. Наконец, structured output через JSON Schema, XML с тегами или явный prompt-контракт стал обязательным для любого вывода, который парсится программно.
Практический итог: промпты с 2000 токенов сжались до 150 без потери качества или с его улучшением. Для простых задач — распарсить JSON, написать unit-тест, перевести текст — reasoning-модель справляется с минимальным промптом, и любое усложнение здесь только оверхед.
Автор формулирует и более широкий вывод: уже сейчас существуют meta-prompting инструменты, где одна модель оптимизирует промпт для другой. Когда это станет нормой, роль промпт-инженера сожмётся до роли постановщика задачи — человека, который умеет точно формулировать, чего он хочет. Навык, который всегда был главным, просто без дополнительного технического слоя.
