Průvodce zadáváním promptů pro Cursor AI

Když AI umí prozkoumat repozitář, lepší prompt je obvykle užší — ne širší. Dejte Cursoru soubory, hranice, omezení a ověření, na kterých záleží, a poté jej požádejte, aby před úpravou analyzoval relevantní oblast.

Nástroje znalé repozitáře mohou odhalit užitečný kontext, ale také mohou způsobit, že změna vypadá jistěji, než ve skutečnosti je. Cílem je proměnit přístup k repozitáři v důkazy, nikoli v oprávnění upravit každý související soubor.

Aktuální dokumentace Cursoru popisuje odkazy na kontext pro materiál repozitáře, například soubory, složky, změny git a chyby linteru. Pomocí ovládacích prvků kontextu dostupných ve své verzi nasměrujte asistenta na co nejmenší užitečnou sadu důkazů.

Například místo tohoto:

Opravte pomalý dashboard.

napište:

Prozkoumejte zpoždění načítání dashboardu pro přihlášené uživatele.

Rozsah: Začněte routou dashboardu, jejím hookem pro načítání dat a jedinou kartou,
která příliš dlouho zobrazuje skeleton načítání. Jako kontext použijte aktuálního
poskytovatele profilu a stávající instrumentaci výkonu.

Výsledek: Určete, zda je zpoždění dobou načítání, zbytečným vykreslováním, nebo
přechodem stavu. Navrhněte nejmenší měřitelné zlepšení.

Omezení: Zachovejte chování autorizace, lokalizované UI a stávající
zpětnou vazbu při načítání. Bez důkazů nepřidávejte cache ani novou knihovnu stavu.

Před úpravou shrňte cestu vykonání a uveďte, co byste měřili.

Prompt dává asistentovi cestu do repozitáře, aniž by každý soubor dashboardu považoval za změnitelný.

Kontext repozitáře je nejcennější na začátku úkolu. Požádejte Cursor, aby:

1. sledoval relevantní tok dat nebo řízení;
2. určil kód, který vlastní dané chování;
3. oddělil potvrzená fakta od předpokladů;
4. uvedl nejmenší soubory, které se pravděpodobně změní;
5. vysvětlil, který test nebo pozorování opravu prokáže.

To je obzvlášť důležité, když požadavek zasahuje sdíleného poskytovatele, globální komponentu, ověření, platby nebo navigaci. Tyto oblasti často mají místa volání, která místní změna nemůže bezpečně ignorovat.

„Aktualizujte funkci oznámení“ je stále široké, pokud funkce zahrnuje UI, perzistenci, workery a nastavení. Přidejte omezení souboru nebo hranice:

Změňte pouze formulář předvoleb oznámení. Klientský zapisovač je zdrojem
pravdy pro aktualizace předvoleb; v tomto úkolu nepřidávejte další zapisovač
ani neměňte scheduler.

Prozkoumejte formulář, typovaný klientský zapisovač a jejich přímé testy.
Pokud hlášená chyba vyžaduje změnu backendu, zastavte se a vysvětlete důkazy,
místo abyste rozšiřovali rozsah.

To asistentovi nebrání najít skutečný problém přes hranice. Rozšíření tím činí explicitním a snadno kontrolovatelným.

Opakovaný kontext projektu patří do pokynů nebo pravidel repozitáře, ne do každého promptu chatu. Pro trvalé vedení projektu použijte invarianty jako:

• hranice statického exportu nebo nasazení;
• požadavky na locale;
• příkazy pro testy a styl kódu;
• pravidla vlastnictví sdíleného stavu;
• cesty vyžadující zvláštní revizi.

Prompt úkolu držte zaměřený na konkrétní problém a kritéria přijetí. Když se pokyny projektu a prompt rozcházejí, vyřešte konflikt v požadavku, místo abyste doufali, že asistent uhodne, na čem záleží.

Rozsáhlé požadavky se těžko ověřují, protože široký diff skrývá příčinu a následek. Rozdělte práci do kontrolních bodů:

Nejprve prozkoumejte a vysvětlete aktuální cestu odeslání formuláře. Soubory
neupravujte.

Po analýze implementujte pouze opravu stavu validace a přidejte k ní cílený
test. Zatím nerefactorujte sousední komponenty formuláře.

Spusťte relevantní test a shrňte diff. Pokud projde, navrhněte samostatný
následný krok pro sdílený úklid.

Tento vzor usnadňuje revizi práce asistenta a umožňuje praktické vrácení změn, pokud byla hypotéza chybná.

AI asistent pro programování by si neměl jako pravidlo dokončení zvolit „vypadá správně“:

Kritéria přijetí:
- stávající chování stále funguje při úspěšném odeslání;
- nahlášený neplatný stav je dosažitelný a viditelný;
- zpětná vazba pro klávesnici a čtečku obrazovky zůstává zachována;
- cílený test projde a selhání by zachytilo starou chybu.

Ověření: spusťte cílenou sadu testů, kontrolu typů a popište každý ruční
krok v prohlížeči, který pokrývá chování, jež test nemůže pozorovat.

Požádejte jej, aby určil chybějící test, místo aby si z výsledku úspěšné kompilace vymýšlel jistotu.

Úkol: [Jednovětý technický cíl.]

Kontext repozitáře: [Relevantní soubory, složka, diff, chyba nebo existující pravidlo.]
Problém: [Pozorované chování a koho ovlivňuje.]
Rozsah: [Soubory nebo hranice, které je třeba nejprve prozkoumat.]
Požadovaný výsledek: [Pozorovatelný výsledek pro uživatele nebo systém.]
Omezení: [Chování, kompatibilita, architektura a cíle mimo rozsah.]
Kritéria přijetí: [Požadované výsledky.]
Ověření: [Cílené testy, kontrola typů, ruční kontrola, měření.]

Nejprve analyzujte. Uveďte aktuálního vlastníka chování, zpochybněte každý slabý
předpoklad a před úpravou navrhněte nejmenší bezpečnou změnu.

Použijte širší rámec uvažování z článku jak psát lepší prompty pro AI a vzory podle typu úkolu najdete v článku prompt engineering pro vývojáře. U změny, která je převážně strukturální, použijte tyto šablony promptů pro refaktoring kódu.

Pokud úkol v repozitáři zahrnuje skripty nebo výstup terminálu, ověřte před změnou skutečné chování příkazu. Procvičujte pracovní postupy příkazového řádku v prohlížeči, abyste proměnili předpokládaný výstup v pozorovatelný testovací případ.