Com escriure prompts per a creadors d'apps amb IA (amb exemples d'abans i després)
Un bon prompt per a un creador d'apps amb IA descriu el producte, no el codi: qui l'utilitza, què fa pas a pas, quines dades guarda i qui té permís per veure cada cosa. Un cop existeix la primera versió, demana un canvi concret per missatge, digues què ha de quedar igual i descriu els problemes com "he fet X, esperava Y, i ha sortit Z". Aquests tres hàbits arreglen la majoria de resultats decebedors.
La resta d'aquesta guia mostra els patrons amb detall, amb exemples d'abans i després que pots adaptar.
Per què fer prompts a un creador d'apps és diferent de xatejar amb una IA
Quan fas una pregunta a un assistent de xat, un prompt vague rep una resposta vaga i continues. Quan fas un prompt a un creador d'apps amb IA, la resposta és un programa en funcionament. Cada buit de la teva descripció s'omple amb una suposició, i aquestes suposicions es converteixen en codi, taules de base de dades i pantalles que després has de conviure o desfer.
Així que l'objectiu d'un prompt no és sonar intel·ligent. És deixar menys decisions importants a l'atzar. No necessites vocabulari tècnic per això. Necessites ser concret sobre el que només tu saps: els teus usuaris, el teu flux de treball i les teves regles.
Què incloure en un primer prompt
Abans d'escriure res, respon aquestes preguntes. Cadascuna tanca un buit en què la IA endevinaria.
| Inclou | Per què importa | Exemple |
|---|---|---|
| El producte en una frase | Marca el context de totes les decisions posteriors | "Un lloc de reserves per a una barberia de dues cadires" |
| Qui l'utilitza | Decideix les pantalles i el to | "Clients que entren sense cita des del mòbil, i el propietari des d'un portàtil" |
| El flux principal, pas a pas | La cosa que ha de funcionar primer | "Triar un servei, triar una hora, introduir nom i telèfon, rebre una confirmació" |
| Les dades que guarda | Es converteix en el disseny de la base de dades | "Serveis, reserves, clients" |
| Qui pot veure o canviar què | Decideix l'inici de sessió i els permisos | "Només el propietari veu totes les reserves" |
| Aspecte i estil, breument | Evita un estil per defecte genèric | "Fosc, simple, botons grans" |
| Què deixar fora de moment | Manté petita la primera versió | "Encara no hi ha pagaments ni ressenyes" |
Aquesta última fila es subestima. Dir el que no vols evita que la IA afegeixi un blog, una pàgina de preus i un formulari de newsletter que mai no has demanat.
Abans i després: el primer prompt
Abans:
Fes-me una app per al meu gimnàs.
El creador ha d'endevinar-ho tot: són membres o personal? Classes o entrenament personal? Pagaments? Obtindràs alguna cosa que sembla una web de gimnàs i no fa res del que necessites.
Després:
Construeix una app de reserva de classes per a un petit estudi de ioga. Els socis veuen les classes d'aquesta setmana (nom, professor, hora, places lliures), reserven una plaça i poden cancel·lar fins a dues hores abans. Els socis es registren amb correu i contrasenya. El propietari de l'estudi entra per afegir classes, veure qui està apuntat i marcar l'assistència. Guarda classes, socis i reserves en una base de dades. Disseny tranquil i clar que funcioni bé en mòbils. Encara sense pagaments.
La segona versió continua sent curta. Simplement respon les preguntes de la taula anterior.
Descriu el comportament, no la implementació
Sovint obtindràs millors resultats descrivint què ha de passar en lloc de com construir-ho.
Abans:
Afegeix un useEffect que carregui les reserves i un component modal per editar-les.
Després:
Quan el propietari fa clic en una reserva, obre un panell on pugui canviar l'hora o cancel·lar-la. Els canvis han de sortir a la llista de seguida.
El primer prompt bloqueja la IA en una tècnica concreta que potser no encaixa amb com està construïda l'app. El segon li diu el resultat i li deixa triar l'enfocament correcte per al codi que ja ha escrit. Si ets desenvolupador i tens una preferència forta, digues-la, però acompanya-la del resultat.
Sigues concret amb les regles
Les regles de negoci són on les apps construïdes amb IA sovint fallen, perquè són òbvies per a tu i invisibles per a la IA. Escriu-les explícitament.
- Límits: "Un soci pot tenir com a màxim tres reserves futures."
- Temps: "Les cancel·lacions es tanquen dues hores abans que comenci la classe."
- Casos límit: "Si una classe és plena, mostra un botó de llista d'espera en lloc de Reservar."
- Permisos: "Els professors veuen l'assistència de les seves pròpies classes, però no la d'altres professors."
Cadascuna d'aquestes regles és una frase. Si n'oblides alguna, l'app o no aplicarà la regla o inventarà la seva pròpia versió.
Després de la primera versió: un canvi per missatge
Quan alguna cosa ja s'executa a la vista prèvia, passa de descriure tot el producte a demanar canvis petits i comprovables.
Abans:
El disseny no està bé, la reserva no funciona bé i vull una vista de calendari i correus.
Després (quatre missatges separats):
- Quan reservo l'última plaça d'una classe, la classe continua mostrant "1 plaça lliure". Hauria de mostrar "Completa" i amagar el botó Reservar.
- Afegeix a la pàgina d'horaris un calendari de vista setmanal, una columna per dia. Mantén la vista de llista actual com a opció.
- Fes les targetes de classe més compactes en mòbils: menys marge, nom del professor a la mateixa línia que l'hora.
- Envia al soci un correu de confirmació quan faci una reserva.
Per què funciona això:
- Cada canvi és prou petit perquè la IA l'encerti en una sola passada.
- Pots provar cadascun abans de continuar.
- Si un surt malament, pots desfer només aquell pas sense perdre els altres.
Digues què has de mantenir
Quan demanes un canvi en alguna cosa que ja funciona, digues a la IA què no ha de canviar. És la manera més fàcil d'evitar regressions (coses que funcionaven i deixen de funcionar després d'una edició).
Redissenya la portada de la pàgina d'inici amb un titular més gran i una foto a la dreta. Mantén la navegació, els colors i tot el que hi ha sota la portada exactament igual.
El mateix s'aplica a les dades: "Afegeix un camp de número de telèfon als socis. No eliminis ni reanomenis cap camp existent."
Fes servir captures de pantalla i text exacte
Paraules com "la cosa de dalt" són ambigües. La majoria de creadors d'apps amb IA accepten imatges, i una captura de pantalla amb una nota curta és més ràpida que un paràgraf de descripció.
- Adjunta una captura de pantalla i digues "el botó marcat en vermell se solapa amb el menú en mòbils".
- Enganxa el text exacte de qualsevol missatge d'error en lloc de parafrasejar-lo.
- Cita les etiquetes de la pantalla exactament: "el botó Desa els canvis de la pàgina de Configuració".
Per als errors concrets, fes servir aquesta forma:
A la pàgina de reserves, he fet clic a Cancel·la una reserva per a demà. Esperava que desaparegués de la meva llista. En lloc d'això no va passar res i la reserva continua allà després de refrescar la pàgina. Arregla-ho i comprova que la cancel·lació funciona.
La nostra guia sobre com depurar una app construïda amb IA va més a fons en aquest tema.
Planifica primer els canvis grans
Per a qualsevol cosa que toqui moltes parts de l'app —afegir comptes d'usuari a una app que no en tenia, afegir pagaments, canviar com s'estructuren les dades—, demana un pla abans que el codi canviï.
Abans de canviar res, explica com afegiries comptes d'equip: quines taules noves, quines pàgines canvien i què passa amb els usuaris existents. No editis el codi encara.
Llegeix el pla. Si entén malament alguna cosa, corregir un paràgraf és molt més barat que corregir una funcionalitat acabada. Molts creadors tenen un mode dedicat per a això; a Mythex és el mode Plan, juntament amb Build i Ask.
Què evitar
| Evita | Per què | Millor |
|---|---|---|
| "Millora-ho" / "Fes que quedi més vistós" | No hi ha objectiu, així que la IA canvia coses a l'atzar | Anomena el canvi: "més espai en blanc entre seccions, titulars més grans" |
| Un prompt gegant amb deu funcionalitats | Els errors s'acumulen; és difícil de provar | Una funcionalitat per missatge |
| Enganxar claus d'API al xat | Les claus acaben a l'historial del xat | Fes servir els secrets o la configuració d'entorn del creador |
| Discutir amb un resultat trencat | Cada arranjament s'apila sobre l'error | Desfer i després reformular |
| Especificar codi que no entens | Bloqueja un encaix pobre | Descriu el comportament que vols |
| Demanar "seguretat de nivell empresarial" | No vol dir res de concret | Enumera les regles reals: qui pot veure què |
Sobre les claus d'API: si necessites un servei de pagaments o de correu, posa les seves claus als secrets del projecte en lloc del prompt. Consulta què són les variables d'entorn i els secrets si és nou per a tu.
Plantilles de prompts reutilitzables
Adapta-les substituint les parts entre claudàtors.
App nova:
Construeix una [tipus d'app] per a [qui]. [Flux principal, pas a pas]. [Segon tipus d'usuari] entra per [què fa]. Guarda [dades] en una base de dades. [Aspecte i estil]. Deixa fora [coses per més endavant].
Funcionalitat nova:
Afegeix [funcionalitat] a [pàgina]. Quan [usuari] fa [acció], [què ha de passar]. Només [qui] pot [fer-ho]. Mantén [coses existents] tal com estan.
Canvi de disseny:
A [pàgina], canvia [element concret] a [canvi concret]. Mantén [què mantenir]. Comprova que es veu bé en una pantalla d'amplada de mòbil.
Error:
A [pàgina], [passos]. Esperava [esperat]. En lloc d'això [real, més el text exacte de l'error]. Arregla-ho i verifica que el flux funciona.
Pregunta sense canvis:
No canviïs cap codi. Explica com funciona [part de l'app] i on es guarden [dades].
Escriure una especificació més llarga
Per a projectes més grans, pot ajudar escriure primer un resum d'una pàgina i enganxar-lo com a prompt inicial: els usuaris, els fluxos principals, les dades, les regles i què queda fora de l'abast. Fins i tot pots fer que una IA t'ajudi a redactar-lo; la nostra guia sobre com escriure un document de requisits de producte amb IA explica com. Només cal que la primera petició de construcció es limiti al flux principal, i afegeix la resta pas a pas.
Fer prompts a Mythex
Tot el que hi ha més amunt funciona a Mythex. Algunes especificitats que ajuden:
- Modes Build, Plan i Ask. Fes servir Plan per a canvis grans o arriscats, i Ask quan vulguis una explicació sense edicions.
- Punts de control. Després de cada canvi reeixit, Mythex desa un punt de control, i Torna a aquest punt en una resposta reverteix el projecte. També pots editar un missatge anterior i reenviar-lo per provar un prompt diferent des d'aquell punt.
- Targeta de secrets. Quan l'agent necessita una clau d'API, ho demana mitjançant una targeta al xat perquè el valor es guardi com a secret del projecte en lloc d'escriure's al teu missatge.
- Imatges. Adjunta captures de pantalla o maquetes i l'agent les mirarà.
La documentació té una pàgina curta sobre prompts efectius i una altra sobre iterar sense reconstruir. Si comences de zero, com construir una app amb IA explica un projecte complet, i com dissenyar una app ben aspecte amb IA cobreix els prompts per a l'acabat visual.
Preguntes
Quant ha de durar un prompt per a un creador d'apps amb IA?
Per a la primera versió, normalment n'hi ha prou amb un paràgraf de quatre a vuit frases: qui fa servir l'app, el flux principal, les dades que guarda i qui pot veure cada cosa. Després, els prompts més curts que demanen un canvi cada vegada funcionen millor que els llargs.
He de dir a la IA quin framework o llenguatge ha d'usar?
Només si tens un motiu, com un desenvolupador que es farà càrrec del codi o un servei que només funciona amb una pila concreta. Si no, descriu el producte i deixa que el creador triï valors per defecte raonables.
Per què la IA continua canviant coses que no li he demanat?
Normalment perquè el prompt era massa general ("millora-ho") o no deia què mantenir. Anomena exactament el que vols canviar, digues què ha de quedar igual i demana un canvi per missatge.
És millor arreglar un mal resultat amb més prompts o començar de nou?
Si l'últim canvi ha empitjorat les coses, torna a la versió anterior i reformula, en lloc d'apilar arranjaments sobre el mal resultat. Comença un projecte nou només quan la idea en si ha canviat.