Kako iterirati pozive za UI: preprost sistem za testiranje
Nehajte ugibati, zakaj vaši pozivi ne delujejo. Štiristopenjski cikel za testiranje in izboljševanje pozivov, ki zares prinaša boljše rezultate.
Napisali ste poziv. Rezultat je bil napačen. Zato ste ga prepisali. Še vedno napačen, le drugače napačen. Spremenili ste nekaj besed, ponovno ustvarili odgovor, dobili nekaj boljšega — potem pa izgubili pregled nad tem, kaj ste sploh spremenili. Trideset minut pozneje ste spet na začetku in ne veste več, katera različica je bila pravzaprav boljša.
Pristop "znova ustvari in upaj" je način, kako večina ljudi uporablja UI. In prav zato ostaja večina nezadovoljnih. Po raziskavi podjetja Workday se približno 37 % časa, ki ga zaposleni prihranijo z UI, izgubi pri popravljanju — odpravljanju napak, preverjanju rezultatov in ponovnem pisanju vsebine, ki je zgrešila cilj.
Razlika med naključnim spreminjanjem in sistematičnim iteriranjem ni v vloženem trudu, temveč v metodi. Ko spremembe testirate, ocenjujete in beležite, prenehate ponavljati iste napake. Naučite se, kaj zares deluje za vaš konkreten primer uporabe. In ustvarite pozive, ki zanesljivo dajejo dobre rezultate, namesto da nanje občasno naletite po naključju.
Zakaj naključno spreminjanje ne deluje
Obstaja razlog, zakaj iteriranje pozivov spominja na igre na srečo. Ko hkrati spremenite tri stvari in se rezultat izboljša, ne veste, katera sprememba je pomagala. Ko poziv prepisujete po spominu, namesto da bi primerjali različice, ne morete prepoznati vzorcev. Ko izbrišete prejšnje poskuse, izgubite podatke, ki bi vam povedali, kaj deluje.
Raziskava MIT Sloan je pokazala, da le polovica izboljšav pri uporabi naprednih modelov UI izhaja iz samega modela. Druga polovica izhaja iz tega, kako uporabniki prilagodijo svoje pozive. Z drugimi besedami: vaše veščine pri pisanju pozivov so enako pomembne kot zmogljivosti UI.
A veščina ni čarovnija. Je prepoznavanje vzorcev, zgrajeno s strukturirano vajo. Videti morate, katere spremembe prinašajo katere rezultate — kar pomeni, da potrebujete sistem.
Štiristopenjski cikel iteracije
Učinkovito iteriranje pozivov sledi preprosti zanki:
Testiraj — Zaženite poziv in shranite celoten odgovor
Oceni — Primerjajte rezultat s svojim konkretnim ciljem
Izboljšaj — Naredite eno ciljno spremembo glede na to, kaj ni v redu
Dokumentiraj — Zapišite, kaj ste spremenili in kaj se je zgodilo
Ni zapleteno. A izvajanje vseh štirih korakov — še posebej zadnjega — je tisto, kar loči ljudi, ki postajajo vedno boljši, od tistih, ki se vedno znova spopadajo z istimi težavami.
Krožni diagram s prikazom štirih korakov iteracije pozivov: testiraj, oceni, izboljšaj, dokumentiraj
1. korak: zaženite poziv in shranite vse
Začnite s katerim koli pozivom, ki ga imate. Ne razmišljajte preveč o prvi različici — tako ali tako jo boste izboljšali. Cilj je dobiti izhodišče, ki ga lahko merite.
Ko poženete poziv, shranite tako poziv kot celoten odgovor. Ne le dobrih delov. Ne povzetka. Vse skupaj. Za diagnostiko težav potrebujete celotno sliko.
Če testirate v ChatGPT ali Claudu, prekopirajte celotno izmenjavo v zapisek ali dokument, preden začnete s spremembami. Ko enkrat ponovno ustvarite ali uredite odgovor, izvirnika ni več.
2. korak: ocenite glede na dejanski cilj
Tukaj večina ljudi naredi napako. Pogledajo rezultat in pomislijo "to ni čisto v redu" — in takoj začnejo prepisovati. Tako nejasno nezadovoljstvo vam ne pove, kaj popraviti.
Namesto tega uporabite tisto, čemur pravim test rdečega svinčnika. Pojdite skozi rezultat in označite konkretne težave:
Je ton napačen? Kje točno?
Manjkajo informacije? Katere?
Je predolgo? Kateri deli so polnilo?
Je napačno razumelo nalogo? Kako?
Je oblika napačna? Kakšna naj bi bila?
Zapišite svojo oceno. "Preveč formalno v drugem odstavku, manjka omejitev proračuna, vključuje nepomembno ozadje o zgodovini podjetja." Zdaj natanko veste, kaj je treba popraviti.
3. korak: spreminjajte po eno stvar naenkrat
To je najtežja disciplina, ki jo je treba obdržati, in hkrati najpomembnejša. Ko spremenite več stvari hkrati, se ne morete naučiti, katera sprememba je pomagala. Raziskave A/B-testiranja dosledno kažejo, da je izolacija ene same spremenljivke ključna — sočasno testiranje več sprememb onemogoča, da bi rezultate pripisali pravemu vzroku.
Iz svoje ocene izberite najpomembnejšo težavo in naslovite samo to. Pogosti popravki vključujejo:
Dodajte kontekst: navedite ozadje, ki ga UI potrebuje za razumevanje vašega položaja
Dodajte omejitve: določite dolžino, obliko, ton ali kaj naj se izpusti
Dodajte primere: pokažite, kako izgleda dober rezultat (temu pravimo pozivanje s primeri)
Razjasnite nalogo: nejasna navodila prepišite tako, da postanejo konkretna
Dodelite vlogo: povejte UI, kdo naj bi bil (glejte pozivanje z vlogo)
Naredite eno spremembo, znova zaženite poziv in primerjajte. Je pomagala? Je ustvarila novo težavo? Vedeli boste, ker ste spremenili samo eno stvar.
4. korak: dokumentirajte, kaj ste spremenili
Ta korak deluje neobvezen. Ni. Brez dokumentacije boste ponavljali neuspele poskuse, pozabili uspešne tehnike in svoje najboljše pozive izgubili v zgodovini klepeta.
Vaša dokumentacija ne potrebuje biti dovršena. Dovolj je preprost dnevnik:
Različica: v1, v2, v3 …
Kaj se je spremenilo: "Dodana omejitev števila besed na 200"
Rezultat: "Izhod ima zdaj pravo dolžino, a izgubil je sproščen ton"
Obdrži ali zavrzi: omejitev obdrži, ton popravi v naslednjem koraku
Sčasoma postane ta dnevnik vaš osebni priročnik. Opazili boste vzorce — morda dodajanje primerov pri vaših pisnih nalogah vedno pomaga ali pa zgodnja določitev oblike vedno pripelje do boljše strukture. Takšni uvidi se kopičijo.
Če iterirate pozive, ki jih boste ponovno uporabljali, vam orodje, kot je PromptNest, omogoča, da opombe pripnete neposredno k vsakemu pozivu. Spremljate lahko, kaj ste poskusili, kaj je delovalo in zakaj — brez ločenega dokumenta.
Konkreten primer: iteriranje poziva za povzetek sestanka
Sprehodimo se skozi pravi cikel iteracije. Recimo, da morate zapiske s sestanka strniti v seznam nalog za svojo ekipo.
Različica 1:
Summarize these meeting notes.
{{meeting_notes}}
Rezultat: splošen povzetek, ki naloge zakoplje med odstavke konteksta. Predolg je in morate brskati, kaj je v resnici treba narediti.
Ocena: manjka strukturiran izhod. Ni jasnih nalog. Vsebuje nepotreben pregled.
Sprememba: dodajte omejitve oblike.
Različica 2:
Extract action items from these meeting notes. Format as a bulleted list with the owner's name in brackets after each item.
{{meeting_notes}}
Rezultat: čist seznam alinej z nalogami in odgovornimi osebami. A nekatere postavke so nejasne ("sledi tisti zadevi, o kateri smo govorili") in roki manjkajo.
Ocena: dobra oblika, a postavkam manjka konkretnost in časovni okvir.
Sprememba: dodajte zahteve glede konkretnosti in rokov.
Primerjava prej in potem, ki prikazuje, kako se nejasen poziv spremeni v konkreten in strukturiran poziv
Različica 3:
Extract action items from these meeting notes.
For each action item, include:
- What specifically needs to be done (not vague references)
- Who owns it [in brackets]
- Deadline if mentioned, or "No deadline specified"
If an action item is unclear in the notes, flag it with "[NEEDS CLARIFICATION]" so I can follow up.
{{meeting_notes}}
Rezultat: konkretne naloge, jasni odgovorni, roki, kjer so na voljo, in oznake pri vsem dvoumnem. To je uporabno.
Tri iteracije. Vsaka je odpravila konkretno težavo, prepoznano pri ocenjevanju. Končni poziv je dramatično boljši od prvega — in natanko veste, zakaj.
Kdaj nehati iterirati
Iteracija ima padajoče donose. Na neki točki samo še glancate nekaj, kar je že dovolj dobro. Tukaj je nekaj znakov, da je čas, da nehate:
Rezultat izpolnjuje vaše zahteve. Ne popoln — zahteve. Če dela, kar potrebujete, ga uporabite.
Spremembe stvari poslabšujejo. Včasih zadenete lokalni vrh. Če so zadnje tri spremembe vse poslabšale kakovost, se vrnite na svojo najboljšo različico in zaključite.
Optimizirate za robne primere. Če poziv deluje v 90 % primerov in porabljate ure za preostalih 10 %, premislite, ali je ta čas vreden vložka.
Težava je v nalogi, ne v pozivu. Nekatere naloge so za današnji UI dejansko težke. Če ste preizkusili vse smiselne pristope, je morda težava v tem, da od UI zahtevate nekaj, česar še ne zmore zanesljivo opraviti.
Gradite sistem, ne le pozivov
Prava vrednost sistematičnega iteriranja ni v posameznem izboljšanem pozivu. Je v veščini, ki jo razvijete, in knjižnici, ki jo zgradite.
Vsak poziv, ki ga izpilite z iteracijami, vas nekaj nauči o tem, kako se UI odziva na navodila. Sčasoma boste začeli pisati boljše prve osnutke, ker boste ponotranjili, kaj deluje. Pogoste vzorce neuspeha boste prepoznali takoj. Imeli boste zbirko preizkušenih pozivov, ki jih lahko prilagodite za nove naloge.
Ta zbirka je pomembna. Najboljši inženirji pozivov ne začenjajo vsakič znova — vzdržujejo knjižnice preizkušenih pozivov, ki jih lahko spreminjajo in ponovno uporabljajo. Po anketi spletnega mesta Rev.com imajo uporabniki, ki se jim predlogi pozivov zdijo koristni, 280 % večjo verjetnost, da v manj kot dveh minutah dobijo zadovoljiv odgovor, kot tisti, ki tega ne uporabljajo.
Če gradite zbirko pozivov, vrednih ohranitve, jim PromptNest ponuja pravi dom — urejene po projektih, iskljive in dosegljive z bližnjico s tipkovnico iz katere koli aplikacije. Svoje izpiljene pozive lahko shranite z vgrajenimi spremenljivkami, kot je {{meeting_notes}}, izpolnite manjkajoče dele, ko jih potrebujete, in se izognete celotnemu iteracijskemu postopku, ker ste delo že opravili.
Štiristopenjski cikel preizkusite na svojem naslednjem pozivu. Testiraj, oceni, izboljšaj, dokumentiraj. Sprva traja malo dlje. A vsaka ura, ki jo vložite v iteracijo, je ura, ki jo boste prihranili — in to mnogokrat — ko bodo vaši pozivi končno zares delovali.
