Claude Code меняет соседние файлы, переходит к рефакторингу или затрагивает настройки, о которых вы не просили.
Быстрое решение: задайте в CLAUDE.md четыре правила — ограничить область задачи, сначала предложить план, вносить минимальные изменения и проверять результат; помните, что это проектные инструкции, а не запрет на уровне доступа.
Эта статья для разработчиков, которым нужно удерживать изменения Claude Code в рамках конкретной задачи.
Она пригодится техническим руководителям, настраивающим общие правила проекта.
Также она поможет инженерам, которые хотят превратить идеи Andrej Karpathy Skills в проверяемый рабочий процесс.
Как CLAUDE.md задаёт границы для Claude Code
CLAUDE.md помогает сообщить Claude Code, как работать именно с вашим проектом: какие соглашения соблюдать, какие проверки учитывать и как действовать при неоднозначном задании. Документация описывает этот файл как часть механизма проектной памяти и инструкций, а не как автономную систему блокировки операций. Подробности о назначении и загрузке таких файлов приведены в документации Claude Code о проектной памяти.
Здесь важно различать инструкцию и техническое ограничение. Формулировка «не меняй файлы вне каталога» сообщает модели ожидаемое поведение, но сама по себе не отнимает у процесса доступ к остальным файлам. Поэтому она способна снизить вероятность лишних изменений, но не гарантирует, что модель правильно поймёт границы и всегда им последует. Если вам необходимо ограничить доступ к конкретным действиям, настройте соответствующие разрешения отдельно: официальная документация о permissions рассматривает управление допустимыми действиями как самостоятельный механизм.
Риск лишних правок часто возникает не из-за недостатка текста в CLAUDE.md, а из-за того, что правила допускают разные толкования:
- Цель смешана со способом реализации. Просьба «улучшить обработку ошибок» не объясняет, нужно ли менять одну функцию или перестраивать обработку во всём модуле.
- Не названы границы. Если не указать допустимые файлы и побочные изменения, Claude Code может затронуть соседние конфигурации, тесты или документацию.
- Не определён порядок действий. Инструмент может перейти к редактированию до того, как вы заметите, что запрос понят неверно.
- Проверка описана расплывчато. Просьба «убедиться, что всё работает» не сообщает, какие проверки доступны и какие результаты нужно отчитаться.
- Инструкции расходятся. Правило «не меняй API» может конфликтовать с задачей, в которой изменение API необходимо, если порядок согласования не установлен.
Можно ли с помощью CLAUDE.md запретить Claude Code выполнять изменения без подтверждения?
В файле можно потребовать, чтобы инструмент сначала описывал план и запрашивал согласование в оговорённых ситуациях. Однако текстовая инструкция не равна техническому запрету: не считайте её заменой разрешениям, контролю изменений и ревью. Для защиты, зависящей от конкретного действия, сверяйте ожидаемое поведение с настройками доступа и другими средствами контроля из официальной документации Claude Code.
Формулировка «следуй этому правилу» задаёт ожидаемое поведение, но не создаёт границу доступа. Если нарушение должно быть технически невозможным, одного CLAUDE.md недостаточно.
Отделите Andrej Karpathy Skills от правил вашего проекта
Название Andrej Karpathy Skills связано с подходом к формализации рабочих инструкций для кодирующих агентов. Но название репозитория само по себе не подтверждает авторство Andrej Karpathy и не превращает его содержание в официальный стандарт Claude Code. Чтобы установить, что именно было опубликовано и кем, сопоставляйте оригинальную публикацию Andrej Karpathy с содержимым репозитория, посвящённого Andrej Karpathy Skills. Не приписывайте автору публикации или репозитория формулировки, которые нельзя подтвердить первоисточником.
Для настройки рабочего процесса разделяйте три понятия:
- CLAUDE.md — файл с контекстом и инструкциями для работы с проектом.
- Skills — отдельный механизм, описанный в документации Claude Code о Skills. Это не другое название CLAUDE.md.
- Права и технические ограничения — самостоятельные настройки, определяющие, какие действия допустимы. Они не возникают автоматически от того, что вы записали правило в проектный файл.
Практическая ценность Andrej Karpathy Skills для этой задачи — не в том, чтобы скопировать набор формулировок и считать его готовой политикой. Возьмите идею явных, повторяемых рабочих правил и адаптируйте её к своему репозиторию. Инструкция для библиотеки, приложения и инфраструктурного проекта может требовать разных границ изменений, проверок и условий согласования. Привязывайте правила к текущему коду и задачам команды, а не к универсальному представлению о том, как должен работать любой агент.
Настройте четыре правила для управляемых изменений
Первое правило: перечислите разрешённую область
Укажите, что требуется сделать, какие файлы или каталоги можно менять и что запрещено менять без отдельного согласования. Не полагайтесь только на фразу «не выходи за рамки задачи»: её границы разные участники могут понять по-разному.
Пример для адаптации:
Для каждой задачи сначала определи затрагиваемые файлы. Меняй только файлы, необходимые для выполнения запроса. Не выполняй несвязанный рефакторинг, не меняй зависимости, конфигурацию и публичные интерфейсы без отдельного согласования. Если требуемая правка выходит за указанные границы, сначала объясни причину и запроси подтверждение.
Измените пример под структуру проекта: добавьте конкретные каталоги или названия файлов, если они известны. Но не представляйте список разрешённых путей как обещание, что остальные пути недоступны. Это правило просит Claude Code соблюдать границы, а не изолирует репозиторий технически.
Как задать правило, чтобы Claude Code менял только выбранные файлы?
Назовите разрешённые пути в самом задании и закрепите в CLAUDE.md требование сначала перечислять планируемые изменения. Если обнаруживается необходимость выйти за пределы списка, попросите инструмент остановиться и запросить подтверждение. Перед принятием результата сравните план с фактически изменёнными файлами: инструкция полезна только тогда, когда вы проверяете её соблюдение.
Второе правило: сначала план, затем редактирование
Попросите до внесения изменений кратко изложить понимание задачи, перечислить предполагаемые файлы, назвать последовательность действий и указать способ проверки. Так вы сможете обнаружить неверное понимание раньше, чем оно превратится в diff. План, однако, не гарантирует правильную реализацию: после него всё равно нужны проверка изменений и анализ результата.
Представьте небольшую задачу: нужно исправить отображение сообщения об ошибке в одном компоненте. До редактирования Claude Code должен указать, какой компонент намерен проверить, какие файлы предлагает изменить, какие соседние части проекта не затрагивает и как будет проверять результат. Если из плана следует изменение общего слоя обработки ошибок или другого неочевидного файла, обсудите расширение объёма до начала работы.
Что записать в CLAUDE.md, чтобы план был полезным, а не формальным?
Попросите включать в план цель, предполагаемые файлы, исключённые побочные изменения и способ верификации. Добавьте условие остановки: при неоднозначном требовании, необходимости менять дополнительные файлы или затрагивать публичное поведение инструмент сначала задаёт вопрос. Не требуйте длинного плана для каждой мелкой задачи — включайте сведения, по которым вы можете принять решение до начала редактирования.
Третье правило: сохраняйте минимальный diff
Требуйте вносить только изменения, необходимые для запроса, придерживаться стиля и архитектурных решений проекта, не заменять зависимости и не перестраивать код «заодно». Это ограничивает объём, который вам предстоит проверить, и упрощает поиск причины возможной регрессии.
Минимальный diff не означает минимальное количество строк любой ценой. Если исправление требует изменить тест, обработать пограничный случай или затронуть связанные файлы, исключать такие изменения ради внешне компактного diff не нужно. Критерий — связь каждой правки с задачей, а не число строк.
Пример формулировки:
Реализуй только изменения, необходимые для выполнения задачи. Сохраняй существующие соглашения и архитектуру. Не переименовывай несвязанные элементы, не форматируй файлы целиком и не добавляй зависимости без необходимости. Если исправление неизбежно затрагивает дополнительные файлы, объясни связь и укажи это до продолжения.
После выполнения проверь перечень изменённых файлов и сам diff. Для каждого изменения спросите: «Какую часть запроса оно выполняет?» Если связь не ясна, попросите объяснение или отклоните несвязанную правку. Отдельно убедитесь, что вместе с лишними изменениями не исключены обязательный тест или необходимая корректировка. Малый diff не должен превращаться в неполное исправление.
Четвёртое правило: требуйте проверку и точный отчёт
Укажите в CLAUDE.md, что для каждой задачи нужно выбирать подходящие проверки, уже принятые в проекте, и сообщать, что именно было выполнено. Не записывайте универсальную команду тестирования, пока не подтвердили, что она существует и подходит репозиторию. Сначала изучите инструкции проекта, конфигурационные файлы и существующие сценарии сборки, тестирования или статического анализа.
Попросите Claude Code завершать работу отчётом из четырёх пунктов:
- Какие файлы изменены и зачем.
- Какие проверки действительно запускались.
- Каков фактический результат каждой проверки.
- Какие проверки не выполнялись и почему.
Например, отчёт «тесты не запускались: в текущем окружении не найдена подходящая команда проекта» честнее, чем неподтверждённое «всё работает». Если проверка завершилась ошибкой, результат нужно указать прямо, не создавая впечатления, будто ошибка не относится к задаче. Если проект не содержит подходящего способа проверки, это также следует сообщить, а не придумывать команду.
Как потребовать проверку результата через CLAUDE.md?
Опишите последовательность: определить подходящие проверки по существующим материалам проекта, выполнить доступные проверки и перечислить пропущенные вместе с причиной. Подход согласуется с советами официального руководства по рабочим практикам Claude Code, но конкретный набор тестов должен исходить из вашего репозитория, а не из шаблона для чужого проекта.
Выберите способ контроля по уровню риска
Перед работой определите, достаточно ли проектных инструкций или нужны дополнительные меры. Сравните варианты по тому, какую проблему они решают и чего от них ожидать:
| Вариант | Когда подходит | Что он даёт | Чего не гарантирует |
|---|---|---|---|
| Правила в CLAUDE.md | Нужно закрепить соглашения проекта, границы задачи и порядок отчёта | Даёт Claude Code постоянный контекст и проверяемые ожидания | Не блокирует доступ к файлам и не гарантирует соблюдение каждого указания |
| План до редактирования | В задаче есть риск неоднозначного понимания или неожиданных файлов | Позволяет заметить неверный объём до появления изменений | Сам по себе не подтверждает правильность реализации |
| Проверка списка файлов и diff | Нужно выявить побочные правки после выполнения задачи | Показывает, что фактически изменено и связано ли это с запросом | Не доказывает, что код корректен или тесты пройдены |
| Разрешения и технические ограничения | Важно ограничить допустимые действия, а не только попросить их не выполнять | Может обеспечить отдельный уровень контроля доступа при правильной настройке | Требует настройки и проверки; не заменяет ревью результата |
Используйте таблицу как выбор по ситуации: если задача невысокого риска и охват понятен, начните с ясных инструкций и проверки diff. Если план затрагивает дополнительные файлы, публичный интерфейс, зависимости или конфигурацию, остановитесь и запросите объяснение и согласование. Если недопустимое действие должно быть ограничено технически, настройте соответствующие разрешения, а не полагайтесь на формулировку в CLAUDE.md. Если проект не имеет однозначного способа проверки, зафиксируйте это в отчёте и согласуйте проверку с ответственным разработчиком.
Проверьте правила на малой задаче и закрепите результат
Оценивайте CLAUDE.md не по убедительности формулировок, а по тому, упрощают ли они работу и проверку. Возьмите задачу с ясной целью и ограниченным охватом. До начала работы сохраните текущее состояние проекта и определите, какие файлы не должны затрагиваться. Затем пройдите цикл от плана до отчёта.
До редактирования сравните предложенный план с запросом: совпадает ли цель, объяснён ли каждый предполагаемый файл, назван ли подходящий способ проверки? Если план включает дополнительную область, уточните её до начала правок, а не после появления большого diff.
После редактирования сопоставьте фактически изменённые файлы с планом. Проверьте diff на несвязанные перемещения, переименования, форматирование, новые зависимости и изменения конфигурации. Каждое отклонение должно быть объяснено. Объяснение не означает автоматическое согласие: решите, действительно ли дополнительная работа нужна.
При проверке убедитесь, что отчёт описывает реально выполненные действия. Сопоставьте его с выводом проверок и состоянием проекта; отметьте, что осталось непроверенным. Если подходящую проверку не запускали, выясните причину и определите дальнейшее действие до принятия изменения.
По итогам скорректируйте CLAUDE.md там, где правило оказалось двусмысленным, слишком широким или конфликтующим с другим указанием. Например, фразу «работай самостоятельно» можно согласовать с требованием подтверждения, перечислив исключения: выход за указанные пути, изменение зависимостей, публичного интерфейса или сценария сборки. Если правило повторяется в проектных инструкциях и другом механизме конфигурации, установите, какой источник задаёт требование, и устраните противоречие.
Для технической защиты файлов и команд рассматривайте не только текстовые инструкции. Официальные документы о permissions описывают разрешения, а документация о hooks — отдельный механизм автоматизации действий вокруг рабочего процесса. Их применение требует настройки и проверки под ваш репозиторий; упоминание hook в CLAUDE.md само по себе не устанавливает ограничение.
Перед принятием правки проверьте четыре пункта: область совпадает с задачей; план не расходится с фактическими изменениями; diff не содержит необъяснимой работы; отчёт отделяет выполненные проверки от пропущенных.
Решите, где заканчивается CLAUDE.md и начинается контроль доступа
Четыре правила особенно полезны, если вы хотите сделать взаимодействие предсказуемее и сократить число несвязанных изменений. Они дают модели контекст до работы и создают понятные критерии ревью. Но если команда требует, чтобы определённые действия вообще не могли выполняться без разрешения, одной записи в CLAUDE.md недостаточно. Совмещайте инструкции с проверкой diff, системой контроля версий, ревью и необходимыми настройками доступа. Даже подробные советы официального руководства по Claude Code не отменяют проверки конкретного результата в вашем проекте.
В ближайшей задаче выберите небольшой, хорошо ограниченный участок работы и пройдите весь цикл: область, план, минимальный diff, проверка. Затем обновляйте CLAUDE.md по наблюдаемым отклонениям, а не добавляйте общие запреты на всякий случай. Такой подход покажет, какие правила действительно помогают команде, а где нужны разрешения или более строгий процесс ревью.
Если вы работаете на собственном компьютере, учитывайте реальные ограничения: доступность локальной машины зависит от её состояния, окружение нужно поддерживать самостоятельно, а общий временный стенд для команды может потребовать отдельной настройки. Аренда Mac не заменяет CLAUDE.md и не устраняет риск избыточных изменений, однако может подойти, если вам нужен отдельный Mac для временного тестирования или удалённой рабочей среды. Для сравнения доступны варианты аренды Mac mini и Mac mini в США на восточном побережье. Если нагрузка постоянная, нужны физические интерфейсы или локальное окружение, которое нельзя перенести, сначала оцените собственное оборудование: аренда подходит не каждому проекту.