Файл-инструкция для ИИ-ассистента: как задать правила проекта один раз

Каждый новый чат с ИИ-ассистентом начинается одинаково: он понятия не имеет, на чём написан ваш проект, какой у вас порт, куда складывать компоненты и какая у вас версия Node. Вы объясняете всё заново. И на следующий день опять. Выход есть — один файл в корне проекта, куда вы один раз записываете правила. Дальше ассистент читает его сам.

Так я веду проект Hytaleservers.tech (мониторинг и топ-лист серверов Hytale) и держу для него два таких файла. Покажу, как они устроены и что в них писать.

Зачем вообще нужен такой файл

Модель не помнит предыдущие сессии. Всё, что вы рассказали вчера, сегодня для неё просто не существует. Файл-инструкция закрывает эту дыру: ассистент подхватывает его при старте и сразу работает в контексте вашего проекта.

Что это даёт на практике:

• ассистент не путает версии и не советует установить то, что у вас уже стоит;
• новый разработчик (или новая модель) разворачивает окружение по шагам без ваших пояснений;
• правила проекта собраны в одном месте, и вам больше не нужно держать их в голове.

Что положить внутрь

Содержимое я делю на два типа файлов, и так удобнее.

Первый — карта проекта. Обзор: что за проект, какой стек, какие версии. У меня в шапке стоит название, описание «Мониторинг и топ-лист серверов Hytale», статус, версия. Дальше — технический стек по разделам. Для фронтенда это Next.js 16.1.1 на App Router, React 19.2.3, TypeScript 5, Tailwind CSS 4, shadcn/ui в стиле New York, Radix UI, Framer Motion 12.26.2 для анимаций и набор утилит вроде clsx и tailwind-merge. Модель видит эти строки и перестаёт гадать.

Второй — инструкция по локальному запуску. Здесь пошаговый сценарий: как поднять окружение с нуля. У меня он начинается с проверки Node.js командой node --version и ожидаемым результатом v20.0.0 или выше. Затем идут шаги по установке зависимостей, настройке переменных окружения и запуску. Отдельно фиксирую порты: локально проект работает на 3000, в продакшене на VPS — на 3003. Такие мелочи ассистент угадать не может, их надо записать явно.

Как оформить, чтобы модель поняла

Эти файлы я пишу обычным Markdown — тем же, что и любую документацию. Никакого специального синтаксиса не нужно, модель одинаково хорошо читает и заголовки, и списки, и блоки кода.

Несколько приёмов, которые реально помогают:

• Пишите версии цифрами. «Next.js 16.1.1» работает лучше, чем «последний Next.js». Через полгода «последний» будет означать что-то другое.
• Давайте команды прямо в блоках кода. Ассистент выполняет их буквально, поэтому node --version понятнее словесного описания.
• Указывайте ожидаемый результат. Рядом с командой полезно написать, что должно получиться. Тогда модель понимает, прошёл шаг или нет.
• Структурируйте по шагам. «Шаг 1: проверка окружения», «Шаг 2: установка» читаются легче, чем сплошной текст.

Где хранить файл

Кладите его в корень репозитория. Тогда он попадает в контекст первым, и его видит любой инструмент. Имя выбирайте говорящее: у меня это отдельные файлы под карту проекта и под локальную настройку. Часть инструментов подхватывает файлы с определёнными именами автоматически. Но даже простой текстовый файл, на который вы дадите ассистенту ссылку в начале разговора, уже снимает большинство повторяющихся вопросов.

Держите файл живым

Главная ошибка — написать один раз и забыть. Обновили версию Next.js, сменили порт, переехали на новый VPS — правьте файл сразу. Устаревшая инструкция хуже её отсутствия: ассистент уверенно советует то, чего у вас давно нет. Я держу в шапке дату последнего обновления, чтобы сразу видеть, насколько документ свежий.

С чего начать сегодня

Не пытайтесь описать проект целиком за один присест. Начните с трёх вещей: стек с версиями, команда запуска и порты. Этого хватит, чтобы следующий чат стартовал без разогрева. Остальное — структуру папок, соглашения по коду, переменные окружения — дописывайте по мере того, как ловите себя на повторных объяснениях. Объяснили ассистенту одно и то же во второй раз — это сигнал: строчку пора занести в файл.