# Plan Mode в Claude Code: инструкция по четырём этапам Anthropic > Узнайте, как использовать Plan Mode в Claude Code: переключение через Shift+Tab, четыре этапа работы, шаблоны промптов и настройка /goal для автономных задач. Source: https://ailoot.ai/blog/ru/claude-code-plan-mode/ Canonical: https://ailoot.ai/blog/ru/claude-code-plan-mode/ Language: ru Publisher: Ailoot (https://ailoot.ai/) Translation: guide-197 Revision: sha256-a02e92a5a14c84a2bd6be19601bce476ef6675cfe573d4a8f01563b76d34d507 Дополнительные материалы доступны в [документации Ailoot](https://ailoot.ai/docs/). ## Что такое Plan Mode и почему одного режима планирования недостаточно?
Главное Plan Mode в Claude Code позволяет изучать файлы и анализировать проект, а затем предлагать последовательность изменений. Код не меняется до вашего одобрения. Переключайте Shift+Tab до метки `plan` либо используйте `--permission-mode plan`. Число нажатий зависит от исходного режима. Он полезен при неясном подходе, незнакомом коде или значимом межкомпонентном либо операционном риске. Понятной малорисковой опечатке отдельное планирование обычно не требуется.
В обычном режиме Claude Code может сразу приступить к редактированию, и без внимательного контроля неожиданно затронуть много файлов. Plan Mode меняет порядок действий: сначала исследование и подготовка плана, затем ваше одобрение и только после этого внесение изменений. В документации Anthropic режим планирования описан так:

В режиме планирования Claude исследует проект и предлагает изменения, не применяя их. Он читает файлы, выполняет команды оболочки для изучения проекта и составляет план, но не редактирует код.

— Документация Anthropic, https://code.claude.com/docs/en/permission-modes
Главное здесь — новый порядок работы: сначала согласовать направление, затем выполнять задачу. Это не просто косметическое переключение. Если попросить добавить вход через Google в обычном режиме, Claude быстро начнёт писать код, хотя ещё неясно, какие именно части проекта нужно менять. В Plan Mode тот же запрос сначала превращается в план, который можно прочитать и скорректировать до начала правок. У режима есть ограничение: план остаётся в текущем диалоге. После закрытия окна к нему нельзя вернуться, а историю изменений и удобную передачу следующему агенту он сам по себе не обеспечивает. Для крупных задач — например, рефакторинга десятков файлов или перехода на другую базу данных — одного диалога может оказаться мало: по мере роста переписки модели сложнее удерживать ранние решения в контексте. Для продолжительной работы план можно сохранять в каталоге `plans/` репозитория. Например, файл `plans/2026-05-21-google-oauth.md` может содержать этапы и флажки выполнения, чтобы к нему можно было вернуться в новой сессии. Такой подход помогает заранее подготовить нужные материалы и правила контекста. ## Как включить Plan Mode в Claude Code
Главное Есть несколько способов перейти в Plan Mode: нажать Shift+Tab дважды, использовать префикс `/plan`, запустить Claude Code с параметром `--permission-mode plan` или задать `defaultMode` в `.claude/settings.json`. В активном состоянии внизу терминала отображается `⏸ plan mode on`.
Самый быстрый способ в открытой сессии — воспользоваться клавиатурой: ``` Shift+Tab # циклически переключает режимы: default → acceptEdits → plan ``` После двух нажатий внизу терминала появится надпись `⏸ plan mode on`. Третье нажатие вернёт прежний режим. Это удобно, когда уже начатая задача разрастается и перед дальнейшими действиями стоит сначала составить план. Другой вариант — добавить `/plan` перед отдельным запросом: ``` /plan напиши план миграции базы с MySQL на Postgres ``` Так можно отправить один запрос в Plan Mode, не меняя режим всей сессии, например если для остальных задач включено автоматическое принятие изменений. Третий способ — включить режим при запуске Claude Code: ```bash claude --permission-mode plan ``` Используйте его, если заранее знаете, что предстоит задача, требующая предварительного планирования, например масштабный рефакторинг или миграция. Четвёртый способ — задать режим по умолчанию в файле `.claude/settings.json` проекта: ```json { "permissions": { "defaultMode": "plan" } } ``` Это подходит командам, которые работают со сложной системой, где даже небольшая правка может повлиять на соседние модули. Тогда проектная настройка по умолчанию помогает избежать случайного редактирования. Ещё одна полезная команда — `Ctrl+G`: она открывает план в текстовом редакторе. Если нужно изменить несколько формулировок или добавить ограничение, внесите правки, сохраните файл, и Claude продолжит работу с обновлённым вариантом. ## Какие четыре этапа Anthropic рекомендует для работы с Plan Mode?
Главное В рекомендациях Anthropic описан процесс из четырёх этапов: Explore — изучить проект; Plan — подготовить план без изменений файлов; Implement — реализовать одобренный план; Commit — зафиксировать результат в коммите и подготовить Pull Request. Для этапов применяются разные режимы и инструменты.
В статьях процесс иногда сокращают до трёх этапов — Explore, Plan и Execute — или двух: Plan и Implement. В руководстве Anthropic выделены четыре этапа. Отдельный Commit помогает завершить работу: зафиксировать изменения и подготовить Pull Request, вместо того чтобы откладывать это на неопределённое время. | Этап | Действия Claude | Действия пользователя | Режим | |---|---|---|---| | **Explore** | Изучает `/src/auth`, выясняет, как устроены сессии и переменные окружения | Определяет границы исследования | Plan Mode | | **Plan** | Перечисляет файлы для изменения и создания, описывает риски и порядок работы | Проверяет план, при необходимости редактирует его через Ctrl+G и одобряет | Plan Mode | | **Implement** | Реализует OAuth-процесс, добавляет тесты и callback по плану | Контролирует применение изменений | Default или acceptEdits | | **Commit** | Создаёт коммит с описанием и открывает Pull Request | Проверяет сообщение коммита и проводит ревью PR | Default | На каждом этапе нужны отдельные запросы. Для Explore попросите прочитать `/src/auth` и разобраться с обработкой сессий и входа. Для Plan — перечислить изменения, необходимые для добавления Google OAuth, и оформить план. Для Implement — выполнить утверждённый план, написать тесты, запустить набор проверок и устранить найденные сбои. Для Commit — создать содержательный коммит и открыть Pull Request. В Plan Mode Claude может выполнять исследовательские действия: читать файлы, изучать структуру проекта, искать текст и запускать команды оболочки. Например, можно проверить историю через `git log` или просмотреть тесты. Редактирование и другие операции, меняющие файлы, в этом режиме заблокированы. ## Как оценить план Claude и решить, стоит ли его одобрять?
Главное Качественный план называет конкретные файлы и предполагаемые правки, задаёт порядок действий, отмечает риски и содержит критерии успеха. Общего обещания «обновить модуль авторизации» недостаточно. Ниже приведены семь признаков, по которым можно проверить план, и способы запросить его уточнение через обратную связь или Ctrl+G.
После подготовки плана 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 хранит план в текущем диалоге. Файл вида `plans/YYYY-MM-DD-feature.md` делает его доступным и после завершения сессии: в нём можно описать этапы, флажки и статус. Другой агент или новая сессия смогут продолжить работу, прочитав этот файл.
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`. | Признак | Только Plan Mode | Plan Mode с каталогом plans/ | |---|---|---| | Сохранение результата | Только в текущем диалоге | В файле репозитория | | Передача другому агенту | Не предусмотрена | Файл можно прочитать командой `cat plans/file.md` | | История версий | Отдельной истории нет | Можно посмотреть через `git diff` | | Работа субагентов | В рамках текущей сессии | Этапы можно распределить между агентами | | Флажки и статусы | Текстовое описание | Markdown-флажки `[ ]` и `[x]` | | Размер плана | Ограничен контекстом диалога | Определяется задачей и структурой проекта | Если каждому направлению работы соответствует отдельный файл, спустя несколько месяцев можно вернуться к нему и восстановить, почему было выбрано конкретное решение, какие варианты рассматривались и какие вопросы обсуждались. Рабочий план при этом становится документом, который можно обновлять вместе с проектом. ## Как организовать автономную работу Claude с Plan Mode и /goal?
Главное Команда `/goal` в Claude Code v2.1.139 (11 мая 2026) задаёт проверяемое условие завершения: Claude продолжает работу, пока оно не выполнено, либо пока не достигнуто заданное ограничение. Для автономного запуска заранее сформулируйте критерий успеха и предел по ходам или времени.
Команда `/goal` позволяет задать условие, по которому сессия должна остановиться. После каждого хода небольшая модель-проверяющий анализирует транскрипт и решает, выполнено ли условие. Если нет, работа продолжается. Сам оценщик не запускает инструменты, а только читает переписку. Для команды используется такой формат: ```bash /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, добавьте к условию ограничение по числу ходов или времени, например «или остановиться после 20 ходов».

— Документация Anthropic, https://code.claude.com/docs/en/goal
Например, если запустить `/goal` без ограничения и с расплывчатой формулировкой, система может продолжать попытки дольше, чем вы планировали. Поэтому задавайте критерии и предел до начала автономной работы. ## Как применить четырёхшаговый цикл при работе в Plan Mode?
Главное Для сложной задачи удобно разделить работу в Plan Mode на четыре шага: сначала собрать факты без предложений по исправлению, затем рассмотреть подтверждённые варианты, составить подробный план с рисками и, наконец, проверить предположения. Так проще отделить диагноз от решения и заметить недоказанные детали.
Частая ошибка при работе с Plan Mode — сразу спрашивать: «Как это исправить?» Claude может предложить быстрый ответ, который не устраняет причину или усугубляет ситуацию. Четырёхшаговая последовательность помогает сначала разобраться в наблюдаемых фактах, а уже после этого переходить к решению. Выполняйте её по порядку в одной сессии Plan Mode. **Шаг 1. Зафиксируйте факты, не предлагая решения.** Промпт: «Наблюдается следующая проблема: \[описание симптома\]. Сейчас установи только факты. Не предлагай решений, идей или советов. Перечисли, что именно наблюдается, какие шаги воспроизводят проблему, какие данные доступны и каких данных не хватает. Стоп-условие: не предлагать исправления, только описать диагноз». Так Claude сначала формулирует известное и неизвестное, не переходя сразу к способу исправления. **Шаг 2. Найдите варианты и подтверждающие примеры.** Промпт: «Теперь, когда диагноз сформулирован, найди официальные материалы и примеры решения аналогичных проблем. Рассмотри не менее трёх разных подходов. Для каждого укажи ссылку на первоисточник, краткое описание, преимущества и недостатки применительно к нашей задаче». Этот этап помогает опираться на проверяемые материалы, а не только на предположение модели. Используйте официальные документы производителя или организации, отвечающей за соответствующий продукт. **Шаг 3. Подготовьте подробный план с рисками.** Промпт: «Выбери наиболее подходящий подтверждённый вариант и составь детальный план. Укажи конкретные файлы для изменения, что нужно добавить или удалить, какие тесты написать, что может сломаться и какие риски проявятся на два-три шага вперёд». На этом этапе план опирается на установленные факты и проверенные варианты, а не на неподтверждённые догадки. **Шаг 4. Проверьте план на неподтверждённые предположения.** Промпт: «Выполни обязательную самопроверку плана. Найди утверждения, которые не подтверждаются кодом проекта, официальной документацией или материалами из шага 2. Отметь их и скорректируй план». Финальная проверка помогает выявить детали, которые выглядят убедительно, но пока не подтверждены. После неё план можно прочитать и одобрить. Когда все четыре шага выполнены, задача описана, варианты сопоставлены, а риски обозначены. Такой порядок особенно полезен для сложных ошибок и архитектурных решений, где неверное исправление может повлечь дополнительные проблемы. ## Пять шаблонов промптов для Plan Mode
Главное Шаблоны помогают структурировать план для рефакторинга, миграции базы, новой функции, тестирования и диагностики ошибки. Замените параметры в фигурных скобках на данные своего проекта и сохраните результат в `plans/`.
**Шаблон 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, а когда обычный режим?
Главное Выбирайте Plan Mode для неясного подхода, незнакомого кода, архитектуры, миграций и значимых побочных эффектов. Число файлов — повод рассмотреть зависимости, а не жёсткое правило. Небольшую понятную безопасную правку можно делать напрямую; одно предложение не делает аутентификацию или миграцию безопасной.
Отдельный план можно пропустить, когда настоящий diff мал, понятен и мало рискован. Планируйте поиск подхода и согласование опасных межкомпонентных изменений. Известные имена файлов и краткое описание цели не устраняют риски миграции, авторизации и целостности данных. | Задача | Режим | Причина | |---|---|---| | Исправить опечатку в README | Default | Один файл, простое и очевидное изменение | | Переименовать переменную в одном файле | Default | Объём понятен, ссылки проверяемы; оценить побочные эффекты | | Добавить строку журналирования | Default | Однострочная правка без изменения логики | | Добавить одну кнопку на страницу | Default | Если место и назначение кнопки ясны, план не нужен | | Рефакторинг модуля | Plan Mode | Несколько файлов и риск побочных эффектов | | Миграция базы данных | Plan Mode + `/goal` | Много этапов и необходимость продумать откат | | Добавить аутентификацию | Plan Mode | Может затрагивать много файлов; важны требования безопасности | | Написать тесты для модуля | Plan Mode | Сначала нужно определить проверяемое поведение | | Разобраться с непонятной ошибкой | Plan Mode + четырёхшаговый цикл | Без диагностики легко выбрать неверное исправление | | Перейти на другой фреймворк | Plan Mode + plans/ + `/goal` overnight | Длительная работа требует этапов и заданного условия завершения | До выбора режима выясните, понятны ли подход, последствия и проверка. Небольшую локальную безопасную правку с очевидной проверкой можно делать напрямую. При неопределённости, незнакомом коде, миграции, авторизации или координации компонентов нужен план, даже если уже известны все три-пять файлов. ## Как связать Plan Mode, CLAUDE.md и субагентов?
Главное Plan Mode можно сочетать с настройками проекта в `CLAUDE.md` и субагентами. Файл с правилами помогает Claude учитывать архитектуру при планировании, а этапы плана можно распределить между субагентами. Сохранённый план служит общей точкой, к которой они могут обращаться.
Claude Code читает `CLAUDE.md` в начале сессии, в том числе при планировании. Если в файле указано, например, что даты нельзя записывать прямо в код и их следует получать из базы данных, Claude сможет учесть это правило при подготовке плана. Без такого указания он может предложить неподходящий вариант. Работу можно разделить на три уровня. **Уровень 1. Правила проекта в CLAUDE.md.** Укажите используемый стек, архитектурные принципы, запреты — например, не применять устаревший API — и требования вроде единого макета для всех писем. **Уровень 2. Планирование с учётом этих правил.** Если попросить добавить OAuth, Claude сможет прочитать правила проекта, учесть хранение токенов в Redis вместо базы данных и отразить это в плане. **Уровень 3. Распределение этапов между субагентами.** Если план разбит на этапы, каждый из них можно поручить отдельному субагенту. Он работает в собственном контекстном окне; общий файл в `plans/` помогает агентам видеть последовательность действий и отмечать выполненные пункты. ## Семь ошибок, из-за которых Plan Mode работает хуже
Главное Использованию Plan Mode мешают типичные ошибки: хранить план только в диалоге, смешивать задачи в одной сессии, не делить работу на этапы, не проверять официальные материалы, просить решение до сбора фактов, пропускать самопроверку и ставить расплывчатую цель для `/goal`.
**Ошибка 1. План существует только в диалоге.** Признак: после закрытия окна к плану уже нельзя вернуться. Сохраняйте его в файл проекта, например `plans/YYYY-MM-DD-feature-name.md`. Диалог нужен для работы, файл — для дальнейшего использования. **Ошибка 2. Несколько разных задач в одной сессии.** Если в одном разговоре обсуждать авторизацию, миграцию, дизайн и отдельную ошибку, контекст постепенно смешивается. Завершив планирование одной задачи, начните новую сессию для следующей. **Ошибка 3. Длинный план без этапов.** Документ на тысячи строк без флажков затрудняет понимание того, что завершено, и передачу работы. Разделите план на три-семь этапов с конкретными действиями и отметками выполнения. **Ошибка 4. Нет проверки официальных материалов.** Если план строится только на ответе модели, можно пропустить подход, описанный в первоисточниках. Сверяйте технические решения с официальной документацией продукта или используемого фреймворка. **Ошибка 5. Запрос решения до диагностики.** Вопрос «как исправить ошибку?» может привести к преждевременному совету. Сначала попросите описать воспроизводимые шаги, логи и недостающие сведения, затем переходите к возможным вариантам. **Ошибка 6. План не проверен на предположения.** В нём могут оказаться несуществующая библиотека, неподдерживаемый API или неверная версия. Сверьте такие сведения с кодом и официальными документами до реализации. **Ошибка 7. Для `/goal` задано расплывчатое условие.** Условие «сделай хорошо» нельзя проверить. Укажите конкретный критерий, команду для проверки и предел, например `or stop after N turns`. ## Что предпринять после первого знакомства с Plan Mode?
Главное После первого запуска можно зафиксировать правила проекта в `CLAUDE.md`, создать каталог `plans/` и проверить `/goal` на одной задаче с понятными критериями. Вместе эти средства помогают сохранять требования, планы и условия завершения между этапами работы.
Попробуйте три шага, переходя от простого к более сложному. **Шаг 1. Подготовьте CLAUDE.md.** Если файла ещё нет, добавьте правила, которые Claude должен учитывать: используемый стек, архитектурные ограничения и требования проекта. Без них планирование будет опираться на неполное описание системы. Сосредоточьтесь на ясных и конкретных инструкциях. **Шаг 2. Создайте в репозитории каталог `plans/`.** Сохраните в нём план для каждой отдельной задачи, используя формат имени `YYYY-MM-DD-feature-name.md`. Так можно возвращаться к решениям и продолжать работу в новой сессии. **Шаг 3. Испытайте `/goal` на одной задаче.** Выберите задачу, которую обычно выполняете около 30–40 минут. Включите Plan Mode, подготовьте план и сохраните его в `plans/`. Затем выйдите из режима планирования и задайте условие, например: выполнить этапы из `plans/file.md`, добиться прохождения тестов или остановиться через 30 ходов. После запуска проверьте итог и историю выполнения. Этих действий достаточно, чтобы начать. Добавляйте новые этапы постепенно: сначала опишите правила проекта, затем сохраняйте планы, а после этого проверьте автономный режим на ограниченной задаче.
### Официальные источники - [Anthropic Docs — Permission Modes](https://code.claude.com/docs/en/permission-modes) - [Anthropic Docs — Common Workflows](https://code.claude.com/docs/en/common-workflows) - [Anthropic Engineering — Claude Code Best Practices](https://www.anthropic.com/engineering/claude-code-best-practices) - [Anthropic Docs — команда /goal](https://code.claude.com/docs/en/goal) - [Anthropic Docs — история изменений Claude Code](https://github.com/anthropics/claude-code/blob/main/CHANGELOG.md)
Познакомьтесь с [Ailoot](https://ailoot.ai/). ## Вопросы и ответы ### Можно ли пропустить планирование, раз известны изменяемые файлы? Нет. Имена не устраняют неопределённость последствий и проверки. Планируйте миграции, аутентификацию и согласованные изменения компонентов даже при готовом списке файлов. ### Когда отдельный Plan Mode не нужен? Для небольшого понятного малорискового diff с очевидной проверкой, например локальной опечатки. Планируйте, когда подход неясен, код незнаком или нужно разобрать межкомпонентные и операционные риски. ## Ailoot · Компания и портфель её проектов Ailoot опирается на накопленный опыт работы, большую клиентскую базу, стабильный сервис и постоянный контроль KPI. Компания и портфель её проектов: миллионы клиентов; продажи на миллиарды ежемесячно. Этот опыт Ailoot использует для API-доступа к нейросетям в продуктах клиентов, агентах, приложениях и автоматизациях.