Osvědčené postupy pro zadávání promptů GitHub Copilotu

GitHub Copilot poskytuje užitečnější pomoc s programováním, když popis úkolu vysvětluje problém, rozsah, omezení a důkaz úspěchu. Krátký prompt může stačit pro místní doplnění kódu. Změna repozitáře potřebuje stejnou jasnost jako dobře napsaný issue.

Na povrchu produktu záleží: aktuální dokumentace GitHubu popisuje pokyny pro celý repozitář, pokyny pro konkrétní cesty, pokyny pro agenta a znovupoužitelné soubory s prompty, přičemž podpora se liší podle funkce a IDE. Používejte nástroje dostupné ve svém prostředí, ale základní požadavek udržujte explicitní.

Dejte doplnění kódu místní kontrakt

U malé funkce často stačí okolní název, typy a testy. Doplňte chování, které lze nenápadně udělat chybně:

Implementujte parser pro hlavičku retry-after.

Vraťte milisekundy pro sekundy nebo platné datum HTTP. Pro chybějící, zápornou
nebo neplatnou hodnotu vraťte null. V cestě chyby odpovědi nevyhazujte výjimku.
Přidejte testy řízené tabulkou pro sekundy, budoucí datum, minulé datum a chybný
vstup.

Kontrakt vede doplnění bez nutnosti dlouhého popisu architektury.

Popisujte testovací práci jako chování

Vyhněte se tomuto:

Napište testy pro hook předvoleb.

Použijte:

Přidejte testy pro hook předvoleb s použitím stávajících testovacích konvencí.

Ověřte, že počáteční stav načítání nepřesměrovává, úspěšné čtení zpřístupní
uložené předvolby, aktualizace atomicky zapíše celý objekt předvoleb a
neúspěšná aktualizace zachová předchozí viditelnou hodnotu.

Používejte veřejné chování namísto interních počtů volání funkcí. Zahrňte
regresi, která by selhala s nahlášenou chybou.

Asistent nyní zná kontrakt viditelný pro uživatele včetně důležitého negativního případu.

Dejte promptům pro refaktoring pravidla zachování chování

Návrhy kódu mohou vytvořit čistou místní abstrakci, ale zahodit veřejný detail. Zachování vložte do požadavku:

Vyčleňte opakovanou prezentaci stavu z těchto dvou karet.

Zachovejte aktuální props, viditelné popisky, názvy analytických událostí,
zaměření klávesnice a mobilní rozložení. Omezte změny na tuto funkci a její přímé testy.

Před úpravou uveďte opakované chování a rozdíly, které musí zůstat
oddělené. Neměňte to na sdílenou komponentu design systému, pokud
stávající primitivum nedokáže výsledek vyjádřit.

Pokud nedokážete pojmenovat chování, které je třeba zachovat, požádejte Copilot nejprve o vysvětlení aktuálního kontraktu a míst volání.

Laďte pomocí příznaků a důkazů

Příznak: Stránka vyhledávání zobrazuje zastaralé výsledky poté, co uživatel změní filtry.

Očekávané: Výsledky na obrazovce řídí nejnovější výběr filtru.
Pozorované: Pomalejší předchozí požadavek může přepsat novější odpověď.

Relevantní kód: UI filtrů, hook požadavku a renderer výsledků. Nedávná změna:
byla přidána opakování požadavků.

Nejprve nastíněte životní cyklus požadavku a konkurenční hypotézy. Uveďte, jaké
logy nebo časování testu by každou z nich prokázaly. Poté navrhněte nejmenší opravu a regresní
pokrytí. Bez důkazů nenahrazujte datovou vrstvu.

Tím zabráníte tomu, aby se obecná odpověď „opravte závodní podmínku“ rozrostla v zbytečnou migraci správy stavu.

Použijte pokyny repozitáře pro stabilní kontext

Stabilní pravidla by tam, kde je to podporováno, měla žít s projektem:

jak spouštět testy a formátování;
omezení nasazení;
podporované locale nebo platformy;
veřejná API, která musí zůstat kompatibilní;
cesty, u nichž záleží na revizi zabezpečení nebo přístupnosti.

Dokumentace GitHubu popisuje vlastní pokyny na úrovni repozitáře a cílenější soubory s pokyny. Tyto pokyny udržujte krátké, přesné a omezené na trvalé konvence. Podrobnosti aktuálního tiketu — příznaky, výsledek a kritéria přijetí — vložte přímo do promptu.

Požadujte dokumentaci ukotvenou v kódu

Aktualizujte průvodce řešením problémů s nasazením po nové kontrole prostředí.

Ověřte každý příkaz a proměnnou prostředí podle repozitáře. Vysvětlete
signál úspěchu, běžný signál selhání a bezpečnou další akci. Tajné údaje
neuvádějte v příkladech. Namísto duplikování přidejte odkazy na existující provozní runbook.

Na větě „ověřte podle repozitáře“ záleží. Říká Copilotu, že přesná dokumentace je úkol čtení kódu, nikoli úkol generování prózy.

Každý významný prompt zakončete kritérii přijetí

Použijte cílovou čáru, kterou může zrevidovat někdo další:

Hotovo znamená:
- nahlášené chování uživatele se změní podle popisu;
- chráněné chování zůstane nezměněné;
- cílené testy prokážou novou i starou cestu;
- projde kontrola typů a relevantní příkaz lint;
- diff neobsahuje nesouvisející úklid.

Obecnou strukturu promptu najdete v článku jak psát lepší prompty pro AI. Pro vzory konkrétních úkolů pokračujte článkem prompt engineering pro vývojáře a poté se vyhněte způsobům selhání popsaným v článku chyby AI asistentů pro programování a jak se jim vyhnout.

Když programátorský úkol zahrnuje skripty, výstup příkazů nebo reprodukci v terminálu, ověřte jej namísto popisování zpaměti. Procvičte si pracovní postup příkazového řádku v prohlížeči, než jej proměníte v prompt nebo test.