Як писати промпти для AI-конструкторів застосунків (з прикладами до і після)

Добрий промпт для AI-конструктора застосунків описує продукт, а не код: хто ним користується, що вони роблять крок за кроком, які дані він зберігає і хто має право що бачити. Коли перша версія вже існує, просіть одну конкретну зміну в повідомленні, казати, що має лишитися незмінним, і описувати проблеми як «я зробив X, очікував Y, отримав Z». Ці три звички вирішують більшість розчаровуючих результатів.

Решта посібника детально показує ці шаблони з прикладами «до» і «після», які можна адаптувати.

Чим промптинг конструктора відрізняється від розмови з AI

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

Тож мета промпту не в тому, щоб звучати розумно. Вона в тому, щоб залишити менше важливих рішень на волю випадку. Для цього не потрібна технічна лексика. Потрібно бути конкретними щодо того, що знаєте тільки ви: ваших користувачів, вашого процесу і ваших правил.

Що включити в перший промпт

Перш ніж щось писати, дайте відповіді на ці питання. Кожне закриває прогалину, яку AI інакше вгадував би.

Останній рядок недооцінюють. Якщо сказати, чого ви не хочете, AI не додасть блог, сторінку цін і форму підписки на розсилку, про які ви не просили.

Приклад до і після: перший промпт

До:

Зроби мені застосунок для мого спортзалу.

Конструктор має вгадати все: учасники чи персонал? Групові заняття чи персональні тренування? Оплати? Ви отримаєте щось, що схоже на сайт спортзалу і не робить того, що вам потрібно.

Після:

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

Друга версія все ще коротка. Вона просто відповідає на питання з таблиці вище.

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

Часто кращі результати дає опис того, що має відбуватися, а не того, як це побудувати.

До:

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

Після:

Коли власник натискає на бронювання, відкривається панель, де можна змінити час або скасувати його. Зміни мають одразу з'являтися в списку.

Перший промпт прив'язує AI до конкретної техніки, яка може не пасувати до того, як побудований застосунок. Другий називає результат і дозволяє обрати правильний підхід для коду, який уже є. Якщо ви розробник і маєте сильну перевагу, скажіть про неї, але поєднайте з результатом.

Будьте конкретними щодо правил

Бізнес-правила — це місце, де застосунки, побудовані з AI, найчастіше помиляються, бо для вас вони очевидні, а для AI непомітні. Пропишіть їх.

• Обмеження: «Учасник може мати не більше трьох майбутніх бронювань».
• Строки: «Скасування закривається за дві години до початку заняття».
• Граничні випадки: «Якщо заняття заповнене, показуй кнопку листа очікування замість Записатися».
• Права доступу: «Викладачі бачать відвідуваність своїх занять, але не чужих».

Кожне з цих правил — це одне речення. Якщо пропустити будь-яке, застосунок або не забезпечить правило, або вигадає власну версію.

Після першої версії: одна зміна в повідомленні

Коли щось уже працює в попередньому перегляді, переходьте від опису всього продукту до прохань про невеликі зміни, які можна перевірити.

До:

Дизайн не той, бронювання працює некоректно, і я хочу вид календаря та листи на email.

Після (чотири окремі повідомлення):

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

Чому це працює:

• Кожна зміна достатньо мала, щоб AI зробив її правильно за один прохід.
• Ви можете перевірити кожну перед тим, як рухатися далі.
• Якщо одна зміна пішла не так, можна відкотити лише цей крок, не втрачаючи інших.

Скажіть, що зберегти

Коли просите змінити щось, що вже працює, скажіть AI, що не можна міняти. Це найлегший спосіб зупинити регресії (те, що працювало раніше і зламалося після правки).

Переробити головний блок домашньої сторінки: більший заголовок і фото справа. Залиш навігацію, кольори і все під цим блоком точно таким, як є.

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

Використовуйте скриншоти і точний текст

Слова на кшталт «та штука вгорі» неоднозначні. Більшість AI-конструкторів приймають зображення, і скриншот з коротką приміткою швидший за абзац опису.

• Додайте скриншот і напишіть «кнопка, обведена червоним, перекриває меню на телефонах».
• Вставляйте точний текст повідомлення про помилку, а не переказуйте його.
• Цитуйте написи на екрані дослівно: «кнопка Зберегти зміни на сторінці Налаштувань».

Для помилок використовуйте таку форму:

На сторінці бронювань я натиснув Скасувати для бронювання на завтра. Очікував, що воно зникне зі списку. Натомість нічого не сталося, і після оновлення сторінки бронювання все ще там. Виправ це і перевір, що скасування працює.

Наш посібник про те, як налагоджувати застосунок, побудований з AI, розглядає це детальніше.

Плануйте перед великими змінами

Для всього, що зачіпає багато частин застосунку, — додавання облікових записів користувачів до застосунку, якого їх не було, додавання оплат, зміна структури даних — попросіть план до будь-яких змін у коді.

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

Прочитайте план. Якщо він щось неправильно розуміє, виправити абзац набагато дешевше, ніж виправити готову функцію. Багато конструкторів мають для цього окремий режим; у Mythex це режим Plan, поруч із Build і Ask.

Чого уникати

Щодо API-ключів: якщо потрібен сервіс оплат або email, покладіть його ключі в секрети проєкту, а не в промпт. Див. що таке змінні середовища і секрети, якщо це для вас нове.

Шаблони промптів для повторного використання

Адаптуйте їх, замінюючи частини в квадратних дужках.

Новий застосунок:

Побудуй [тип застосунку] для [кого]. Вони [головний сценарій, крок за кроком]. [Другий тип користувача] входить, щоб [що вони роблять]. Зберігай [дані] в базі даних. [Вигляд і відчуття]. Залиш осторонь [що для пізніше].

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

Додай [функцію] на сторінку [сторінка]. Коли [користувач] робить [дію], має статися [що має статися]. Лише [хто] може [що робити]. Зберігай [наявне] без змін.

Зміна дизайну:

На сторінці [сторінка] зміни [конкретний елемент] на [конкретна зміна]. Збережи [що зберегти]. Перевір, що вигляд правильний на екрані шириною з телефон.

Помилка:

На сторінці [сторінка] я [кроки]. Я очікував [очікуване]. Натомість [фактичне, плюс точний текст помилки]. Виправ і перевір, що сценарій працює.

Запитання без змін:

Не змінюй жодного коду. Поясни, як працює [частина застосунку] і де зберігаються [дані].

Написання довшої специфікації

Для більших проєктів може допомогти написати спершу короткий однасторінковий бриф і вставити його як початковий промпт: користувачі, основні сценарії, дані, правила і що поза межами. Можна навіть попросити AI допомогти з чернеткою — наш посібник про написання документа вимог до продукту з AI пояснює, як це зробити. Просто обмежте перший запит на побудову основним сценарієм, а решту додавайте крок за кроком.

Промптинг у Mythex

Усе вищезазначене працює в Mythex. Кілька деталей, які допомагають:

• Режими Build, Plan і Ask. Використовуйте Plan для великих або ризикованих змін, а Ask — коли хочете пояснення без редагування.
• Контрольні точки. Після кожної успішної зміни Mythex зберігає контрольну точку, а Повернутися до цієї точки у відповіді відкочує проєкт. Також можна відредагувати попереднє повідомлення і надіслати знову, щоб спробувати інший промпт з цього місця.
• Картка секретів. Коли агенту потрібен API-ключ, він запитує його через картку в чаті, тож значення зберігається як секрет проєкту, а не записується у ваше повідомлення.
• Зображення. Прикріпіть скриншоти або макети, і агент їх перегляне.

У документації є коротка сторінка про ефективні промпти і одна про ітерації без перебудови. Якщо починаєте з нуля, як створити застосунок з AI проводить через повний проєкт, а як розробити гарний застосунок з AI розповідає про промпти для візуального полірування.

Запитання