Четыре промпта для Claude Code: как проверять решения до изменений в коде

Что называют ИИ-подхалимством в Claude Code#

В психологии для чрезмерного стремления угодить давно существует термин «сикофантия». Так называют поведение, при котором собеседник говорит то, что от него хотят услышать, чтобы поддержать ход разговора. С развитием больших языковых моделей этот термин стали применять и к ИИ. В одном из официальных разборов Anthropic признала, что модель может предпочесть быстрое согласие точности.

В программировании это может выглядеть так: вы пишете Claude Code: «исправь эту ошибку в authMiddleware, перестали работать magic-link». Модель не уточняет детали, не просит журнал ошибок и не спрашивает версию библиотеки. Она сразу предлагает решение, поскольку нацелена быстро помочь. Ответ выглядит убедительно: импорты, обработка ошибок, комментарии. Но модель могла неверно понять задачу и заполнить пробелы в исходных данных догадками.

Проблема может быть не в Claude, а в формулировке запроса. Вопрос «как исправить?» заранее предполагает, что способ исправления уже известен. Модель может принять это предположение и предложить решение, хотя причина кроется в архитектуре, версии библиотеки или другом дефекте, который лишь проявляется описанным симптомом.

Проверить, готова ли задача к решению, можно простым вопросом: «Что именно сломалось?» Если на него нельзя ответить тремя предложениями, сначала нужно разобраться в причине. Диагностика предшествует исправлению. С неё и начинается четырёхэтапный процесс.

Пример: восемь отменённых коммитов за час#

Вот пример из апреля 2026 года. В src/lib/auth/ разбиралась проблема с авторизацией по magic-link: токены проходили проверку, но сессия не сохранялась. Пользователь переходил по ссылке из письма на сайт, а через пять секунд снова попадал на /login.

В Claude Code был введён запрос: «после magic-link сессия не сохраняется; проверь src/lib/auth/ и исправь». Claude задал три уточняющих вопроса, а затем предложил план: обновить обработчик callback, переписать сериализатор JWT, добавить явное сохранение в Redis и устранить race condition в middleware. План выглядел правдоподобно и был одобрен.

Спустя 18 минут появился diff на 14 файлов, но magic-link так и не заработал. Одновременно перестал работать токен обновления, нарушился вход по паролю и возникла ошибка 500 в маршруте оплаты. Тесты тоже завершились с ошибками, поэтому изменения начали отменять.

Выполнили git reset --hard origin/main, отменив восемь коммитов. Час работы пропал. О том, как правильно отменять изменения в Claude Code и сохранять полезное, рассказано в руководстве по отмене изменений.

Затем код проверили вручную: открыли src/lib/auth/magic-link.ts:42, просмотрели журналы и проверили Redis. Через 20 минут причина обнаружилась: в set-cookie не было атрибута SameSite=lax. Safari удалял cookie при перенаправлении с домена письма обратно на сайт. JWT, Redis и middleware оказались ни при чём — требовалась одна строка.

При первоначальном запросе Claude не изучил журналы браузера и не располагал сведениями о Safari. Он предположил, что проблема с сохранением сессии связана с сериализацией, поскольку такой ответ часто встречается в обучающих данных. Получилось статистически правдоподобное решение, которое не относилось к реальной причине.

Из этого примера следует практическое правило: вместо вопроса «как исправить?» попросите «установить факты». Далее этот подход оформляется в последовательный процесс.

Почему возникает склонность соглашаться#

В инженерном постмортеме от апреля Anthropic отдельно описала, как ошибка кеширования в Claude Code приводила к тому, что модель теряла ход рассуждений между ответами.

Если модель теряет часть контекста рассуждений, возрастает риск, что она попытается восстановить ответ по знакомому шаблону. Поэтому полезно требовать, чтобы предположения проверялись по фактам и источникам.

При работе с новой моделью не обязательно выбирать менее мощную версию или возвращаться к предыдущей. Вместо этого можно яснее задавать порядок работы: сначала проверить факты, затем предлагать решения. Подробнее о различиях рассказывает обзор Opus 4.8 в Claude Code.

Когда четыре шага оправданы#

Например, текст приветственного письма можно поправить сразу. Для добавления кнопки CTA на сайт подойдёт Plan Mode без полного цикла. Переход проекта с MySQL на Postgres требует всех четырёх шагов. Если ошибка 500 в рабочей среде не воспроизводится локально, начните с дополнительного этапа: подготовьте минимальный воспроизводимый пример.

Одна из частых ошибок — применять этот процесс к мелким задачам. Это замедляет работу и делает методику неудобной. Используйте её там, где цена ошибки выше времени на планирование.

Все четыре промпта выполняются в одной сессии Plan Mode. Если этот режим вам незнаком, сначала прочитайте руководство по Plan Mode в Claude Code.

Шаг 1. Запретите предлагать решения и попросите собрать факты#

Начните с самого важного: не позволяйте модели перескакивать сразу к исправлению. Используйте промпт:

Я столкнулся со следующей проблемой: [симптом].

Сейчас нужно установить факты. Не предлагай решений,
идей или советов. Заполни только эти пункты:
- что именно я наблюдаю (точная формулировка симптома)
- как воспроизвести проблему (минимальный сценарий)
- какие данные уже есть (логи, версии, окружение)
- каких данных не хватает (что нужно собрать дополнительно)

Строгое условие: не предлагай исправлений, а только
описывай диагностику. Если хочешь что-то предложить,
вместо этого задай мне вопрос.

Явный запрет помогает Claude не пропускать этап сбора сведений. Модель должна описать наблюдения, способ повторить проблему, известные данные и пробелы. Последний пункт может показать, что неизвестны версия библиотеки, содержание журналов или то, возникает ли проблема в рабочей среде. Эти пробелы определят следующий шаг.

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

Шаг 2. Ищите проверяемые примеры и источники#

Когда факты и диагноз собраны, попросите модель изучить похожие случаи:

Теперь, когда диагноз установлен, найди в интернете
примеры решений похожих проблем.

Найди как минимум 3 разных подхода. Для каждого укажи:
- ссылку на первоисточник (issue, статью или документацию)
- краткое описание подхода
- преимущества и недостатки для нашей ситуации
- известные ограничения и подводные камни

Не выдавай собственные знания за подтверждённые факты
без ссылки на источник. Если подходящих примеров нет,
скажи об этом прямо.

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

Модель может привести несуществующую или нерелевантную ссылку, например указать issue с подходящим номером, которое на деле посвящено другой проблеме. Чтобы снизить этот риск, в CLAUDE.md можно записать правило: «Перед цитированием открывай ссылку через WebFetch». Подробности есть в руководстве по настройке CLAUDE.md.

Шаг 3. Запишите подробный план с рисками#

В Plan Mode попросите оформить лучший подход из второго шага в план:

Возьми наиболее подходящий вариант из Шага 2 и запиши
подробный план в файл plans/YYYY-MM-DD-fix-[название].md:

- какие именно файлы изменяются (полные пути и номера строк)
- что добавляется и что удаляется
- какие тесты нужно написать и какие существующие
  тесты должны пройти
- какие риски могут проявиться через 2-3 шага
  (что может затронуть пользователей)
- как отменить изменения, если возникнет проблема

Оформи каждый шаг как чекбокс [ ]. План должен помещаться
на экран. Если он превышает 200 строк, раздели его на этапы.

В результате вместо временной записи в чате появляется отдельный документ. К нему можно вернуться через две недели, передать его другому агенту или использовать как основу для команды /goal. План в файле сохранится дольше переписки в Claude Code.

Особенно внимательно перечислите риски, которые могут проявиться через два-три шага. Такая проверка помогает выявить побочные эффекты, которые в обычном оптимистичном плане могли бы остаться незамеченными.

Шаг 4. Перечитайте план и проверьте его предположения#

Завершите процесс обязательной самопроверкой:

Теперь обязательно перепроверь свой план. Перечитай его
внимательно и честно.

Есть ли в нём утверждения, которые ты сделал без проверки:
- по коду, который прочитал;
- по документации, указанной в Шаге 2;
- по примерам из Шага 2?

Если есть, отметь их явно, уточни или удали.

Также проверь:
- не упомянуты ли библиотеки, которых ещё нет
  в package.json;
- не указаны ли переменные окружения, которые я не задавал;
- нет ли шагов, описанных общими словами вместо
  конкретных действий.

Такой запрос заставляет Claude повторно проверить ход рассуждений. По наблюдениям автора примерно на 50 циклах, на этом этапе исправлялись как минимум два-три пункта плана. Это были допущения, которые прошли незамеченными на третьем шаге.

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

Почему в цикле именно четыре шага#

Этот подход опирается на порядок работы, описанный Anthropic в официальной документации.

В документации рекомендована последовательность из четырёх фаз: Explore, Plan, Implement и Commit.

Четырёхэтапный цикл развивает фазу Plan, чтобы снизить риск поспешного согласия. Фаза разделяется на сбор фактов, изучение примеров, составление плана и его проверку. Затем подготовленный план можно использовать на этапах Implement и Commit.

Вот какие последствия возможны, если пропустить один из шагов:

Каждый этап нацелен на отдельную категорию ошибок. Если задача настолько проста, что можно обойтись двумя шагами, вероятно, ей вообще не нужен Plan Mode.

Как использовать plans/ и /goal#

Для работы с циклом понадобятся:

1. Включённый Plan Mode (двойное нажатие Shift+Tab в Claude Code).
2. Папка plans/ в репозитории для сохранения планов.
3. По желанию — команда /goal для автономного выполнения длительных планов.

После третьего шага можно сохранить план, например, в plans/2026-05-27-fix-magic-link.md, вместе с этапами и чекбоксами. Это позволит через неделю восстановить логику решения, а через несколько месяцев — сопоставить его с похожей задачей и повторно использовать подход. Папка plans/ может стать частью «второго мозга» проекта; подробнее об этом рассказано в руководстве о «втором мозге» в Claude Code.

Когда все четыре шага завершены и план утверждён, выйдите из Plan Mode и запустите /goal:

/goal выполнить все фазы из plans/2026-05-27-fix-magic-link.md,
все тесты в test/auth проходят, или стоп через 30 ходов

Для локальной сессии Claude Code оставьте терминал запущенным, компьютер бодрствующим, а сеть доступной. Не закрывайте ноутбук без явно настроенного поддерживаемого режима без сна. Вернувшись, проверьте историю: возможны завершение, лимит ходов, запрос разрешения или ошибка. Goal не гарантирует прогресса во время сна компьютера. Непроверенный план может направить расход на бесполезные попытки; подготовка помогает двигаться к заданной цели.

Если вы только начинаете пользоваться Claude Code, попробуйте процесс на ближайшей нетривиальной задаче — например, той, которая затрагивает три или более файлов либо связана с непонятным поведением. Возьмите приведённые промпты и добавьте детали своей задачи.

Если вы уже работаете в Plan Mode, создайте в репозитории папку plans/ и выберите формат имён вроде YYYY-MM-DD-feature-name.md. Со временем в ней накопятся планы и история решений проекта. Управление контекстом до составления промпта отдельно рассмотрено в руководстве по контекст-инжинирингу в Claude Code.

Если папка plans/ и Plan Mode уже используются, проверьте /goal на задаче, занимающей вручную 30–40 минут. Пройдите четыре шага, сохраните план, запустите команду и оставьте локальный терминал и компьютер бодрствующими. Для работы при выключенном компьютере сначала явно настройте удалённое или облачное исполнение и убедитесь, что задача действительно работает там.