Prompt engineering pro vývojáře

Prompt engineering pro vývojáře je praxe poskytování kontextu a omezení AI asistentovi pro programování, které potřebuje k bezpečnému technickému rozhodnutí. Užitečný prompt není ten nejsložitější. Je to ten, který jednoznačně vymezuje rozsah, kritéria přijetí a ověření.

Zacházejte s požadavkem na AI jako se silným implementačním tiketem: měl by vysvětlit problém, chránit důležité chování a uvést, jak tým pozná, že změna funguje.

Kontrakt promptu pro vývojáře

Většina programátorských úkolů může používat tento stručný kontrakt:

Problém: Co selhává nebo je obtížné pro uživatele či správce?
Rozsah: Kterou funkci, soubory nebo hranici má asistent prozkoumat?
Výsledek: Jaké pozorovatelné chování se má změnit?
Omezení: Co musí zůstat pravdivé?
Kritéria přijetí: Co prokazuje, že je implementace dokončena?
Ověření: Které testy, kontroly nebo ruční kroky se mají spustit?

Za kontrakt přidejte relevantní kód, logy, designové rozhodnutí nebo selhání testu. Asistent tak dostane fakta, ze kterých může vycházet, namísto požadavku, aby si celý systém domýšlel.

Prompty pro implementaci: určete napojovací bod

Prompt pro implementaci by měl pojmenovat stávajícího vlastníka chování:

Přidejte prázdný stav do existující komponenty výsledků vyhledávání.

Routa stránky vlastní dotaz a komponenta výsledků přijímá typovaný seznam.
Toto vlastnictví ponechte beze změny. Prázdný stav musí vysvětlit, že žádné
výsledky neodpovídají, nabídnout stávající akci pro vymazání hledání a zachovat
zaměření klávesnice.

Přidejte komponentový test pro prázdný výsledek a potvrďte, že se naplněné
výsledky vykreslují beze změny.

Pojmenování napojovacího bodu brání asistentovi v přidání paralelního stavu dotazu nebo přesunu logiky routy do prezentační komponenty.

Prompty pro ladění: nejprve si vyžádejte důkazy

U chyby podobné produkčnímu problému uspořádejte prompt jako důkazy, hypotézy, ověření, opravu a validaci:

Důkazy: Požadavky po obnovení tokenu vrátí jednou 401, pak při opakování
uspějí. UI stále zobrazuje banner odhlášení.

Očekávané: Banner se po úspěšném opakování skryje.
Pozorované: Data se načtou, ale banner zůstává.

Prozkoumejte přechody stavu ověření. Uveďte konkurenční hypotézy a nejmenší
pozorování potřebné k potvrzení každé z nich. Neměňte kód, dokud není
cesta selhání reprodukována. Poté navrhněte opravu s regresním testem.

Tím asistent ukazuje hranici svého uvažování. Dříve než se v diffu objeví rozsáhlý přepis správy stavu, můžete zkontrolovat hypotézu založenou na důkazech.

Prompty pro architekturu: chraňte rozhodnutí, nejen soubory

Práce na architektuře potřebuje jasné cíle mimo rozsah:

Posuďte, zda mají předvolby oznámení zůstat v dokumentu uživatelského profilu
nebo se mají přesunout do samostatného modelu nastavení.

Omezení: Aplikace se exportuje staticky, zápisy obstarává klient,
stávající čtečky předvoleb musí zůstat kompatibilní a žádná migrace nesmí
potichu zahodit volbu uživatele.

Porovnejte možnosti podle vzorců čtení, autorizace, rizika nasazení a
testovatelnosti. Než navrhnete kód, doporučte jeden přístup s kompromisy.

O analýzu před implementací žádejte vždy, když by úkol mohl změnit vlastnictví dat, veřejné kontrakty nebo chování při nasazení.

Prompty pro revizi kódu: vyžádejte si rizika, ne komplimenty

Revize pomocí AI je užitečnější, když má cíl:

Zkontrolujte tuto změnu z hlediska regresí chování, mezer v přístupnosti,
zpracování chyb a testů, které už neprokazují kontrakt s uživatelem.

Zaměřte se na změněné soubory a místa volání, která ovlivňují. Zjištění seřaďte podle
priority a u každého uveďte důkazy. Nenavrhujte změny pouze stylu,
pokud nezakrývají defekt nebo nečiní kontrakt nejasným.

Tím se vyhnete obecné revizi, která vytvoří dlouhý seznam málo hodnotných návrhů na formátování.

Prompty k dokumentaci: zachovejte provozní pravdu

Dokumentaci je třeba kontrolovat podle kódu:

Aktualizujte průvodce nastavením pro nový příkaz místního prostředí.

Vysvětlete předpoklady, očekávaný výstup, obnovu po selhání a ověření připravenosti
služby. Každý příkaz porovnejte se skripty balíčku a nedokumentujte proměnné
prostředí, které se ve skutečnosti nevyužívají.

Poslední věta je důležitá: asistent dokáže napsat uhlazenou dokumentaci k příkazu, který nikdy neběží.

Prompty pro testování: převeďte kritéria přijetí na scénáře

Když žádáte o testy, dejte každému scénáři výsledek pro uživatele nebo systém:

Přidejte regresní pokrytí pro opravu filtru vyhledávání.

Ověřte, že změna filtru aktualizuje seznam výsledků, vymazání filtru
obnoví úplný seznam a pomalý předchozí požadavek nemůže přepsat novější
výsledek. Použijte stávající testovací konvence a vyhněte se tvrzením
zaměřeným pouze na implementaci.

Testy jsou jasnější, když popisují chování, které musí implementace zachovat.

Zvyk, díky němuž jsou prompty bezpečnější

Než odešlete prompt k programování, zeptejte se sami sebe:

Pochopil by jiný vývojář, proč je tato změna důležitá?
Poznal by, co se nesmí rozbít?
Ví, kde má začít hledat?
Dokázal by prokázat výsledek pomocí kritérií přijetí?

Pokud je odpověď ne, prompt potřebuje kontext — ne více přídavných jmen.

Základní rámec najdete v článku jak psát lepší prompty pro AI, využijte konkrétní požadavky z článku jak zadávat prompty ChatGPT pro programování a porovnejte formulace pro konkrétní úkoly v článku příklady prompt engineeringu pro softwarové inženýry. Abyste se vyhnuli vzorcům selhání, které činí implementaci rizikovou, přečtěte si chyby AI asistentů pro programování a jak se jim vyhnout. Když vaše práce zahrnuje shellové skripty, logy nebo výstup příkazů, procvičte si pracovní postup příkazového řádku, než jej zautomatizujete nebo změníte.