Как писать промпты для ИИ-конструкторов приложений (с примерами «до и после»)

Хороший промпт для ИИ-конструктора приложений описывает продукт, а не код: кто им пользуется, что делает пользователь шаг за шагом, какие данные хранятся и кому разрешено что видеть. Когда первая версия уже есть, просите одно конкретное изменение в сообщении, говорите, что должно остаться прежним, и описывайте проблемы в формате «я сделал X, ожидал Y, получил Z». Эти три привычки исправляют большинство неудачных результатов.

Остальная часть руководства подробно показывает эти приёмы с примерами «до и после», которые можно адаптировать.

Почему промптинг конструктора отличается от общения с ИИ-чатом

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

Поэтому цель промпта — не звучать умно. Цель — оставить меньше важных решений на волю случая. Для этого не нужен технический словарь. Нужно быть конкретным в том, что знаете только вы: о ваших пользователях, сценариях и правилах.

Что включить в первый промпт

Прежде чем что-либо написать, ответьте на эти вопросы. Каждый закрывает пробел, который ИИ иначе додумал бы сам.

Последняя строка недооценена. Сказать, чего вы не хотите, — значит не дать ИИ добавить блог, страницу с ценами и подписку на рассылку, о которых вы не просили.

До и после: первый промпт

До:

Сделай мне приложение для моего спортзала.

Конструктору придётся угадывать всё: участники или сотрудники? Занятия или персональные тренировки? Платежи? В итоге вы получите что-то, что выглядит как сайт спортзала, но не делает то, что вам нужно.

После:

Сделай приложение для записи на групповые занятия в небольшой студии йоги. Участники видят занятия на этой неделе (название, инструктор, время, свободные места), записываются и отменяют запись не позже чем за два часа до начала. Участники регистрируются по email и паролю. Владелец студии входит, чтобы добавлять занятия, видеть, кто записан, и отмечать посещаемость. Храни занятия, участников и записи в базе данных. Спокойный светлый дизайн, который хорошо работает на телефонах. Платежей пока нет.

Вторая версия по-прежнему короткая. Она просто отвечает на вопросы из таблицы выше.

Описывайте поведение, а не реализацию

Часто результат лучше, если описать, что должно происходить, а не как это сделать.

До:

Добавь useEffect, который загружает записи, и модальное окно для редактирования.

После:

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

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

Будьте конкретны в правилах

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

• Ограничения: «У участника не больше трёх будущих записей».
• Сроки: «Отмена закрывается за два часа до начала занятия».
• Крайние случаи: «Если мест нет, показывать кнопку «Встать в лист ожидания» вместо «Записаться»».
• Права доступа: «Преподаватели видят посещаемость своих занятий, но не чужих».

Каждое из этих правил — одно предложение. Если пропустить любое, приложение либо не будет его соблюдать, либо придумает свою версию.

После первой версии: одно изменение за сообщение

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

До:

Дизайн не тот, бронирование работает плохо, и хочу календарь и письма.

После (четыре отдельных сообщения):

1. Когда я записываю участника на последнее место в занятии, там всё ещё написано «Осталось 1 место». Должно быть «Мест нет», а кнопка «Записаться» скрыта.
2. Добавь на страницу расписания календарь с видом по неделе, по одной колонке на каждый день. Текущий список оставь как вариант.
3. Сделай карточки занятий компактнее на телефонах: меньше отступы, имя преподавателя в одной строке со временем.
4. Отправляй участнику письмо с подтверждением при записи.

Почему это работает:

• Каждое изменение достаточно маленькое, чтобы ИИ сделал его правильно за один проход.
• Каждое можно проверить перед тем, как двигаться дальше.
• Если одно пошло не так, можно откатить только этот шаг, не потеряв остальные.

Скажите, что оставить

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

Переделай главный блок домашней страницы: крупнее заголовок и фото справа. Цвета, навигацию и всё, что ниже главного блока, оставь ровно таким, какое оно есть.

То же относится к данным: «Добавь поле для телефона участникам. Не удаляй и не переименовывай существующие поля».

Используйте скриншоты и точный текст

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

• Прикрепите скриншот и напишите: «кнопка, обведённая красным, на телефонах налезает на меню».
• Вставляйте точный текст сообщения об ошибке, а не пересказ.
• Цитируйте надписи на экране дословно: «кнопка Сохранить изменения на странице настроек».

Для ошибок используйте такой формат:

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

Наше руководство как отлаживать приложение, созданное с помощью ИИ подробнее раскрывает эту тему.

Планируйте перед большими изменениями

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

Прежде чем что-либо менять, объясни, как добавить учётные записи команды: какие новые таблицы, какие страницы изменятся и что будет с уже существующими пользователями. Пока код не меняй.

Прочитайте план. Если он что-то неправильно понял, исправить абзац гораздо дешевле, чем исправлять готовую функцию. Многие конструкторы имеют для этого отдельный режим; в Mythex это режим Plan, наряду с Build и Ask.

Чего избегать

По API-ключам: если нужен сервис платежей или email, поместите его ключи в секреты проекта, а не в промпт. Если это новое для вас, см. что такое переменные окружения и секреты.

Шаблоны промптов для повторного использования

Адаптируйте их, заменив части в скобках.

Новое приложение:

Сделай [тип приложения] для [кого]. Они [основной сценарий по шагам]. [Второй тип пользователя] входит, чтобы [что он делает]. Храни [данные] в базе данных. [Внешний вид]. Пока не делай [что оставить на потом].

Новая функция:

Добавь [функцию] на [страницу]. Когда [пользователь] делает [действие], должно произойти [что именно]. Только [кто] может [что делать]. Оставь [существующее] как есть.

Изменение дизайна:

На [странице] измени [конкретный элемент] на [конкретное изменение]. Сохрани [что оставить]. Проверь, что на экране шириной с телефон всё выглядит правильно.

Ошибка:

На [странице] я [шаги]. Ожидал [ожидаемое]. Вместо этого [фактическое, плюс точный текст ошибки]. Исправь и проверь, что сценарий работает.

Вопрос без изменений:

Не меняй код. Объясни, как работает [часть приложения] и где хранятся [данные].

Как написать более длинное описание

Для больших проектов может помочь одностраничный бриф, который вы вставите как первый промпт: пользователи, основные сценарии, данные, правила и то, что не входит в проект. Можно даже попросить ИИ помочь составить его: наше руководство как написать PRD с помощью ИИ объясняет, как это сделать. Только держите первый запрос на сборку в рамках основного сценария, а остальное добавляйте по шагам.

Промптинг в Mythex

Всё описанное выше работает в Mythex. Несколько особенностей, которые помогают:

• Режимы Build, Plan и Ask. Используйте Plan для больших или рискованных изменений, а Ask — когда нужно объяснение без правок.
• Контрольные точки. После каждого успешного изменения Mythex сохраняет контрольную точку, а Revert to this point в ответе откатывает проект к ней. Также можно отредактировать более раннее сообщение и отправить его заново, чтобы попробовать другой промпт с этого места.
• Карточка секретов. Когда агенту нужен API-ключ, он запрашивает его через карточку в чате, так что значение сохраняется как секрет проекта, а не записывается в ваше сообщение.
• Изображения. Прикрепите скриншоты или макеты, и агент их рассмотрит.

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

Вопросы