Откройте шаблон системного промпта, который инженеры одного из AI-вендоров выложили как образец «идеального поведения агента» — и увидите сотни строк: тон голоса, порядок работы с кодом, реакция на конфликтующие требования, форматирование ответов, что делать, если пользователь резок. Это не стартап, который торопится и копирует правила со Stack Overflow. Это люди, которые саму модель обучали. Если создатели агента не удерживают его поведение в двух десятках строк, а расписывают на сотни — проблема не только в дисциплине команды: единый статичный файл плохо подходит для правил, зависящих от задачи.
Во многих командах CLAUDE.md, .cursorrules и аналоги стали использовать как общий склад инструкций: туда часто попадают инструкции разных типов: стиль кода, тон ответа, регламенты, формат вывода. Файл растёт, пока не превращается в простыню правил, которую сам автор дочитывает по диагонали.
Такой файл начинает работать как антипаттерн, когда смешивает постоянные сведения о проекте и ситуативные правила поведения. Попытка зафиксировать универсальную личность и свод правил поведения агента в едином статичном файле снижает качество ответов агента в задачах, где нужны короткий контекст и точные инструкции.
Какие сбои вызывает разросшийся контекст
Контекстное окно модели ограничено не только физическим лимитом токенов — оно ограничено ещё и тем, насколько эффективно модель распределяет между ними внимание. Чем больше фонового шума загружено в системный контекст перед конкретной задачей, тем ниже качество её выполнения. На практике чаще всего проявляются три сбоя, у каждого своя причина:
- Размытие внимания (prompt pollution). Модель тратит ресурс внимания на правила, которые к текущему шагу не имеют отношения. Просите агента написать одну регулярку — а ему приходится сначала прочитать сорок пунктов о том, как вести себя в сложных архитектурных дискуссиях.
- Конфликт требований. Универсальное правило «всегда пиши подробные комментарии к коду и развёрнутые пояснения» превращается в помеху, когда от агента нужен точечный быстрый патч или короткий вывод CLI-команды. Файл на все случаи жизни неизбежно противоречит сам себе.
- Отсутствие гибкости. Рефакторинг ядра, клиентская документация, security-аудит, быстрый прототип — задачи с противоположными требованиями к глубине, тону и граничным условиям. Один статичный файл плохо обслуживает такие режимы одновременно, без компромиссов в полноте, краткости или строгости инструкций.
Даже хорошо написанные правила начинают конфликтовать, если их хранить как единый универсальный текст.
Чем CLAUDE.md должен быть по замыслу
CLAUDE.md лучше рассматривать как README для агента. CLAUDE.md может выполнять роль README для агента: команды сборки и деплоя, архитектура кодовой базы, пути к ключевым файлам, соглашения проекта. Критерий отбора: добавлять только сведения, которые агент не восстановит из репозитория. Не дублировать структуру папок, которую агент и так увидит через ls. Не пересказывать банальные практики, которые модель и так знает.
Хороший README обычно не описывает очевидные вещи вроде полного дерева папок, потому что как только он начинает объяснять очевидное, его перестают читать — что человек, что модель. У CLAUDE.md, задуманного как карта репозитория, а не как книга должностных инструкций, та же проблема: лишний текст снижает вероятность, что важное будет учтено. Команды часто нарушают это разделение не потому, что не понимают README-аналогию, а потому что не имеют отдельного места для ситуативных правил — тона, глубины, граничных условий, регламентов. И сваливают это в единственный файл, который агент точно прочитает целиком.
Ситуативные правила лучше хранить в обвязке
Если CLAUDE.md обязан оставаться картой, а операционное поведение — тон, глубина, фокус, ограничения — реальным и разным на каждом шаге, то этому поведению попросту негде уместиться внутри одного файла. Одного сокращения файла недостаточно: ситуативные правила нужно подавать динамически. Вся операционная логика переносится из статичного файла во внешнюю обвязку — оркестратор, пайплайн или обёртку над CLI/API, которая формирует финальный контекст прямо перед постановкой конкретной задачи.
Минимальная схема:
┌─────────────────────────────────────────────────────────┐
│ Внешняя обвязка │
│ (Определяет тип задачи, фазу и требуемый режим работы) │
└───────────────────────────┬─────────────────────────────┘
│
┌───────────────┴───────────────┐
▼ ▼
┌──────────────────────┐ ┌─────────────────────────┐
│ Базовый контекст │ + │ Динамический контекст │
│ (Минимальный │ │ - Тон и глубина ответа │
│ CLAUDE.md) │ │ - Вектор и правила │
│ │ │ - Граничные условия │
└──────────────────────┘ └─────────────────────────┘Оркестратор определяет тип задачи и добавляет только нужные инструкции — вместо того чтобы заранее прописывать правила на все случаи жизни в файле, который агент читает целиком независимо от задачи.
Какие параметры обвязка задаёт перед задачей
Вместо того чтобы прописывать правила на все случаи жизни в одном файле, система контекстуализации настраивает параметры под конкретный запрос:
- Объём ответа. Для быстрой проверки гипотезы подставляется инструкция «дай только работающий минимальный код без пояснений». Для задачи проектирования архитектуры — требование провести анализ рисков и сравнить альтернативы.
- Тон ответа. Сухой и строгий формат для оформления PR, диалоговый и вовлекающий — для брейншторма, академический — для анализа исследовательских данных.
- Приоритет задачи. В зависимости от этапа обвязка фокусирует модель на производительности, обратной совместимости, безопасности или скорости реализации.
- Ограничения и граничные условия. Соблюдение регламентов, запрет на определённые сторонние библиотеки — подключаются ровно тогда, когда задача затрагивает соответствующие модули, а не добавляются в каждый запрос без необходимости.
Пример из практики. В моём собственном пайплайне текст для конкретного канала не хранится одним файлом на все каналы сразу — он собирается на лету из промпта под конкретный канал, файла с описанием голоса автора (voice/identity.md), языкового регистра (voice/ru.md или voice/en.md) и одной строки из таблицы настроек канала (voice/dials.md): допустимая резкость, частота хуков, обязательные фирменные элементы. Пост в Telegram и пост в LinkedIn получают один и тот же базовый авторский голос, но разный тон, разную плотность и разные ограничения — подставленные под задачу в момент генерации, а не записанные заранее в одном монолитном файле «как автор всегда пишет».
В том же проекте корневой CLAUDE.md устроен так же: правило, общее для трёх и более скиллов, выносится в CLAUDE.md один раз, а в описании каждого отдельного скилла остаётся только операционная специфика конкретного шага. Файл ограничивают правилом: общее для трёх и более скиллов — в корень, специфичное — в описание скилла.
Похожий принцип используется и в других системах:
- Code review боты подключают security-чек-лист только когда диф трогает
auth/, а не всегда. - **
.cursor/rules/*.mdcсglobs:** — правило подгружается лишь для файлов нужного типа. - RAG-агенты поддержки подмешивают в контекст только статьи базы знаний по теме текущего тикета.
- CI/CD с path-triggers — набор шагов и секретов зависит от того, какие пути реально изменились.
- Мультиагентные оркестраторы дают каждому субагенту свой узкий промпт под конкретный шаг, а не один файл на всех.
Ограничение подхода
Перенос правил в обвязку не решает проблему автоматически. При росте числа правил обвязка тоже может стать шумной и противоречивой, если за ней не следить. Тот же эффект размытого поведения знаком не только по CLAUDE.md, но и по числу компонентов в проекте вообще: при малом числе компонентов поведение проще отследить; когда счёт идёт на десятки, ассистент начинает вести себя по-разному день ото дня, и разобраться постфактум, что именно сломало паттерн, трудно без логирования, версионирования и тестов промптов. Обвязку тоже нужно ограничивать правилами состава, версиями и проверками. Она переносит дисциплину в другое место, а не отменяет необходимость эту дисциплину поддерживать. Разница в том, что теперь разрастается управляемый и версионируемый слой логики, а не текст, который агент обязан целиком прочитать перед каждой задачей.
Преимущества динамической подачи правил
Перенос операционной логики из статичного файла в динамическую обвязку даёт несколько практических преимуществ — они объясняют, почему монолитный файл хуже масштабируется и хуже управляет вниманием модели:
- Меньше лишнего контекста. Агент получает только те инструкции, которые нужны для выполнения текущего шага. Внимание не рассеивается на нерелевантные требования — риск prompt pollution снижается не потому, что правил стало меньше вообще, а потому что их стало меньше в конкретном промпте.
- Выше шанс соблюдения инструкции. Когда инструкция подаётся непосредственно перед задачей и сформулирована под конкретный контекст, модели проще учесть такую инструкцию. Инструкция, зарытая на сороковой строке общего файла, конкурирует за внимание с тридцатью девятью соседними; инструкция, поданная прямо в момент задачи, — нет.
- Централизованное изменение правил. Изменение требований к тону или правилам безопасности происходит в одном месте — в логике обвязки, — без необходимости переписывать конфигурационные файлы во всех репозиториях компании.
Как меняется ответственность в команде
Для команды это конкретный сдвиг ответственности. CLAUDE.md перестаёт быть местом, где фиксируется договорённость «агент всегда ведёт себя вот так», — потому что такая договорённость слишком груба для разных типов задач: агент должен вести себя по-разному в зависимости от фазы и типа задачи. Ответственность за поведение переходит в логику обвязки — код, который можно версионировать, тестировать и централизованно менять, а не текстовый файл, который приходится точечно править в каждом из десятков репозиториев компании одновременно.
CLAUDE.md как карта репозитория
CLAUDE.md — это краткое описание проекта для агента, а не инструкция по эксплуатации агента на каждый день. В нём стоит держать стек, структуру и ограничения среды — то, что не очевидно из кода и не меняется от задачи к задаче. Всё остальное — тон, глубина, вектор, границы — лучше не хранить в этом файле. Эти параметры должен добавлять динамический контекст, который собирается заново под каждый конкретный запрос.
Если ваш CLAUDE.md за последние полгода вырос до пятисот строк — не стоит ограничиваться новыми разделами внутри того же файла. Это сигнал, что часть его содержимого, скорее всего, относится к обвязке: правилам выбора контекста, шаблонам задач или настройкам оркестратора, а не должна оставаться текстом, который агент вынужден прочитывать перед каждой однострочной регуляркой.