Как научить кодового агента писать в стиле вашей команды

Проблема: агент пишет правильно, но не по-вашему

Вы просите ассистента добавить эндпоинт. Он выдаёт рабочий код: типизация на месте, тесты есть, ошибки обрабатываются. Но импорты отсортированы не так, как у вас, комментарии на английском вместо русского, а вместо вашего внутреннего логгера используется console.log. Формально всё верно. На ревью — двадцать комментариев про стиль.

Крупные инструменты 2024–2025 годов решают это одинаково: они читают файл с правилами из корня репозитория и подмешивают его в контекст каждого запроса. У Anthropic это CLAUDE.md в Claude Code, у Cursor — .cursor/rules (пришедшие на смену старому .cursorrules), у GitHub Copilot — .github/copilot-instructions.md. Механика одна: вы описываете конвенции человеческим текстом, агент держит их в контекстном окне¹ и старается им следовать.

Что реально можно задать через правила

Файл правил — это не магия. Модель по-прежнему может проигнорировать инструкцию, особенно если она длинная и противоречивая. Но короткий, конкретный набор запретов и предпочтений заметно снижает объём правок на ревью. Полезно фиксировать то, что нельзя вывести из самого кода за пару файлов.

• Стек и версии. Какой фреймворк, какой менеджер пакетов (npm, pnpm, yarn), какая версия языка. Иначе агент предложит синтаксис, недоступный в вашей среде.
• Запреты. «Не используй any в TypeScript», «не добавляй новые зависимости без явной просьбы», «не трогай сгенерированные файлы в src/generated».
• Внутренние соглашения. Свой логгер вместо console, свой клиент HTTP, свой способ работы с ошибками.
• Тесты. Какой раннер, где лежат тесты, нужны ли они к каждому изменению.
• Язык. На каком языке комментарии и сообщения коммитов.

Правило работает, когда его можно проверить взглядом за секунду. «Пиши чистый код» агент проигнорирует. «Функции не длиннее 40 строк, ранний возврат вместо вложенных if» — выполнит.

Плохое правило против хорошего

Сравните две формулировки одной и той же мысли. Левая — пожелание, правая — инструкция.

Три уровня, на которых закрепляется стиль

Файл правил — верхний слой. Под ним есть более надёжные механизмы, и агента стоит настраивать на все три сразу.

1. Линтер и форматтер. ESLint, Prettier, Ruff, gofmt. Это единственный слой, который гарантирует результат: правило либо выполнено, либо сборка красная. Агент, которому дали команду запускать линтер и чинить ошибки, сам подгонит код под конфиг.
2. Файл правил проекта. То, что линтер проверить не может: архитектурные предпочтения, выбор внутренних библиотек, тон комментариев.
3. Примеры в кодовой базе. Агент смотрит на соседние файлы. Если в проекте один эталонный модуль написан идеально, укажите на него в правилах: «новые сервисы делай по образцу src/services/users.ts».

Сравнение подходов у популярных инструментов

Синтаксис и глубина настройки различаются. Данные ниже актуальны на начало 2025 года — форматы у этих продуктов меняются часто, сверяйтесь с документацией.

Дообучение против правил в контексте

Есть соблазн «обучить агента на нашем коде» в буквальном смысле — сделать дообучение² модели на репозитории. Для задачи «пиши в нашем стиле» это почти всегда избыточно и дорого.

Дообучение оправдано, когда у вас гигантская внутренняя кодовая база на редком фреймворке, которую модель не видела при обучении, и вы готовы платить за инфраструктуру и повторять процесс при каждой смене базовой модели. В остальных случаях выигрывает связка «файл правил плюс подгрузка релевантных файлов в контекст» — это дешевле, обновляется правкой текста и не устаревает при выходе новой версии модели.

RAG для больших проектов

Если репозиторий не помещается в контекстное окно, агент использует RAG³: ищет по кодовой базе релевантные фрагменты и подмешивает только их. Cursor делает это через индексацию проекта автоматически. Вам достаточно держать код чистым — плохие примеры в базе агент тоже подхватит и размножит.

Кому это пригодится и кому нет

Пригодится:

• Командам от трёх человек, где ревью тонет в комментариях про стиль, а не про логику.
• Проектам с нестандартными внутренними библиотеками: свой ORM, свой слой валидации, свои обёртки над API.
• Тем, кто активно генерирует бойлерплейт — контроллеры, миграции, типовые тесты. Здесь единый шаблон в правилах экономит больше всего.

Скорее не нужно:

• Соло-разработчику на пет-проекте: настройка правил займёт больше времени, чем сэкономит.
• Командам, у которых ещё нет линтера и форматтера. Сначала настройте их — это закроет 80 процентов стилевых претензий без всякого ИИ.
• Тем, кто ждёт, что агент угадает архитектурные решения. Правила фиксируют «как писать», но «что строить» решаете вы.

¹ Контекстное окно — объём текста (кода, инструкций, истории диалога), который модель удерживает одновременно. Всё, что в него не влезло, для модели не существует.

² Дообучение (fine-tuning) — дополнительное обучение готовой модели на своих данных, чтобы изменить её поведение. Требует вычислительных ресурсов и повторяется при смене базовой модели.

³ RAG (retrieval-augmented generation) — подход, при котором система сначала ищет релевантные документы или фрагменты кода, а потом отдаёт их модели вместе с запросом, вместо того чтобы держать всю базу в контексте.