Plan Mode в Claude Code: инструкция по четырём этапам Anthropic

Дополнительные материалы доступны в документации Ailoot.

Что такое Plan Mode и почему одного режима планирования недостаточно?#

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

В документации Anthropic режим планирования описан так:

Главное здесь — новый порядок работы: сначала согласовать направление, затем выполнять задачу. Это не просто косметическое переключение. Если попросить добавить вход через Google в обычном режиме, Claude быстро начнёт писать код, хотя ещё неясно, какие именно части проекта нужно менять. В Plan Mode тот же запрос сначала превращается в план, который можно прочитать и скорректировать до начала правок.

У режима есть ограничение: план остаётся в текущем диалоге. После закрытия окна к нему нельзя вернуться, а историю изменений и удобную передачу следующему агенту он сам по себе не обеспечивает. Для крупных задач — например, рефакторинга десятков файлов или перехода на другую базу данных — одного диалога может оказаться мало: по мере роста переписки модели сложнее удерживать ранние решения в контексте.

Для продолжительной работы план можно сохранять в каталоге plans/ репозитория. Например, файл plans/2026-05-21-google-oauth.md может содержать этапы и флажки выполнения, чтобы к нему можно было вернуться в новой сессии. Такой подход помогает заранее подготовить нужные материалы и правила контекста.

Как включить Plan Mode в Claude Code#

Самый быстрый способ в открытой сессии — воспользоваться клавиатурой:

Shift+Tab           # циклически переключает режимы: default → acceptEdits → plan

После двух нажатий внизу терминала появится надпись ⏸ plan mode on. Третье нажатие вернёт прежний режим. Это удобно, когда уже начатая задача разрастается и перед дальнейшими действиями стоит сначала составить план.

Другой вариант — добавить /plan перед отдельным запросом:

/plan напиши план миграции базы с MySQL на Postgres

Так можно отправить один запрос в Plan Mode, не меняя режим всей сессии, например если для остальных задач включено автоматическое принятие изменений.

Третий способ — включить режим при запуске Claude Code:

claude --permission-mode plan

Используйте его, если заранее знаете, что предстоит задача, требующая предварительного планирования, например масштабный рефакторинг или миграция.

Четвёртый способ — задать режим по умолчанию в файле .claude/settings.json проекта:

{
  "permissions": {
    "defaultMode": "plan"
  }
}

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

Ещё одна полезная команда — Ctrl+G: она открывает план в текстовом редакторе. Если нужно изменить несколько формулировок или добавить ограничение, внесите правки, сохраните файл, и Claude продолжит работу с обновлённым вариантом.

Какие четыре этапа Anthropic рекомендует для работы с Plan Mode?#

В статьях процесс иногда сокращают до трёх этапов — Explore, Plan и Execute — или двух: Plan и Implement. В руководстве Anthropic выделены четыре этапа. Отдельный Commit помогает завершить работу: зафиксировать изменения и подготовить Pull Request, вместо того чтобы откладывать это на неопределённое время.

На каждом этапе нужны отдельные запросы. Для Explore попросите прочитать /src/auth и разобраться с обработкой сессий и входа. Для Plan — перечислить изменения, необходимые для добавления Google OAuth, и оформить план. Для Implement — выполнить утверждённый план, написать тесты, запустить набор проверок и устранить найденные сбои. Для Commit — создать содержательный коммит и открыть Pull Request.

В Plan Mode Claude может выполнять исследовательские действия: читать файлы, изучать структуру проекта, искать текст и запускать команды оболочки. Например, можно проверить историю через git log или просмотреть тесты. Редактирование и другие операции, меняющие файлы, в этом режиме заблокированы.

Как оценить план Claude и решить, стоит ли его одобрять?#

После подготовки плана Claude предлагает варианты продолжения:

• Approve and start in auto mode
• Approve and accept edits
• Approve and review each edit manually
• Keep planning with feedback
• Refine with Ultraplan (browser review)

Перед одобрением важно внимательно прочитать предложенные действия: автоматическое подтверждение может привести к необходимости отменять уже сделанные изменения. Не торопитесь переходить к реализации, если объём или последствия правок пока не ясны.

Проверьте план по семи признакам:

1. Указаны конкретные файлы. Вместо «обновлю авторизацию» в плане должны быть, например, src/auth/login.ts:42-58, новый src/auth/oauth-callback.ts и изменение src/auth/session.ts:103.
2. Определён порядок действий. Работа разделена на этапы, а не сведена к расплывчатому обещанию сделать всё сразу.
3. Названы внешние зависимости. Если требуется библиотека или переменная окружения, это явно указано.
4. Описаны риски. План отмечает возможные побочные эффекты и проверки, которые помогут их обнаружить. Например, миграция может повлиять на существующие сессии.
5. Заданы критерии успеха. Например, тесты test/auth проходят, линтер не сообщает об ошибках, сервер разработки запускается.
6. Проверены предположения о проекте. Если Claude предлагает библиотеку Z, сверьте это с package.json: возможно, зависимость ещё не установлена.
7. Объём соответствует задаче. Если план для небольшой функции занимает 200 строк, разделите работу на более мелкие задачи.

Если план не прошёл проверку, можно выбрать один из трёх вариантов:

• Keep planning with feedback — напишите, что именно нужно исправить, и попросите обновить план.
• Ctrl+G — откройте план в редакторе, внесите изменения и сохраните; Claude продолжит с отредактированным текстом.
• Refine with Ultraplan — перенесите план в браузерный режим Claude Code on the web, проверьте отдельные разделы и оставьте комментарии; после этого выполнение можно продолжить локально или в облаке.

Если реализация пошла по неверному пути, вернитесь к планированию и пересмотрите последовательность действий. Остановка на этом этапе помогает избежать накопления исправлений и лишних откатов.

Plan Mode и каталог plans/ для работы с длинным контекстом#

Plan Mode — это режим Claude Code, а plans/ — способ сохранять результаты планирования в проекте. Если вести длинную задачу только в одном диалоге, его контекст постепенно заполняется новыми решениями, обсуждением ошибок и дополнительными вопросами. В результате Claude может хуже учитывать ранние договорённости или смешивать разные части задачи.

Полезный принцип — одна задача на один диалог.

Можно организовать работу так:

1. Диалог 1 — подготовка плана. Включите Plan Mode, опишите задачу, получите план, сохраните его как plans/2026-05-21-feature-name.md, затем завершите диалог.
2. Диалог 2 — разделение на этапы. Начните новую сессию и попросите разделить содержимое plans/2026-05-21-feature-name.md на этапы. Сохраните обновлённый файл.
3. Диалог 3 — выполнение этапа 1. В новой сессии попросите реализовать первый этап из плана и отмечать выполненные пункты флажками.
4. Диалог 4 — выполнение этапа 2. Продолжите аналогично для следующего этапа.

При таком порядке каждый разговор начинается со свежего контекста. Новая сессия может не знать деталей предыдущих обсуждений, зато сохранённый в plans/ документ содержит нужный план. Его смогут использовать новая сессия, субагент или запуск через /goal.

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

Как организовать автономную работу Claude с Plan Mode и /goal?#

Команда /goal позволяет задать условие, по которому сессия должна остановиться. После каждого хода небольшая модель-проверяющий анализирует транскрипт и решает, выполнено ли условие. Если нет, работа продолжается. Сам оценщик не запускает инструменты, а только читает переписку.

Для команды используется такой формат:

/goal все тесты в test/auth проходят и линт чист, или стоп через 20 ходов

Условие может содержать до 4000 символов. В одной сессии задаётся один goal. После каждой итерации проверяющая модель Haiku оценивает, достигнут ли результат, и при необходимости разрешает следующий ход.

Для отключения или сброса доступны варианты: /goal stop, /goal off, /goal reset, /goal none, /goal cancel.

Сочетать /goal с Plan Mode можно следующим образом:

1. Включите Plan Mode двойным нажатием Shift+Tab.
2. Попросите подготовить план миграции MySQL на Postgres и сохранить его в plans/2026-05-21-postgres-migration.md, разделив работу на этапы и задав критерии для каждого.
3. Прочитайте план, внесите нужные поправки и одобрите его.
4. Выйдите из Plan Mode ещё одним нажатием Shift+Tab.
5. Задайте goal: выполнить все этапы из plans/2026-05-21-postgres-migration.md, отметить флажки и добиться успешного прохождения тестов либо остановиться через 50 ходов.
6. После этого можно оставить задачу выполняться автономно.

Позже проверьте итоговый статус: /goal сообщает о завершении условия либо об остановке после заданного числа ходов и показывает историю действий.

Чтобы автономная задача оставалась управляемой, соблюдайте три правила:

Правило 1: задайте измеримый итог. Формулировка «сделай красиво» не задаёт критерия завершения. Укажите, например, что npm test и npm run lint должны завершаться с кодом 0, а в CHANGELOG.md должна появиться запись.

Правило 2: укажите способ проверки. Критерий должен опираться на команду, файл или эндпоинт. Вместо «всё работает» задайте конкретную проверку, например: curl localhost:3000/api/users возвращает 200.

Правило 3: ограничьте продолжительность. Добавьте в условие предельное число ходов или времени. В документации Anthropic приведён пример с ограничением после 20 ходов:

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

Как применить четырёхшаговый цикл при работе в Plan Mode?#

Частая ошибка при работе с Plan Mode — сразу спрашивать: «Как это исправить?» Claude может предложить быстрый ответ, который не устраняет причину или усугубляет ситуацию. Четырёхшаговая последовательность помогает сначала разобраться в наблюдаемых фактах, а уже после этого переходить к решению.

Выполняйте её по порядку в одной сессии Plan Mode.

Шаг 1. Зафиксируйте факты, не предлагая решения.

Промпт: «Наблюдается следующая проблема: [описание симптома]. Сейчас установи только факты. Не предлагай решений, идей или советов. Перечисли, что именно наблюдается, какие шаги воспроизводят проблему, какие данные доступны и каких данных не хватает. Стоп-условие: не предлагать исправления, только описать диагноз».

Так Claude сначала формулирует известное и неизвестное, не переходя сразу к способу исправления.

Шаг 2. Найдите варианты и подтверждающие примеры.

Промпт: «Теперь, когда диагноз сформулирован, найди официальные материалы и примеры решения аналогичных проблем. Рассмотри не менее трёх разных подходов. Для каждого укажи ссылку на первоисточник, краткое описание, преимущества и недостатки применительно к нашей задаче».

Этот этап помогает опираться на проверяемые материалы, а не только на предположение модели. Используйте официальные документы производителя или организации, отвечающей за соответствующий продукт.

Шаг 3. Подготовьте подробный план с рисками.

Промпт: «Выбери наиболее подходящий подтверждённый вариант и составь детальный план. Укажи конкретные файлы для изменения, что нужно добавить или удалить, какие тесты написать, что может сломаться и какие риски проявятся на два-три шага вперёд».

На этом этапе план опирается на установленные факты и проверенные варианты, а не на неподтверждённые догадки.

Шаг 4. Проверьте план на неподтверждённые предположения.

Промпт: «Выполни обязательную самопроверку плана. Найди утверждения, которые не подтверждаются кодом проекта, официальной документацией или материалами из шага 2. Отметь их и скорректируй план».

Финальная проверка помогает выявить детали, которые выглядят убедительно, но пока не подтверждены. После неё план можно прочитать и одобрить.

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

Пять шаблонов промптов для Plan Mode#

Шаблон 1. Рефакторинг модуля.

Включаю Plan Mode. Задача: рефакторинг модуля {название-модуля}.

Шаг 1: Изучи текущую структуру модуля {путь-к-модулю}. Опиши:
- какие файлы входят в модуль
- какие внешние зависимости используются
- где повторяется код
- какие функции слишком сложны

Шаг 2: Найди официальные материалы и примеры рефакторинга похожих модулей.
Используй первоисточники Anthropic или документацию соответствующего фреймворка.

Шаг 3: Составь план рефакторинга в plans/YYYY-MM-DD-refactor-{module}.md:
- какие файлы нужно переименовать
- какие функции вынести в отдельные модули
- какие тесты сохранить и какие изменить
- какие пользовательские сценарии могут пострадать

Шаг 4: Проверь план на неподтверждённые предположения.
Подтверди их или исключи.

Шаблон 2. Миграция базы данных.

Включаю Plan Mode. Задача: миграция БД с {старая} на {новая}.

Шаг 1: Изучи текущую схему БД через {команда-чтения-схемы}. Опиши:
- какие таблицы есть и каков их размер
- какие связи, индексы и ограничения заданы
- где находятся файлы миграций
- какие данные критичны

Шаг 2: Изучи официальные руководства по миграции {старая → новая}.
Рассмотри не менее трёх подходов, например pg_dump, dual-write и blue-green.
Для каждого укажи преимущества и риски для нашего объёма данных.

Шаг 3: Составь план миграции в plans/YYYY-MM-DD-db-migration.md:
- этапы: резервная копия, перенос, проверка, переключение
- критерии успеха каждого этапа
- порядок отката при сбое
- ожидается ли простой

Шаг 4: Проверь, подтверждены ли числа документацией.
Убедись, что шаги можно проверить в среде разработки.

Шаблон 3. Добавление новой функции.

Включаю Plan Mode. Задача: добавить в проект функцию {описание}.

Шаг 1: Изучи, как устроены похожие функции в проекте.
Проверь:
- {файл-1}
- {файл-2}
- используемые архитектурные шаблоны
- тесты для аналогичных функций

Шаг 2: Изучи официальные примеры реализации этой функции
в проектах с похожей архитектурой. Рассмотри не менее двух подходов.

Шаг 3: Составь план в plans/YYYY-MM-DD-feature-{name}.md:
- новые файлы
- изменяемые файлы с конкретными строками
- порядок реализации
- необходимые тесты
- правила проекта, которые следует внести в CLAUDE.md для будущих сессий

Шаг 4: Проверь соответствие плана архитектуре проекта.
Убедись, что он не предполагает наличия ещё не установленных библиотек.

Шаблон 4. Написание тестов.

Включаю Plan Mode. Задача: покрыть тестами модуль {название}.

Шаг 1: Изучи модуль {путь}. Определи:
- публичные функции и их сигнатуры
- внутренние функции, которые не нужно тестировать напрямую как детали реализации
- крайние случаи: пустой ввод, ошибки, конкурентный доступ

Шаг 2: Изучи официальные примеры тестов для похожего класса задач
в документации используемого фреймворка.

Шаг 3: Составь план тестов в plans/YYYY-MM-DD-tests-{module}.md:
- тесты для каждой публичной функции
- необходимые моки
- необходимые фикстуры
- выбранный стиль проверок (assertions)

Шаг 4: Проверь, что тесты проверяют поведение, а не детали реализации.
Убедись, что учтены крайние случаи.

Шаблон 5. Диагностика сложной ошибки.

Включаю Plan Mode. Задача: выяснить причину ошибки {описание-симптома}.

Шаг 1: УСТАНОВИТЬ ФАКТЫ. Решения и идеи запрещены. Зафиксируй только:
- точное сообщение об ошибке
- воспроизводимые шаги
- доступные данные: логи, трассировки, версии библиотек
- недостающие данные, которые нужно собрать

Шаг 2: Найди официальные материалы об этой ошибке.
Для каждого источника укажи ссылку и краткое описание возможного решения.

Шаг 3: Составь план диагностики в plans/YYYY-MM-DD-bug-{name}.md:
- гипотезы в порядке вероятности
- команды или скрипты для проверки каждой гипотезы
- ожидаемый результат каждой проверки

Шаг 4: Проверь, не основаны ли гипотезы на догадках.
Свяжи каждую из них с фактами шага 1.

Скопируйте нужный шаблон, подставьте значения вместо {параметров} и отправьте его в Claude Code в Plan Mode. Сохраните полученный рабочий план в plans/, проверьте его и только после этого переходите к реализации.

Когда выбрать Plan Mode, а когда обычный режим?#

Отдельный план можно пропустить, когда настоящий diff мал, понятен и мало рискован. Планируйте поиск подхода и согласование опасных межкомпонентных изменений. Известные имена файлов и краткое описание цели не устраняют риски миграции, авторизации и целостности данных.

До выбора режима выясните, понятны ли подход, последствия и проверка. Небольшую локальную безопасную правку с очевидной проверкой можно делать напрямую. При неопределённости, незнакомом коде, миграции, авторизации или координации компонентов нужен план, даже если уже известны все три-пять файлов.

Как связать Plan Mode, CLAUDE.md и субагентов?#

Claude Code читает CLAUDE.md в начале сессии, в том числе при планировании. Если в файле указано, например, что даты нельзя записывать прямо в код и их следует получать из базы данных, Claude сможет учесть это правило при подготовке плана. Без такого указания он может предложить неподходящий вариант.

Работу можно разделить на три уровня.

Уровень 1. Правила проекта в CLAUDE.md.

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

Уровень 2. Планирование с учётом этих правил.

Если попросить добавить OAuth, Claude сможет прочитать правила проекта, учесть хранение токенов в Redis вместо базы данных и отразить это в плане.

Уровень 3. Распределение этапов между субагентами.

Если план разбит на этапы, каждый из них можно поручить отдельному субагенту. Он работает в собственном контекстном окне; общий файл в plans/ помогает агентам видеть последовательность действий и отмечать выполненные пункты.

Семь ошибок, из-за которых Plan Mode работает хуже#

Ошибка 1. План существует только в диалоге.

Признак: после закрытия окна к плану уже нельзя вернуться. Сохраняйте его в файл проекта, например plans/YYYY-MM-DD-feature-name.md. Диалог нужен для работы, файл — для дальнейшего использования.

Ошибка 2. Несколько разных задач в одной сессии.

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

Ошибка 3. Длинный план без этапов.

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

Ошибка 4. Нет проверки официальных материалов.

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

Ошибка 5. Запрос решения до диагностики.

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

Ошибка 6. План не проверен на предположения.

В нём могут оказаться несуществующая библиотека, неподдерживаемый API или неверная версия. Сверьте такие сведения с кодом и официальными документами до реализации.

Ошибка 7. Для /goal задано расплывчатое условие.

Условие «сделай хорошо» нельзя проверить. Укажите конкретный критерий, команду для проверки и предел, например or stop after N turns.

Что предпринять после первого знакомства с Plan Mode?#

Попробуйте три шага, переходя от простого к более сложному.

Шаг 1. Подготовьте CLAUDE.md.

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

Шаг 2. Создайте в репозитории каталог plans/.

Сохраните в нём план для каждой отдельной задачи, используя формат имени YYYY-MM-DD-feature-name.md. Так можно возвращаться к решениям и продолжать работу в новой сессии.

Шаг 3. Испытайте /goal на одной задаче.

Выберите задачу, которую обычно выполняете около 30–40 минут. Включите Plan Mode, подготовьте план и сохраните его в plans/. Затем выйдите из режима планирования и задайте условие, например: выполнить этапы из plans/file.md, добиться прохождения тестов или остановиться через 30 ходов. После запуска проверьте итог и историю выполнения.

Этих действий достаточно, чтобы начать. Добавляйте новые этапы постепенно: сначала опишите правила проекта, затем сохраняйте планы, а после этого проверьте автономный режим на ограниченной задаче.

Познакомьтесь с Ailoot.