Вайбкодинг: папка /docs и стоп-слопы для ИИ, чтобы не ломать сайт

Почему нейросеть начинает вести себя как творческий хаос

Признак работающего вайбкодинга — вы быстро получаете страницу или компонент. Признак приближающейся проблемы — когда ИИ, открыв новый чат, предлагает меню другого цвета, перепридумывает блок «О себе» и незаметно ломает перелинковку. Это не баг конкретной модели и не ошибка промпта. Это прямое следствие отсутствия зафиксированных проектных ограничений.

Каждая сессия для языковой модели — чистый лист. Если вы не передали ей контекст дизайн-системы, структуры страниц, правил текста и явных запретов, она заполнит пробелы собственными предположениями. И в каждом новом чате предположения будут разными. За несколько итераций сайт из целостного продукта превращается в коллекцию несвязанных решений.

Проектная энтропия нарастает незаметно. Сегодняшний «небольшой компромисс» по шрифту или отступу завтра становится стандартом для пары новых страниц, и через неделю вы обнаруживаете три варианта карточек услуг. Решение не в том, чтобы писать всё более подробные промпты, а в том, чтобы вынести правила из головы разработчика в документы, которые живут рядом с кодом и всегда доступны ИИ.

Папка /docs: центр управления поведением ИИ

Практика, проверенная в реальных проектах на вайбкодинге, — папка /docs в корне проекта. В неё складываются не технические спецификации в классическом понимании, а набор файлов, каждый из которых отвечает на один вопрос: «Как ИИ должен действовать в этой части проекта, чтобы не разрушить уже сделанное».

Ключевая идея: это инструкции, написанные для того, чтобы их читала нейросеть. Они короткие, структурированные, с явными примерами и запретами. Когда запускается новая сессия, первым делом вы отправляете модели содержимое одного или нескольких файлов из /docs, и дальше она работает в заданных границах.

Такой подход превращает хаотичные взаимодействия в управляемый процесс. Вы не тратите время на исправление случайных «улучшений» ИИ, а накапливаете базу знаний, которая с каждым новым файлом становится точнее. Проект начинает развиваться не вопреки инструменту, а благодаря ему.

Минимальный боевой комплект файлов

Первый вопрос, который возникает: «Сколько файлов заводить и какие именно?» Ориентироваться имеет смысл на те аспекты проекта, где разночтения стоят дороже всего. Ниже — набор, который закрывает большинство типовых проблем при создании сайта через ИИ, и с которого можно начинать уже сегодня.

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

Стоп-слопы: что нельзя делать ни при каких условиях

Самые дорогие ошибки происходят не когда ИИ добавляет что-то лишнее, а когда он меняет то, что трогать было запрещено. Поэтому в проекте появляется директория stop-slop/ — коллекция файлов с явными запретами. Каждый файл отвечает за конкретный участок: главную страницу, навигацию, форму заявки, критичный стилевой токен.

Правила здесь формулируются предельно однозначно, без полутонов. Пример содержания файла stop-slop/main-navigation.md:

• Не менять структуру пунктов меню.
• Не добавлять новые пункты без явного запроса.
• Не изменять порядок элементов.
• Не заменять текстовые метки на иконки.
• Не трогать мобильное поведение (гамбургер, раскрытие).

Такие файлы не описывают, как должно быть, — они только блокируют нежелательные действия. Модель получает их вместе с основной инструкцией и действует в очерченном периметре. Если ИИ всё же предлагает изменение, вы ссылаетесь на стоп-слоп, и обсуждение закрывается.

Формат стоп-слопов особенно полезен при командной работе, где разные участники могут взаимодействовать с проектом через ИИ и не знать всей истории. Запреты страхуют от случайного разрушения узких мест.

Как масштабировать систему правил на растущий проект

Папка /docs — не застывшая конструкция. Когда сайт разрастается, появляются новые типы страниц, разделы, языковые версии или интеграции, система правил должна эволюционировать. Принцип остаётся прежним: один файл — одна зона ответственности. Никаких мега-инструкций на несколько экранов.

На практике это даёт несколько рабочих приёмов:

1. Дробление по смыслу. Если файл components.md перевалил за две страницы, его разделяют на components-cards.md, components-headers.md и т.д. ИИ получает только релевантную задаче часть, а не тонну контекста.
2. Версионирование через changelog. Каждое важное изменение правил фиксируется в changelog.md с датой и кратким обоснованием. Это позволяет в будущем понять, почему решение было принято, и избежать отката назад.
3. Связка с промптами. В шаблонах промптов, которыми вы начинаете сессию, появляются постоянные ссылки на конкретные файлы: «Используй правила из /docs/design-system.md и /docs/components.md». Это сокращает время на введение в контекст.
4. Аудит актуальности. Раз в несколько недель полезно пробежаться по /docs и удалить то, что больше не нужно, или обновить устаревшие правила. Мёртвые инструкции сбивают модель с толку.

Система правил работает тем лучше, чем точнее она отражает текущее состояние проекта. Это живой актив, а не архив.

Практический чеклист: с чего начать прямо сейчас

Ниже — воспроизводимая последовательность действий. Она не требует специальной подготовки и применима к любому сайту, который делается или дорабатывается с помощью ИИ.

1. Создайте папку /docs в корне проекта.
2. Скопируйте в .md-файлы всю разрозненную информацию, которая сейчас живёт в переписках с нейросетью: выбранные цвета, шрифты, структуру страниц, утверждённый тон текстов.
3. Сформулируйте минимум три явных запрета в папке stop-slop/. Цель — защитить самые критичные элементы: навигацию, главную страницу, форму захвата контактов.
4. В следующей сессии с ИИ начните с передачи одного-двух файлов из /docs вместе с задачей. Например: «Прочитай components.md и copywriting-skill.md, после этого добавь новый блок «Отзывы» на страницу услуг, используя только готовые компоненты».
5. Каждый раз, когда модель снова придумывает несогласованный вариант, не правьте руками — добавьте новый пункт в соответствующий файл правил или в стоп-слоп.
6. Заведите changelog.md и фиксируйте в нём значимые изменения: смену дизайн-токена, реструктуризацию страниц, новые запреты.
7. Проверьте через 2–3 сессии, сократилось ли число случайных переделок. Если нет — правила записаны недостаточно однозначно; перепишите их короче и конкретнее.

Этот подход не отменяет необходимость думать, но переносит контроль из реактивного режима в превентивный. Каждая минута, потраченная на документирование правила, экономит десятки минут на исправление незапланированных «улучшений».

Источники

• Telegram-сигнал ONFF Journal — кейс и набор файлов правил из практики вайбкодинга.