раздел 10 · подстраница 1

Режимы мышления

Claude умеет "думать вслух" - выделять токены на внутренние рассуждения перед ответом. Это extended thinking. Включается ключевыми словами в промпте. Стоит токенов, но иногда экономит часы.

Концепция

Когда Claude отвечает сразу - он генерирует токены ответа подряд. Когда включён thinking - сначала выделяет внутренний буфер на размышления (вы их не видите в ответе, но они есть), и только потом пишет финальный ответ.

В Claude Code это управляется ключевыми словами в вашем промпте.

Слова-триггеры

| Триггер | Бюджет thinking-токенов | | --- | --- | | think | минимальный, около 4k | | think hard | средний, около 10k | | think harder / think really hard | большой, около 30k | | ultrathink | максимальный, около 60k+ |

Это не публичная контрактная спецификация - цифры приблизительные, могут меняться от версии к версии. Но порядок такой.

Триггер просто пишется внутри промпта:

> think hard - какой самый чистый способ замигрировать этот код
  с callbacks на async/await, сохранив обратную совместимость?

Когда стоит использовать

Нетривиальный баг

Баг, который не сводится к "поменяй одну строку". Например - race condition, утечка памяти, странное поведение под нагрузкой.

> ultrathink - вот баг: в проде 1 из 1000 запросов возвращает 500.
  В логах - попадание в catch без stacktrace. Я приложил код handler'а
  и middleware-цепочку. Найди гипотезы и план диагностики.

Архитектурное решение

Развилка, после которой переделывать сложно - выбор стэка, схема БД, разделение модулей.

> think hard - проектирую event-sourcing для биллинга. Вот текущая
  схема (приложил). Подумай, как лучше: events в Kafka + read model
  в Postgres, или events в той же Postgres через outbox pattern.
  Сравни по сложности, fault-tolerance, observability.

Сложный рефакторинг

Изменение, после которого может всё развалиться, если не предусмотреть зависимости.

Дебаг чужого кода

Незнакомый репо, нужно понять, что происходит. Думающий режим помогает Claude не потеряться в файлах.

Когда НЕ нужно

  • Рутина: "добавь поле в API", "напиши тест на эту функцию", "перенеси из A в B".
  • Известные паттерны: "сделай по-нашему как обычно". Думать не о чем.
  • Простой Q&A по докам.
  • Быстрые правки в одну-две строки.

Думающий режим стоит токенов и времени. На банальных задачах вы переплачиваете без пользы.

Скрытый эффект - больше токенов на ответ тоже

Когда вы включаете thinking, Claude обычно ещё и пишет более развёрнутый финальный ответ. Это плюс, если вам нужно объяснение, но минус если хотелось коротко.

Антипаттерны

  • Лепить ultrathink в каждый промпт "на всякий случай". Платите за думанье, которое не нужно.
  • Думающий режим без чёткого вопроса. Если задача размыта - thinking не спасёт. Сначала сформулируйте.
  • Использовать think на Haiku-модели. Эта модель не оптимизирована под extended thinking, эффект минимальный.

Пример сравнения

Простой промпт:

> почему этот код падает?

С thinking:

> think hard - почему этот код падает?
  Условия: запускается в Docker, лимит памяти 256MB,
  падение случается через 30 минут работы.

Второй ответ будет содержать гипотезы (утечка, OOM, GC behavior), план проверки и приоритезацию. Первый - может выдать сразу "ставь try/catch".

Полезные ссылки