Как ставить задачу Claude Code

Claude Code — мощный агент, но он не читает мысли. Он делает ровно то, что ты попросил, — и результат получается зеркалом твоей постановки. Расплывчато объяснил задачу — получил расплывчатый результат, и списывать это на «слабую модель» бесполезно: дело почти всегда в запросе, а не в агенте. Умение ясно ставить задачу — это главный навык при работе с Claude Code, важнее любых хитрых команд. В этом гайде разберём, из чего состоит хорошая задача, какими приёмами повысить попадание и как перестать получать «не то».

Короткий ответ

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

Сравни. Плохо: «почини авторизацию». Хорошо:

«В файле @src/auth.ts при входе с неверным паролем пользователь получает пустой экран вместо ошибки. Нужно показывать сообщение „Неверный логин или пароль“. Логику самой проверки пароля не трогай — правь только обработку ответа. Готово, когда при неверном пароле на форме появляется текст ошибки.»

Вторая формулировка длиннее, но именно с ней агент попадает с первого раза. Первая — лотерея.

Что понадобится

• Установленный и работающий Claude Code (команда claude запускается в терминале).
• Проект под рукой — открытая папка, в которой ты хочешь что-то сделать. Даже пустая: с неё Claude Code начинает так же, как с большой.
• Понимание, что ты хочешь получить на выходе. Не как это сделать технически, а какой результат считается успехом. Это и есть половина работы.

Почему постановка решает всё

Модель под капотом Claude Code действительно мощная — она умеет читать код, планировать, писать целые модули. Но у этой мощи есть цена: когда задача сформулирована размыто, агент не останавливается и не переспрашивает по каждой мелочи. Он делает разумное предположение и идёт дальше. А предположение — это угадывание. Иногда он угадывает то, что ты имел в виду. Часто — нет.

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

Ключевая мысль: агент не читает мысли и не знает контекста у тебя в голове. Всё, что не сказано явно, он додумает сам — и не факт, что так, как ты хотел. Хорошая постановка убирает додумывание.

Из чего состоит хорошая задача

Разберём на части. Любая толковая формулировка держится на четырёх опорах:

• Цель — что должно получиться на выходе. Не «поработай с формой», а «на форме логина должна появляться ошибка при неверном пароле». Цель — это результат, который ты сможешь проверить глазами.
• Контекст — какие файлы или часть проекта затронуты. Не заставляй агента искать вслепую по всему репозиторию: подставь нужный файл через символ @ (например, @src/auth.ts), и агент возьмёт именно его.
• Ограничения — что нельзя трогать и в каком стиле работать. «Не меняй логику проверки пароля», «не добавляй новых зависимостей», «стиль как в соседних компонентах». Границы уберегают от того, чтобы агент починил одно и сломал три других.
• Критерий готовности — как понять, что задача решена. «Тесты проходят», «страница открывается без ошибки в консоли», «при неверном пароле виден текст ошибки». Без критерия агент не знает, где финиш, и останавливается там, где ему показалось достаточно.

Собранная из этих четырёх частей задача выглядит так:

«Цель: на странице профиля @src/pages/Profile.tsx имя пользователя должно подтягиваться из API, а не быть захардкоженным „John Doe“. Контекст: запрос к API уже есть в @src/api/user.ts, используй его. Ограничения: вёрстку и стили не трогай, работай только с данными; новых библиотек не добавляй. Готово, когда страница показывает реальное имя из ответа API и в консоли браузера нет ошибок.»

Заметь: ни строчки кода, всё словами. Ты описываешь результат и границы, а как это сделать технически — забота агента.

Приёмы, которые повышают попадание

Помимо самой формулировки есть несколько встроенных в Claude Code вещей, которые заметно поднимают шанс попасть с первого раза.

Plan-режим — для задач сложнее трёх шагов. В этом режиме агент сначала показывает план того, что собирается сделать, и не трогает код, пока ты план не одобрил. Ты успеваешь сверить: то он понял или нет, туда ли лезет. Переключается plan-режим сочетанием Shift+Tab (оно перебирает режимы работы по кругу) либо командой /plan. Дешевле поправить план из пяти пунктов, чем откатывать полчаса сделанной не туда работы.

Упоминание файла через @ — чтобы не заставлять агента угадывать, где что лежит. Пишешь в задаче @src/api.ts — и агент подставляет этот файл в контекст напрямую, вместо того чтобы искать его по проекту и, может, найти не тот. Чем точнее указал файлы, тем меньше агент блуждает.

Разбивай крупное на шаги. Большую задачу — «перепиши весь модуль оплаты» — агент тянет хуже, чем ту же работу, нарезанную на понятные куски: сначала одно, проверили, потом следующее. Мелкими шагами и ошибки дешевле, и контроль плотнее.

Проси «сначала план, потом код». Даже без формального режима простая фраза в задаче — «сначала покажи план, код не пиши, дождись моего ок» — заставляет агента затормозить и показать намерение до действия.

Совет: на сложной задаче всегда включай plan-режим (Shift+Tab или /plan). Пробежать глазами план и поправить одну строчку в нём — минута. Переписывать то, что агент уже наворотил не в ту сторону, — полчаса. План почти всегда окупается.

Плохо против хорошо

Самый быстрый способ научиться — увидеть разницу на конкретных парах. Слева — как формулируют по привычке, справа — как стоит.

Видно закономерность: сильная версия всегда называет файл, говорит про результат и даёт признак «готово». Слабая оставляет всё это агенту на угадывание.

Частые ошибки

FAQ

Нужно ли писать код прямо в задаче?

Нет. Наоборот — описывай результат словами, а не диктуй реализацию. «Хочу, чтобы при неверном пароле показывалась ошибка» работает лучше, чем попытка на пальцах объяснить агенту, какой код написать. Как сделать технически — его работа; твоя — ясно сказать, что должно получиться.

Что если задача большая?

Разбей её на шаги и веди по одному: сделали первый кусок, проверили, перешли к следующему. И включи plan-режим (Shift+Tab или /plan) — пусть агент сначала покажет весь маршрут, а ты сверишь его целиком до начала работы. Крупное монолитом агент тянет заметно хуже, чем то же самое по частям.

Почему он игнорирует часть моей просьбы?

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

Обязательно ли делать /init в каждом проекте?

Не обязательно, но в новом или незнакомом проекте это сильно помогает. Команда /init собирает для агента обзор проекта — что где лежит, как всё устроено, — и дальше он реже блуждает и переспрашивает. Один раз в начале работы с проектом — хорошая привычка.

Что ты увидишь

В план-режиме (Shift+Tab) агент сперва показывает план и ЖДЁТ твоего «ок» — ничего не трогает, пока не подтвердишь. Примерно так:

⏸  План — жду подтверждения
 1. Прочитать компонент и его стили
 2. Добавить состояние загрузки
 3. Обновить тест и прогнать

 Одобрить план? (y / n)

Итог

Claude Code силён ровно настолько, насколько ясно ты объяснил задачу. Хорошая постановка — это четыре опоры: цель (что на выходе), контекст (какие файлы, через @), ограничения (что не трогать) и критерий готовности (как понять, что сделано). На задачах сложнее трёх шагов включай plan-режим (Shift+Tab или /plan) и сверяй план до кода. Расплывчатый запрос — расплывчатый результат; чёткий запрос — попадание с первого раза.

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