Cursor Rules: настраиваю AI под себя один раз и не объясняю снова

Каждый раз объяснять AI, что «у нас TypeScript, не JavaScript», «используем Tailwind, не обычный CSS», «пиши тесты с Vitest» — это утомляет. После 50-го повторения начинаешь думать, что AI не обучается.

Он и не обучается. Но у Cursor есть rules — файлы с правилами, которые он читает автоматически при каждом запросе. Один раз написал — и больше не объясняешь.

Статья для тех, кто использует Cursor и хочет перестать повторять одни и те же инструкции в каждом чате. Если вы только знакомитесь с AI-редакторами — сначала посмотрите сравнение Cursor, Claude Code и Codex.

Что такое Cursor Rules

Rules — это markdown-файлы с инструкциями для AI. Cursor читает их автоматически и учитывает в каждом запросе в проекте.

Работает как системный промпт, только не нужно вставлять его вручную каждый раз.

Где хранятся:

• .cursor/rules/ — папка в корне проекта (рекомендую)
• .cursorrules — один файл в корне (старый формат, работает, но менее гибкий)

Разница: в папке .cursor/rules/ можно создать несколько файлов и настроить, когда каждый применяется. В .cursorrules — один файл на всё.

Три типа rules

1. Always (всегда активны)

Применяются к каждому запросу. Идеально для общих правил проекта: стек, стиль кода, соглашения.

2. Auto-attached (автоматически по паттерну файла)

Подключаются, когда AI работает с файлами определённого типа. Например, rules для *.test.ts — только когда пишете тесты.

3. Agent-requested (по запросу агента)

AI сам решает, применять ли их. Укажите описание — модель поймёт, когда это уместно.

4. Manual (вручную через @)

Вы явно вызываете через @rules-имя в чате. Для специфических сценариев.

Создаём rules: с чего начать

Открываем настройки: Cmd+Shift+J → вкладка Rules → или просто создаём файл .cursor/rules/general.mdc.

Формат — markdown с YAML-заголовком:

markdownКопировать

--- description: Общие правила проекта globs: alwaysApply: true --- # Правила проекта ## Стек - TypeScript, строгий режим (strict: true) - React 18 + Next.js 14 App Router - Tailwind CSS — никаких inline-стилей - Prisma + PostgreSQL для работы с данными ## Стиль кода - Функциональные компоненты, не классы - Именованные экспорты, не default - Типы явные, никакого any - Импорты: React не нужен (уже в scope)

alwaysApply: true — это и есть тип Always.

Пример реального набора rules

Вот что я использую в одном из своих проектов. Адаптируйте под себя.

general.mdc — базовые правила

markdownКопировать

--- description: Базовые правила для всего проекта alwaysApply: true --- # Проект: личный дашборд ## Стек - Next.js 14 App Router (не Pages Router) - TypeScript strict mode - Tailwind CSS + shadcn/ui - Zustand для стейта - Tanstack Query для серверного стейта - Vitest + Testing Library для тестов ## Принципы - Компоненты маленькие (< 100 строк) - Логика вынесена в хуки - Типы описаны явно, any — только с комментарием почему - Ошибки обрабатываем везде — нет молчаливых catch ## Запрещено - console.log в продакшн-коде (используй logger) - Хардкодить строки (используй константы или i18n) - Мутировать стейт напрямую

tests.mdc — правила для тестов

markdownКопировать

--- description: Правила написания тестов globs: ["**/*.test.ts", "**/*.test.tsx", "**/*.spec.ts"] alwaysApply: false --- # Тесты ## Фреймворк - Vitest, не Jest - Testing Library для React-компонентов - MSW для мокирования API (не fetch мокируем напрямую) ## Структура - describe → it (не test) - Один assert на тест где возможно - Имена: "should [поведение] when [условие]" ## Пример \`\`\`typescript describe('UserCard', () => { it('should show username when user is loaded', async () => { render(<UserCard userId="123" />) expect(await screen.findByText('Иван')).toBeInTheDocument() }) }) \`\`\`

api.mdc — правила для API-роутов

markdownКопировать

--- description: Правила для Next.js API routes и серверных компонентов globs: ["**/api/**/*.ts", "**/app/**/(route|page|layout).tsx"] alwaysApply: false --- # API Routes ## Структура ответа Всегда возвращай { data, error, meta } — не голые данные ## Ошибки - 400 — невалидные данные пользователя - 401 — не авторизован - 403 — нет прав - 404 — не найдено - 500 — серверная ошибка (логируй подробно, пользователю — общее сообщение) ## Валидация входных данных Всегда через Zod. Никаких ручных if-проверок.

Как писать эффективные rules

Конкретно, не общо. «Пиши чистый код» — бесполезно. «Компоненты не длиннее 100 строк, логика в хуках» — работает.

Примеры лучше описаний. Если у вас нестандартный паттерн — покажите пример кода прямо в rule. AI скопирует стиль.

Запреты работают. «Не используй fetch напрямую, только axios через наш httpClient» — AI это соблюдает.

Не перегружайте. Rule на 500 строк с 50 правилами работает хуже, чем 3 коротких файла по теме. AI лучше воспринимает фокусированные инструкции.

Готовые шаблоны rules

Не нужно писать с нуля. В репозитории awesome-cursorrules на GitHub — сотни готовых rules для популярных стеков:

• Next.js + TypeScript
• FastAPI + Python
• React Native
• Flutter
• Go + Gin

Берёте подходящий, адаптируете под свой проект.

Разница с .cursorrules (старый формат)

Старый .cursorrules в корне проекта — один файл, всегда применяется. Работает, но:

• Нельзя контролировать, для каких файлов
• Всё в одном месте — становится громоздким
• Нельзя передавать через @ в чате

Новый формат .cursor/rules/*.mdc — гибче. Рекомендую переходить, если у вас ещё .cursorrules.

Практика: попробуйте прямо сейчас

Если вы используете Cursor на реальном проекте:

1. Создайте .cursor/rules/ в корне
2. Напишите general.mdc с базовым стеком (3-5 пунктов)
3. Откройте чат, попросите написать простой компонент — посмотрите, соблюдает ли он ваши правила
4. Добавляйте правила по мере необходимости

Мне потребовалось примерно полчаса, чтобы написать первый вариант rules. Сейчас экономлю минут 10-15 в день на повторных объяснениях.

Следующий уровень — superpowers для Claude Code: там аналогичная концепция, но для агентного режима, где AI работает автономно.