Справочник лучших практик: эффективная работа с AI-помощником
📚 Навигация по серии: Предыдущая статья 48 Капстоун-проект провела нас через сквозной процесс разработки приложения todo-cli от пустого каталога до финального коммита Git с использованием MCP-серверов и субагентов. Эта статья подводит итоги курса — мы не будем изучать новые функции, а соберем воедино все рекомендации по эффективной работе с Claude Code. Эти правила, выработанные разработчиками Anthropic и первыми пользователями, помогут вам тратить меньше времени на споры с AI и получать качественный результат с первой попытки.
«Промпт написан слишком лаконично».
Представьте разработчика, который только начинает работать с Claude Code. Он вводит в терминале фразу «исправь баг в логине» и нажимает Enter. Спустя минуту Claude переписывает половину файлов авторизации, ломая смежные функции. Разработчик разводит руками: «Неужели я непонятно объяснил задачу?»
Но если вы дадите это задание новому стажеру, который только сегодня пришел в офис и не видел кодовую базу вашего проекта, сможет ли он исправить ошибку правильно? Какая именно форма логина? В чем проявляется баг? В каком файле искать код? Что будет критерием успешного исправления? Вы не предоставили ни одной детали.
Попробуем переписать промпт: «Пользователи сообщают, что после истечения таймаута сессии повторная авторизация завершается ошибкой. Изучи файл src/auth/ в части обновления токенов, напиши тест для воспроизведения бага и исправь ошибку, запустив проверку тестов после изменения». С таким промптом Claude исправит ошибку с первой попытки.
Качество работы с Claude Code на 80% зависит от того, насколько правильно вы организуете взаимодействие с ним. AI обладает высокой квалификацией, но он не умеет читать ваши мысли. В этой статье мы разберем ключевые правила взаимодействия, которые вы сможете применить в своей работе уже сегодня.
Прочитав эту статью, вы получите:
- Главное системное ограничение (лимиты контекста), понимание которого лежит в основе всех остальных правил.
- Пять фундаментальных законов работы с AI: автоматическая проверка результатов, разделение этапов анализа и кодинга, конкретизация промптов, лаконичность
CLAUDE.mdи своевременная очистка сессий. - Таблицы «Как делать не надо» и «Как делать правильно» для быстрого улучшения ваших повседневных промптов.
- Карту выбора правил под конкретные рабочие сценарии и практическое упражнение для закрепления материала.
01 Главный закон: экономия контекста
Все лучшие практики разработки с помощью AI базируются на одном ограничении. Официальное руководство формулирует его так:
Большинство рекомендаций по повышению эффективности работы с Claude Code основаны на лимите контекста: память чата заполняется быстро, и по мере её заполнения качество ответов модели начинает снижаться.
Контекст диалога (context window) — это вся информация, которую Claude держит в памяти в текущий момент: история ваших сообщений, тексты прочитанных им файлов, выводы команд терминала и логи ошибок. При глубокой отладке или массовом сканировании папок объем контекста может быстро достичь десятков тысяч токенов (мы подробно разбирали токенные лимиты в статье 19).
Как только контекст переполняется, Claude начинает ошибаться — «забывает» ваши исходные требования и допускает глупые ошибки в логике.
Аналогия со стажером и школьной доской. Представьте умного и исполнительного стажера, у которого есть особенность: его оперативная память ограничена размером небольшой школьной доски. Все ваши указания, прочитанные им файлы кода и результаты тестов он вынужден записывать на этой доске. Как только доска заполняется, ему приходится стирать старые записи, чтобы записать новые. Если доска переписана несколько раз, стажер начинает забывать ваши утренние инструкции (например, требование «запускать линтер перед коммитом»), так как они были стерты под грузом последующих логов.
Все наши дальнейшие рекомендации направлены на то, чтобы помочь этому «стажеру» эффективно использовать место на своей доске:
- Предоставить ему инструменты самостоятельной проверки, чтобы вам не приходилось контролировать каждый шаг (экономия вашего времени и места на доске от лишних обсуждений).
- Заставить его сначала планировать, а затем писать код, чтобы не тратить место на записи неверных вариантов реализации.
- Формулировать задачи конкретно с первого раза, исключая лишние уточняющие диалоги.
- Держать постоянные памятки в лаконичном виде, чтобы они не занимали половину доски со старта сессии.
- Очищать историю диалога при первых признаках того, что обсуждение зашло в тупик.
Запомните это системное ограничение. Все правила, описанные ниже, направлены на решение одной задачи — экономию контекста.
💡 Резюме в одной фразе: Лимит контекста — главное ограничение AI; все правила эффективной работы направлены на экономию памяти чата, чтобы Claude не терял качество ответов при долгих диалогах.
02 Правило 1: предоставление инструментов самопроверки
Это наиболее важное правило для организации автономной работы AI:
Предоставьте Claude автоматический способ проверки результатов его работы — автотесты, сборку проекта или скрипты сравнения скриншотов. Это разграничивает сессии, в которых вам приходится контролировать каждый шаг, и сессии, которые выполняются автономно.
Почему это критично? Ответ дает документация:
При отсутствии автоматических проверок Claude останавливается, как только код «выглядит готовым». В этом случае вы берете на себя роль тестировщика, тратя время на ручную проверку каждого изменения.
Вы превращаетесь из архитектора в ручного контролера качества. Но если передать Claude скрипт проверки, логический цикл замыкается внутри сессии: AI вносит изменения, запускает скрипт, анализирует логи ошибок, исправляет код и повторяет цикл до тех пор, пока тесты не завершатся успешно.
Аналогия с приемкой ремонта. Вы нанимаете строителей для укладки плитки. Если у них нет четких критериев качества, они сдадут работу, как только плитка будет лежать на полу по принципу «вроде нормально выглядит». Все неровности и пустоты вам придется искать самостоятельно. Но если перед началом работы вы выдадите им чек-лист проверки (например, «проверить уровнем каждую стену, простучать на пустоты»), они будут обязаны провести эти тесты самостоятельно перед тем, как позвать вас на приемку. Автотесты — это такой чек-лист для Claude.
Варианты автоматических проверок:
- Автотесты (unittest, pytest, jest) — самый надежный способ проверки логики.
- Сборка проекта (compiler build exit codes) — проверка отсутствия синтаксических ошибок.
- Инструменты линтинга (linter) — проверка форматирования кода.
- Скрипты сравнения скриншотов — для проверки верстки (тема статьи 17).
Примеры формулирования задач с автопроверкой:
| Задача | ❌ Без автопроверки | ✅ С автопроверкой |
|---|---|---|
| Создание функции | «Напиши функцию проверки формата почты» | «Напиши функцию validateEmail. Входные параметры: user@example.com (true), invalid (false). После создания запусти тесты для проверки» |
| Рефакторинг UI | «Сделай карточку товара красивее» | «[Прикрепляем изображение макета]. Измени стили карточки по макету. После завершения сделай скриншот и сравни с оригиналом, исправь расхождения» |
| Исправление сборки | «Сборка падает на этапе компиляции» | «Сборка завершается с ошибкой [лог ошибки]. Исправь ошибку и убедись в успешном прохождении сборки. Устрани первопричину, а не маскируй ошибку» |
Обратите внимание на правую колонку: каждый промпт заканчивается указанием запустить конкретную команду проверки.
Вы можете настраивать уровень строгости проверок в зависимости от важности задачи:
- Разовое указание в промпте — подходит для простых повседневных задач («напиши код и запусти тесты»).
- Использование команды
/goal— фиксирует проверку как обязательное условие завершения текущей сессии чата. - Настройка Stop hooks — жесткое правило, блокирующее коммит, если тесты сборки завершились с ошибкой (тема статьи 33).
Для простых задач достаточно добавлять фразу «запусти тесты и убедись в их успешности» в конце каждого запроса.
Также требуйте от Claude предоставления логов тестов, а не просто утверждения «все работает»:
Просите Claude выводить подтверждение успешности прохождения проверок: логи тестов, статус сборки или скриншот верстки.
Визуальный лог успешного прохождения тестов в чате гарантирует корректность выполнения задачи до фиксации изменений.
💡 Резюме в одной фразе: Всегда завершайте промпты указанием запустить тесты или сборку для проверки результатов. Это позволяет Claude самостоятельно исправлять свои ошибки до передачи кода вам.
03 Правило 2: разделение этапов планирования и кодинга
Второй закон защищает проект от хаотичных изменений в коде.
Не разрешайте Claude сразу приступать к написанию кода для сложных задач. Разделяйте процесс на этапы: сбор информации (исследование), составление плана изменений (планирование) и реализация кода (программирование).
Вспомним четыре этапа работы из официального руководства:
布局： 
Схема наглядно иллюстрирует этот процесс: сначала мы исследуем кодовую базу и составляем план в режиме Plan Mode, затем одобряем план, переходим в обычный режим для написания кода и фиксируем стабильный коммит.
Почему это важно? Если стажер сразу начнет вносить правки в крупный проект, не разобравшись в архитектуре, он может написать код, несовместимый с другими модулями. Сначала он должен изучить документацию, составить схему изменений и показать её вам. Для этого этапа в Claude Code предназначен режим планирования Plan Mode (вызываемый по Shift+Tab, подробнее в статье 35).
Пример промпта на этапе исследования:
Изучи структуру папки src/auth и объясни, как устроен механизм авторизации пользователей. Сделай краткое резюме без изменения кода.В этом режиме Claude может читать файлы, но не имеет права вносить правки. После сбора информации попросите составить план:
Мы планируем добавить авторизацию через Google OAuth. Какие файлы нужно изменить? Опиши пошаговый план изменений.Если предложенный план вас не устраивает, вы можете отредактировать его текст прямо в чате (сочетание Ctrl+G открывает редактор плана). После согласования плана переведите сессию в обычный режим работы для написания кода.
Исключение из правила планирования:
Для простых локальных задач (исправление опечатки, добавление лога, переименование переменной) планирование не требуется, поручайте Claude реализацию кода сразу.
Ориентируйтесь на простое правило:
Если вы можете описать изменения одной фразой для git diff — планирование не нужно, пишите код сразу.
Если задача затрагивает более трех файлов или логику работы незнакомого вам модуля — сначала запускайте этап планирования в Plan Mode.
💡 Резюме в одной фразе: Для сложных задач сначала запускайте этап исследования и планирования в Plan Mode, согласовывайте архитектуру и только потом переходите к написанию кода. Простые правки в один файл делайте сразу.
04 Правило 3: конкретизация промптов
Это правило напрямую влияет на количество необходимых итераций правок.
Чем точнее сформулирована задача в первом промпте, тем меньше уточнений потребуется Claude для написания верного кода.
Использование названий файлов, указание граничных условий и ссылки на существующие примеры в проекте значительно повышают качество кода. Сравним примеры формулирования задач:
| Параметр | ❌ Неконкретно | ✅ Конкретно |
|---|---|---|
| Ограничение области | «Напиши тесты для файла auth.py» | «Напиши тесты для auth.py, покрывающие сценарий с истекшим токеном, без использования моков» |
| Указание источников | «Почему API класса Parser такой сложный?» | «Изучи git-историю файла Parser.py и объясни, какие архитектурные изменения привели к текущей структуре API» |
| Использование шаблонов | «Создай форму отправки отзыва» | «Изучи структуру компонента UserCard.vue. Используя аналогичный стиль кодирования, создай форму отправки отзыва FeedbackForm.vue без подключения сторонних библиотек» |
| Описание симптомов | «Исправь баг в форме входа» | «Пользователи получают ошибку при повторном входе после таймаута. Проверь код в src/auth/, особенно метод регенерации токена. Напиши тест для воспроизведения и исправь ошибку» |
Правая колонка содержит конкретные рамки задачи: названия методов, ссылки на файлы-ориентиры и критерии успешного исправления.
Особое внимание уделите приему «Использование шаблонов». Вместо того чтобы описывать правила оформления кода (отступы, именование переменных, обработку ошибок), просто укажите Claude на файл, который вы считаете эталонным: «посмотри, как написан метод X, и сделай новый метод Y в том же стиле». Это гарантирует соответствие кода стандартам вашего проекта без написания длинных промптов-инструкций.
Исключение из правила конкретизации:
Открытые неконкретные вопросы полезны на этапе исследования кодовой базы.
Запрос «Как бы ты оптимизировал этот класс?» позволяет Claude предложить архитектурные идеи, о которых вы могли не подумать. Используйте неконкретные запросы для генерации идей, а конкретные — для написания кода.
Правила предоставления контекста
Для обеспечения Claude информацией используйте встроенные механизмы:
- Символ
@— для быстрого прикрепления файлов проекта к запросу. - Вставка изображений — копируйте скриншоты ошибок или макеты верстки прямо в окно чата (тема статьи 17).
- Ссылки на документацию — передавайте URL-адреса справочных систем.
- Передача через конвейер — используйте команды вида
cat error.log | claudeдля отправки логов. - Поиск силами AI — просите Claude самостоятельно найти нужные файлы с помощью grep или find.
💡 Резюме в одной фразе: Пишите промпты с максимальной конкретикой: указывайте точные файлы, ссылайтесь на примеры кода в проекте и описывайте критерии успешного завершения задачи. Открытые вопросы оставляйте для исследований.
05 Правило 4: лаконичность файла CLAUDE.md
Файл CLAUDE.md является базой знаний проекта, считываемой при каждом старте чата. Но помните ключевое правило его наполнения: краткость важнее объема.
Поскольку файл CLAUDE.md загружается в контекст автоматически, его избыточный размер сокращает полезный объем оперативной памяти AI.
Аналогия с запиской для сменщика. Вы оставляете коллеге, принимающему смену, короткую записку: «в 3:00 сервер перезагружается автоматически», «пароль от базы данных изменен» — 3-4 важные строчки, которые он легко запомнит. Но если вы оставите ему распечатку всей должностной инструкции на 50 страниц, он просто отложит её в сторону и пропустит важные предупреждения. Файл CLAUDE.md работает так же: он должен содержать только самые критичные правила.
Документация предупреждает:
Пишите лаконично. Для каждого правила задайте вопрос: «Приведет ли его удаление к ошибкам в действиях Claude?» Если нет — удалите правило. Избыточный объем файла CLAUDE.md приведет к тому, что Claude начнет игнорировать ваши текущие промпты.
Частые ошибки при наполнении файла:
- Запись истории разработки проекта и архитектурных концепций. Claude может изучить структуру проекта самостоятельно по коду файлов, не тратьте на это память чата.
- Внесение правил, которые нужны редко (например, правила создания релизных веток раз в месяц). Перенесите эти инструкции в специализированные навыки (Skills, статья 26).
Сравним рекомендации по наполнению файла CLAUDE.md:
| ✅ Записывать в файл | ❌ Удалять из файла |
|---|---|
| Уникальные команды сборки и запуска тестов | Архитектурные рассуждения, которые понятны из кода |
| Отличия вашего код-стиля от стандартов языка | Общепринятые правила программирования (например, "пиши чистый код") |
| Команды запуска конкретных проверок линтера | Справочные материалы и API сторонних библиотек (замените ссылками) |
| Специфические требования к коммитам и веткам | Инструкции, которые меняются каждый день |
Для акцентирования внимания на важных правилах используйте в тексте файла ключевые слова IMPORTANT или YOU MUST. Если правил становится много, разделяйте их по файлам, ссылаясь на них через синтаксис @docs/git-rules.md внутри основного CLAUDE.md.
💡 Резюме в одной фразе: Файл
CLAUDE.mdдолжен быть коротким и содержать только уникальные команды сборки, тестов и специфические правила кодовой базы. Всю справочную информацию и концепции удаляйте для экономии контекста.
06 Правило 5: своевременная очистка сессий при ошибках
Пятый закон определяет правила гигиены диалога.
Если Claude начал путаться в коде и предлагать неверные варианты, не пытайтесь продолжать диалог в текущей сессии. Очистите историю и начните заново.
В процессе работы вы можете использовать инструменты отката:
- Прерывание выполнения — клавиша
Escостанавливает запущенную Claude команду, сохраняя контекст диалога. Полезно, если вы увидели, что AI начал сканировать не ту папку. - Откат состояния (倒带) — команда
/rewindили двойное нажатиеEscвозвращает файлы проекта и историю диалога к выбранной контрольной точке (тема статьи 37). - Очистка сессии — команда
/clearполностью удаляет историю диалога, освобождая контекст.
Критически важное правило для сложных ситуаций:
Если вы предприняли две безуспешные попытки исправить ошибку в одном чате, текущий контекст переполнен неверными гипотезами и логами падений. Запустите команду
/clear, сформулируйте промпт заново с учетом полученных уроков и начните работу в чистой сессии.
Не пытайтесь «дожать» ошибку в длинном диалоге. Переполнение оперативной памяти AI неверными вариантами кода сделает его последующие ответы хаотичными. Очистите чат через /clear, укажите в новом промпте: «не используй подход X, проблема заключается в Y» — и Claude найдет решение за один шаг.
Для поддержания порядка используйте рекомендации:
- Выносите исследования в субагентов — просите субагентов найти информацию в файлах, чтобы их тексты не засоряли память основного чата (статья 23).
- Ведите историю сессий как ветки git — используйте флаги
claude --continueили--resumeдля переключения между логическими задачами, давая сессиям понятные имена (например,oauth-auth).
💡 Резюме в одной фразе: При признаках зацикливания или после двух неудачных попыток исправления выполните команду
/clearи начните диалог в чистой сессии, добавив полученный опыт в новый промпт. Исследования поручайте субагентам.
07 Правило 6: горизонтальное масштабирование задач
После того как вы научились эффективно работать с одной сессией, переходите к масштабированию процессов.
Не перегружайте одного агента разнородными задачами. Распределяйте работу по параллельным сессиям и автоматическим скриптам.
Методы горизонтального масштабирования:
- Параллельные сессии с изоляцией worktree — запуск независимых задач в разных папках проекта для исключения конфликтов файлов (тема статьи 41).
- Схема «Разработчик и Ревьюер» — написание кода выполняет одна сессия, а его аудит перед коммитом — другая, запущенная в чистом контексте. Это исключает субъективность оценки качества кода.
- Пакетный запуск через скрипты CLI — использование флага
claude -pдля автоматической обработки множества файлов без открытия интерактивного чата. - Автоматическое код-ревью в CI/CD — подключение экшенов GitHub Actions для автоматической проверки пул-реквестов (тема статьи 44).
При запуске автоматических проверок линтерами или авторевьюерами помните: AI может находить гипотетические проблемы даже в корректном коде. Не пытайтесь исправить каждое мелкое предупреждение ревьюера, если это ведет к усложнению архитектуры. Вносите только те правки, которые влияют на работоспособность приложения.
💡 Резюме в одной фразе: Масштабируйте разработку разделением задач по параллельным сессиям через worktree, использованием независимых агентов-ревьюеров и автоматизацией рутины в скриптах
claude -pи CI/CD.
08 Карта выбора правил под задачи
Для удобства использования мы собрали все рекомендации в единую карту выбора решений:
| Рабочая ситуация | Какую практику применить | Команда / Настройка |
|---|---|---|
| AI вносит изменения, но код не работает | Предоставить инструмент самопроверки | Добавить в промпт: «после изменения запусти тесты [команда]» |
| Требуется реализовать крупную фичу с изменением архитектуры | Разделить этапы: планирование и кодинг | Начать в Plan Mode (Shift+Tab), составить SPEC.md, согласовать и начать кодинг |
| Код пишется не в стиле проекта, подключаются лишние библиотеки | Конкретизировать промпт и дать примеры | Использовать ссылки @file, указать файл-шаблон: «пиши в стиле [пример]» |
| Claude начал игнорировать правила сборки и коммитов | Очистить CLAUDE.md от мусора | Сократить размер CLAUDE.md, оставив только уникальные команды и критичные правила |
| Код сломался, попытки исправить в чате делают его еще хуже | Выполнить откат и очистить контекст | Запустить /rewind или git reset --hard, затем выполнить /clear и начать заново |
| Нужно решить несколько не связанных между собой задач в проекте | Запустить параллельные сессии | Использовать флаги claude --worktree [имя] в разных терминалах |
💡 Резюме в одной фразе: При возникновении проблем сверяйтесь со справочником: ошибки логики лечатся автотестами, архитектурные сбои — планированием, игнорирование правил — сокращением CLAUDE.md, а зацикливание — командой
/clear.
09 Практический тест: сравнение эффективности промптов
Убедимся в силе правильного написания промптов на практике. Мы сравним результаты работы Claude при использовании размытого запроса и конкретного запроса с автопроверкой.
Практика выполняется в локальной папке проекта. Требуется установленный Python 3.
Шаг 1: Создаем тестовую среду
Выполните в терминале:
mkdir cc-best-practice-demo && cd cc-best-practice-demo && claudeШаг 2: Тест 1 — отправка размытого запроса
Отправим стандартный промпт новичка:
Напиши функцию, которая проверяет сложность пароля.Ожидаемый результат: Claude сгенерирует код функции проверки пароля. Однако правила проверки (длина, наличие спецсимволов) он придумает самостоятельно. Код не будет содержать тестов, и вам придется верить ему на слово или проверять работоспособность вручную. Выйдите из чата командой
/clear.
Шаг 3: Тест 2 — отправка конкретного запроса с автопроверкой
/clearОтправим оптимизированный по правилам статьи промпт:
Напиши функцию isStrongPassword(pwd) на Python и сохрани её в password.py.
Правила проверки: длина от 8 символов, наличие минимум одной заглавной буквы и одной цифры.
Примеры для тестов: 'Abc12345' (True), 'abc12345' (False - нет заглавной), 'Abcdefgh' (False - нет цифры).
После написания кода создай тесты в test_password.py, запусти их и пришли мне лог успешного прохождения.Ожидаемый результат:
- Claude создаст файл
password.pyс точным соответствием указанным правилам.- Будет создан файл тестов
test_password.pyс переданными примерами.- Claude самостоятельно запустит команду тестирования (вы увидите лог вызова инструмента в чате).
- В чат будет выведен лог успешного прохождения тестов.
- Вы получаете протестированное рабочее решение за один шаг без необходимости ручной проверки.
Этот простой эксперимент наглядно иллюстрирует разницу: конкретизация требований и добавление автопроверок избавляют вас от рутинного тестирования кода и гарантируют точное выполнение задачи.
💡 Резюме в одной фразе: Практический эксперимент подтверждает: размытый промпт перекладывает тестирование кода на ваши плечи, в то время как конкретный запрос с инструкцией самопроверки заставляет Claude сдать полностью протестированный и рабочий код.
10 Заключение
Мы собрали воедино все рекомендации по эффективному использованию Claude Code в повседневной практике.
Резюмируем ключевые правила работы:
| Закон | Описание | Главная рекомендация |
|---|---|---|
| 1. Экономия контекста | Память чата ограничена и быстро заполняется | Используйте субагентов для локальных поисков и очищайте чат при сбоях |
| 2. Автопроверка | AI должен уметь проверять свою работу | Всегда добавляйте команду запуска тестов или сборки в конец промпта |
| 3. Планирование | Сначала схема, затем код | Для крупных задач используйте режим Plan Mode (Shift+Tab) и SPEC.md |
| 4. Конкретика | Точные промпты экономят время | Указывайте имена файлов, граничные условия и приводите файлы-примеры |
| 5. Лаконичность CLAUDE.md | Короткие правила работают лучше | Удаляйте из CLAUDE.md общеизвестные факты и справочные материалы |
| 6. Гигиена сессий | Очистка чата при зацикливании | После двух неудачных попыток запускайте /clear и начинайте с чистого листа |
Соблюдение этих правил взаимодействия превратит Claude Code из простого автодополнителя строк в надежного и эффективного партнера по разработке программных продуктов.
В следующей статье 50 «Каталог антипаттернов: как делать не надо» мы разберем типичные ошибки. Какие действия разработчиков снижают эффективность AI? Мы изучим примеры неправильного проектирования, избыточного доверия к автопилоту, захламления контекста и игнорирования безопасности с реальными примерами «вредных советов» и способами их исправления.