Как ставить Claude Code проверяемые задачи

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

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

Каркас хорошего запроса

Запрос может состоять из пяти частей:

1. Наблюдаемая проблема или желаемый результат. 2. Область проекта и полезные точки входа. 3. Ограничения совместимости и безопасности. 4. Примеры входа и ожидаемого выхода. 5. Команды или сценарий приёмки.

Плохой запрос: «почини авторизацию». Хороший запрос называет сбой, роль пользователя, воспроизведение, предполагаемый модуль и обязательный regression-тест.

Не подменяйте цель рецептом

Если вы не уверены в причине дефекта, не приказывайте изменить конкретную строку. Попросите исследовать и подтвердить root cause. Иначе агент может идеально выполнить неверное техническое предположение.

Вместо «добавь таймаут в функцию X» лучше: «запрос иногда висит дольше 30 секунд; воспроизведи, найди границу без таймаута и предложи минимальное исправление».

Критерии готовности

Фраза «всё должно работать» не проверяема. Укажите наблюдаемые условия:

тест сначала воспроизводит дефект и проходит после исправления;
публичный контракт API не меняется;
линтер, типы и целевой набор тестов проходят;
UI совпадает с приложенным примером при двух размерах экрана;
в diff нет несвязанных изменений.

Итеративное уточнение

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

Упражнение: перепишите задачу

Исходная формулировка:

> Сделай профиль быстрее.

Production-вариант:

> Страница профиля на тестовых данных отвечает около 2,4 секунды. Измерь путь запроса, найди подтверждённое узкое место и предложи план. Не меняй публичный DTO и схему БД без отдельного обоснования. После согласования реализуй минимальное исправление, добавь regression-проверку и покажи измерение до/после.

Возьмите свою реальную задачу и добавьте к ней четыре недостающих элемента: область, ограничения, пример и проверку.

Частые вопросы

Нужно ли писать очень длинный prompt?

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

Следует ли перечислить файлы, которые агент обязан открыть?

Укажите известные точки входа, но оставьте возможность исследовать зависимости. Жёсткий список может скрыть реальную причину в другом модуле.

Что делать, если требования противоречат друг другу?

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

Что важно запомнить

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

https://yadro-code.ru/lessons/without-university/claude-code-workflows/claude-code-05