Cursor стал главным AI-редактором кода для профессиональных разработчиков. Но большинство использует лишь малую часть его возможностей. Настоящая сила Cursor скрыта в системе Cursor Rules — механизме, который позволяет обучить ИИ писать код именно так, как принято в вашей команде: с правильными паттернами, конвенциями и ограничениями.
В этом руководстве мы разберём всё, что нужно знать о правилах Cursor: типы правил, как писать эффективные инструкции, реальные примеры для популярных стеков и продвинутые техники совмещения правил с MCP-серверами. Подходит и для соло-разработчиков, и для команд из 50 человек.
Что такое Cursor Rules и зачем они нужны
Cursor Rules — это инструкции, которые вы даёте AI-моделям (GPT-4, Claude и др.) внутри Cursor, чтобы управлять тем, как они генерируют, редактируют и проверяют код. Без правил ИИ делает обобщённые предположения — может использовать классовые компоненты в проекте на хуках, генерировать JavaScript вместо TypeScript или игнорировать конвенции вашей команды.
С грамотно составленными правилами вы получаете:
- Единый стиль кода — каждый сгенерированный фрагмент соответствует вашим соглашениям
- Соблюдение архитектуры — ИИ уважает вашу файловую структуру, паттерны и границы модулей
- Меньше циклов ревью — меньше времени на исправление AI-кода под ваши стандарты
- Выравнивание команды — новые разработчики с первого дня получают те же рекомендации
- Безопасность — предотвращение генерации небезопасных паттернов: захардкоженных секретов, SQL-инъекций и т.д.
Думайте о Cursor Rules как о конституции кодовой базы. Это единственный источник истины о том, как должен быть написан код, и каждое взаимодействие ИИ в Cursor подчиняется этим правилам.
Типы правил в Cursor
Cursor поддерживает три способа задания правил. Каждый имеет свою область действия и сценарии использования.
1. Файл .cursorrules (корень проекта)
Оригинальный и самый распространённый подход. Вы создаёте файл .cursorrules в корне проекта:
my-project/
.cursorrules <-- правила проекта
src/
package.json
Файл содержит текстовые инструкции. Cursor читает его автоматически при работе с проектом. Минимальный пример:
# .cursorrules
Стек: TypeScript, React 19, Next.js 15 (App Router), Tailwind CSS v4.
Пакетный менеджер: pnpm. Всегда использовать lockfile.
## Стиль кода
- Только функциональные компоненты. Никаких классовых компонентов.
- Именованные экспорты вместо default export.
- TypeScript strict mode. Не использовать "any" — предпочитать "unknown" с type guards.
- Имена файлов: kebab-case (user-profile.tsx), компоненты: PascalCase.
## Архитектура
- Связанные файлы рядом: page.tsx, loading.tsx, error.tsx в одной папке маршрута.
- Бизнес-логика в lib/ или hooks/. Компоненты — презентационные.
- Server Components по умолчанию. "use client" только когда необходимо.
## Безопасность
- Никогда не хардкодить API-ключи, токены и секреты.
- Валидировать все пользовательские данные через Zod на сервере.
- Использовать параметризованные запросы к БД.
Плюсы: Просто, широко принято, легко коммитить в Git, работает со всеми версиями Cursor.
Минусы: В больших проектах один файл может стать громоздким. Нет контекстной специфичности.
Заметка: Хотя Cursor ввёл новые форматы правил, .cursorrules остаётся полностью поддерживаемым и является самым популярным подходом в open source проектах. Если начинаете новый проект, присмотритесь к директорному подходу ниже, но .cursorrules — вполне рабочий вариант.
2. Директория .cursor/rules/ (контекстные правила)
Более гибкий подход, появившийся в 2025 году. Вместо одного файла вы создаёте несколько файлов правил внутри .cursor/rules/:
my-project/
.cursor/
rules/
general.mdc <-- всегда активны
react.mdc <-- активны для .tsx файлов
api.mdc <-- активны для api/ маршрутов
testing.mdc <-- активны для тестов
src/
package.json
Каждый .mdc-файл (Markdown Configuration) имеет frontmatter-блок, управляющий активацией:
---
description: Конвенции React-компонентов
globs: ["**/*.tsx", "**/*.jsx"]
alwaysApply: false
---
# Правила React-компонентов
- Функциональные компоненты с TypeScript-интерфейсами для пропсов.
- Деструктуризация пропсов в сигнатуре функции.
- Обработчики событий с префиксом handle: handleClick, handleSubmit.
- React.memo() только при подтверждённой профилированием необходимости.
- Предпочитать композицию, а не проброс пропсов. React Context для сквозных данных.
Ключевые поля frontmatter:
| Поле | Описание |
|---|---|
description | Краткое описание, видимое в списке правил Cursor |
globs | Паттерны файлов, активирующие правило (**/*.tsx) |
alwaysApply | Если true, правило активно всегда, независимо от файла |
Плюсы: Модульность, контекстная осведомлённость, правила активны только когда актуальны, чистая организация.
Минусы: Более новая возможность — не все команды с ней знакомы.
3. Глобальные правила (настройки Cursor)
Глобальные правила применяются ко всем проектам в Cursor. Настраиваются в Settings → General → Rules for AI. Идеальны для личных предпочтений:
# Глобальные правила (в настройках Cursor)
Отвечай на русском языке.
По умолчанию используй TypeScript для новых файлов.
Предпочитай функциональный и декларативный стиль.
Когда прошу "исправить" — сначала объясни, что было не так.
Никогда не генерируй комментарии-заглушки типа "// TODO: implement this".
Когда использовать глобальные правила:
- Личные предпочтения стиля кода (отступы, кавычки)
- Язык ответов ИИ
- Стиль взаимодействия (подробные объяснения или краткие ответы)
Когда НЕ использовать глобальные правила:
- Выбор технологий проекта (React vs. Vue)
- Командные конвенции (это для проектных правил)
- Архитектурные решения (меняются от проекта к проекту)
Приоритет и наслоение правил
Когда есть несколько источников правил, Cursor объединяет их с таким приоритетом (от высшего к низшему):
- .cursor/rules/*.mdc — самые специфичные, привязаны к паттернам файлов
- .cursorrules — проектные правила
- Глобальные правила — самая широкая область действия
Это позволяет задать широкие дефолты глобально, установить проектные конвенции в .cursorrules и переопределить для конкретных типов файлов в .cursor/rules/.
Как писать эффективные правила
Не все правила одинаково полезны. Расплывчатые инструкции типа «пиши чистый код» не помогут ИИ. Вот проверенные принципы написания работающих правил.
Будьте конкретны и декларативны
Плохо: «Используй хорошие имена.»
Хорошо:
Именование:
- Переменные и функции: camelCase (getUserData, isLoading)
- Компоненты: PascalCase (UserProfile, DataTable)
- Константы: UPPER_SNAKE_CASE (MAX_RETRIES, API_BASE_URL)
- Файлы: kebab-case (user-profile.tsx, data-table.ts)
- Типы/интерфейсы: PascalCase с говорящими именами (UserProfileProps, ApiResponse)
- Булевы переменные: префикс is/has/should (isLoading, hasError, shouldRetry)
Используйте позитивные инструкции
Говорите ИИ, что делать, а не только чего избегать. К каждому «не делай» добавьте «делай вместо этого»:
# Вместо просто:
Никогда не используй any.
# Пишите:
Не использовать тип "any". Использовать "unknown" с type guards или явные типы.
Когда тип действительно неизвестен в compile time:
function processData(input: unknown): Result {
if (isValidInput(input)) { ... }
}
Включайте примеры кода
Правила с примерами кода работают значительно эффективнее. Покажите ИИ точный формат вывода:
# Конвенция API-маршрутов
Каждый файл маршрута следует этой структуре:
import { NextRequest, NextResponse } from "next/server";
import { z } from "zod";
const requestSchema = z.object({ ... });
export async function POST(request: NextRequest) {
const body = await request.json();
const parsed = requestSchema.safeParse(body);
if (!parsed.success) {
return NextResponse.json({ error: parsed.error.flatten() }, { status: 400 });
}
// ... бизнес-логика
return NextResponse.json({ data: result });
}
Группируйте правила по категориям
Структурируйте файл правил с чёткими разделами:
# Контекст проекта
Стек, обзор архитектуры, ключевые решения.
# Стиль кода
Именование, форматирование, порядок импортов.
# Архитектура
Файловая структура, паттерны, границы модулей.
# Обработка ошибок
Как обрабатывать ошибки, что логировать, что выбрасывать.
# Тестирование
Структура тестовых файлов, что тестировать, ожидания по покрытию.
# Безопасность
Работа с секретами, валидация входных данных, безопасные паттерны.
Практические примеры по стекам
Вот готовые к продакшену примеры правил для популярных технологических стеков. Используйте их как отправную точку и адаптируйте под свой проект. Все эти шаблоны также доступны в каталоге правил Mindaxis.
Правила для React / Next.js
Типичный проект на Next.js App Router с React 19, TypeScript и Tailwind CSS. Полные шаблоны: TypeScript + Next.js и React.
# .cursorrules — Проект на Next.js App Router
## Стек
TypeScript, Next.js 15 (App Router), React 19, Tailwind CSS v4, pnpm.
## Компоненты
- Только функциональные компоненты. Никаких классовых.
- React Server Components по умолчанию. "use client" только при необходимости.
- Пропсы: TypeScript-интерфейс, деструктуризация в сигнатуре.
- Один компонент на файл. Имя файла = имя компонента в kebab-case.
## Получение данных
- Server Components: async/await с fetch() или запросы к БД напрямую.
- Client Components: React Query (TanStack Query) с обработкой ошибок/загрузки.
- Не использовать useEffect для загрузки данных.
## Маршрутизация
- Файловая маршрутизация по конвенциям App Router.
- page.tsx, loading.tsx, error.tsx, layout.tsx рядом в папке маршрута.
- Route groups (папки в скобках) для организации без влияния на URL.
## Стили
- Утилитарные классы Tailwind CSS. Без отдельных CSS-файлов без необходимости.
- Повторяющиеся паттерны классов — выносить в переиспользуемые компоненты.
- Утилита cn() для условного объединения классов.
- Mobile-first: sm:, md:, lg: брейкпоинты.
Правила для Node.js бэкенда
Для API-сервиса на Node.js с Express или Hono. Смотрите также шаблоны API guidelines и security rules.
# .cursorrules — API-сервис на Node.js
## Стек
TypeScript, Node.js 22, Hono (или Express), PostgreSQL, Drizzle ORM, pnpm.
## Структура проекта
src/
routes/ — обработчики маршрутов по доменам
services/ — бизнес-логика (без HTTP-деталей)
repositories/ — запросы к БД и доступ к данным
middleware/ — аутентификация, валидация, ошибки, логирование
lib/ — утилиты, конфиг, типы
index.ts — точка входа сервера
## Паттерны
- Слоистая архитектура: routes → services → repositories.
- Routes — HTTP (парсинг запроса, отправка ответа). Services — логика. Repos — БД.
- Dependency injection через параметры конструктора, не глобальные синглтоны.
- Возвращать Result-типы (success/error) из сервисов. Throw только для непредвиденных сбоев.
## Безопасность
- Не хардкодить секреты. Переменные окружения через dotenv.
- Валидация всех входных данных через Zod middleware.
- Rate-limiting для чувствительных эндпоинтов.
- Хэширование паролей через argon2. Никогда не хранить пароли в открытом виде.
Правила TypeScript Strict Mode
Максимальная типобезопасность. Шаблон доступен в TypeScript rules.
# .cursorrules — TypeScript Strict
## Требования к tsconfig
Включить все strict-опции:
"strict": true,
"noUncheckedIndexedAccess": true,
"noImplicitReturns": true,
"noFallthroughCasesInSwitch": true,
"exactOptionalPropertyTypes": true
## Типобезопасность
- Никогда не использовать "any". Только "unknown" с type guards или явные типы.
- Минимум type assertions (as Type). Предпочитать type guards.
- Discriminated unions для моделирования состояний:
type State =
| { status: "idle" }
| { status: "loading" }
| { status: "success"; data: Result }
| { status: "error"; error: AppError };
- Branded types для ID и доменных значений:
type UserId = string & { readonly __brand: "UserId" };
## Функции
- Явная аннотация типа возвращаемого значения у каждой функции.
- Перегрузки, когда функция имеет разные типы возврата в зависимости от входа.
- readonly-параметры: (items: readonly Item[]) => ...
Правила безопасности: обязательный минимум
Каждый проект должен включать правила безопасности. Без них AI-ассистент может непреднамеренно генерировать небезопасный код — захардкоженные токены, уязвимости SQL-инъекций, пропущенную валидацию. Вот сфокусированный набор (также доступен в шаблоне security rules):
# Правила безопасности
## Секреты
- НИКОГДА не хардкодить API-ключи, токены, пароли или строки подключения.
- Переменные окружения для всех секретов.
- В примерах и тестах — плейсхолдеры: "sk-test-xxx", "your-api-key-here".
- .env в .gitignore. Предоставлять .env.example с плейсхолдерами.
## Валидация входных данных
- Валидировать ВСЕ пользовательские данные на сервере через Zod.
- Клиентская валидация — только для UX. Никогда не полагаться на неё для безопасности.
- Санитизировать HTML для предотвращения XSS.
## База данных
- Параметризованные запросы или ORM. Никогда не конкатенировать пользовательский ввод в SQL.
- Принцип минимальных привилегий для ролей БД.
- Шифровать чувствительные данные at rest.
## Зависимости
- Регулярно запускать "pnpm audit".
- Фиксировать версии зависимостей в lockfile.
- Проверять changelog перед мажорными обновлениями.
Продвинутый уровень: правила + MCP-серверы
Cursor Rules становятся ещё мощнее в сочетании с MCP (Model Context Protocol) серверами. MCP-серверы расширяют возможности ИИ за пределы генерации кода — дают доступ к инструментам, базам данных, API и другим ресурсам.
Как правила и MCP-серверы работают вместе:
Пример: правила + MCP-сервер базы данных
Правила определяют паттерны кода, а MCP-сервер даёт ИИ прямой доступ к схеме вашей БД:
# .cursorrules (фрагмент)
При написании запросов к БД:
- Всегда проверяй текущую схему через MCP-инструмент БД перед написанием миграций.
- Используй точные имена колонок и типы из актуальной схемы.
- Генерируй Drizzle ORM schema-файлы, соответствующие состоянию БД.
Пример: правила + Git MCP-сервер
# .cursorrules (фрагмент)
Перед внесением изменений:
- Через git MCP-инструмент проверь текущую ветку и незакоммиченные изменения.
- Conventional commits: feat:, fix:, docs:, refactor:, test:, chore:.
- Не коммитить напрямую в main. Создавать feature-ветки.
Вы можете настроить MCP-серверы вместе с правилами через конструктор конфигов Mindaxis. Конструктор позволяет выбрать правила, MCP-серверы, промпты и суб-агенты, а затем экспортировать готовую конфигурацию для Cursor, VS Code, Claude или другого поддерживаемого инструмента.
Советы по внедрению в команде
Чтобы команда действительно начала использовать Cursor Rules, недостаточно просто создать файл. Проверенные стратегии:
- Коммитьте правила в репозиторий. Файл
.cursorrulesили директория.cursor/rules/должны быть под контролем версий. Все в команде автоматически получают одни и те же правила. - Начинайте с малого. 10-15 критических правил (именование, файловая структура, безопасность). Дополняйте по мере выявления повторяющихся паттернов.
- Ревьюйте правила в PR. Изменения
.cursorrules— как изменения ESLint-конфига. Они влияют на всех. - Добавляйте контекст. Краткий комментарий «почему» для неочевидных правил. Помогает и ИИ, и людям.
- Тестируйте правила. После добавления новых правил попробуйте несколько промптов в Cursor. Скорректируйте формулировки, если ИИ не следует им.
Начните с Mindaxis
Написание правил с нуля требует времени, особенно при настройке нового проекта или освоении нового стека. Mindaxis даёт быстрый старт с 80+ курируемых шаблонов правил для React, Next.js, TypeScript, Node.js, Python, Go, Rust, безопасности, тестирования и многого другого.
Как использовать:
- Откройте каталог правил — фильтруйте по технологии, фреймворку или области (безопасность, тестирование, стиль).
- Выберите пак — курируемые паки объединяют правила + MCP-серверы + промпты для типовых конфигураций (например, «Next.js Full Stack» или «Node.js API»).
- Используйте конструктор конфигов — выберите отдельные правила, MCP-серверы и промпты. Настройте параметры. Просмотрите результат.
- Экспортируйте — скачайте готовый
.cursorrules, директорию.cursor/rules/или конфигурацию для VS Code, Claude Desktop, Claude Code.
Каждый шаблон проверен на безопасность, следует лучшим практикам и обновляется по мере развития инструментов. Не пишите шаблонные правила с нуля — начните с проверенного шаблона и адаптируйте под свои нужды.
Заключение
Cursor Rules — одна из самых высокоэффективных инвестиций в ваш рабочий процесс разработки. Грамотно составленные правила превращают Cursor из обобщённого AI-помощника в члена команды, который действительно понимает конвенции, архитектуру и требования безопасности вашего проекта.
Начните с основ — файл .cursorrules, покрывающий стек, конвенции именования и политики безопасности. По мере роста проекта мигрируйте на .cursor/rules/ для контекстных правил. Комбинируйте правила с MCP-серверами для ещё более мощной AI-разработки.
Когда нужно вдохновение или быстрый старт — заходите в каталог правил Mindaxis за готовыми шаблонами.