Руководство по CLAUDE.md: как записать правила проекта в его память
📚 Навигация по серии: Предыдущая статья 17 Изображения и мультимодальность научила вас отправлять скриншоты и изображения с ошибками напрямую в Claude. Эта статья меняет направление — мы запишем «правила» проекта в его память раз и навсегда, чтобы он автоматически соблюдал их при каждом запуске, и вам не приходилось повторять их каждый день.
Все говорят, что CLAUDE.md должен быть как можно более подробным. Но, честно говоря, самый бесполезный CLAUDE.md — это тот, в котором 300 строк, и Claude ни одну из них не выполнил.
Представьте себе CLAUDE.md, оставленный предыдущим разработчиком в проекте, который вы приняли. В нём красноречиво описываются: предыстория компании, видение продукта, представление команды, история выбора технологий... И только прокрутив до второго экрана, вы видите полезную фразу: «используйте pnpm, а не npm». И каков результат? Claude всё равно то и дело выполняет для вас npm install.
Проблема не в том, что он не слушается, а в том, что это правило погребено под двумя сотнями строк чепухи, и его внимание давно рассеялось.
CLAUDE.md (файл памяти проекта Claude) — это мощный инструмент, если он написан хорошо, и обуза, если написан плохо. При каждом сеансе он занимает ваше контекстное окно. Чем он более раздут, тем меньше места остаётся для реальной работы. Сегодня мы разберём это по полочкам: на какие уровни он делится, что следует писать, чего писать не следует, как ссылаться на другие файлы и как поддерживать его кратким.
Прочитав эту статью, вы получите:
- Понимание того, за что отвечают три уровня CLAUDE.md (пользовательский / проектный / уровень подкаталога) и как организован порядок их загрузки.
- Список того, что «следует писать, а что нет», чтобы избежать 90% ошибок новичков, которые заполняют его чепухой.
- Правильный способ использования синтаксиса
@для ссылки на другие файлы, а также его реальную цену для контекста. - Официальный способ временного добавления памяти в сеансе, плюс таблицу сравнения «хорошо vs плохо» в качестве шаблона.
ℹ️ В этой статье рассматривается только то, как правильно написать и поддерживать файл CLAUDE.md. Использование
/initдля генерации в один клик обсуждалось в 12 «Инициализация проекта», а более широкая автоматическая память (auto-memory) будет подробно рассмотрена в статье 25 «Система памяти».
01 Сначала поймите: что же такое CLAUDE.md на самом деле
Дадим сразу вывод: CLAUDE.md — это «постоянная инструкция», которую вы пишете для Claude. При каждом открытии сеанса он сначала читает её, загружая в свою память в качестве контекста проекта.
Зачем это нужно? Потому что каждый сеанс Claude Code начинается с чистого листа. То, что вы настойчиво объясняли в прошлый раз — «использовать pnpm, не трогать каталог legacy, тесты запускать вот так», — в этот раз он совершенно не помнит. Без CLAUDE.md вам пришлось бы объяснять всё заново каждый раз. Разве это не раздражает?
Аналогия: справочник для нового сотрудника. В первый день работы новичка вы не будете стоять рядом с ним весь день, устно диктуя правила. Вы даёте ему руководство: для чего нужен проект, как отправлять код, какие минные поля следует обходить. Он сам прочитает это и приступит к работе. CLAUDE.md — это справочник для адаптации Claude, причём такой, который он будет перечитывать каждое утро перед началом работы.
Но здесь есть ключевое понимание, о котором в официальной документации сказано очень прямо:
Содержимое CLAUDE.md передаётся как сообщение пользователя после системного промпта, а не является частью самого системного промпта. Claude читает его и пытается ему следовать, но нет строгих гарантий соблюдения.
Перевод на человеческий язык: CLAUDE.md — это «настоятельная рекомендация», а не «железное правило». Он формирует поведение Claude, но не является уровнем жёсткого принуждения. Поэтому, чем конкретнее и лаконичнее вы пишете, тем стабильнее он соблюдается. Ожидаете, что это на 100% заблокирует какое-то опасное действие? Это работа для хуков (Hook), а не для CLAUDE.md — разделение их ролей мы обсудим в последующих главах.
Когда следует добавлять в него содержимое? Официальные источники дают несколько очень практичных сигналов:
- Claude во второй раз совершает одну и ту же ошибку — это значит, что правило нужно записать и закрепить.
- Вы снова вводите в этом сеансе то же исправление, которое вводили в прошлом сеансе.
- Во время проверки кода (code review) вы обнаружили, что он уже должен был знать определённое соглашение для этой кодовой базы.
- Новым членам команды нужен тот же контекст для быстрого старта.
💡 Краткий итог: CLAUDE.md — это справочник для адаптации, который Claude обязательно читает перед каждым запуском. Это уровень «настоятельной рекомендации», а не «железного правила». Чем конкретнее он написан, тем эффективнее работает.
02 Три уровня: кто управляет глобально, а кто — одним проектом
Существует не один CLAUDE.md, его можно разместить в нескольких местах, область действия которых варьируется от широкой к узкой. Новички чаще всего путаются именно здесь, давайте разберёмся с этим раз и навсегда.
Согласно официальной документации, обычно используются эти три уровня (плюс один локальный вариант):
| Уровень | Где находится | Область действия | Попадает ли в git |
|---|---|---|---|
| Пользовательский | ~/.claude/CLAUDE.md | Все проекты на вашей машине | Нет, чисто личные предпочтения |
| Проектный | ./CLAUDE.md или ./.claude/CLAUDE.md | Только текущий проект | ✅ Да, для всей команды |
| Уровень подкаталога | Любой подкаталог/CLAUDE.md | Загружается только когда Claude читает файлы в этом каталоге | ✅ Да, подходит для многомодульных репозиториев |
| Локальный (вариант) | ./CLAUDE.local.md | Текущий проект, только для вас | ❌ Добавьте в .gitignore |
Существует также «уровень управляемой политики», который развёртывается ИТ-администраторами в системном каталоге (в macOS это
/Library/Application Support/ClaudeCode/CLAUDE.md). Он загружается перед пользовательским уровнем и не может быть исключён отдельным пользователем. Обычные пользователи с этим обычно не сталкиваются, поэтому здесь мы это опускаем; корпоративные сценарии можно найти в официальной документации.
Как разделить обязанности? Запомните одно предложение: личные привычки помещайте на пользовательский уровень, а правила команды — на проектный.
- Пользовательский уровень (
~/.claude/CLAUDE.md): здесь хранятся ваши личные предпочтения, общие для всех проектов. Например: «отвечай на русском», «расскажи о своих мыслях перед тем, как менять код, а не приступай к делу сразу», «сообщения коммитов пиши на английском». Они не связаны с конкретным проектом, это привычки «вас как человека», поэтому они действуют для всех проектов и не попадают в git ни одного из них. - Проектный уровень (
./CLAUDE.md): здесь хранятся правила, специфичные для этого проекта, которые должна соблюдать вся команда. Технологический стек, команды сборки, соглашения о каталогах, списки запретов на редактирование. Он отправляется в систему контроля версий вместе с кодом, и когда новые коллеги клонируют его, они получают этот набор стандартов. - Уровень подкаталога: используется только в больших репозиториях. Например, в каталоге фронтенда лежит специфичный для фронтенда файл, а в бэкенде — для бэкенда. Обычно он не загружается, но когда Claude действительно собирается прочитать файлы в этом каталоге, он заодно подхватывает и этот CLAUDE.md — это экономит контекст.
Аналогия со справочником сотрудника: Пользовательский уровень = ваш личный блокнот с рабочими привычками (вы берёте его с собой при смене компании); Проектный уровень = справочник сотрудника, выданный этой компанией (вы возвращаете его при увольнении); Уровень подкаталога = дополнительные правила конкретного отдела (выдаются только при переводе в этот отдел).
Пример типичной пользовательской настройки: добавьте в ~/.claude/CLAUDE.md фразу «Когда есть несколько вариантов реализации, перечисли варианты, чтобы я мог выбрать, а не принимай решение за меня молча». Это правило справедливо для каждого вашего проекта, поэтому проще всего разместить его на пользовательском уровне — один раз настроив, вам больше не придётся повторять это в каждом новом проекте.
💡 Краткий итог: Личные привычки пишите на пользовательском уровне (
~/.claude/CLAUDE.md), правила команды — на проектном уровне (./CLAUDE.mdидёт в git), а для больших репозиториев используйте уровень подкаталога для разделения по модулям.
03 Порядок загрузки: почему правила проектного уровня «имеют большее значение, если сказаны позже»
В предыдущем разделе перечислены три уровня, но если они существуют одновременно, кто за кем закрепляет последнее слово? Это ещё одно частое заблуждение, которое необходимо прояснить.
Официальное правило: загрузка происходит от самого широкого к самому узкому уровню; чем ближе инструкции к вашему рабочему каталогу, тем позже они считываются.
Как именно они располагаются? Claude Code начинает с вашего текущего каталога и идёт вверх. На каждом уровне он собирает встреченные CLAUDE.md и в итоге объединяет их в единый контекст. Порядок примерно такой:
Пользовательский уровень ~/.claude/CLAUDE.md
↓ (читается первым)
(Выше в дереве каталогов) Родительский каталог CLAUDE.md
↓
Корень проекта ./CLAUDE.md
↓ (читается позже, ближе к вам)
Подкаталог CLAUDE.md (загружается, только если Claude читает файлы в этом каталоге)Обратите внимание на два ключевых момента, оба взяты из официальной документации:
Во-первых, все найденные файлы «объединяются», а не «перезаписывают» друг друга. Все они попадают в контекст, последующие не вытесняют предыдущие. Поэтому пользовательский и проектный уровни действуют одновременно, не бывает такого, чтобы «при установке проектного уровня пользовательский аннулировался».
Во-вторых, инструкции, находящиеся ближе к рабочему каталогу, «читаются последними». Когда два правила конфликтуют — например, пользовательский уровень говорит «используй одинарные кавычки для строк», а проектный — «используй двойные кавычки» — проектный уровень, находящийся ближе, обычно преобладает, потому что был прочитан позже. Проще говоря, правила проекта могут переопределить ваши личные привычки, и именно такого эффекта мы добиваемся при командной работе.
На этой иллюстрации три уровня наложены друг на друга сверху вниз: Пользовательский уровень (управляет всеми проектами, читается первым), проектный уровень (текущий проект, попадает в git), уровень подкаталога (ближе всего к коду, преобладает при конфликтах); стрелка справа указывает порядок загрузки «сверху вниз», а железное правило внизу подчёркивает: три уровня объединяются, а не перезаписываются, и те, что ближе к коду, читаются позже и имеют приоритет.
Здесь нужно исправить одно часто встречающееся заблуждение. Во многих руководствах в интернете приоритет указывается как «Локальный проект → Корень проекта → Подкаталог → Глобальный». Это прямо противоречит порядку загрузки, описанному официально. Легко поддаться этому утверждению, но если вы посмотрите официальную документацию, всё станет ясно: там прямо сказано, что загрузка идёт «от самой широкой к самой конкретной области», и инструкции проекта появляются после инструкций пользователя. Опирайтесь на официальную информацию, не запоминайте наоборот.
Ещё одна приятная деталь: CLAUDE.md в корне проекта автоматически перечитывается с диска после выполнения /compact (сжатия диалога), он не теряется. А вот вложенные CLAUDE.md в подкаталогах не внедряются заново автоматически; нужно дождаться, пока Claude в следующий раз не прочитает файлы в этом каталоге, чтобы они вернулись. Поэтому важные правила старайтесь размещать в корне проекта, не закапывайте их слишком глубоко.
💡 Краткий итог: Несколько CLAUDE.md объединяются, а не перезаписываются. Чем ближе к рабочему каталогу, тем позже они читаются и тем больший вес имеют при конфликте. Таким образом, правила проекта могут перекрыть личные привычки — не путайте официальное направление загрузки.
04 Что следует писать, а что не следует
Этот раздел — суть всей статьи. Если CLAUDE.md написан плохо, в 90% случаев это потому, что «то, что должно быть написано, не ясно, а то, чего не должно быть, свалено в кучу».
Сначала о том, что следует писать. Официальная документация предельно ясна: Пишите «факты, которые Claude должен помнить в каждом сеансе». В виде списка это пять категорий:
| Категория | Что именно писать | Пример |
|---|---|---|
| Обзор проекта | Одним предложением объясните, что это за проект | «Бэкенд управления заказами на базе FastAPI» |
| Технологический стек | Языки, фреймворки, базы данных, ключевые инструменты | «Python 3.11 / PostgreSQL / pytest» |
| Часто используемые команды | Как запускать тесты, сборку, проверки | uv run pytest, uv run ruff check . |
| Соглашения по коду | Стиль, именование, обязательные правила написания | «Функции должны иметь аннотации типов», «Для строк используются двойные кавычки» |
| Чёткие «Что нельзя делать» | Минные поля, файлы, которые нельзя изменять, действия, требующие предварительного запроса | «Запрещено изменять существующие файлы в migrations/» |
Среди них часто используемые команды просматриваются чаще всего — перед запуском тестов или сборки Claude заглянет сюда, чтобы не гадать и не ошибиться. Список запретов — это ограждение от «умного, но причиняющего вред» поведения: какие каталоги содержат старый код и доступны только для чтения, о каких файлах нужно сообщить вам перед изменением, содержимое каких файлов с ключами запрещено выводить.
Теперь о том, что писать не следует, это главная ловушка для новичков:
- ❌ Длинные фоновые истории: презентации компании, видение продукта, исторические причины выбора технологий — это не нужно Claude для написания кода и лишь занимает контекст.
- ❌ Устаревшая информация: поменяли пакетный менеджер, но не обновили CLAUDE.md, там всё ещё написано npm, что сбивает его с толку.
- ❌ То, что и так видно из кода: не пересказывайте, что делает каждый файл в структуре каталогов, не копируйте стили кода, уже определённые в конфигурации ESLint. Claude сам прочитает код, пересказ — пустая трата места.
Официальная позиция по этому поводу очень чёткая, и специально указана красная линия размера:
Целевой размер каждого файла CLAUDE.md — менее 200 строк. Более длинные файлы потребляют больше контекста и снижают уровень соблюдения правил.
Почему так важно ограничение в 200 строк? Потому что CLAUDE.md использует то же контекстное окно, что и ваш диалог. Если вы впихнёте туда триста строк чепухи, это равносильно тому, что вы сразу займёте огромный кусок рабочего стола, и места для реальных задач останется меньше. Более того, важные правила утонут в чепухе, внимание рассеется, и уровень соблюдения упадёт, а не вырастет. Это и есть корень проблемы «триста строк, которые никто не слушает», упомянутой в начале.
Есть хороший проверенный метод: перед тем как записать каждое правило, спросите себя: «Сможет ли Claude сам вывести это, посмотрев на код? Если да, удаляйте». Только благодаря этому одному правилу можно сократить CLAUDE.md унаследованного проекта с более чем 300 строк до 80, оставив только строгие ограничения, которые он не сможет вывести сам. После такой чистки количество раз, когда он использует неправильный менеджер пакетов, заметно снизится.
💡 Краткий итог: Пишите «факты, которые следует помнить при каждом сеансе» (обзор / тех. стек / команды / соглашения / запретные зоны). Удаляйте всё, что Claude может сам понять из кода, и уложитесь в 200 строк.
05 Ссылки на другие файлы: синтаксис @ и его цена
Иногда в вашем проекте уже есть готовые нормативные документы — руководство по проектированию API, соглашения о базе данных. Нет необходимости копировать это содержимое в CLAUDE.md, просто используйте синтаксис @ для ссылки на них.
Синтаксис очень прост: в любом месте CLAUDE.md напишите @ и путь:
Обзор проекта см. в @README, доступные команды см. в @package.json.
# Другие инструкции
- Рабочий процесс git @docs/git-instructions.mdКогда Claude читает CLAUDE.md, он раскрывает содержимое этих файлов и загружает их все в контекст. Вот несколько официально подтверждённых деталей, запомните их, чтобы избежать проблем:
- Относительные пути разрешаются относительно «файла, содержащего ссылку», а не вашего рабочего каталога. В этом легко запутаться.
- Абсолютные пути тоже работают; ссылаемые файлы могут ссылаться на другие файлы, максимум на четыре прыжка рекурсивно.
- Когда впервые встречается ссылка за пределами проекта, Claude Code покажет диалоговое окно утверждения со списком этих файлов; если вы отклоните, эта ссылка будет навсегда отключена, и окно больше не появится.
Но здесь есть одно самое важное понимание, которое официально подчёркивается снова и снова и которое является самой распространённой ловушкой:
Импортированные файлы разворачиваются и загружаются в контекст при запуске. Разделение на импорты
@pathпомогает в организации, но не уменьшает размер контекста, поскольку импортированные файлы загружаются при запуске.
Проще говоря: ссылка @ — это «организация», а не «экономия». Многие думают, что если вынести содержимое во внешние файлы, то сам CLAUDE.md станет короче, и контекст сэкономится. ОШИБКА. Содержимое файлов по ссылкам всё равно будет полностью загружено в окно при запуске, и весь положенный объём контекста будет израсходован. Представьте, что вы разделили документ со спецификациями на пятьсот строк с помощью @, думая, что сэкономили место, но при проверке через /context (посмотреть потребление контекста) вы увидите, что ни один токен не был сэкономлен.
Поэтому принцип таков: Ссылки @ используются для того, чтобы сделать структуру более понятной и удобной для человека, но для экономии контекста нужно «сокращать содержимое» или использовать «правила области путей», а не разделять файлы. Размер отдельных файлов, на которые даются ссылки, тоже не должен быть слишком большим, иначе они также будут тормозить работу.
Кстати, о смежном: если у вас есть некоторые чисто личные предпочтения проекта, которые вы не хотите добавлять в git (например, ваш локальный URL-адрес песочницы, ваши любимые тестовые данные), не пишите их в ./CLAUDE.md, запишите их в ./CLAUDE.local.md, а затем добавьте его в .gitignore. Он загружается и обрабатывается абсолютно так же, как CLAUDE.md, просто не будет зафиксирован и не повлияет на коллег.
💡 Краткий итог:
@путьвтягивает внешние документы для «чистоты структуры», но содержимое по ссылкам всё равно полностью загружается в контекст и не экономит токены. Хотите сэкономить — удаляйте текст; личные предпочтения помещайте вCLAUDE.local.mdи добавляйте в gitignore.
06 Поддержка: добавление на лету в сеансе и периодическая чистка
CLAUDE.md — это не то, что вы пишете один раз и забываете, он должен расти вместе с проектом. В этом разделе мы обсудим два действия по обслуживанию: как быстро добавить правило на лету и как регулярно проводить чистку.
Что делать, если во время сеанса захотелось временно добавить правило
Часто бывает так: в процессе общения вы поправили Claude и подумали: «Это нужно соблюдать каждый раз в будущем, надо бы записать». Самый простой официальный способ — прямо сказать ему в диалоге:
Добавь правило «Операции с базой данных должны проходить через сервисный слой (Service), не пиши SQL напрямую в маршрутах» в CLAUDE.mdClaude сам запишет это правило в файл CLAUDE.md. Вы также можете в любой момент ввести команду /memory, и она выведет список всех файлов CLAUDE.md, CLAUDE.local.md и файлов правил, загруженных в текущем сеансе. Кликните по нему, и он откроется в редакторе, где вы сможете отредактировать его вручную. Если хотите, чтобы Claude сам определил формулировку, используйте первый способ; если хотите точно контролировать формулировку, используйте /memory и редактируйте сами.
ℹ️ Заметка о разнице версий: в ранних версиях Claude Code можно было быстро добавить память, набрав предложение, начинающееся с
#в поле ввода. В новых версиях этот тип взаимодействия изменился. Ориентируйтесь на текущий официальный подход: либо прямо скажите Claude «добавь в CLAUDE.md», либо используйте/memoryдля самостоятельного редактирования. Если вы просто напишете «запомни xxx», Claude, скорее всего, по умолчанию сохранит это в свою собственную автоматическую память (auto-memory, тема статьи 25 «Система памяти»); чтобы правило точно попало в CLAUDE.md, так и напишите: «добавь в CLAUDE.md».
Регулярная чистка: удаление устаревшего и противоречивого
Официально упомянутая скрытая опасность: когда два правила противоречат друг другу, Claude может просто выбрать одно наугад. Поэтому необходимо периодически пересматривать файл и удалять устаревшее или конфликтующее. Когда следует инициировать чистку:
- Изменён пакетный менеджер / инструмент сборки (старые команды обязательно нужно удалить, их наличие вводит в заблуждение).
- Добавлена или удалена важная зависимость.
- Установлены новые соглашения по программированию (заодно проверьте, не конфликтуют ли они со старыми правилами).
- Вы обнаружили, что CLAUDE.md незаметно перевалил за 200 строк.
Хорошее ли правило, зависит от того, выглядит ли оно как «правило» или как «проза». Официальное сравнение очень практично, я свёл его в таблицу:
| ❌ Размытая проза (бесполезно) | ✅ Конкретное правило (работает) |
|---|---|
| Код должен быть достаточно чистым | Функция не более 50 строк, если больше — обязательно разбить |
| Старайся писать тесты | Каждая новая функция должна иметь соответствующий юнит-тест |
| Обрати внимание на безопасность | Пользовательский ввод должен обязательно пройти через sanitize() перед SQL-запросом |
| Каталог legacy не очень важен | Запрещено изменять любые файлы в каталоге legacy/ |
| Лучше использовать pnpm | Для управления зависимостями использовать только pnpm, npm и yarn запрещены |
То, что слева, равносильно пустому звуку — «чистый», «старайся», «обрати внимание» — всё это субъективные слова, Claude не может их проверить и, естественно, не может стабильно выполнять. Каждое правило справа конкретизировано до возможности проверки: 50 строк, обязательно наличие тестов, обязательно прохождение определённой функции. Официальные слова звучат так: «Пишите инструкции, которые достаточно конкретны, чтобы их можно было проверить».
При написании CLAUDE.md полезно выработать жёсткую привычку: написав каждое правило, будьте сами себе судьёй и решите: «Можно ли с первого взгляда определить, было ли нарушено это правило?». Если нельзя, значит, написано туманно, возвращайтесь и делайте конкретнее.
💡 Краткий итог: Чтобы быстро добавить правило, попросите Claude «добавить в CLAUDE.md» или используйте редактирование через
/memory; регулярно удаляйте устаревшие и конфликтующие правила; хорошее правило похоже на «правило, которое можно проверить с первого взгляда», а не на прозу вроде «чисто, старайся».
07 Практика: настройка правильного CLAUDE.md для игрушечного проекта
Одной теории мало. Ниже мы используем минимальный проект, чтобы пройти весь процесс: «Создание файла → Написание правил → Проверка загрузки». Повторяйте за мной, это займёт пять минут.
Шаг первый: создайте игрушечный проект и инициализируйте git (Mac / Linux)
mkdir claude-md-demo
cd claude-md-demo
git init
echo 'def add(a, b):
return a + b' > main.pyОжидание: В каталоге claude-md-demo есть main.py и каталог .git. Инициализация git нужна для того, чтобы этот CLAUDE.md мог попасть в систему контроля версий (обязательное условие для совместного использования в команде).
Шаг второй: напишите краткий проектный CLAUDE.md вручную
Используйте удобный для вас редактор, создайте CLAUDE.md в корневой директории проекта и вставьте следующее (обратите внимание, что в нём всего несколько строк — так и должен выглядеть хороший CLAUDE.md):
# add-demo — минимальный проект на Python для демонстрации
Здесь есть только функция `add`, она используется для демонстрации того, как писать CLAUDE.md.
## Часто используемые команды
- `python -m pytest` — запуск тестов
## Соглашения по программированию
- Все функции должны иметь аннотации типов
- Для строк используются только двойные кавычки
## Примечания
- Не изменяйте сигнатуру функции `add` в `main.py`, можно добавлять логику только внутри неёОжидание: В корневом каталоге проекта появится файл CLAUDE.md, его содержимое — это разделы выше. Весь текст занимает меньше 15 строк — запомните этот объём, не позволяйте реальным проектам бесконтрольно разрастаться.
Шаг третий: запустите Claude, проверьте, действительно ли он его прочитал
Запустите в каталоге проекта:
claudeПосле запуска введите эту команду, чтобы проверить статус загрузки:
/memoryОжидание: В списке вы увидите только что написанный ./CLAUDE.md. Пока он находится в списке, это означает, что Claude действительно загрузил его в контекст в текущем сеансе. Этот шаг является официально рекомендованным методом устранения неполадок — если какое-то правило не соблюдается, первое, что нужно сделать, это использовать /memory, чтобы проверить, загружен ли файл вообще.
Шаг четвёртый: поручите ему задачу, «нарушающую соглашения», и посмотрите, будет ли он соблюдать правила
Выйдите из /memory, вернитесь в поле ввода и введите:
Добавь аннотации типов к функции addОжидание: В diff-файле, предоставленном Claude, будут использоваться аннотации типов, оговорённые в проекте, и он не затронет те части, кроме сигнатуры функции, которые ему запрещено изменять. Если он честно изменит код в соответствии с вашим правилом в CLAUDE.md «Все функции должны иметь аннотации типов» — поздравляем, это руководство для сотрудника вступило в силу.
⚠️ Если вдруг обнаружите, что он не последовал CLAUDE.md: сначала используйте
/memory, чтобы подтвердить, что файл загружен; затем проверьте, не слишком ли размыто написано это правило (как слово «чисто»); и наконец, посмотрите, не конфликтуют ли два правила. Эти три шага — стандартный порядок устранения неполадок от разработчиков, следуя им, вы почти всегда найдёте причину.
💡 Краткий итог: Пройдите полный процесс «Создание файла → Написание кратких правил (менее 15 строк) → Проверка загрузки с помощью
/memory→ Запуск задачи для проверки соблюдения правил». Если не сработало, устраняйте неполадки в официальном порядке:/memory→ проверка на размытость → проверка на конфликты.
08 Заключение
В этой статье вы изучили CLAUDE.md — «память проекта для Claude» от начала и до конца:
| Аспект | Ключевой вывод |
|---|---|
| Что это такое | Справочник для адаптации, который необходимо читать в каждом сеансе. Уровень «настоятельной рекомендации», не железное правило |
| Сколько уровней | Пользовательский (личный) / Проектный (командный, идёт в git) / Уровень подкаталога (по необходимости) |
| Порядок загрузки | Объединение, не перезапись. Чем ближе, тем позже читается, преобладает при конфликтах |
| Что писать | Обзор / тех. стек / команды / соглашения / запретные зоны. Удаляйте всё, что код может доказать сам |
Ссылка @ | Используется для организации структуры, не экономит контекст (всё равно загружается полностью) |
| Поддержка | Попросите Claude «добавить в CLAUDE.md» или редактируйте через /memory; регулярно удаляйте устаревшее и конфликтующее; правило должно выглядеть как правило, а не как проза |
Теперь вы должны уметь: Определять, следует ли помещать информацию в CLAUDE.md и на каком уровне; писать конкретные, проверяемые правила вместо пустых слов; использовать ссылки @ на внешние документы, понимая при этом их цену для контекста; знать, как быстро добавлять правила на лету и периодически проводить чистку по мере развития проекта. Одним словом, вы можете написать CLAUDE.md, который Claude действительно будет слушать, а не тот 300-строчный файл, который все игнорируют.
Следующая статья: 19 «Управление контекстом». В этой статье неоднократно упоминалось, что «CLAUDE.md занимает контекстное окно» и что «ссылки @ по-прежнему загружаются полностью». Так что же такое это контекстное окно, что будет, когда оно заполнится, и как использовать /context и /compact? В следующей статье мы подробно разберём этот рабочий стол. Небольшой вопрос для размышлений: как вы думаете, что расходует больше токенов: один файл CLAUDE.md или весь ваш диалог целиком?