Prompt engineering для reasoning-моделей (o3, R1, Claude extended thinking)
Reasoning-модели — это не быстрые модели с лишними шагами. Они вознаграждают другое промптование, игнорируют часть привычных паттернов и имеют свои подвохи. Практическое руководство по работе с ними.
Reasoning-модели — самый важный класс моделей, появившийся со времён исходного ChatGPT. o1, o3, GPT-5 Thinking, Claude Opus / Sonnet с extended thinking, DeepSeek R1, Gemini 2.5 Thinking, Grok-4 Heavy — к 2026 году каждая крупная лаборатория выпустила reasoning-модель, и они изменили то, что в принципе возможно в сложной аналитической работе.
Они также вознаграждают другой стиль промптования по сравнению с быстрыми моделями. Многие техники, которые блестяще работают с моделями класса GPT-4 (тяжёлые строительные леса, «think step by step», развёрнутые role-промпты), для reasoning-моделей в лучшем случае нейтральны, а в худшем вредны. Правильный стиль ближе к «ясно опиши задачу и доверься модели», чем к тому, что вы читали в гайдах по prompt engineering.
Эта статья — про то, что такое reasoning-модели, когда их брать, как их хорошо промптовать и какие подвохи ловят даже опытных пользователей AI.
Что reasoning-модели на самом деле собой представляют
Reasoning-модель — это модель, которая внутри генерирует расширенную цепочку рассуждений, прежде чем выдать финальный ответ. Модель «думает» десятки секунд, часто минуты, прежде чем ответить. Токены «размышления» часто скрыты от вас (видите индикатор «thinking…») или сжаты в резюме.
Это реальный сдвиг в возможностях. На сложных многошаговых бенчмарках reasoning-модели регулярно опережают быстрые модели с большим отрывом — конкретный разрыв сильно зависит от задачи и сравниваемых провайдеров, но он достаточно велик, чтобы выбор между «fast» и «thinking» был теперь реальным архитектурным решением. Они также дороже, дольше работают и требуют другого промптования.
Основные reasoning-модели в 2026:
- OpenAI o3 и его варианты (o3-mini, o3-pro). Доступны через API и ChatGPT (Plus и Pro). GPT-5 в режиме «Thinking» — версия для потребителя.
- Claude 4.5 Opus / Sonnet с extended thinking. Доступны в claude.ai (Pro и выше) и через API. Чтобы включить reasoning, задайте параметр
thinking. - DeepSeek R1 (и наследники). Открытые веса; доступны через приложение DeepSeek, OpenRouter и других провайдеров.
- Gemini 2.5 Thinking. Внутри Gemini Advanced и API.
- Grok 4 Heavy. Доступен пользователям X Premium+.
Все они работают по одному базовому принципу. Различия — в цене, задержке, видимости трассы рассуждений и в том, на каких именно задачах каждая сильнее.
Когда тянуться за reasoning-моделью
Reasoning-модель — правильный инструмент, когда:
- Задача состоит из нескольких шагов, опирающихся друг на друга. Математика, логика, многошаговое планирование, код с прослеживанием состояния.
- Цена ошибки реальна. Финансовый анализ, юридическая интерпретация, медицинские рассуждения, отладка боевых проблем.
- Обычные модели стабильно ошибаются. Если быстрая модель уже пробовалась и ответ постоянно мимо — reasoning-модель обычно решает задачу.
- Задача требует аккуратного сравнения или анализа компромиссов. Многокритериальные решения, архитектурные выборы, оценка подрядчиков.
- Нужно, чтобы модель действительно подумала о граничных случаях, а не просто выдала правдоподобный текст.
Когда reasoning-модель не нужна:
- Разговорный чат. Задержка делает обмен репликами мучительным.
- Генерация и черновики. По опыту многих пользователей reasoning-модели пишут хуже быстрых.
- Простое вспоминание. Спрашивать у reasoning-модели «какая столица Эстонии» — пустая трата её вычислений и вашего времени.
- Циклы итеративной доработки. Когда хочется отправить 10 быстрых сообщений — это работа быстрой модели.
- Задачи, где нужно контролировать промежуточные шаги. Reasoning-модели прячут рассуждения; если хочется видеть каждый шаг — используйте быструю модель с явным CoT.
Полезное правило: если вы бы не платили аналитику за 20 минут на эту задачу, не используйте reasoning-модель. Если платили бы — используйте.
Сдвиг в промптовании
Главная ошибка с reasoning-моделями — применять к ним prompt engineering от быстрых моделей. Пять вещей, от которых надо отказаться:
1. Перестаньте писать «think step by step»
Reasoning-модели и так это делают. Добавление фразы — в лучшем случае избыточно. Хуже того, на некоторых reasoning-моделях эта фраза может мешать внутреннему процессу рассуждений — модель тратит вычисления на выполнение видимого пошагового мышления вместо использования своего более сильного внутреннего.
Плохо: Think step by step. Solve this carefully. Show your work. [задача]
>
Хорошо: [задача]
Просто чётко изложите задачу. Доверьтесь модели.
2. Перестаньте обвешивать структуру лесами
Паттерн, который хорошо работает с быстрыми моделями, — тяжёлые строительные леса: «сначала сделай A, потом B, потом C, вот формат…». С reasoning-моделями модель часто сама находит правильную структуру ответа — а диктовать её можно дать худший результат, чем если позволить модели решить.
Стиль быстрой модели: Сначала перечисли ключевые ограничения. Затем варианты. Затем оцени каждый по каждому ограничению. Затем выбери. Затем обоснуй. Формат вывода: …
>
Стиль reasoning-модели: Помоги выбрать между вариантом A и вариантом B. Контекст: […]
Reasoning-модель обычно внутри проведёт более тонкий анализ, чем тот, который вы бы навязали структурой.
3. Не стопкуйте техники рассуждений
CoT + self-critique + tree-of-thoughts работают на быстрых моделях. На reasoning-моделях модель уже делает эквивалент всех трёх внутри. Накладывать сверху внешние версии — избыточно и ухудшает качество.
Если ваш промпт к reasoning-модели содержит «think step by step, then critique your own answer, then revise» — сократите до самого вопроса. Модель сама знает.
4. Не переопределяйте роль
Паттерн, который хорошо работает с быстрыми моделями, — тяжёлая роль: «Ты старший инженер с 20-летним опытом распределённых систем, который строил крупные приложения и знает компромиссы…». Reasoning-модели не выигрывают от этих лесов так же сильно. Они и так подтягивают нужный тип экспертизы по самой задаче.
Короткий, прямой role-промпт всё ещё полезен, чтобы задать тон и регистр, но длинная подробная персона избыточна.
Плохо: Ты бэкенд-инженер мирового класса с 20+ лет опыта…
>
Хорошо: Помоги мне продумать эту проблему распределённых систем. [задача]
5. Не просите показать «размышление»
В o3 и некоторых других трасса рассуждений намеренно скрыта. Просьба «покажи рассуждения» может дать другой (часто более поверхностный) вывод, чем если позволить модели подумать приватно и выдать вывод.
Если хочется видеть рассуждения — это разумное предпочтение, и в Claude с extended thinking трасса часто доступна. Но прямая просьба показать на модели, где это обычно скрыто, может ухудшить качество.
Чего reasoning-модели ХОТЯТ
Несколько вещей, которые они вознаграждают:
Конкретики. Числа, даты, точные ограничения, конкретные файлы и люди. Reasoning-модели умеют делать настоящую арифметику на настоящих числах — давайте им числа.
Открытой формулировки. «Вот ситуация. Вот что хочу понять. Что думаешь?» даёт лучший выход, чем жёсткие шаблоны.
Честной неопределённости. Скажите модели, чего вы не знаете. «Я не уверен, X это или Y; помоги разобраться». Reasoning-модели хорошо обращаются с неоднозначностью и используют её продуктивно.
Разрешения возражать. «Возрази, если моя рамка неверна» или «скажи, чего я не учитываю» даёт заметно лучший выход, чем просьба поддержать вашу позицию.
Конкретных данных. Таблицы, код, документы — вставляйте. Reasoning-модели работают лучше всего, когда есть реальные артефакты, с которыми можно работать, а не абстрактные вопросы.
Проработанные примеры
Пример 1: отладка
Допустим, у вас неприятный баг.
Быстрая модель + CoT:
>
Ты старший инженер, специализирующийся на TypeScript. Думай по шагам про этот баг.
>
Сначала найди релевантные куски кода. Затем проследи поток данных. Затем определи вероятные причины. Затем порекомендуй фикс.
>
Вот баг: [описание] Вот код: [код]
Reasoning-модель:
>
Помоги найти этот баг.
>
Симптомы: [описание] Релевантный код: [код] Что я уже пробовал: [список]
Reasoning-модель пройдёт по багу системно без подпорок. Часто поймает проблему быстрее, чем связка «быстрая модель + CoT», потому что её внутреннее рассуждение действительно глубже.
Пример 2: стратегическое решение
Быстрая модель:
>
Ты старший стратегический консультант. Я думаю, запускать ли продукт X. Примени фреймворк [название]. Сначала, … [длинный структурированный промпт]
Reasoning-модель:
>
Думаю, запускать ли продукт X. Контекст: - Мы компания на 50 человек с $5M ARR. - Продукт строить два квартала. - Смежен, но не напрямую конкурирует с основным продуктом. - Двое из топ-10 клиентов просили его. - Команда уже перегружена.
>
Помоги продумать. Возражай против слабых аргументов. Скажи, чего я не учитываю.
Reasoning-модель из минималистичного промпта выдаст более глубокий и тонкий анализ, чем из переобвешанного. Она, скорее всего, поднимет соображения, которые вы не подумали упомянуть, и заметит противоречия в том, что вы сказали.
Пример 3: сложный анализ кода
Быстрая модель:
>
Проанализируй этот код на проблемы с производительностью. Думай по шагам. Сначала найди структуры данных, затем проследи сложность алгоритма, затем укажи конкретные bottleneck-и. [код]
Reasoning-модель:
>
Что в этом коде медленное? Сейчас он выполняется ~3 секунды на типичном входе; хотелось бы под 500 мс.
>
[код]
Reasoning-модель проанализирует сложность, найдёт bottleneck-и, предложит фиксы, часто посоветует, как замерять — без явных лесов.
Подвохи специфические для reasoning-моделей
Короткий список того, что ловит даже опытных пользователей:
Задержка. Reasoning-модели могут выдавать ответ от 30 секунд до нескольких минут. Это реально ломает поток, если не быть к этому готовым. Закладывайтесь; не используйте их для разговорных задач.
Цена. Reasoning-модели обычно стоят в несколько раз дороже быстрых за запрос — иногда на порядок дороже, в зависимости от тарифа, провайдера и того, сколько токенов размышления модель сожжёт. По ценам API один сложный запрос может стоить заметную сумму. Используйте осознанно.
Проблема «обрезанного размышления». У reasoning-моделей есть бюджет токенов на внутреннее размышление. На очень сложных задачах модель может исчерпать бюджет до того, как придёт к уверенному выводу. Тогда ответ шаткий. Лечение: давайте «дружественный размышлению» промпт (чёткая, ограниченная задача), а на инструментах, где это возможно, увеличивайте бюджет thinking.
Reasoning-петли. Изредка reasoning-модель залипает — внутреннее размышление ходит по кругу, или она ушла по неверному пути и не возвращается. Симптомы: очень длинное thinking, затем оговоренный или странный ответ. Решение: перезапустите с слегка другой формулировкой.
Самоуверенность не там, где надо. Reasoning-модели бывают увереннее, чем должны, в вопросах, где внутренние рассуждения на самом деле не проверили ответ. На критически важных вопросах всегда спрашивайте: «насколько ты в этом уверен и что изменило бы ответ?»
Асимметрия стоимости по подзадачам. Reasoning-модель тратит вычисления примерно пропорционально сложности задачи. Лёгкие подвопросы дешёвые; сложные дорогие. Имейте в виду: попросив модель сделать пять сложных вещей в одном промпте, можно тихо потратить заметно больше вычислений, чем ожидалось.
Гибридный паттерн, который часто работает лучше всего
Для многих реальных процессов правильный паттерн — быстрая модель + reasoning-модель в связке:
- Быстрая модель, чтобы оценить рамки, исследовать, провести брейншторм. Быстрый обмен репликами. Уточнить вопрос.
- Reasoning-модель, чтобы прожать 1–3 самых сложных подвопроса, выскочивших из исследования.
- Быстрая модель, чтобы перевести вывод reasoning-модели в нужную форму (слайды, email, документ).
Этот паттерн держит задержку управляемой, расходы предсказуемыми и использует каждый инструмент по сильной стороне.
Проработанный пример: задача анализа рынка.
- Быстрая модель (Claude / GPT): «Хочу понять рынок X. Помоги задать рамки анализа: на что смотреть, какие нужны данные, какие вопросы важны?»
- Reasoning-модель (o3 / Claude Thinking): «С учётом данных, которые я собрал, что это означает для [конкретный стратегический вопрос]? Жёстко продави рассуждение».
- Быстрая модель: «Теперь помоги превратить это в одностраничный бриф для нашего руководства».
Три инструмента, каждый под то, в чём он лучше. Общая цена и время ниже, чем если просить reasoning-модель сделать все три шага; качество выше, чем если просить быструю модель сделать все три.
Несколько практических привычек
Каждый раз явно решайте, заслуживает ли задача reasoning-модели. По умолчанию — быстрая; апгрейд только когда задача его оправдывает.
Держите две вкладки. ChatGPT или Claude с быстрой моделью в одной; тот же продукт с reasoning-моделью в другой. Удобное переключение без путаницы.
Следите за затратами на reasoning-модели. Через мониторинг тарифа или API-биллинг — почувствуйте свой месячный счёт за reasoning. Подстраивайте использование.
Замечайте моменты, когда раньше бы не взяли её. По мере роста уровня вы будете ловить себя на том, что тянетесь за быстрой моделью на задаче, где reasoning-модель решила бы лучше. Накачивайте мышцу паузы.
Перепромптовывайте минимально. Инстинкт после слабого ответа reasoning-модели — расширить промпт. Сначала попробуйте обратное: более короткую, более простую версию того же промпта. Reasoning-моделям иногда мешает избыточная помощь сложными промптами.
Главная мысль
Reasoning-модели — это не быстрые модели с лишними шагами. Они вознаграждают минимальные, прямые промпты; наказывают тяжёлые леса; долго работают; стоят дороже; и на сложных задачах дают радикально лучшие ответы.
Используйте их осознанно, промптуйте просто и перестаньте применять к ним паттерны для быстрых моделей. Связка быстрой и reasoning-моделей — каждая под то, в чём она лучшая — самый мощный рабочий процесс с AI, доступный в 2026, и разрыв между теми, кто эту разницу освоил, и теми, кто нет, продолжает расти.