Почему ИИ-агенты игнорируют ваши .md-правила — и как сделать, чтобы CLAUDE.md, Cursor Rules и AGENTS.md действительно работали

Вы спрашиваете Claude Code: «Ты прочитал CLAUDE.md?» Он бодро отвечает: «Да, прочитал». Через несколько ходов выясняется, что ни одно правило из этого файла на самом деле не соблюдается — ни ваши проектные команды, ни конвенции коммитов, ни шаги деплоя. Всё это тихо испарилось.

Это проблема не только Claude Code. Тот же дрейф проявляется в .cursor/rules у Cursor, в .github/copilot-instructions.md у GitHub Copilot и в AGENTS.md у Codex CLI — стоит лишь поработать с ними подольше.

В этой статье разобраны пять ключевых причин, по которым ИИ-агенты игнорируют ваши .md-файлы с правилами, а затем — техники быстрого переписывания и долгосрочной систематизации с помощью Hooks и sub-agent, всё с конкретными примерами.

1. Почему ИИ игнорирует ваши правила — 5 ключевых причин

1. Структурные ограничения окна контекста

LLM не уделяет одинаковое внимание каждому токену во входных данных. Инструкции, спрятанные в середине длинного документа, теряются — это хорошо задокументированный эффект «lost in the middle». Как только ваш CLAUDE.md переваливает примерно за 200 строк, всё, что находится в середине, фактически исчезает.

2. Auto-compact в длинных сессиях

В Claude Code есть функция /compact, которая сжимает историю диалога. Когда она срабатывает автоматически, инструкции уровня system prompt сохраняются, а оперативные детали из CLAUDE.md либо сворачиваются в краткую сводку, либо вовсе выбрасываются. Именно поэтому нарушения правил скапливаются во второй половине длинных сессий.

3. Прямые указания пользователя имеют приоритет

Для ИИ «то, что только что сказал пользователь» весит больше, чем «правило, прочитанное 300 ходов назад». Стоит пользователю сказать «просто сделай это» или «коммить уже», и ваше правило «всегда подтверждай перед коммитом» из CLAUDE.md тут же сметается.

4. Расплывчатые или противоречивые правила

Субъективные указания вроде «пиши вежливо» или «обработай это уместно» оставляют интерпретацию на усмотрение ИИ, а она редко совпадает с тем, чего вы хотели. Переписывайте их в виде проверяемых ограничений: «ответы — не более 3 строк», «для Slack API использовать chat.postMessage» и так далее.

5. Раздутые и разбросанные файлы правил

CLAUDE.md плюс SPEC.md плюс README.md плюс ещё куча .md-файлов — когда они разнесены по проекту и каждый сам по себе длинный, ИИ читает их с разным весом. Если одно и то же правило встречается в нескольких файлах с лёгкими расхождениями, ИИ обычно выбирает самый «безопасный» вариант.

2. Как понять, действительно ли ваши правила соблюдаются

Начните с проверки текущего состояния. Задайте ИИ следующие вопросы и посмотрите на ответ:

Слова ИИ «я прочитал» или «понял» не говорят ни о чём. Применяет ли он правила на практике — это отдельный вопрос: судите по поведению после выполнения, а не по заявлениям.

3. Быстрые правки, которые можно внедрить за 5 минут

1. Сожмите файл правил до 150 строк или меньше

На практике Claude Code надёжно следует CLAUDE.md объёмом примерно 100–150 строк. Всё, что больше, нужно разделять:

• Непреложные правила (10–20 строк) — в начало CLAUDE.md
• Спецификации сервисов — выносим в SPEC-xxx.md
• История и предыстория — в каталог docs/

Оставьте в CLAUDE.md «то, забвение чего катастрофично». Подробности живут в связанных файлах.

2. Добавьте явные маркеры приоритета

Используйте громкие ключевые слова приоритета, чтобы привлечь внимание ИИ:

• CRITICAL — нарушение приводит к инциденту в production
• MUST — соблюдать всегда
• SHOULD — соблюдать по умолчанию
• NICE TO HAVE — только если есть возможность

Строку вида «CRITICAL: разрушительные запросы к production-БД требуют явного подтверждения» гораздо труднее проглядеть, даже если она зарыта в длинном файле.

3. Подчеркните правила в самом чате

В начале сессии бросьте однострочник вида «Перед стартом перечисли три самых важных правила из CLAUDE.md». Это вытаскивает их в свежий контекст и заставляет работать до конца сессии.

4. Заносите опасные операции в TodoWrite

Используйте инструмент TodoWrite у ИИ-агента (или аналогичную функцию задач в вашем инструменте), чтобы внести «проверка правил» как отдельный явный шаг. Когда шаг виден, «забыл» случается куда реже.

4. Долгосрочная систематизация — Hooks, sub-agent, slash command

Текстовые правила можно докрутить лишь до определённого предела. Переход от «просим ИИ соблюдать правила» к «заставляем окружение их обеспечивать» намного надёжнее.

1. Механически принуждайте через Claude Code Hooks

Функция Hooks в Claude Code позволяет запускать произвольные скрипты до или после конкретных вызовов инструментов. Можно собрать схему, при которой система останавливает ИИ, даже когда он сам забыл правило.

Например, через хук PreToolUse:

• Обнаруживать опасные команды (rm -rf, git push --force) до запуска Bash и блокировать их
• Проверять права на файл или его блокировку до того, как Edit коснётся целевого файла
• Запускать проектные тесты перед коммитом и прерывать его при падении

Вежливые просьбы в тексте не выдерживают конкуренции с механическим принуждением через Hooks.

2. Разделяйте задачи через sub-agent

Используйте возможности sub-agent в Claude Agent SDK или Cursor, чтобы построить выделенный «агент-аудитор правил». Двухступенчатая схема, в которой основной агент пишет код, а аудитор его проверяет, ловит нарушения правил даже тогда, когда основной агент о них забыл.

Sub-agent нужен лишь короткий промпт под аудит, поэтому его уровень распознавания правил остаётся высоким. В этом и весь смысл.

3. Кодифицируйте рутину как кастомные slash command

Повторяющиеся сценарии вроде «перед каждым коммитом запусти эти 3 проверки» отлично укладываются в slash command (/precommit и т. п.). Когда пользователь набирает /precommit, ИИ выполняет фиксированную последовательность. Перечитывать файл правил каждый раз не нужно.

4. Ловите нарушения автоматизированными скриптами

Запускайте grep-проверки запрещённых паттернов в CI или как pre-commit hook. Примеры:

• Забытые console.log в production-коде
• Захардкоженные API-ключи
• Отсутствующие заголовки с copyright

Не полагайтесь на ИИ — пусть ищут машины. Это ваша последняя линия обороны.

5. Лучшие практики по каждому инструменту

Универсальное правило — «коротко, конкретно, с приоритетами». Имена файлов и расположение зависят от инструмента, но принципы написания одни и те же.

6. Три антипаттерна в проектировании правил

1. «Соблюдай best practice».

Чьи именно best practice? ИИ по умолчанию выдаёт усреднённое из своих обучающих данных, то есть наименьший общий знаменатель. Особенности именно вашего проекта туда не попадают. Пишите конкретные «делай» и «не делай».

2. Одно и то же правило, продублированное в нескольких файлах

Если ваши «конвенции коммитов» живут в CLAUDE.md, SPEC.md и README.md, три копии со временем тонко разойдутся и собьют ИИ с толку. Выберите один источник истины и ссылайтесь на него отовсюду.

3. Лепить «АБСОЛЮТНО ОБЯЗАТЕЛЬНО» на всё подряд

Если всё «абсолютно», ИИ теряет способность расставлять приоритеты. Берегите «CRITICAL» для по-настоящему катастрофических случаев; всё остальное пусть лежит обычным текстом. Акценты страдают от инфляции — расходуйте их экономно.

Итоги

Когда ИИ-агенты игнорируют ваши .md-правила, дело почти всегда в структурных ограничениях и проблемах проектирования правил, а не в «лени» ИИ. Большинство случаев решается быстрыми правками — сожмите файл до 150 строк, добавьте маркеры приоритета, переподчеркните в чате. Для оставшихся по-настоящему критичных правил переходите к механическому принуждению: Hooks, sub-agent, slash command и автоматизированные скрипты-детекторы.

«Если правила не соблюдаются — постройте систему, которая заставит» — новый здравый смысл в эксплуатации ИИ-агентов.

FAQ

Q1. Какая идеальная длина для CLAUDE.md?

На практике — 100–150 строк. После 200 разбивайте на SPEC-xxx.md и подобные. Краткая «сводка топ-5 критичных правил» в самом верху — хорошая страховка от забывчивости.

Q2. Что использовать в Cursor — .cursorrules или .cursor/rules/*.mdc?

Для новых проектов — .cursor/rules/*.mdc. Одно правило на файл, с glob-шаблонами для определения области применения. Старый одиночный .cursorrules со временем имеет привычку раздуваться.

Q3. Делает ли ИИ строже более длинный файл правил?

Наоборот. Чем длиннее файл, тем сильнее размывается его середина. Короткие сущностные правила, размещённые на видном месте (вверху), соблюдаются с заметно более высоким коэффициентом.

Q4. Что делать, если на одном проекте сразу несколько ИИ-инструментов (Claude Code + Cursor)?

Прагматичный ответ — положить одну и ту же сводку в файл конфигурации каждого инструмента, а детали централизовать в общем SPEC.md. Полностью унифицированного решения пока нет (по состоянию на май 2026).

Q5. Когда ИИ говорит «я прочитал», он действительно не читает?

Заявление «я прочитал» и реальное поведение в рантайме — разные вещи. Используйте методы диагностики из раздела 2, чтобы проверить распознавание на уровне исполнения.