Příklady prompt engineeringu pro softwarové inženýry

Opravte nespolehlivou chybu checkoutu.

Příznak: Požadavek checkoutu může jednou selhat s časovým limitem a poté uspět při
automatickém opakování. Po opakování se neobjeví obrazovka úspěchu.

Očekávané: Úspěšné opakování má nahradit chybový stav a povolit další
krok checkoutu.
Pozorované: Síťové logy ukazují odpověď 200, ale první chybový banner zůstává.

Rozsah: Prozkoumejte pouze mutaci checkoutu, callback opakování a stav obrazovky.
Omezení: Zachovejte stávající integraci poskytovatele plateb i texty chyb.
Neskrývejte chyby předtím, než požadavek skutečně uspěje.

Nejprve uveďte dvě nebo tři hypotézy založené na důkazech a nejmenší reprodukci
nebo signál v logu, který je odliší. Poté navrhněte minimální opravu a
regresní test.

Refaktorujte tyto formuláře a odstraňte duplicitu.

Formuláře účtu, oznámení a profilu duplikují vykreslování stavu ukládání.
Určete přesné opakované chování a místa, v nichž se formuláře liší.

Výsledek: Omezte duplicitní vykreslování, aniž změníte veřejné props formulářů,
časování validace, lokalizované chyby, analytické události nebo chování klávesnice.

Rozsah: Tři formuláře nastavení a jejich přímé testy.
Mimo rozsah: Nevytvářejte obecný framework formulářů ani nepřesouvejte vlastnictví
požadavků mimo existující hooky funkce.

Doporučte nejmenší extrakci, ukažte zachovaný kontrakt a přidejte nebo
aktualizujte testy načítání, selhání a úspěchu pro každý formulář.

Přidejte testy pro vyhledávání.

Přidejte regresní pokrytí závodní podmínky při vyhledávání.

Scénář: Uživatel vyhledá "network", ihned změní dotaz na
"terminal" a odpověď pro network se vrátí jako poslední.

Očekávané: UI zobrazuje pouze výsledky pro "terminal". Starší odpověď je nesmí
nahradit.

Použijte stávající testovací stack a přístupná tvrzení. Netvrďte názvy interních
stavů. Pokud produkční kód nedokáže jasně vyjádřit zrušení nebo aktuálnost,
vysvětlete před napsáním testu nejmenší potřebnou změnu.

Přidejte cache konfigurace, aby byla aplikace rychlejší.

Posuďte, zda by klientská cache konfigurace zrychlila pomalou obrazovku,
aniž by vytvářela zastaralá rozhodnutí o oprávněních nebo předvolbách.

Kontext: Aplikace už má poskytovatele konfigurace a obrazovka čeká na
ověřeného uživatele. Nezměřili jsme, zda je úzkým hrdlem načítání nebo
vykreslování.

Porovnejte: žádnou cache, omezenou cache v paměti a navrhovanou perzistentní
cache. Vyhodnoťte aktuálnost, invalidaci, soukromí, chování offline a měření
potřebné k odůvodnění změny.

Dokud neuvedete, kterou možnost doporučujete a proč, nic neimplementujte.

Zrevidujte tento pull request.

Zrevidujte tento diff z hlediska regresí autorizace, navigace porušující
lokalizaci a změn chování skrytých refaktoringem.

Sledujte každé změněné rozhodnutí o oprávnění až k jeho volajícímu. Ověřte, že
interní odkazy zachovávají aktivní locale a že zamítnuté stavy neodhalují chráněná
data.

Uveďte pouze zjištění s důkazy z diffu nebo jeho přímých míst volání.
Upřednostněte správnost a zabezpečení před návrhy na styl. Chybějící
testy uvádějte odděleně od potvrzených defektů.

Aktualizujte dokumentaci k nastavení.

Aktualizujte průvodce místním nastavením podle aktuálních package scriptů.

Ověřte každý zdokumentovaný příkaz podle package.json a pokynů k nastavení
v repozitáři. Vysvětlete předpoklady, očekávaný výstup připravenosti, běžné
signály selhání a bezpečný postup obnovy.

Nedokumentujte tajné údaje, hodnoty zkopírované z místního prostředí ani příkazy,
které projekt ve skutečnosti nespouští. Přidejte krátký kontrolní seznam ověření pro
nového přispěvatele.