Како да пишете промптови за AI алатки за апликации (со примери пред и после)
Добриот промпт за AI алатка за апликации го опишува производот, а не кодот: кој го користи, што прави чекор по чекор, какви податоци чува и кој смее да ги види. Откако ќе постои првата верзија, побарајте по една конкретна промена во секоја порака, кажете што мора да остане исто и опишете проблеми како „Направив X, очекував Y, добив Z“. Овие три навики поправаат повеќето разочарувачки резултати.
Остатокот од овој водич ги прикажува шаблоните во детали, со примери пред и после што можете да ги прилагодите.
Зошто промптирањето на алатка за апликации е различно од разговорот со AI
Кога му поставувате прашање на асистент за разговор, нејасен промпт добива нејасен одговор и вие продолжувате. Кога промптирате AI алатка за апликации, одговорот е работна програма. Секоја празнина во вашиот опис се пополнува со претпоставка, а тие претпоставки стануваат код, табели во базата и екрани со кои или живеете или ги поништувате.
Затоа целта на промптот не е да звучи паметно. Целта е помалку важни одлуки да се остават на случајноста. За тоа не ви треба технички речник. Треба да бидете конкретни за работите што само вие ги знаете: вашите корисници, вашиот тек на работа и вашите правила.
Што да вклучите во првиот промпт
Пред да напишете што било, одговорете на овие прашања. Секое од нив затвора една празнина во која AI инаку би погодувал.
| Вклучете | Зошто е важно | Пример |
|---|---|---|
| Производот во една реченица | Ја поставува рамката за сите подоцнежни одлуки | „Сајт за резервации за берберница со два стола“ |
| Кој го користи | Ги одредува екраните и тонот | „Клиенти што доаѓаат без најава, на телефони, и сопственикот на лаптоп“ |
| Главниот тек, чекор по чекор | Она што прво мора да работи | „Изберете услуга, изберете време, внесете име и телефон, добијте потврда“ |
| Податоците што ги чува | Станува дизајн на базата | „Услуги, резервации, клиенти“ |
| Кој што може да види или менува | Ги одредува најавата и дозволите | „Само сопственикот ги гледа сите резервации“ |
| Изгледот, накратко | Спречува генерички стандарден стил | „Темно, едноставно, големи копчиња“ |
| Што да се исклучи сега | Ја држи првата верзија мала | „Уште без плаќања и рецензии“ |
Последниот ред е потценет. Кажувањето што не го сакате го спречува AI да додаде блог, страница со цени и формулар за билтен што никогаш не сте го барале.
Пред и после: првиот промпт
Пред:
Направи ми апликација за мојата теретана.
Алатката мора сè да погоди: членови или персонал? Часови или персонален тренинг? Плаќања? Ќе добиете нешто што изгледа како веб-страница за теретана и не прави ништо од она што ви треба.
После:
Направи апликација за резервација на часови за мало студио за јога. Членовите ја гледаат распоредот на часовите за оваа недела (име, инструктор, време, слободни места), резервираат место и можат да откажат најдоцна два часа пред почеток. Членовите се регистрираат со е-пошта и лозинка. Сопственикот на студиото се најавува за да додава часови, да гледа кој е резервиран и да ја означува присутноста. Чувај часови, членови и резервации во база на податоци. Смирен, светол дизајн што добро функционира на телефони. Уште без плаќања.
Втората верзија е сè уште кратка. Таа едноставно одговара на прашањата од табелата погоре.
Опишете однесување, не имплементација
Често ќе добиете подобри резултати ако опишете што треба да се случи, наместо како да се изгради.
Пред:
Додај useEffect што ги вчитува резервациите и модална компонента за уредување.
После:
Кога сопственикот ќе кликне на резервација, отвори панел каде може да го промени времето или да ја откаже. Промените да се прикажуваат веднаш во листата.
Првиот промпт ја заклучува AI на одредена техника што можеби не одговара на начинот на кој е изградена апликацијата. Вториот му го кажува исходот и му дозволува да ја избере вистинската пристап за кодот што веќе го напишал. Ако сте програмер и имате силна преференција, кажете ја, но спарете ја со исходот.
Бидете конкретни за правилата
Деловните правила се местото каде апликациите изградени со AI најчесто грешат, бидејќи се очигледни за вас и невидливи за AI. Напишете ги целосно.
- Ограничувања: „Членот може да има најмногу три идни резервации.“
- Време: „Откажувањата се затвораат два часа пред почетокот на часот.“
- Рабни случаи: „Ако часот е полн, прикажи копче за список на чекање наместо Резервирај.“
- Дозволи: „Инструкторите можат да ја видат присутноста на своите часови, но не и на туѓите.“
Секое од нив е една реченица. Ако некое од нив го изоставите, апликацијата или нема да го спроведе правилото или ќе измисли своја верзија.
По првата верзија: една промена во порака
Кога нешто работи во прегледот, преминете од опишување на целиот производ кон барање мали промени што можат да се проверат.
Пред:
Дизајнот не е во ред, резервацијата не работи како треба и сакам календарски приказ и е-пошта.
После (како четири посебни пораки):
- Кога ќе го резервирам последното место во часот, на часот сè уште пишува „1 слободно место“. Треба да пишува „Полн“ и копчето Резервирај да се сокрие.
- Додај календарски приказ по недела на страницата за распоред, по една колона за секој ден. Остави го тековниот приказ во листа како опција.
- Направи ги картичките за часови покомпактни на телефони: помали маргини, името на инструкторот во истата линија со времето.
- Испрати му на членот потврда по е-пошта кога ќе резервира.
Зошто ова функционира:
- Секоја промена е доволно мала за AI да ја направи точно во еден обид.
- Можете да ја тестирате секоја пред да преминете понатаму.
- Ако една оди наопаку, можете да ја вратите само таа чекор без да ги изгубите другите.
Кажете што да се задржи
Кога барате промена на нешто што веќе работи, кажете што не смее да се промени. Ова е најлесниот начин да се спречат регресии (работи што порано функционирале и се расипале по измена).
Редизајнирај го насловниот дел на почетната со поголем наслов и фотографија десно. Задржи ја навигацијата, боите и сè под насловниот дел точно како што е.
Истото важи и за податоците: „Додај поле за телефонски број кај членовите. Не отстранувај и не преименувај ниту едно постоечко поле.“
Користете слики и точен текст
Зборови како „нештото на врвот“ се двосмислени. Повеќето AI алатки за апликации прифаќаат слики, а сликата со кратка белешка е побрза од пасус опис.
- Приложете слика и кажете „копчето заокружено со црвено се преклопува со менито на телефони“.
- Залепете го точниот текст од секоја порака за грешка наместо да го перифразирате.
- Цитирајте ги натписите на екранот точно: „копчето Зачувај промени на страницата Поставки“.
За грешки конкретно, користете ја оваа форма:
На страницата за резервации, кликнав Откажи за резервација за утре. Очекував да исчезне од мојата листа. Наместо тоа ништо не се случи и резервацијата е уште таму и по освежување. Поправи го и провери дека откажувањето функционира.
Нашиот водич за како да дебагирате апликација изградена со AI оди подлабоко во ова.
Планирајте прво за големи промени
За сè што допира многу делови од апликацијата — додавање кориснички сметки на апликација што немала, додавање плаќања, промена на начинот на структурирање на податоците — побарајте план пред било каква промена на кодот.
Пред да менувате нешто, објаснете како би додале сметки за тим: какви нови табели, кои страници се менуваат и што се случува со постоечките корисници. Не менувајте код уште.
Прочитајте го планот. Ако нешто погрешно разбрал, поправката на еден пасус е многу поевтина од поправка на завршена функција. Многу алатки имаат посебен режим за ова; на Mythex тоа е режимот Plan, покрај Build и Ask.
Што да избегнувате
| Избегнувајте | Зошто | Наместо тоа |
|---|---|---|
| „Направи го подобро“ / „Направи го да блесне“ | Нема цел, па AI менува работи на случаен начин | Именувајте ја промената: „повеќе простор меѓу делови, поголеми наслови“ |
| Еден голем промпт со десет функции | Грешките се собираат; тешко се тестира | Една функција во порака |
| Лепење API клучеви во разговорот | Клучевите завршуваат во историјата на разговорот | Користете ги тајните или поставките за околината на алатката |
| Расправа со расипан резултат | Секоја поправка се става врз грешката | Вратете се, па преформулирајте |
| Пропишување код што не го разбирате | Заклучува лоша поставеност | Опишете го однесувањето што го сакате |
| Барање „безбедност од ниво на претпријатие“ | Нема конкретно значење | Наведете ги вистинските правила: кој што може да види |
За API клучевите: ако ви треба услуга за плаќања или е-пошта, ставете ги клучевите во тајните на проектот, а не во промптот. Видете што се променливи на околината и тајни ако ви е ново.
Повторно употребливи шаблони за промптови
Прилагодете ги со замена на заградените делови.
Нова апликација:
Направи [вид на апликација] за [за кого]. Тие [главен тек, чекор по чекор]. [Втор тип корисник] се најавува за да [што прави]. Чувај [податоци] во база на податоци. [Изглед]. Исклучи [работи за подоцна].
Нова функција:
Додај [функција] на [страница]. Кога [корисник] ќе [дејство], [што треба да се случи]. Само [кој] може да [го направи тоа]. Задржи [постоечки работи] како што се.
Промена на дизајн:
На [страницата], промени [конкретен елемент] во [конкретна промена]. Задржи [што да се задржи]. Провери дали изгледа добро на екран со ширина на телефон.
Грешка:
На [страница], [чекори]. Очекував [очекувано]. Наместо тоа [вистинско, плус точен текст од грешката]. Поправи го и провери дали текот функционира.
Прашање без промени:
Не менувај код. Објасни како функционира [дел од апликацијата] и каде се чуваат [податоци].
Пишување подолга спецификација
За поголеми проекти, може да помогне прво да напишете краток бриф од една страница и да го залепите како почетен промпт: корисниците, главните текови, податоците, правилата и она што е надвор од опсегот. Можете дури и AI да ви помогне да го нацрташе — нашиот водич за пишување документ за барања на производот со AI објаснува како. Само задржете го првото барање за изградба на основниот тек, а останатото додавајте го чекор по чекор.
Промптирање во Mythex
Сè погоре функционира во Mythex. Неколку конкретни работи што помагаат:
- Режими Build, Plan и Ask. Користете Plan за големи или ризични промени и Ask кога сакате објаснување без измени.
- Контролни точки. По секоја успешна промена Mythex зачувува контролна точка, а Врати на оваа точка кај одговор ја враќа проектот назад. Можете и да уредите порака од порано и повторно да ја испратите за да пробате друг промпт од таа точка.
- Картичка со тајни. Кога агентот ќе му треба API клуч, прашува преку картичка во разговорот, така што вредноста се чува како тајна на проектот, а не се пишува во вашата порака.
- Слики. Приложете снимки од екран или макети и агентот ќе ги погледне.
Документацијата има кратка страница за ефективни промптови и една за итерирање без повторно градење. Ако почнувате од нула, како да изградите апликација со AI поминува низ цел проект, а како да дизајнирате добро изгледаща апликација со AI ги опфаќа промптите за визуелно дотерување.
Прашања
Колку треба да биде долг промпт за AI алатка за апликации?
За првата верзија обично е доволен краток пасус од четири до осум реченици: кој ја користи апликацијата, главниот тек, податоците што ги чува и кој што може да види. Потоа, пократките промпти што бараат по една промена најдобро функционираат, подобро од долгите.
Треба ли да кажам на AI која рамка или јазик да ги користи?
Само ако имате причина, како програмер што ќе го преземе кодот или услуга што работи само со одреден стек. Во спротивно опишете го производот и дозволете алатката да избере разумни стандардни поставки.
Зошто AI продолжува да менува работи што не сум ги побарал?
Обично затоа што промптот бил широк („направи го подобро“) или не кажал што да се задржи. Наведете точно што да се промени, кажете што мора да остане исто и побарајте по една промена во секоја порака.
Подобро е да поправам лош резултат со повеќе промптови или да почнам одново?
Ако последната промена направила работите полоши, вратете се на верзијата пред неа и преформулирајте, наместо да ставате поправки една врз друга. Почнете нов проект само кога самата идеја се променила.