🚶‍♂️ Логика активации .mdc и управление контекстом

В прошлом посте я говорил, что сваливать все правила в одну кучу — зло.

Переход на формат .mdc меняет подход к инженерии промптов. Ключевой инструмент здесь — frontmatter.

Простыми словами, это блок технических настроек в самом начале файла. Именно через него мы объясняем Курсору, в какой конкретно момент нужно активировать то или иное правило.

Это решает главную проблему больших проектов — перегрузку контекстного окна (context window). Если загружать в модель всё подряд, происходит размывание внимания: точность ответов падает, появляются галлюцинации. Метаданные позволяют этого избежать, отсекая лишний шум.

4 типа активации правил, которые я использую: ⭐️ Apply to Specific Files (Glob-паттерны) Самый надежный метод для разделения контекста. Правило активируется автоматически, но строго при совпадении с паттерном (например, app/**/*.ts). Это гарантирует, что инструкции по фронтенду не будут мешать модели, когда она пишет SQL-миграции.

⭐️ Always Apply (Постоянная активация) Правило находится в контексте всегда. Этот режим стоит использовать только для фундаментальных вещей: базовых стандартов безопасности, Code Style и архитектурных принципов, которые актуальны для любой задачи.

⭐️ Apply Intelligently (Интеллектуальная активация) Агент сам решает, нужно ли ему это правило, анализируя его описание. Важный нюанс: здесь требуется высокая точность формулировок в метаданных. Если описание будет размытым, модель может ошибочно проигнорировать файл или, наоборот, подтянуть его не к месту.

⭐️ Manual (Ручной вызов) Правило добавляется в контекст только при явном вызове через символ @. Идеально подходит для редких сценариев, таких как специфический рефакторинг или генерация документации.

Итог: Вместо того чтобы надеяться, что ИИ сам разберется в каше из инструкций, мы создаем жесткую архитектуру.

Результат — модель тратит меньше токенов на чтение мусора и выдает решение быстрее.