Как да пишете промпти за AI инструменти за изграждане на приложения (с примери преди и след)
Добрият промпт за AI инструмент за изграждане на приложения описва продукта, а не кода: кой го използва, какво прави стъпка по стъпка, какви данни пази и кой има право да вижда какво. След като първата версия съществува, поискайте една конкретна промяна на съобщение, кажете какво трябва да остане същото и описвайте проблемите като „направих X, очаквах Y, получих Z“. Тези три навика оправят повечето разочароващи резултати.
Останалата част от това ръководство показва моделите подробно, с примери преди и след, които можете да адаптирате.
Защо промптването на инструмент за приложения е различно от разговор с AI
Когато задавате въпрос на чат асистент, неясен промпт води до неясен отговор и вие продължавате напред. Когато промптвате AI инструмент за приложения, отговорът е работеща програма. Всяка празнина в описанието ви се запълва с предположение, а тези предположения стават код, таблици в базата данни и екрани, с които после трябва да живеете или които трябва да отмените.
Затова целта на промпта не е да звучи умно. Тя е да остави по-малко важни решения на случайността. За това не са ви нужни технически термини. Нужно е да сте конкретни за неща, които знаете само вие: вашите потребители, работният ви процес и вашите правила.
Какво да включите в първия промпт
Преди да напишете каквото и да е, отговорете на тези въпроси. Всеки затваря празнина, която иначе AI би предположил.
| Включете | Защо има значение | Пример |
|---|---|---|
| Продуктът с едно изречение | Задава рамката за всяко следващо решение | „Сайт за резервации за бръснарница с два стола“ |
| Кой го използва | Определя екраните и тона | „Клиенти без резервация по телефони и собственикът на лаптоп“ |
| Основният поток, стъпка по стъпка | Нещото, което трябва да работи първо | „Избери услуга, избери час, въведи име и телефон, получи потвърждение“ |
| Данните, които пази | Става дизайн на базата данни | „Услуги, резервации, клиенти“ |
| Кой какво може да вижда или променя | Определя входа и правата | „Само собственикът вижда всички резервации“ |
| Визия и усещане, накратко | Предотвратява общ стандартен стил | „Тъмно, просто, големи бутони“ |
| Какво да оставите за по-късно | Пази първата версия малка | „Все още без плащания и отзиви“ |
Последният ред се подценява. Казването на това, което не искате, спира AI да добави блог, страница с цени и формуляр за бюлетин, за които не сте молили.
Преди и след: първият промпт
Преди:
Направи ми приложение за фитнеса ми.
Инструментът трябва да предположи всичко: членове или служители? Групови часове или персонални тренировки? Плащания? Ще получите нещо, което изглежда като уебсайт за фитнес, но не прави нищо от нужното ви.
След:
Построй приложение за резервации на групови занимания за малко студио за йога. Членовете виждат тази седмица часовете (име, инструктор, час, свободни места) и резервират място, а могат да отменят до два часа преди началото. Членовете се регистрират с имейл и парола. Собственикът на студиото влиза, за да добавя часове, да вижда кой е записан и да отбелязва присъствие. Съхранявай часовете, членовете и резервациите в база данни. Спокоен, светъл дизайн, който работи добре на телефони. Още без плащания.
Втората версия е все още кратка. Тя просто отговаря на въпросите от таблицата по-горе.
Описвайте поведението, а не реализацията
Често ще получите по-добри резултати, ако опишете какво трябва да се случи, вместо как да се построи.
Преди:
Добави useEffect, който взима резервациите, и компонент modal за редактиране.
След:
Когато собственикът натисне една резервация, отвори панел, в който може да промени часа или да я отмени. Промените трябва да се виждат веднага в списъка.
Първият промпт заключва AI в конкретна техника, която може да не пасва на начина, по който е построено приложението. Вторият казва резултата и оставя AI да избере правилния подход за кода, който вече е написал. Ако сте разработчик и имате силно предпочитание, кажете го, но го съчетайте с резултата.
Бъдете конкретни за правилата
Бизнес правилата са мястото, където приложенията, построени с AI, най-често се объркват, защото са очевидни за вас и невидими за AI. Опишете ги изрично.
- Ограничения: „Членът може да има най-много три предстоящи резервации.“
- Времеви рамки: „Отмяната се затваря два часа преди началото на часа.“
- Гранични случаи: „Ако часът е пълен, покажи бутон за списък на чакащите вместо Резервирай.“
- Права: „Инструкторите виждат присъствието на собствените си часове, но не и на другите инструктори.“
Всяко от тях е едно изречение. Пропускането на което и да е означава, че приложението или няма да наложи правилото, или ще измисли своя собствена версия.
След първата версия: една промяна на съобщение
Веднъж щом нещо работи в предварителния преглед, преминете от описване на целия продукт към искане на малки промени, които могат да се проверят.
Преди:
Дизайнът е нагоре-надолу, резервацията не работи както трябва и искам календарен изглед и имейли.
След (като четири отделни съобщения):
- Когато резервирам последното място в час, часът все още показва „1 свободно място“. Трябва да показва „Пълен“ и да скрие бутона Резервирай.
- Добави календарен изглед по седмици на страницата с програмата, една колона за всеки ден. Запази текущия списъков изглед като опция.
- Направи картите на часовете по-компактни на телефони: по-малко отстояние, името на инструктора на същия ред като часа.
- Изпрати на члена потвърдителен имейл, когато резервира.
Защо това работи:
- Всяка промяна е достатъчно малка, за да я направи AI правилно с един опит.
- Можете да тествате всяка една, преди да продължите.
- Ако една се обърка, можете да върнете само тази стъпка, без да загубите останалите.
Кажете какво да се запази
Когато поискате промяна на нещо, което вече работи, кажете на AI какво не бива да се променя. Това е най-лесният начин да спрете регресиите (неща, които са работели и са се счупили след редакция).
Преработи началната секция на началната страница с по-голямо заглавие и снимка вдясно. Запази навигацията, цветовете и всичко под секцията точно както е.
Същото важи и за данните: „Добави поле за телефонен номер към членовете. Не премахвай и не преименувай никое съществуващо поле.“
Използвайте снимки и точен текст
Думите като „нещото горе“ са двусмислени. Повечето AI инструменти за приложения приемат изображения, а снимка с кратка бележка е по-бърза от параграф описание.
- Прикачете снимка и кажете „бутонът, оцветен в червено, препокрива менюто на телефони“.
- Поставете точния текст на всяко съобщение за грешка, вместо да го преразказвате.
- Цитирайте точно етикетите на екрана: „бутонът Запази промените на страницата с настройките“.
За грешки конкретно използвайте тази форма:
На страницата с резервации натиснах Отмени за резервация за утре. Очаквах тя да изчезне от списъка ми. Вместо това нищо не се случи и резервацията е там и след презареждане. Поправи го и провери дали отмяната работи.
Нашето ръководство за как да откриете грешки в приложение, построено с AI разглежда това по-задълбочено.
Планирайте първо при големи промени
За всичко, което засяга много части на приложението — добавяне на потребителски акаунти към приложение, което нямаше такива, добавяне на плащания, промяна на начина, по който са структурирани данните — поискайте план, преди да се променя какъвто и да е код.
Преди да променяш нещо, обясни как би добавил акаунти за екип: какви нови таблици, кои страници се променят и какво се случва със съществуващите потребители. Все още не редактирай код.
Прочетете плана. Ако е разбрал нещо грешно, поправянето на един параграф е много по-евтино от поправянето на завършена функция. Много инструменти имат специален режим за това; в Mythex това е режим Plan, заедно с Build и Ask.
Какво да избягвате
| Избягвайте | Защо | Вместо това |
|---|---|---|
| „Направи го по-добро“ / „Направи го да изпъква“ | Няма цел, така че AI променя неща на случаен принцип | Назовете промяната: „повече празно пространство между секциите, по-големи заглавия“ |
| Един огромен промпт с десет функции | Грешките се натрупват; трудно за тестване | Една функция на съобщение |
| Поставяне на API ключове в чата | Ключовете остават в историята на чата | Използвайте тайните или настройките на средата на инструмента |
| Спорене с развален резултат | Всяка поправка се натрупва върху грешката | Върнете се, после преформулирайте |
| Указване на код, който не разбирате | Заключва лошо пасване | Опишете поведението, което искате |
| Искане на „сигурност от корпоративно ниво“ | Не означава нищо конкретно | Изброявайте реалните правила: кой какво вижда |
Относно API ключовете: ако ви трябва услуга за плащания или имейл, сложете ключовете ѝ в тайните на проекта, а не в промпта. Вижте какво представляват променливите на средата и тайните, ако това е ново за вас.
Шаблони за промптове за многократна употреба
Адаптирайте ги, като замените частите в скоби.
Ново приложение:
Построй [тип приложение] за [за кого]. Те [основен поток, стъпка по стъпка]. [Втори тип потребител] влиза, за да [какво прави]. Съхранявай [данни] в база данни. [Визия и усещане]. Остави [нещата за по-късно] за по-късно.
Нова функция:
Добави [функция] към [страница]. Когато [потребител] направи [действие], [какво трябва да се случи]. Само [кой] може да [направи това]. Запази [съществуващите неща] такива, каквито са.
Промяна в дизайна:
На [страница] промени [конкретен елемент] на [конкретна промяна]. Запази [какво да се запази]. Провери дали изглежда добре на екран с ширината на телефон.
Грешка:
На [страница] направих [стъпки]. Очаквах [очаквано]. Вместо това [действителното, плюс точният текст на грешката]. Поправи го и провери дали потокът работи.
Въпрос без промени:
Не променяй никакъв код. Обясни как работи [част от приложението] и къде се съхраняват [данните].
Писане на по-дълга спецификация
За по-големи проекти може да помогне първо да напишете кратко описание на една страница и да го поставите като първи промпт: потребителите, основните потоци, данните, правилата и какво е извън обхвата. Можете дори да помолите AI да ви помогне да го изготвите — нашето ръководство за писане на документ за изискванията на продукта с AI показва как. Просто ограничете първата заявка за изграждане до основния поток и добавяйте останалото стъпка по стъпка.
Промптване в Mythex
Всичко по-горе работи в Mythex. Няколко специфики, които помагат:
- Режими Build, Plan и Ask. Използвайте Plan за големи или рискови промени и Ask, когато искате обяснение без редакции.
- Контролни точки. След всяка успешна промяна Mythex запазва контролна точка, а Revert to this point към отговор връща проекта назад. Можете също да редактирате по-ранно съобщение и да го изпратите отново, за да пробвате друг промпт от тази точка.
- Карта с тайни. Когато агентът има нужда от API ключ, той пита през карта в чата, така че стойността се запазва като тайна на проекта, а не се записва в съобщението ви.
- Изображения. Прикачете снимки на екрани или макети и агентът ще ги разгледа.
Документацията има кратка страница за ефективните промптове и една за итериране без прекомпилиране. Ако започвате от нулата, как да построите приложение с AI минава през пълен проект, а как да проектирате добре изглеждащо приложение с AI обхваща промптовете за визуална изгладеност.
Въпроси
Колко дълъг трябва да бъде промптът за AI инструмент за приложения?
За първата версия обикновено е достатъчен кратък параграф от четири до осем изречения: кой използва приложението, основният поток, данните, които пази, и кой какво може да вижда. След това по-кратките промпти, които искат една промяна наведнъж, работят по-добре от дългите.
Трябва ли да кажа на AI кой фреймуърк или език да използва?
Само ако имате причина, например разработчик, който ще поеме кода, или услуга, която работи само с определен стек. В противен случай опишете продукта и оставете инструмента да избере разумни стандартни настройки.
Защо AI продължава да променя неща, за които не съм го молил?
Обикновено защото промптът е бил общ („направи го по-добро“) или не е казал какво да се запази. Назовете точно какво да се промени, кажете какво трябва да остане същото и поискайте по една промяна на съобщение.
По-добре ли е да поправя лош резултат с още промптове или да започна отначало?
Ако последната промяна е направила нещата по-лоши, върнете се към версията преди нея и преформулирайте, вместо да трупате поправки една върху друга. Започвайте нов проект само когато самата идея се е променила.