В этом материале
Правила Continue в .continue/rules дают инструкции проекта. Роли моделей и инструменты настраиваются отдельно; правило само по себе не принуждает политику команд.
Правило проекта сообщает Continue, как выполнять работу в репозитории: какие соблюдать соглашения, где лежат генерируемые файлы и какие нужны проверки. Это отличается от выбора модели и принудительного ограничения инструментов. Разделение облегчает перенос локальной настройки между проектами и сопровождение во времени. Текст инструкции полезен только при понимании, какой компонент действительно читает его и где он должен действовать.
Разместите инструкции по документации
Руководство Continue Rules указывает .continue/rules для локальных правил проекта. Храните соглашения вместе с репозиторием. Правило миграций одного приложения не должно превращаться в глобальную инструкцию для всех несвязанных проектов рабочего компьютера только из-за удобства единого файла.
Начните с узкого факта: какой исходник создаёт API-клиент. Объясните правильное место изменения и причину. Конкретное знание полезнее требования всегда быть правым, которое не даёт дополнительного контекста для выбора файла и не помогает отличить исходную схему от генерируемого результата.
Настраивайте модели независимо
Актуальный справочник YAML-конфигурации описывает поля и роли моделей. Правило использовать локальную модель не создаёт соединение runtime, её идентификатор и назначение роли. Значения должны присутствовать в действующей конфигурации, которую действительно загрузил установленный клиент Continue.
При разных моделях для чата и completion отдельно проверьте каждый процесс. Затем испытывайте правило в нужном режиме. Успешный ответ чата не доказывает, что другая функция использовала ту же модель или получила те же инструкции. Не объясняйте разницу правилом до проверки фактической конфигурации.
Изучите старый пример до переноса
Текущая документация помечает прежние JSON и context-provider материалы устаревшими. Подробное руководство правил лучше описывает современное поведение, чем исторический файл неизвестного поколения. Сначала определите, к какому интерфейсу и релизу относится найденный пример, затем выбирайте способ миграции.
Разделите старую настройку по назначению: инструкции репозитория, соединение модели, поиск и инструменты. Перенесите каждую часть в актуальный документированный механизм. Переименование файла не завершает миграцию, если пример зависел от контекстной функции, которая больше не выбрана или должна настраиваться отдельно.
Используйте противоречивый учебный случай
Создайте одноразовый репозиторий с генерируемым клиентом и небольшой исходной схемой. Попросите изменение, которое провоцирует исправление готового клиента. Посмотрите, направляет ли правило работу к правильному источнику, а не только появляется ли упоминание соглашения в объяснении модели.
Затем проверьте соседний файл, для которого правило не должно добавлять посторонние действия. Это выявляет чрезмерную широту инструкции. Рассмотрите объяснение вместе с diff: модель способна правильно пересказать правило и изменить неверный файл. Держите пример достаточно маленьким для понятной человеку ручной проверки.
Отделите инструкцию от гарантии
Правила попадают в контекст. Они не создают самостоятельно границу файловой системы, не устанавливают зависимости и не доказывают выполнение теста. Существенные условия обеспечивайте соответствующей средой или проверками репозитория, изучая фактический результат вместо одного обещания модели.
Для диагностики храните ревизию правил, версию Continue и действующую конфигурацию вместе. Исправляйте устаревшие пути и противоречия. Краткие точные инструкции помогают локальной модели пользоваться знаниями проекта; накопление исторических требований, наоборот, затрудняет определение актуального рабочего процесса и поиска причины нового неправильного изменения.
Материалы по теме
Воспроизводимый стек инференса: как сохранить результат GPU-пилота, LLM для кода на 12 ГБ VRAM: модель, контекст и запас.