Недавно я показывал, как ускорить создание админ-панели с помощью Admiral — фреймворка от команды dev.family для построения бэк-офиса на React. Тогда я использовал Cursor rules — набор текстовых правил, которые инструмент автоматически превращает в код.
Со временем я заметил, что такие правила универсальны: это обычные .md-файлы, которые можно использовать не только в Cursor, но и в других средах. Например, в GitHub Copilot, Windsurf, Replit, Zed, Continue и т.д. Возникает логичный вопрос: дадут ли они такой же эффект там, где изначально не задумывались?
Чтобы это проверить, я сравнил, как три популярных инструмента — Cursor, Copilot и Windsurf — справляются с одними и теми же инструкциями для админки. В статье разберём:
насколько легко адаптировать правила под разные среды;
где результат ближе всего к ожидаемому;
и в каких случаях инструмент действительно экономит время.
Эта статья будет полезна, если вы:
выбираете инструмент для своего проекта и хотите понять, чем они отличаются на практике;
уже работаете с правилами в Cursor и думаете, стоит ли переносить их в другие среды;
просто хотите увидеть честное сравнение трёх популярных помощников по коду.
Сравнение функциональности правил
Для начала свёл основные характеристики в одну таблицу: от типов и места хранения до режимов активации и ограничений по длине.
Возможности и подходы к правилам |
Cursor |
Windsurf |
Copilot |
Типы правил |
Проектные общие, проектные локальные, глобальные |
Проектные общие, проектные локальные, глобальные |
Проектные общие, проектные локальные |
Место хранения |
.cursor/rules |
.windsurf/rules |
.github/copilot-instructions.md .github/instructions |
Поддержка вложенности правил |
✅ |
✅ |
❌ |
Использование множества правил |
✅ |
✅ |
✅ |
Режимы активации |
Упоминание, постоянный режим, glob-шаблон, решение агента |
Упоминание, постоянный режим, glob-шаблон, решение агента |
Постоянный режим, glob-шаблон |
Ограничение длины |
Рекомендуется не более 500 строк |
12 000 символов |
Нет информации |
Типы правил
У разных инструментов есть свои уровни применения правил. Вот как они работают:
Проектные общие правила – применяются ко всей кодовой базе внутри конкретного проекта;
Проектные локальные правила — также действуют внутри проекта, но с возможностью выбрать определенные файлы или директории для их применения;
Глобальные правила – используются во всех проектах, где установлен инструмент.
? В Copilot можно создать один или несколько файлов с общими проектными правилами, либо с помощью glob определить файлы или папки, для которых будет действовать конкретное правило. В Cursor и Windsurf помимо этого есть возможность использовать глобальные правила, которые работают для всех проектов, разрабатываемых в IDE, а также правила активирующиеся с помощью прямого упоминания. Таким образом Copilot имеет меньше возможностей в сравнении с конкурентами.
Место хранения
Указывает, где физически хранятся файлы с правилами для каждого инструмента – это может быть отдельная папка или файл в корне репозитория. В идеале хотелось бы видеть унифицированную структуру, подходящую для разных AI-инструментов, но на практике каждый из них использует собственный формат. Тем не менее, Windsurf поддерживает импорт правил из директории .cursor, если она есть в проекте.
Поддержка вложенности правил
Речь о возможности размещать правила в дочерних директориях. Это особенно удобно в монорепозиториях, где разные части проекта требуют отдельных инструкций.
Но будем честны: хоть Copilot и не позволяет вкладывать файлы правил в дочерние директории, он предоставляет возможность настроить контекст использования для каждого правила. Например, указать glob-шаблон:
applyTo: "src/app/**/*.ts"
Использование множества правил
Позволяет применять сразу несколько правил, что актуально для сложных проектов, где могут быть разные требования.
Режимы активации
У каждого инструмента есть свои способы определить, когда и где применять правило:
Упоминание – правило активируется при прямом вызове или ссылке на него;
Постоянное – правило всегда активно, без дополнительных условий;
Glob-шаблон – правило работает только для файлов, подходящих под указанный шаблон;
Решение агента – AI сам решает, применимо ли правило на основе логики инструмента.
Ограничение длины
Указывает на рекомендуемую или максимальную длину правил. Это может влиять на производительность и удобство использования, а так же на количество потребляемых токенов и соответственно, стоимость инструмента.
Использование правил в правиле
Пришла идея проверить возможность использовать правила в правиле. Например, когда у нас могут быть какие-то условные расхождения в логике. Чтобы их избежать, в одном правиле можно описать структуру создания страницы, в зависимости от типа страницы можно было бы ссылаться на другое правило, в котором будут описаны некоторые нюансы, которые присущи для данного типа.
Создадим два простых правила.
test1.md
Write Hello in the chat
After that use @test2.md rule
test2.md
Write Bye-bye in the chat
В первом правиле просим использовать второе правило после выполнения первого.
Cursor отрабатывает идеально – сделал все что от него потребовали без лишнего текста.

Windsurf справился частично и только с третьей попытки.

Очевидно, что Cursor более чётко понимает, что от него требуется.

Так как Copilot не обладает возможностью активации правила упоминанием, для него проверять нечего.
Проверка эффективности при использовании правил.
Ну а теперь переходим к самому интересному и посмотрим, как каждый из инструментов справляется с нашей кастомной инструкцией, описывающей создание CRUD-структур в проектах на базе библиотеки Admiral. Добавляем это правило в соответствующее место, чтобы инструмент мог его распознать, и пробуем использовать его в работе.
Правило требует предоставить список из семи пунктов. Я подготовил его заранее:
clients
clients
id, full_name, phone, email, created_at, actions
surname, phone, first_name, email, patronymic, gender, birthday, previous_surname, password, uuid_1c, deleted_at, document_type, document_number, document_expiry_date, birth_address, settings_is_notify_upcoming_payments
id, phone, email, full_name
-
А теперь посмотрим, как правило сработает для разных инструментов.
Windsurf
Вот, что встречает нас на старте.
На этом можно было бы заканчивать работу с данным инструментом, но мы ребята настойчивые и просто включим VPN. К слову, у Cursor нет никаких геополитических ограничений.
В самом правиле содержатся все инструкции. Оно было составлено так, чтобы его было достаточно просто упомянуть в чате, где агент сам запросит всю необходимую информацию. Пробуем так сделать и видим, что агент читает файл с правилом и делает краткий пересказ.
Далее пробуем просто отправить список в надежде на дальнейшую генерацию кода. Агент понял задачу и сгенерировал всю необходимую кодовую базу.
Результат
С первой попытки весь необходимый код был сгенерирован без ошибок: компоненты подобраны корректно, атрибуты используются правильно. Однако запустить приложение не удалось из-за измененной структуры директорий. Вместо того чтобы разместить новую директорию clients внутри уже существующей src/crud, агент создал её в корне проекта, хотя по описанию правила это было не предусмотрено.
Со второй попытки структура была сформирована корректно: приложение успешно запускается, все страницы отображаются как ожидается.
Copilot
С этим инструментом всё оказалось сложнее. Дело в том, что Copilot применяет каждое правило при любом запросе, если файл подходит под glob-паттерн. А поскольку для правила по генерации CRUD-структуры нельзя задать чёткую область применения, оно будет срабатывать всегда.
Тем не менее, мы всё равно решили протестировать, чтобы точно понять, есть ли в этом смысл. Как и в случае с Windsurf, просто копируем файл с правилом в .github/instructions.
Так как в Copilot нет возможности активировать правило по упоминанию, мы составим более подробный запрос вручную.
Кодогенерация началась сразу после запроса: агент изучил правило, наметил структуру и… сгенерировал настоящего Франкенштейна, никак не связанного ни с нашим правилом, ни с проектом.
Результат
Запустить сгенерированный код невозможно. Структура файловой системы сформирована корректно, но содержимое самих файлов не соответствует ожидаемому результату.
Импортируются компоненты из неустановленных библиотек, например @pankod/refine-antd. Структура созданных файлов не соответствует, описанной в правиле.
В одной из типизированных заготовок импортируется несуществующий тип из пустого файла. Используются типы и функции из Next.js, хотя этот фреймворк не применяется в проекте. В общем, проблем хватает — итоговая реализация недееспособна.
Был создан пустой файл с типизацией, откуда импортируется несуществующий тип. Используется типизация и функция из фреймворка Next, который не используется в проекте.
В общем, проблем хватает и итоговый код не работает.
Мои выводы
Вот, к чему я пришёл после этого эксперимента:
Cursor снова показал себя, как лучший инструмент, который четко следует правилам.
Windsurf чуть хуже справился с задачей: с первой попытки не решил задачу, но со дальше сгенерировал всё корректно;
Copilot пока не подходит для наших целей как основной инструмент. Его поддержка правил всё ещё ограничена по сравнению с полноценными AI-IDE.
Тем не менее, Copilot отлично подойдёт, если нужно:
задать глобальные правила для проекта (например, по стилю кода);
описать структуру, которая поможет инструменту определять, где размещать новые сущности.
Но если же вы хотите использовать кастомные правила, которые можно активировать упоминанию, то лучше выбрать Cursor или Windsurf.