Файл .cursorrules и правила проекта: как настроить Cursor под свой стек

18 мин. чтения
Bybit
SpaceX за крипту
Дробные доли · 24/7
Открыть рынок →

Языковая модель ничего не помнит между ответами. Каждый новый запрос она читает с чистого листа: не знает, что у вас TypeScript, а не JavaScript, что вы отступаете двумя пробелами, что импорты идут по алиасам, а компоненты лежат в src/components. И каждый раз, когда вы это не напомнили, ИИ-агент честно угадывает — иногда мимо.

Правила (rules) в Cursor — это способ перестать напоминать одно и то же руками. Вы один раз описываете, как устроен ваш проект и как в нём принято писать код, а Cursor подкладывает это описание в начало каждого запроса к агенту. Получается постоянная, переиспользуемая память проекта, которая едет вместе с репозиторием и работает одинаково у всей команды.

Тема звучит просто, но на практике вокруг правил накопилось столько путаницы, что даже свежие гайды 2026 года противоречат друг другу: путают названия типов правил, дают устаревшие форматы файлов и спорят о приоритете. Ниже — разбор, который сверен с официальной документацией Cursor на июль 2026 и показывает, где источники расходятся.

Что такое правила и что они реально делают

Правило — это текстовая инструкция для агента: «пиши тесты на Vitest», «не используй any», «все запросы к базе — через репозиторий, не напрямую». Cursor добавляет подходящие правила в контекст перед тем, как модель начнёт отвечать. Официальная документация формулирует это прямо: модели не сохраняют память между ответами, а правила дают постоянный переиспользуемый контекст на уровне запроса.

BYBIT COPY TRADINGКопитрейдинг на BybitОткрытая статистика трейдеров, старт с $10, отключение в один клик.Выбрать трейдера

Важно сразу очертить границу, о которую спотыкаются новички: правила работают только в чате агента (Agent/Chat), но не влияют на автодополнение Cursor Tab и не применяются к строчному редактированию Inline Edit (Cmd/Ctrl+K) — по крайней мере пользовательские правила. Это официально задокументировано. То есть если вы ждали, что правило поменяет поведение автодополнения на лету, — оно не поменяет. Правила — это про агента.

Как устроен сам агентный чат — план до кода, чекпоинты для откатов и что реально контролирует авто-запуск команд — разобрано в статье про Agent Mode на максимум.

Зачем они нужны на практике:

  • Закодировать знания о проекте — стек, архитектурные решения, соглашения об именах. То, что вы иначе объясняете каждому новому разработчику (и каждому новому чату).
  • Стандартизировать стиль — чтобы код от ИИ выглядел как ваш, а не как усреднённый код из интернета.
  • Автоматизировать типовые шаги — «после изменения схемы обнови типы», «новый эндпоинт — сразу с тестом».

Три формата правил: не путайте их

За пару лет у Cursor сменилось несколько способов хранить правила, и старые статьи описывают уже неактуальные форматы. Вот полная картина на июль 2026.

ФорматЧто этоСтатусКогда использовать
.cursorrulesОдин файл в корне проекта, обычный текстРаботает, но устарел (deprecated)Только в старых проектах; новые — не заводить
.cursor/rules/*.mdcПапка с markdown-файлами и YAML-заголовкомАктуальный формат проектных правилОсновной способ настроить проект под стек
AGENTS.mdПростой markdown без заголовкаОфициальная простая альтернативаКогда не нужны типы/условия; удобен для монорепо

Старый .cursorrules (один файл в корне) Cursor всё ещё читает — ради обратной совместимости, — но документация и практики единогласно советуют мигрировать на папку .cursor/rules. Три независимых источника формулируют это одинаково: файл «работает, но deprecated».

AGENTS.md — это не конкурент .cursor/rules, а официально признанный Cursor вариант того же механизма: обычный markdown-файл с инструкциями для агента, «простая альтернатива» без метаданных. У него есть одна особенность, которая делает его сильнее в монорепозиториях, — о ней ниже.

Если ещё не поставили сам редактор, чтобы всё это попробовать: Cursor ставится бесплатно, правила доступны и на free-тарифе. Хотите сперва понять, что за инструмент и на чьих моделях он работает, — у нас есть полный обзор возможностей Cursor.

BYBITВсё ещё смотришь со стороны?Рынок работает без выходных. Счёт на Bybit открывается за 2 минуты.Начать сейчас

Четыре типа правил — и путаница в их названиях

Вот место, где ошибаются почти все. У проектных правил есть четыре типа поведения — когда именно правило подключается. В 2026 году Cursor переименовал эти типы, но огромная часть гайдов (в том числе обновлённых в июне 2026) до сих пор использует старые названия. Если вы читаете чужую статью и видите «Auto Attached» или «Agent Requested» — это устаревшая терминология.

Старое название (устарело)Актуальное название (2026)Когда правило подключается
AlwaysAlways ApplyВ каждом запросе к агенту
Agent RequestedApply IntelligentlyКогда агент сам решит по описанию, что правило уместно
Auto AttachedApply to Specific FilesКогда в контексте есть файл, подходящий под маску (glob)
ManualApply ManuallyТолько когда вы упомянули правило через @ в чате

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

Как устроен .mdc-файл

Тип правила задаётся не в выпадающем меню на глаз, а тремя полями в YAML-заголовке (frontmatter) .mdc-файла:

  • alwaysApply — булево. true = правило всегда в контексте (тип Always Apply).
  • description — строка. Короткое описание, по которому агент решает, релевантно ли правило (тип Apply Intelligently — когда description задан, а globs нет).
  • globs — маски файлов. Когда открытый файл подходит под маску, правило подключается (тип Apply to Specific Files).

Комбинация этих трёх полей и определяет тип. Пустой заголовок без всего — это Apply Manually: правило сработает, только если вы позовёте его через @имя-правила.

Пример простого проектного правила .cursor/rules/typescript.mdc:

---
description: Правила TypeScript-кода для этого проекта
globs: ["**/*.ts", "**/*.tsx"]
alwaysApply: false
---

- Строгий режим: никаких `any`, используем `unknown` + сужение типов.
- Именованные экспорты вместо default export.
- Асинхронные функции — только с обработкой ошибок через Result-тип из @/lib/result.

Отдельная грабля: проектные правила обязаны иметь расширение .mdc. По официальной документации обычный .md-файл в папке .cursor/rules игнорируется системой правил, потому что у него нет YAML-заголовка. Тут источники расходятся: один сторонний гайд утверждает, что .md «тоже работает, просто без метаданных». Мы держимся формулировки первоисточника — Cursor прямо говорит «ignored», так что не рискуйте и ставьте .mdc.

Где лежат файлы и почему подпапки монорепо ломаются

Папка .cursor/rules сканируется только в корне рабочего пространства. Внутри неё можно раскладывать правила по подпапкам (.cursor/rules/frontend/some-rule.mdc) — это Cursor видит и читает рекурсивно. А вот отдельные папки .cursor/rules внутри подкаталогов монорепо (например, packages/api/.cursor/rules) Cursor не обнаруживает — даже с alwaysApply: true.

Это подтверждённый ответ команды Cursor на форуме, а не догадка. И это самая частая причина жалоб «моё правило не применяется»: разработчик кладёт правила в подпакет монорепо и удивляется тишине.

Официальное решение как раз и объясняет, зачем нужен AGENTS.md: вложенные AGENTS.md автоматически обнаруживаются в любой подпапке и применяются к файлам этой директории и её потомков. Поэтому для монорепо рекомендация такая: общие правила — в корневой .cursor/rules, а специфику подпакета — в packages/api/AGENTS.md, а не во вложенной .cursor/rules.

Приоритет: кто побеждает при конфликте

Правил обычно несколько, и они бывают трёх уровней. Официальный порядок приоритета при конфликте инструкций:

Team Rules → Project Rules → User Rules. Team-правила (командные, задаются админом в дашборде) — высший приоритет; при спорной ситуации побеждает более ранний в этой цепочке источник.

Здесь важно предупредить: часть блогов даёт обратный порядок (якобы User-правила главнее всех). Это ошибка — не тиражируйте её. Официальная документация и независимый технический гайд сходятся на «Team → Project → User».

  • User Rules — глобальные, на всё ваше окружение Cursor, задаются в настройках. Ваши личные привычки.
  • Project Rules — в репозитории, едут с проектом, общие для всех, кто его клонирует.
  • Team Rules — доступны на планах Team и Enterprise, управляются из дашборда. Админ может включить флаг Enforce — тогда правило обязательно для всех и его нельзя отключить локально.

Готовые шаблоны под свой стек

Писать правила с нуля не обязательно. Крупнейшая community-коллекция готовых наборов — репозиторий awesome-cursorrules от PatrickJS (около 40 тысяч звёзд на июль 2026): шаблоны под Next.js, React, Angular, Python, Go и десятки других стеков.

Есть и официальный способ подтянуть чужие правила прямо в интерфейсе: Customize → Rules → Add Rule → Remote Rule импортирует .mdc-правила из любого GitHub-репозитория, к которому у вас есть доступ, и раскладывает их в .cursor/rules/imported/.

Три коротких примера-заготовки под популярные комбинации (адаптируйте под себя):

React / Next.js + TypeScriptglobs: ["**/*.tsx"]:

- Функциональные компоненты + хуки; классовых компонентов нет.
- Server Components по умолчанию; "use client" — только где реально нужен интерактив.
- Стили — Tailwind, без inline-стилей.

Python / FastAPIglobs: ["**/*.py"]:

- Тайпинги обязательны, mypy strict.
- Валидация вход/выхода — Pydantic-модели, не dict.
- Зависимости — через Depends, бизнес-логика вынесена из роутов в сервисы.

Монорепо — общее правило в корне + AGENTS.md в каждом пакете:

- Общие соглашения — в корневой .cursor/rules.
- Специфику пакета описывать в его AGENTS.md, не во вложенной .cursor/rules.

Как создать правило и не потерять его

Актуальных способов создать правило два:

  1. /create-rule прямо в чате агента — опишите, что хотите, и агент сгенерирует .mdc-файл с правильным заголовком и положит его в .cursor/rules.
  2. Customize → Rules → Add Rule в сайдбаре.

Старый путь через палитру команд Cmd+Shift+P → New Cursor Rule, который встречается в гайдах, в текущем интерфейсе заменён на /create-rule — ещё один пример дрейфа, из-за которого чужие инструкции не сходятся с тем, что вы видите на экране.

И главное правило про правила: коммитьте .cursor/rules в git. Это единогласная рекомендация всех источников без исключения. Правила версионируются вместе с кодом, приезжают ко всей команде при клонировании, а когда агент повторяет одну и ту же ошибку — вы правите правило, и на следующем pull выигрывают все.

Ещё один приём из документации: ссылайтесь на файлы кода через @filename, а не копируйте их содержимое в правило. Скопированный кусок кода устаревает при первом же рефакторинге, а ссылка остаётся актуальной. Консенсус трёх источников.

Слабые места и риски, о которых молчат

Вот где правила подводят на практике.

Apply Intelligently срабатывает не всегда. Тип, где агент сам решает по описанию, подключать ли правило, работает ненадёжно — и это подтвердил представитель Cursor на форуме ещё в феврале 2026. Рекомендация от самой команды: если критично, чтобы правило точно применилось, делайте его коротким и Always Apply, а не полагайтесь на «умное» подключение. Независимой перепроверки этого признания нет, но источник — сама Cursor.

Налог на токены. Каждое always-apply правило занимает место в контекстном окне ещё до того, как модель прочитает ваш код. Оценки разнятся: один источник называет «2000+ токенов на запрос» для 20 правил, другой — «16000+ токенов (8–12% окна)» для тех же 20 правил, но по 200 строк каждое. Числа не сопоставимы напрямую — всё зависит от длины файлов. Вывод один: правила должны быть короткими. Официальный потолок — до 500 строк на файл, практики советуют до 100–150.

Конфликтующие правила = непредсказуемость. Если два правила противоречат друг другу («используй default export» и «никогда не используй default export»), Cursor следует более свежезагруженному или выдаёт непоследовательный результат. Чёткого механизма разрешения конфликтов внутри одного типа документация не даёт — так что при добавлении новых правил проверяйте их на противоречия со старыми.

Антипаттерны: как формулировать не надо

Правило работает ровно настолько, насколько конкретно оно написано. Расплывчатые инструкции модель трактует как хочет — и вы получаете тот же разнобой, от которого пытались уйти. Сравните:

  • Плохо: «Пиши хороший код и следуй лучшим практикам». Для модели это шум — «хороший» у каждого свой, конкретного действия тут нет.
  • Хорошо: «Компоненты — функциональные, с типизированными пропсами через interface; побочные эффекты только в useEffect с явным списком зависимостей».

  • Плохо: «Обрабатывай ошибки». — Как именно? Try/catch? Result-тип? Логирование?

  • Хорошо: «Ошибки в асинхронном коде — через Result<T, E> из @/lib/result; голый throw в бизнес-логике запрещён».

Второй антипаттерн — раздувать одно правило до полотна на весь проект. Длинное always-apply правило и токены съедает, и хуже соблюдается: чем больше инструкций в контексте, тем слабее модель держит каждую из них — известный эффект больших языковых моделей. Лучше пять коротких правил под разные зоны, чем один свод на несколько сотен строк.

Третий — противоречия между правилами, которые копятся незаметно. Каждый раз, добавляя новое правило, быстро проверьте, не спорит ли оно с уже существующим: агент при конфликте ведёт себя непредсказуемо.

Чек-лист миграции с .cursorrules на .mdc

Если у вас старый одиночный файл — вот безопасный путь на новый формат:

  1. Аудит. Прочитайте свой .cursorrules и разбейте его на смысловые блоки: общий стиль, фронтенд, бэкенд, тесты.
  2. Создайте базу. .cursor/rules/000-base.mdc с alwaysApply: true — сюда общие для всего проекта вещи (стек, язык, тон).
  3. Разнесите по доменам. Отдельные .mdc под фронтенд (globs: ["**/*.tsx"]), бэкенд, тесты — каждый со своей маской.
  4. Проверяйте на каждом шаге. После каждого файла задайте агенту простую задачу в этой зоне и посмотрите, следует ли он правилу.
  5. Закоммитьте и удалите старый .cursorrules, когда убедитесь, что новые правила покрывают всё.

Неофициальный, но удобный приём: числовые префиксы в именах (00-base.mdc, 01-frontend.mdc) помогают держать порядок загрузки предсказуемым. В документации Cursor этого нет — это community-практика, но она встречается у нескольких авторов и не вредит.

Диагностика: правило не срабатывает

Если правило игнорируется, пройдите по списку — почти всегда причина здесь:

  • Расширение. Файл точно .mdc, а не .md?
  • Заголовок. YAML-frontmatter валиден? Опечатка в globs или alwaysApply — и правило молча не грузится.
  • Маска. src/* и src/**/* — разные вещи; первая берёт только прямых потомков. Проверьте, что glob реально покрывает ваши файлы.
  • Расположение. Файл в корневой .cursor/rules, а не в подпапке пакета монорепо (которая не сканируется)?
  • Тип. Если стоит Apply Intelligently — вспомните, что он ненадёжен; для проверки временно переключите на Always Apply.
  • Прямой вопрос. Спросите агента в чате: «Какие правила сейчас загружены?» — быстрый способ увидеть, видит ли он ваш файл вообще.

Коротко о главном

Правила Cursor — это память проекта для ИИ-агента, которая живёт в репозитории и работает у всей команды одинаково. Новый формат — папка .cursor/rules с .mdc-файлами; старый одиночный .cursorrules ещё работает, но пора мигрировать; AGENTS.md — простая альтернатива, особенно для монорепо. Держите правила короткими, коммитьте в git, ссылайтесь на файлы вместо копирования и помните про границы: правила — про агента, а не про автодополнение.

Хорошо настроенные правила не превращают ИИ в волшебника, но сильно поднимают планку: агент перестаёт угадывать ваш стиль и начинает писать так, как принято именно в вашем проекте. А если вы только осваиваетесь с самим подходом работы через ИИ-агента, начните с разбора, что такое вайб-кодинг и где у него границы.

Частые вопросы

.cursorrules ещё работает или уже нет? Работает — Cursor читает его ради обратной совместимости. Но формат признан устаревшим; для новых проектов используйте .cursor/rules/*.mdc.

Чем AGENTS.md отличается от .cursor/rules? Это markdown без YAML-заголовка и без типов правил — проще, но без условного подключения по маскам. Главный плюс: вложенные AGENTS.md работают в подпапках монорепо, где обычные .cursor/rules не сканируются.

Сколько правил можно держать? Технически сколько угодно, но каждое always-apply правило ест контекст. Держите файлы короткими (до 100–150 строк на практике, официальный потолок — 500) и не делайте всё «always».

Работают ли правила с автодополнением Cursor Tab? Нет. Правила применяются только в чате агента, не в Tab и не в Inline Edit (Cmd/Ctrl+K).

Почему моё правило игнорируется? Чаще всего причина в одном из пяти пунктов: файл не с расширением .mdc, битый YAML-заголовок, неверная маска glob, файл лежит в подпапке монорепо (которая не сканируется) или выбран тип Apply Intelligently, который срабатывает не всегда. Пройдите по чек-листу диагностики выше — он закрывает почти все случаи.

BYBIT COPY TRADING
Копируй профи
Bybit повторит сделки трейдера за тебя
Начать
Поделиться
Связаться:
Крипто- и data-аналитик, инженер-программист (факультет компьютерных наук ХНУРЭ). В IT с 2008 года: администрировал корпоративный мониторинг в «Vodafone Украина», семь лет разрабатывал и продвигал веб-проекты, пять лет руководил маркетингом на метриках — конверсия, CTR, ROI, LTV.Криптовалютными рынками занимаюсь с 2021 года: ончейн-метрики, токеномика, макроэкономические индикаторы. Разработал собственную data-driven модель анализа рынка на 30+ метрик. Стек — Python (pandas, NumPy, SciPy, matplotlib), математическая статистика и EDA; сбор и сверку данных автоматизирую AI-агентами.Принцип — «Don't trust, verify»: каждая цифра проверена по первоисточнику, ключевые — минимум по двум независимым; прогнозы — только сценарии с условиями. Тезис без данных не публикуется.