Jak zadávat prompty ChatGPT pro programování

Při zadávání promptů ChatGPT pro programování popište technické rozhodnutí, nejen kód, který chcete získat. Poskytněte relevantní kód nebo kontext repozitáře, chování, které je třeba zachovat, konkrétní výsledek a způsob, jak ověřit výsledek.

„Napiš funkci, která dělá X“ může stačit pro malou utilitu. Nestačí však, když změna ovlivní chování uživatelů, sdílený kontrakt nebo produkční systém.

Než požádáte o kód, uveďte čtyři věci:

• Co existuje nyní: relevantní komponenta, funkce, API nebo selhání.
• Co se má změnit: výsledek viditelný pro uživatele nebo systém.
• Co se nesmí změnit: kompatibilita, výkon, přístupnost, kontrakty nebo veřejná API.
• Jak to ověřit: testy, kroky k reprodukci, kontroly typů nebo ruční kritéria přijetí.

Pokud používáte dlouhodobý pracovní prostor ChatGPT, udržujte pohromadě poznámky k architektuře, požadavky a relevantní soubory. ChatGPT Projects dokážou organizovat chaty, referenční soubory a pokyny specifické pro projekt; před nahráním zdrojových materiálů si ověřte aktuální plán a ovládací prvky pracovního prostoru.

Vyhněte se tomuto:

Vytvořte komponentu pro nahrávání souborů.

Neurčuje vlastnictví, zpracování chyb, limity souborů, přístupnost ani okolní kontrakt UI.

Místo toho použijte ohraničený požadavek:

Máme stránku nastavení v Reactu, která už vlastní odeslání formuláře a chybové
zprávy. Do existujícího formuláře přidejte nahrávač souborů.

Výsledek: Uživatel může vybrat jeden soubor PNG nebo JPEG menší než 5 MB, vidí
název vybraného souboru, může ho před odesláním odebrat a při neplatných
souborech dostane stávající lokalizovanou chybovou zprávu.

Omezení: Nepřidávejte novou knihovnu pro správu stavu, nevytvářejte endpoint
pro nahrávání a ponechte stávající obsluhu odeslání jako jediného vlastníka
stavu formuláře.

Vraťte nejmenší sadu změněných souborů, vysvětlete každou změnu a zahrňte
testy neplatného typu, limitu velikosti, odebrání a úspěšného výběru.

Požadavek komponentu zmenšuje, protože vylučuje zbytečnou architekturu.

Pro ladění si vyžádejte hypotézu a cestu k reprodukci, než požádáte o patch:

Příznak: Tlačítko Uložit zůstává zakázané po úspěšném opakování požadavku API.

Očekávané chování: Tlačítko bude po úspěšném opakování k dispozici.
Pozorované chování: Data odpovědi se zobrazí, ale tlačítko zůstává zakázané.

Relevantní kontext: Tlačítko závisí na isPending a form.isDirty. Začalo to
poté, co bylo do hooku pro mutace přidáno opakování požadavků.

Nejprve vypište nejpravděpodobnější přechody stavů a důkazy potřebné
k potvrzení každého z nich. Pak navrhněte nejmenší opravu a regresní test.

To je bezpečnější než „oprav tlačítko, které zůstává zakázané“, protože to žádá ChatGPT, aby odlišil chybu zastaralého stavu od problému s validací nebo vykreslováním UI.

Požadavky na refaktoring potřebují silnější klauzuli o zachování:

Refaktorujte seznam cenových karet, abyste odstranili duplicitní logiku
vykreslování plánů.

Zachovejte: veřejné props, názvy analytických událostí, cíle checkoutu, chování
klávesnice, stavy načítání a stávající mobilní rozložení.

Rozsah: Omezte změny na funkci stanovování cen a její přímo související testy.
Nezavádějte abstrakci design systému, pokud stávající primitiva
nedokážou vyjádřit sdílené chování.

Kritéria přijetí: Snapshotové nebo interakční testy pokrývají každý stav plánu a
vykreslené odkazy a datové payloady událostí zůstávají nezměněné.

Před úpravou určete duplicitu a všechna skrytá chování, která obě
karty v současnosti implementují odlišně.

Samotná fráze „zachovejte chování“ nestačí. Pojmenujte chování, na kterém záleží.

Nežádejte o „testy pro tuto komponentu“ bez kontraktu. Pojmenujte scénáře:

Napište testy pro formulář resetování hesla s použitím stávajícího testovacího stacku.

Pokryjte:
1. neplatný e-mail zobrazí lokalizovanou validační zprávu;
2. odeslání odešle normalizovaný e-mail jednou;
3. síťová chyba zachová zadanou hodnotu a zobrazí stávající chybový stav;
4. úspěšná odpověď oznámí potvrzení, aniž by odhalila, zda účet existuje.

Nemockujte implementační detaily. Upřednostněte přístupné role a popisky.

To asistentovi říká, co musí uživatel dokázat, a které chování související se soukromím nesmí regredovat.

Prompt s žádostí o vysvětlení by měl vyžadovat důkazní stopu, ne shrnutí:

Vysvětlete, jak se v tomto repozitáři stav ověření dostává na obrazovku fakturace.

Sledujte cestu od poskytovatele přes ochranu routy až po volání checkoutu. Pojmenujte soubory
a exportované symboly, které se na ní podílejí. Oddělte potvrzené chování od předpokladů
a uveďte, co byste prozkoumali dál, pokud by některá část nebyla jasná.

Tento formát usnadňuje odhalení chybějící závislosti nebo vymyšleného propojení.

ChatGPT je spolehlivější, když mu dáte nejužší kontext, který odpovídá na otázku:

• selhávající test a kód, který testuje;
• komponentu a hook, který vlastní její stav;
• příklad požadavku/odpovědi s odstraněnými citlivými hodnotami;
• konvence projektu, které změnu omezují;
• krátký seznam souborů, které jsou záměrně mimo rozsah.

Nenahrávejte tajemství, produkční přístupové tokeny, data zákazníků ani soukromé logy, které nemáte povoleno sdílet. Nahraďte tyto hodnoty realistickými redakcemi a zachovejte chování, o němž potřebujete přemýšlet.

Obecný rámec těchto promptů popisuje článek jak psát lepší prompty pro AI. Pro sadu vzorů implementace a revize podle rolí pokračujte článkem prompt engineering pro vývojáře. Pokud chcete propracovaný požadavek před úpravou a po ní, použijte příklady prompt engineeringu pro softwarové inženýry, a před průzkumem živého problému použijte šablony promptů pro ladění produkčních problémů.

Vygenerovaný kód je návrh. Spusťte relevantní testy, zkontrolujte diff a sami projděte ovlivněnou cestu. Když práce zahrnuje výstup příkazů, chyby nebo shellové skripty, reprodukce pracovního postupu je součástí ověření — není to volitelný doplněk. Používejte oblast pro procvičování příkazového řádku v prohlížeči, abyste si tento návyk vybudovali se skutečným zadáváním příkazů a zpětnou vazbou.