Когда вы работаете с Claude над производственной системой — заказами, расчётами, материалами — у вас под рукой сразу несколько режимов работы модели. Они называются похоже, легко путаются, и каждый решает свою задачу. Эта статья раскладывает их по полочкам и показывает, как встроить результаты Research в работу с Claude Code.
Есть три разные вещи, которые часто называют одним словом «думать дольше», но это не одно и то же.
Research (исследовательский режим) в Claude.ai — Claude сам ходит по сети, ищет источники, читает их, сравнивает и собирает развёрнутый отчёт. На один запрос уходит от 5 до 45 минут — зависит от глубины. Это отдельный инструмент: вы включаете его прямо в интерфейсе Claude.ai галочкой Research рядом с полем ввода. Подходит, когда нужно сравнить технологии, разобраться в незнакомой теме, проверить факт по нескольким источникам.
Extended thinking (расширенное размышление) — модель явно строит цепочку рассуждений до того, как отвечать. Видно, как она «думает вслух» в отдельном блоке перед ответом. Этот режим есть у Sonnet 4.6 и Haiku 4.5: вы выбираете уровень усилия, и модель тратит больше или меньше «токенов на размышления» перед финальным текстом.
Adaptive thinking (адаптивное размышление) — у Opus 4.7 и Sonnet 4.6. Здесь модель сама решает, нужно ли «подумать дольше», по сложности задачи. На простой вопрос ответит сразу, на сложный — сначала развернёт цепочку рассуждений. Вам не нужно угадывать уровень.
В Claude Code Desktop уровень усилия выбирается из
выпадающего списка прямо рядом с моделью в интерфейсе. У всех моделей
доступны low / medium / high; у
Opus добавляются xhigh и max. Это не slash-команда
в чате, а настройка модели — выбираете один раз и работаете.
В Research adaptive/extended thinking включается автоматически: модель под капотом думает дольше там, где надо, отдельно настраивать ничего не надо.
Главные уязвимости Research — это confirmation bias (подтверждение того, во что уже верите) и cherry-picking (модель находит источники, которые поддерживают вашу гипотезу, и игнорирует противоположные). Если спросить «почему JDBI лучше Exposed», получите статью про то, почему JDBI лучше Exposed — даже если в реальности всё сложнее.
Контрмеры — простые, их шесть.
Нейтральная формулировка. Не «почему лучше X», а «сравните X и Y по таким-то критериям». Перечислите критерии явно: производительность, поддержка типов PostgreSQL, удобство тестирования, активность сообщества, совместимость с Ktor. Чем конкретнее критерии, тем меньше места для подгона.
Цитаты и источники сначала, выводы потом. Структура промпта: «найди 5–7 источников, по каждому приведи 1–2 прямые цитаты со ссылкой, и только потом синтезируй выводы». Так модель сначала кладёт на стол материал, и вы сами видите, на чём построен вывод. Если синтез идёт первым — проверить нечего.
Противоположная точка зрения. Прямо просите: «покажи аргументы за и против», «где источники расходятся», «кто и почему выбирает другое решение». Это вынуждает модель искать не только подтверждения.
Приоритет первичных источников. Документация, официальные публикации, стандарты, исходники — выше, чем блоги и статьи на Medium. Так и пишите в промпте: «приоритет — официальная документация и release notes; блоги и статьи — только во вторую очередь и с пометкой».
Скажите прямо: не выдумывай. «Если данных нет — напиши “нет данных”, а не правдоподобное предположение». Без этой фразы модель в спорных местах подставит что-нибудь похожее на правду — это и есть галлюцинация. С фразой — чаще честно скажет, что не нашла.
Перепроверка критичных фактов. Версия библиотеки, цифра производительности, цитата из стандарта — копируете в обычный чат другой формулировкой и просите проверить. Две независимые проверки сильно снижают шанс пропустить ошибку.
Research-отчёт сам по себе — это просто длинный текст в Claude.ai.
Чтобы он стал полезным в работе над кодом, его надо положить в
репозиторий проекта как обычный markdown-файл. Это рекомендованный
паттерн (Anthropic, статьи про CLAUDE.md): любой файл в
проекте можно подтянуть в чат с Claude Code через @-ссылку,
и он использует его как контекст.
Конвенция структуры в вашем проекте:
project-root/
CLAUDE.md
research/
2026-04-27_jdbi-vs-exposed.md
2026-05-03_postgres-bin-packing.md
Папка research/ рядом с CLAUDE.md, имена
файлов начинаются с даты в формате YYYY-MM-DD и короткого
тега темы. Дата в имени важна: через полгода вы откроете папку и
сразу увидите, что было раньше, а что позже.
Шаблон файла отчёта — четыре секции, всегда одинаковые:
# <тема одной строкой>
**Дата:** 2026-MM-DD
**Модель:** Claude Opus 4.7 (Research mode)
## Промпт
> <запрос целиком, как ты его отправил>
## Ключевые выводы
- ...
## Источники
1. [Заголовок](URL) — что взяли отсюда
2. ...
## Что делать дальше в коде
- ...
Зачем именно такая структура.
Промпт сверху. Через полгода вы открываете файл и сразу видите, откуда взялся отчёт. Можно повторить запрос с уточнениями — версии библиотек обновились, появились новые источники — и получить свежую версию.
Источники с прямыми ссылками. Если выводы вызывают сомнения, у вас есть откуда перепроверить. Без ссылок отчёт — просто мнение модели, его невозможно ни подтвердить, ни опровергнуть.
«Что делать дальше в коде». Это мост к Claude Code. В чате с Claude Code вы пишете что-то вроде:
Прочитай @research/2026-04-27_jdbi-vs-exposed.md, секцию
«Что делать дальше в коде». Применим эти выводы к OrderRepository:
сейчас там сырые JDBC-запросы, перепиши на JDBI согласно отчёту.
Claude Code подтянет файл, прочитает рекомендации и применит их к
OrderRepository. Без файла-моста вам пришлось бы каждый
раз пересказывать выводы Research своими словами — а так контекст
лежит в репозитории навсегда.
Research — мощный, но медленный и шумный инструмент. Не на каждый вопрос его стоит звать.
Простые вопросы. «Как в Kotlin сделать data class с дефолтным значением поля» — обычный чат или прямо Claude Code в редакторе. Research потратит 10 минут на то, что в чате решается за 10 секунд.
Вопросы про сам код проекта. «Почему
OrderCalculationService возвращает ноль для этого
заказа», «где вычисляется markupMaterialsPct», «что
проверяет JwtFilterTest» — это работа Claude Code. У
него есть доступ к вашему репозиторию, у Research нет. Research
ничего не знает о вашем OrderService и
IntegrationTestBase, он умеет только читать публичные
источники.
Срочные задачи. Research медленный по своей природе: он реально читает несколько источников. Если ответ нужен прямо сейчас — обычный чат с adaptive thinking даст приемлемый результат за секунды, а Research всё равно не успеет.
Простое правило: Research зовёте, когда тема новая, спорная или уходит за пределы вашего проекта — и когда вы готовы подождать. Для всего остального — обычный чат и Claude Code.