Prompt-инжиниринг для разработчиков AI-приложений — что действительно работает

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

В этом руководстве — то, что удалось выяснить на практике, собирая множество приложений с помощью AI-инструментов. Не теоретические советы об AI. Практические паттерны, которые работают, когда вы пытаетесь построить что-то конкретное.

Главная проблема: AI ничего не знает о вашей ментальной модели

Когда вы пишете «сделай дашборд», у вас в голове есть конкретная картинка. Возможно, это тёмный аналитический интерфейс с верхней навигацией, боковой панелью фильтров и сеткой карточек. Но у AI этой картинки нет. У него есть слово «дашборд» и все дашборды, которые он когда-либо видел.

Самое важное, что вы можете сделать, — устранить разрыв между тем, что вы видите в голове, и тем, что AI знает из вашего текста. Всё остальное вытекает из этого.

Паттерн 1: Описывайте макет и структуру, а не только функции

Функции абстрактны. Макет конкретен. «Боковая панель с навигационными ссылками» гораздо точнее, чем «навигация». «Модальное окно, которое появляется поверх основного контента» точнее, чем «способ добавить новые элементы».

Слабо: «Сделай приложение для социальной ленты»

Сильно: «Сделай приложение для социальной ленты с центрированной колонкой фиксированной ширины (около 600px) для ленты. Вверху — редактор поста с текстовым полем и кнопкой Submit. Ниже — прокручиваемый список карточек постов. Каждая карточка показывает аватар пользователя слева, имя пользователя и время публикации справа сверху, текст поста ниже, и три кнопки-иконки внизу: Like (со счётчиком), Comment (со счётчиком) и Share.»

Сильная версия даст узнаваемую социальную ленту. Слабая версия даст то, что модель сама интерпретирует под «социальную ленту».

Паттерн 2: Явно описывайте модель данных

AI нужно знать, с какими данными работает ваше приложение. Какие есть сущности? Какие поля у каждой сущности? Какие связи между ними?

Для приложения управления задачами: «Задача (Task) имеет поля: title (текст), description (текст), status (одно из: Backlog / In Progress / Done), assignee (текстовое поле с именем пользователя), due date и priority (Low / Medium / High).»

Для страницы товара в интернет-магазине: «Продукт (Product) имеет поля: name, price (число), category (текст), description (markdown-текст), stock quantity и до 5 image URLs.»

Явное описание не позволяет AI делать допущения, которые не соответствуют вашей предметной области.

Паттерн 3: Описывайте то, что происходит, а не только то, что существует

Приложения не статичны. Они реагируют на действия пользователя. Описывайте взаимодействия явно.

Вместо: «Должна быть кнопка для добавления задач»

Попробуйте: «В правом верхнем углу каждой колонки есть кнопка Add Task. При клике открывается модальное окно с полем Title, полем Description (необязательным) и выпадающим списком Assignee. После отправки формы новая задача появляется вверху этой колонки, а модальное окно закрывается.»

Формат «что происходит когда» ценнее, чем список функций.

Паттерн 4: Задавайте визуальное направление

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

«Чистый, минималистичный дизайн» против «плотная подача информации»
«Тёмный фон с высококонтрастным текстом» против «светлый, воздушный»
«Карточки с мягкими тенями» против «плоский дизайн с рамками»
«Щедрые отступы» против «компактный»
«Профессиональный, корпоративный вид» против «дружелюбный и доступный»

Это не точные технические спецификации, но они ощутимо меняют результат. «Чистый минималистичный дизайн с широкими отступами и нейтральной цветовой палитрой» даёт нечто совершенно другое, чем «плотный профессиональный интерфейс с высокой информационной насыщенностью».

Паттерн 5: Ссылайтесь на понравившийся интерфейс (когда уместно)

Если вы хотите воспроизвести какой-то UI-паттерн, назовите его: «похоже на боковую панель Notion», «как список задач в Linear», «так, как Figma работает со слоями в левой панели». AI видел эти интерфейсы и может применить общий паттерн к вашему конкретному случаю.

Не используйте это как замену описанию собственных требований, но это быстро калибрует визуальное направление.

Паттерн 6: Одна главная вещь за сообщение при итерациях

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

Отправляйте одну вещь за итерационное сообщение. В итоге это быстрее, потому что вам не придётся отменять частичные исправления.

Паттерн 7: Опишите, что работает, прежде чем просить изменения

Когда вы просите об итерации, явно обозначьте, что должно остаться нетронутым: «Боковая панель и навигация хороши, не трогай их. Просто почини модал задачи: когда я нажимаю Edit на задаче, модал должен предзаполняться текущими значениями задачи.»

Это снижает вероятность того, что AI «с пользой» затронет то, о чём вы не просили.

Типичные ошибки, которые тратят кредиты

Описание реализации вместо поведения. «Используй useReducer для управления состоянием» — AI, скорее всего, сделает что-то разумное в любом случае. Описывайте, что должно делать приложение, а не как оно должно быть написано. Детали реализации — это работа AI.

Начинать с «сделай лучше». Расплывчатая обратная связь даёт расплывчатые результаты. «Дизайн кажется скучным» ведёт к случайным изменениям. «Дизайн кажется скучным — добавь больше визуальной иерархии с разными размерами шрифтов и небольшим изменением цвета фона между секциями» — это конкретно.

Просить всё в первой версии. Первая генерация должна правильно выстроить структуру и основные взаимодействия. Не пытайтесь с самого начала прописать каждый пограничный случай, пустое состояние и сообщение об ошибке. Сначала заставьте работать ядро, потом добавляйте полировку.

Не использовать live-preview. Превью обновляется в реальном времени. Наблюдение за ним во время генерации позволяет заметить проблемы рано и отправить корректировку до того, как сборка завершится, а не ждать и просить об исправлении после.

Когда начинать заново, а когда итерировать

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

Признаки, что стоит начать заново:

Основной макет неверен, и вы не можете описать его одним чётким сообщением
Модель данных перевёрнута с ног на голову, и нужно менять несколько компонентов
Вы изначально описали не то, и AI правильно построил именно это

Признаки, что нужно продолжать итерировать:

Отдельные компоненты неверны, но структура правильная
Взаимодействия отсутствуют или сломаны, но UI есть
Это проблема стилей или контента

Промпт, который отправить, когда вы застряли

Если вы постоянно получаете не тот результат и не можете понять почему, попробуйте следующее: опишите текущее состояние и желаемое состояние конкретными терминами, бок о бок. «Сейчас карточки задач показывают только заголовок. Я хочу, чтобы они также показывали имя исполнителя меньшим серым шрифтом под заголовком и цветной метку справа, показывающую приоритет (красный для High, жёлтый для Medium, зелёный для Low).» Такой формат «до/после» сложно неверно интерпретировать.