Как задавать вопросы и давать команды: достучаться до самого сердца Claude
📚 Навигация по серии: В предыдущей статье [14 Пользовательский интерфейс и горячие клавиши] мы научили вас правильно ставить пальцы — курсор, Enter, Esc, команды со слэшем стали привычными. В этой статье мы перейдем на другой уровень: руки знают, куда нажимать, теперь и язык должен знать, что говорить. При одних и тех же требованиях то, как вы сформулируете задачу, кардинально изменит результат работы Claude.
Скажу не самую приятную правду: многие, когда только начинают пользоваться Claude Code, используют его как поисковик.
Представьте такую ситуацию: в проекте возникает ошибка в функции, и вы сбрасываете короткую фразу «Исправь этот баг», даже не указав, в каком файле и что за ошибка. Нажимаете Enter и ждете, как развернется спектакль. В итоге он «угадывает» баг, который, по его мнению, имеет место быть, меняет три файла, и ни один из них не является тем, что вы действительно хотели исправить. Вы смотрите на полный экран diff с недоумением и бормочете: «Этот ИИ никуда не годится».
Но если подумать, становится понятно — проблема не в нем. Проблема вообще не в Claude, а в той ужасной фразе: информативность равна нулю, и ему остается только додумывать. Если он додумал неправильно, кого винить?
Скажу так: потолок возможностей Claude Code в значительной степени ограничен тем, как вы задаете вопросы. С одной и той же моделью, в одном и том же проекте, человек, умеющий ставить задачи, решит всё в три фразы, а тот, кто не умеет, будет переделывать пять раз и останется в бешенстве. Сегодня мы разберем до мелочей этот универсальный принцип общения «как четко сформулировать требование в одном предложении» — я не учу вас заучивать шаблоны, я учу вас понимать, «что именно нужно знать Claude, чтобы не сбиться с пути».
Прочитав эту статью, вы получите:
- Таблицу сравнения «Плохой запрос vs Хороший запрос», по которой можно исправлять свои ошибки, и уровень переделок резко упадет
- Четыре ключевых принципа постановки задач: конкретика, контекст, критерии приемки, и составление плана для сложных задач
- Правильный способ использования
@для ссылок на файлы, чтобы точно определить область - Эксперимент «одно требование, два способа формулировки», который вы можете повторить сами, чтобы воочию убедиться в разнице
01 В чем именно плох плохой запрос
Давайте разберем тот провал. Фраза «Исправь этот баг» с точки зрения Claude лишена огромного количества информации:
- Какой баг? Ему придется самому догадываться, о каком месте вы говорите.
- В каком файле? Ему придется перерыть весь проект.
- Каково ожидаемое правильное поведение? Он вообще не знает, и может только додумывать, «как это обычно должно быть».
Аналогия: обучение новичка. Если вы скажете стажеру, который только что устроился, «Сделай ту штуку», то это будет чудо, если он сделает правильно. А вот если вы скажете «Измени цвет кнопки входа в правом верхнем углу главной страницы с серого на фирменный синий #1A73E8», он сделает это с закрытыми глазами. Чем конкретнее инструкция, тем меньше шансов, что новичок ошибется; чем более расплывчато вы говорите, тем больше ему приходится угадывать, и тем выше вероятность ошибки. С Claude всё точно так же.
Давайте посмотрим на это сравнение, которое неоднократно подчеркивается в официальной документации (переведено на русский по смыслу оригинала):
| Сценарий | ❌ Плохой запрос | ✅ Хороший запрос |
|---|---|---|
| Исправление бага | «Исправь ошибку входа» | «Пользователи сообщают, что после истечения времени сессии вход не удается. Проверь процесс аутентификации в src/auth/, обрати особое внимание на обновление token. Сначала напиши падающий тест, который воспроизведет проблему, а затем исправь ее» |
| Написание тестов | «Добавь тесты для foo.py» | «Напиши тесты для foo.py, покрывающие граничный случай, когда пользователь уже вышел из системы, не используй mock» |
| Вопросы по коду | «Почему API ExecutionFactory спроектирован так криво?» | «Просмотри историю git для ExecutionFactory и подведи итог, как его API шаг за шагом эволюционировал до нынешнего состояния» |
| Добавление функции | «Добавь компонент календаря» | «Сначала посмотри, как реализованы существующие компоненты на главной странице, HotDogWidget.php — хороший пример. Следуя этому паттерну, реализуй компонент календаря, который позволяет пользователям выбирать месяц и перелистывать годы вперед-назад. Не подключай новые библиотеки, кроме тех, что уже есть в кодовой базе» |
Видите суть? Хороший запрос всегда делает одну вещь: то, что Claude должен был бы угадывать, вы заранее «скармливаете» ему.
💡 В одном предложении: Плохой запрос плох тем, что «пробелы в информации Claude заполняет сам», хороший запрос — это когда вы заранее объясняете то, что он должен был бы угадать.
На этой картинке Before/After показаны два способа задать один и тот же вопрос: слева расплывчатый запрос, Claude может только додумывать и задавать кучу встречных вопросов; справа дан полный набор — область, контекст (@файл), критерии приемки, и он попадает в цель с первого раза, тесты сразу проходят. Разница не в Claude, а в том, как вы говорите.
02 Принцип первый: Конкретика > Размытость
Это самый важный из четырех принципов, без вариантов.
В официальной документации есть фраза, которую стоит запомнить, в оригинале она звучит так:
Чем точнее ваши инструкции, тем меньше исправлений вам потребуется.
Переводя на простой язык: одно лишнее слово в начале сэкономит вам три круга переделок в конце. Вы думаете, что «сэкономить усилия» — это напечатать на несколько слов меньше, но на самом деле те слова, которые вы не напечатали, вернутся к вам в виде удвоенной цены за постоянные переделки.
Насколько конкретно нужно быть? Добавляйте информацию в трех измерениях:
Первое, ограничьте область — какой файл, какая функция, какой сценарий. Не заставляйте его искать иголку в стоге сена по всему проекту.
Второе, четко обозначьте ограничения — «Не подключай новые библиотеки», «Сохраняй обратную совместимость», «Не трогай файлы тестов». Если вы не скажете, он сделает по своему усмотрению, и результат может вам не понравиться.
Третье, укажите ориентир — «Сделай по паттерну HotDogWidget.php». На практике этот метод самый удобный: вместо того чтобы описывать словами желаемый стиль, просто бросьте ему готовый пример, который вас устраивает, и он скопирует его, и результат будет очень близок к идеалу.
Здесь есть неинтуитивное исключение, которое нужно прояснить: расплывчатые запросы — это не абсолютное зло. Когда вы находитесь на «этапе исследования» и сами еще не определились с направлением, открытый вопрос «Как ты думаешь, что можно улучшить в этом файле?» может выявить вещи, о которых вы даже не думали спросить. В официальной документации это звучит так: «Когда вы исследуете и можете корректировать курс, расплывчатые подсказки могут быть очень полезны». Правило такое: когда вам нужен результат, будьте максимально конкретны, когда ищете вдохновение — намеренно оставляйте пробелы.
При создании небольших инструментов очень легко наткнуться на эту границу — в начале вы хотите посмотреть, как Claude понимает этот кусок запутанного кода, задаете намеренно широкий вопрос, и некоторые из предложенных им улучшений действительно вдохновляют; но как только у вас появляется четкая цель, использование расплывчатых запросов — это пустая трата времени, ему каждый раз придется заново угадывать, чего вы на самом деле хотите.
💡 В одном предложении: Чтобы получить определенный результат, будьте максимально конкретны (область + ограничения + ориентир), только когда вы активно ищете вдохновение, намеренно оставляйте пробелы.
03 Принцип второй: Давайте контекст, не заставляйте его гадать вслепую
Помимо конкретики, второй прием — подавать «материал» прямо ему в рот, а не описывать словами, где он находится.
Два самых частых действия, запомнив которые, вы решите больше половины проблем:
Первое, используйте @ для ссылки на файлы. Напечатайте @ в поле ввода, и появится автодополнение пути к файлу. После выбора полное содержимое этого файла будет вставлено прямо в диалог — Claude не нужно будет сначала искать, а потом читать, это экономит шаг и исключает ошибку поиска.
Опираясь на определения типов в @src/types/user.ts, добавь аннотации типов в UserServiceЭто в десять тысяч раз надежнее, чем сказать: «В проекте есть файл с типами user, найди его». В официальной документации четко написано, что ссылка через @ «читает полное содержимое файла перед ответом».
Аналогия: USB-порт. @ — это как вставить «USB-флешку с файлом» прямо в рабочий стол Claude — подключил и используй, нужные материалы на месте за секунду; если вы просто скажете «документы лежат во втором шкафу в архиве на третьем этаже», ему придется туда идти, а если он пойдет не туда, это задержит работу еще больше.
Второе, вставляйте ошибки целиком. Это правило стоит довести до автоматизма — когда вы сталкиваетесь с traceback, не пытайтесь обобщать, говоря «там ошибка null pointer», копируйте весь стек целиком:
При запуске возникла эта ошибка, помоги мне найти причину:
TypeError: Cannot read properties of null (reading 'userId')
at getUserProfile (src/services/user.ts:42:18)
at async ProfileController.getProfile (src/controllers/profile.ts:15:20)Зачем вставлять целиком? Потому что в стеке есть имена файлов, номера строк, вся цепочка вызовов, и Claude сможет точно определить местоположение по user.ts:42. Если вы это перескажете своими словами, вы удалите все эти ключевые координаты, и ему снова придется гадать с самого начала.
| Что вы хотите передать | ❌ Описывать словами | ✅ Передавать напрямую |
|---|---|---|
| Содержимое файла | «В проекте есть файл, который обрабатывает аутентификацию» | @src/auth/session.ts |
| Ошибка | «Там ошибка undefined» | Вставить полный traceback как есть |
| Проблема с UI | «Кнопка не на месте» | Вставить скриншот напрямую (Claude умеет читать изображения) |
| Спецификация интерфейса | «Сделай по нашей спецификации API» | @docs/api-spec.md |
Одним словом: Всё, что можно «вставить», ни в коем случае не «описывайте». Claude всегда точнее понимает сырые материалы, чем ваш пересказ этих материалов из вторых рук.
💡 В одном предложении: Используйте
@для файлов, а также копируйте ошибки и скриншоты прямо перед его носом, не заставляйте его гадать по вашим описаниям.
04 Принцип третий: Дайте «проверяемый» критерий успеха
Это правило игнорируют чаще всего, но оно обладает колоссальной силой: вы должны дать Claude понять, «какой результат считается успешным», и в идеале этот критерий он должен уметь проверять сам.
Почему это так важно? Официальная документация раскрывает базовую логику:
Claude останавливается, когда работа кажется завершенной. Без проверок, которые он может запустить, «кажется завершенным» является единственным доступным сигналом, и вы становитесь циклом валидации: каждая ошибка ждет, пока вы её заметите.
Что это значит? Если вы не задаете критерии, Claude заканчивает работу, когда у него возникает «ощущение, что вроде бы всё», и человеком, который на самом деле проводит финальную проверку, становитесь вы, каждую ошибку вам придется отлавливать лично. Но как только вы даете ему проверку, которая может вернуть результат «Успех / Ошибка», этот цикл замыкается на нем самом: он закончил работу → запустил проверку → посмотрел результат → если не прошло, продолжает исправлять, и вам вообще не нужно за этим следить.
Просто сравните:
| Задача | ❌ Нет критериев приемки | ✅ Дан проверяемый критерий |
|---|---|---|
| Написать функцию | «Реализуй функцию валидации email» | «Напиши функцию validateEmail. Примеры использования: user@example.com - true, invalid - false, user@.com - false. После написания запусти тесты» |
| Изменить UI | «Сделай этот дашборд красивее» | «[Вставить макет] Реализуй так, как здесь, затем сделай скриншот результата, сравни с оригиналом, выпиши отличия и исправь их» |
| Починить сборку | «Сборка упала» | «Сборка выдает эту ошибку: [вставить ошибку]. Исправь её и проверь, что сборка проходит. Устрани корневую причину, не пытайся просто подавить ошибку» |
Обратите внимание на последнюю строку: «Устрани корневую причину, не пытайся просто подавить ошибку» — эту фразу я научился добавлять только после того, как набил шишек. Если ее не написать, иногда он, чтобы сэкономить время, просто обернет код в try/except или добавит @ts-ignore, чтобы убрать красное подчеркивание. Ошибка исчезнет, но корень проблемы останется.
Продвинутый уровень: используйте /goal, чтобы превратить критерии приемки в правило «не заканчивать, пока не достигнем цели». (Требуется Claude Code версии v2.1.139 или выше) В обычном запросе критерий приемки — это команда «запусти в этот раз»; а /goal закрепляет критерий как цель всей сессии — после каждого раунда маленькая модель (по умолчанию Haiku) проверяет результат по вашим условиям, если цель не достигнута, автоматически начинается новый раунд, контроль вам не возвращается, пока условие не будет выполнено.
/goal все тесты в test/auth проходят, и этап lint завершается без ошибокПри использовании /goal есть важный нюанс, на котором легко споткнуться: эта маленькая модель-оценщик видит только то, что Claude «показал» в диалоге, она сама не будет запускать команды или читать файлы. Поэтому ваше условие должно подтверждаться выводом самого Claude: условие «все тесты test/auth проходят» работает, потому что Claude действительно запустит тесты, результат будет выведен в диалог, и модель-оценщик сможет его прочитать. Если вы напишете «код высокого качества», что невозможно увидеть в выводе, она не сможет это оценить.
💡 В одном предложении: Дайте ему проверку (тесты, сравнение скриншотов, код выхода сборки), которая даст результат Успех / Ошибка, и цикл замкнется сам; если хотите, чтобы он «не отпускал, пока не добьется цели», используйте
/goal.
05 Принцип четвертый: Для сложных задач сначала попросите составить план
Последнее правило специально для «больших дел»: когда сталкиваетесь с масштабными изменениями, затрагивающими несколько файлов, или с задачами, где вы сами не уверены в направлении, не позволяйте ему сразу писать код — пусть сначала составит план, а вы его утвердите.
Об этом уже упоминалось в статье 06 (Тарифы и биллинг), а здесь я объясню почему. Официальная документация говорит об этом прямо:
Просьба к Claude сразу перейти к программированию может привести к тому, что код будет решать не ту проблему.
Проще говоря: сначала исследование, потом планирование, и только в конце программирование — разделяйте этапы «обдумывания» и «реализации», чтобы он не умчался по ложному пути, и когда вы это заметите, он уже не переписал кучу кода.
Аналогия: Ремонт начинается с чертежа, а не со сноса стен. Ни один нормальный строитель не возьмет кувалду и не начнет крушить несущую стену без лишних слов. Сначала он согласует с вами: «Эту стену сносим, здесь прокладываем кабель, здесь меняем трубы», и только после вашего кивка начнет работу. План — это тот самый чертеж, который Claude дает вам перед тем, как ломать стену — если вы найдете ошибку на чертеже, исправить пару линий будет стоить намного дешевле, чем переделывать всё после сноса стены.
Как заставить его сначала сделать чертеж? Есть два способа:
Способ первый: просто сказать словами «пока ничего не меняй». В обычном диалоге просто добавьте ограничение:
Я хочу добавить переключатель темной темы на страницу настроек. Сначала скажи мне, какие файлы нужно будет изменить и какова общая идея,
на этом этапе пока не меняй никакой код.Способ второй: переключиться в Plan Mode (Режим планирования). Это специальный режим Claude Code «только для чтения и планирования» — он будет читать файлы, предлагать решения, но пока вы не утвердите, не запишет ни одного символа на диск. Как войти: в диалоге нажмите Shift + Tab (один или два раза, чтобы дойти до Plan Mode), режим будет переключаться между default → acceptEdits → plan. Если вы хотите, чтобы в Plan Mode был выполнен только один запрос без переключения всей сессии, просто добавьте префикс /plan перед сообщением.
Однако официально дается и очень полезное предостережение: не впадайте в крайности и не планируйте всё подряд:
Для задач с четко определенной областью и небольшими исправлениями (например, исправление опечаток, добавление строк логов или переименование переменных) просите Claude сразу выполнять. Планирование наиболее полезно, когда вы не уверены в подходе, когда изменения затрагивают множество файлов, или когда вы не знакомы с изменяемым кодом. Если вы можете описать diff одним предложением, пропустите планирование.
Самый практичный совет — это последняя фраза: «Можете ли вы в одном предложении сказать, как это будет выглядеть после изменения?» Если да — просто делайте; если споткнулись — значит, задача достаточно сложна, и пусть он сначала составит план. Использовать Plan Mode для исправления опечатки — это просто создание лишней работы.
💡 В одном предложении: Не уверены / затрагивает много файлов / незнакомый код → сначала пусть составит план (фраза «пока не меняй» или
Shift+Tabдля входа в Plan Mode); небольшие задачи, где diff можно описать одним предложением, делайте сразу.
06 Практика: одно требование, два подхода в действии
Просто слушать теорию недостаточно, давайте проведем небольшой эксперимент, где вы своими глазами увидите разницу. Понадобится создать всего один игрушечный файл из трех строк, это не зависит от ваших текущих проектов.
Шаг 1: Создайте игрушечный файл с «подвохом» (Mac / Linux)
mkdir prompt-demo
cd prompt-demo
echo 'def average(nums):
return sum(nums) / len(nums)' > stats.pyПользователи Windows: mkdir prompt-demo и cd prompt-demo выполняются так же, а stats.py создайте в Блокноте и вставьте туда эти две строки.
В этой функции есть подвох: если передать пустой список [], то len(nums) будет равно 0, что вызовет сбой «деление на ноль». Мы будем использовать это как наш полигон.
Шаг 2: Запустите Claude в каталоге проекта
claudeОжидаемый результат: Появится экран приветствия с полем ввода внизу.
Шаг 3: Сначала используйте «Плохой запрос» и посмотрите, как он будет додумывать
@stats.py помоги мне исправить эту функциюОжидаемый результат: Скорее всего, Claude будет «угадывать», что вы хотите сделать — возможно, добавит аннотации типов, возможно, добавит строку документации, но он не знает, что вас на самом деле волнует сбой при пустом списке, направление зависит от удачи. В этом и заключается цена расплывчатых запросов: он принимает решения за вас.
Шаг 4: Попробуйте «Хороший запрос» — конкретика + контекст + критерии приемки, полный набор
В функции average в @stats.py есть баг: при передаче пустого списка она падает из-за деления на ноль.
Ожидаемое поведение: при пустом списке должна возвращаться 0.
Помоги исправить и добавь тесты: average([]) должна возвращать 0, average([2, 4]) должна возвращать 3.
После написания запусти тесты и убедись, что они проходят.Ожидаемый результат: На этот раз цепочка действий Claude предельно ясна — найти ветку с пустым списком → добавить проверку на пустоту и возврат 0 → написать два теста, которые вы указали → действительно запустить тесты → показать вам результат успешного прохождения. Он больше не гадает, чего вы хотите, потому что вы четко указали «что исправлять, как исправить и что считается успехом».
Шаг 5: Выйдите и проверьте, сохранились ли изменения
cat stats.py(В Windows PowerShell используйте type stats.py)
Ожидаемый результат: В stats.py появилась проверка на пустой список (что-то вроде if not nums: return 0). Это соответствует вашему требованию из четвертого шага = вы уже почувствовали, как это — «ясно выражать свои мысли».
Поставив два запроса рядом, разница очевидна:
| Шаг 3 ❌ Плохой запрос | Шаг 4 ✅ Хороший запрос | |
|---|---|---|
| Что исправлять | Не указано, ищет по всему файлу | Указана конкретная функция average |
| Как исправить | Не указано, импровизирует | Четко задано: при пустом списке возвращать 0 |
| Что считается успехом | Нет критериев, останавливается по своим ощущениям | Два тестовых случая + запуск для проверки |
| Ваш опыт | Смотрите на diff с мыслью «Это не то, что мне нужно» | Делает всё по вашему сценарию с первого раза |
💡 В одном предложении: Для одного и того же файла и одного и того же бага, плохой запрос заставляет Claude принимать решения за вас, а хороший запрос четко определяет «что исправлять, как исправить и что считается успехом» — сделав эти два шага своими руками, вы увидите разницу нагляднее, чем если прочитаете теорию десять раз.
07 Итоги
В этой статье мы разобрали только одну вещь: как сформулировать требование в одном предложении так, чтобы Claude точно его понял.
Сведем всё к четырем принципам. Если не можете их запомнить, сохраните эту таблицу:
| Принцип | Коротко | Как применять на практике |
|---|---|---|
| Конкретика > Размытость | Четко обозначьте область + ограничения + ориентир | «Измени average, не подключай новые библиотеки, по паттерну xxx» |
| Давайте контекст | Всё, что можно вставить, не описывайте словами | @файл, вставка полного текста ошибки, скриншоты |
| Критерии приемки | Пусть он сам сможет проверить, «получилось или нет» | Дайте тесткейсы, попросите запустить проверку; в сложных случаях используйте /goal |
| Сначала план | Для больших задач: сначала чертеж, потом ломать стену | Фраза «пока не меняй» или Shift+Tab для Plan Mode |
Теперь вы должны уметь: Переводить расплывчатое «помоги исправить» в требования, которые Claude действительно поймет — сужать область, предоставлять достаточно контекста, задавать проверяемые критерии успеха, а для сложных задач просить его сначала составить план. Этот свод правил общения — ваш «внутренний стержень» для любых действий с Claude Code в будущем — какие бы крутые фичи ни были, если запрос плохой, то и результат будет соответствующим.
Вопрос на засыпку: раз так важно «ясно выражать свои мысли», значит ли это, что некоторые правила (например, «никогда не подключать новые библиотеки в этом проекте» или «все тесты должны быть в папке
tests/») вам придется повторять каждый раз? Есть ли способ заставить Claude «запомнить» их, чтобы не работать попугаем?
Следующая статья 16 «Частые рабочие процессы» — в этой мы разбирали универсальные принципы «как ясно выражать мысли», а в следующей применим их к четырем самым частым типам задач: изучение незнакомой кодовой базы, исправление багов, рефакторинг, написание тестов. Для каждого типа будет свой стандартный подход. Принципы усвоены, пора переходить к приемам.