# Промпты для вайбкодинга: как просить ИИ, чтобы не было хаоса

> Промпты для вайбкодинга, после которых проект не превращается в хаос: контекст, маленькие шаги, ограничения, план перед кодом и проверка результата.

Published: 2025-04-02 · Source: https://subxcat.com/ru/articles/vibe-coding-prompts · Author: SUBXCAT

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

Ниже — пять привычек, которые держат проект в порядке. Ни одна не требует знать программирование.

## Сначала контекст

ИИ не помнит, что ты имел в виду вчера, и не знает, зачем существует твоё приложение. Если не сказать, он придумает сам, и придумает усреднённое.

Что стоит сообщать в начале задачи:

- что это за продукт и для кого — одной-двумя фразами;
- на чём сделан проект: фреймворк, база, где хостится;
- какая часть приложения затронута: экран, таблица, функция;
- что уже есть и что трогать нельзя.

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

## Маленькие шаги вместо больших просьб

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

Режь на шаги, каждый из которых можно проверить руками за пару минут:

1. Таблица заказов и страница со списком, пока на тестовых данных.
2. Привязка заказов к текущему пользователю.
3. Проверка, что чужие заказы не видны.
4. Подключение оплаты в тестовом режиме.

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

## Ограничения важнее пожеланий

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

Полезные ограничения:

- «Меняй только файлы, которые относятся к этой странице»;
- «Не добавляй новых библиотек без вопроса»;
- «Не трогай схему базы, если не спрошу»;
- «Секреты — только на сервере, не в коде браузера»;
- «Если для задачи нужно что-то из этого нарушить — остановись и спроси».

Последнее особенно важно: оно превращает тихие решения ИИ в вопросы, которые ты видишь.

## Попроси план до кода

Для любой задачи сложнее «поменяй цвет кнопки» сначала попроси план и только потом код. План читается за минуту и показывает, правильно ли тебя поняли.

```
Задача: пользователь может отменить запись не позже чем за 24 часа.
Сначала не пиши код. Опиши план: какие файлы поменяешь,
что добавишь в базу, как сервер проверит, что запись своя
и что до неё больше суток. Перечисли, что может пойти не так.
```

Если в плане есть что-то странное — новая таблица, которая не нужна, или проверка только в интерфейсе, — поправь сейчас. Исправлять план бесплатно, исправлять код — нет.

## Проверяй, а не верь

ИИ уверенно пишет «готово» и тогда, когда сделал половину. После каждого шага:

- открой приложение и пройди сценарий руками, включая неудачный: пустое поле, чужой аккаунт, повторное нажатие;
- попроси объяснить, что поменялось и почему, простыми словами;
- спроси прямо: «Что ты не сделал или сделал упрощённо?» — модели часто признаются, если спросить;
- если инструмент показывает изменения по файлам, пробеги их глазами: неожиданно затронутый файл — повод спросить.

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

## Когда начать заново

Если третья попытка починить одно и то же не помогла, остановись. Откати к последнему рабочему состоянию, начни новый разговор и опиши задачу заново, с учётом того, что узнал. Длинная переписка накапливает неверные предположения, и модель продолжает на них опираться.

## Коротко

- Хороший промпт для вайбкодинга начинается с контекста: продукт, стек, затронутая часть и что трогать нельзя.
- Делай шаги, которые проверяются руками за пару минут, и сохраняй рабочее состояние между ними.
- Ограничения и правило «остановись и спроси» защищают от тихих решений ИИ.
- Для любой непростой задачи сначала план, потом код.
- После каждого шага проверяй сценарий руками и спрашивай, что сделано упрощённо.

Если проект уже успел запутаться, SUBXCAT поможет разобрать его и вернуть к состоянию, где снова можно работать маленькими шагами.
