Grok pro vývojáře

Grok funguje jako spolehlivá gumová kachnička, která vám odpoví. Na grok.online je zcela zdarma a bez nutnosti registrace: Grok 4.20 je rychlý na běžné dotazy, Grok 4.3 Thinking před odpovědí přemýšlí, takže se lépe hodí na hledání chyb, a Grok 4.7, nejnovější model, zvládne ty nejzapeklitější problémy v rámci 10 z vašich 30 denních zpráv. Všechny tři modely umí číst screenshoty. Zde je sedm způsobů využití, každý s promptem, který si můžete otevřít přímo v chatu a upravit.

Hledání a oprava problémů

Většina času při ladění padne na snahu pochopit, co se vlastně děje. Tyto prompty vám tento krok urychlí.

Rozluštění stack trace

Vložte celou chybu (žádné parafrázování) a k tomu řádky, na které ukazuje. Před samotnou opravou požádejte o vysvětlení příčiny lidskou řečí, abyste ji mohli sami posoudit.

Používám [jazyk a verze] s [framework]. Zde je celá chyba a stack trace: [vložte chybu]. Zde je kód, na který odkazuje: [vložte kód]. Vysvětli srozumitelně, co se pokazilo a proč, uveď nejprve nejpravděpodobnější příčinu a pak ukaž nejmenší možnou změnu, která to opraví.

Otevřít v chatu. Nástroj Code Assistant zvládne to samé v jednom přehledném panelu.

Zorientujte se v cizím kódu

Dostat na starost soubor bez jediného komentáře je běžný křest ohněm. Než v něm cokoliv změníte, nechte si udělat rychlou prohlídku s upozorněním na riziková místa.

Právě jsem dostal/a na starost tento soubor v [jazyk] a potřebuji upravit [funkce]. Udělej mi stručný přehled: za co soubor zodpovídá, hlavní funkce v pořadí, v jakém se spouštějí, na jaký globální stav nebo vedlejší efekty si dát pozor a které místo je pro mou úpravu nejbezpečnější: [vložte kód]

Získat přehled a pak se doptat na jakoukoli funkci, která vám stále nedává smysl.

Odhalte logickou chybu pomocí uvažujícího modelu

Když aplikace nespadne, ale výstup je špatně, potřebujete kód pečlivě projít krok za krokem. Grok 4.3 Thinking si kód před odpovědí zanalyzuje, což je ideální pro chyby o jedničku (off-by-one) nebo rozbité podmínky.

Tato funkce v [jazyk] by měla [očekávané chování], ale pro vstup [vstup] vrací [skutečný výstup] místo [očekávaný výstup]. Projdi běh programu krok za krokem s tímto vstupem, ukaž hodnoty klíčových proměnných v každém kroku a ukaž na přesný řádek, kde nastává chyba: [vložte funkci]

Analyzovat pomocí Grok 4.3 Thinking.

Oprava rozbitého layoutu ze screenshotu

Přiložte screenshot aktuálního vzhledu stránky, vložte příslušné HTML a CSS a popište, jak by to mělo vypadat správně.

Přikládám screenshot stránky, kde [popište problém, např. boční panel se na úzkých obrazovkách překrývá s obsahem]. Zde je HTML a CSS pro tuto část: [vložte kód]. Vysvětli, co to způsobuje, a navrhni opravené CSS s minimem nutných změn.

Otevřít tento prompt a přiložit screenshot.

Plánování rizikového refaktoringu

Rozplétání obřího modulu je přesně ta chvíle, kdy se vyplatí využít jednu z omezených denních zpráv nejnovějšího modelu. Chtějte plán, ne přepsání celého kódu naráz.

Níže je modul v [jazyk], který už je příliš složitý na úpravy: [vložte kód]. Zatím ho nepřepisuj. Popiš jeho odpovědnosti, skryté závislosti a navrhni plán refaktoringu po malých krocích tak, aby byl kód po každém kroku plně funkční. Uveď, jaké testy bych měl/a doplnit ještě před prvním krokem.

Naplánovat s Grok 4.7 a jednotlivé kroky pak postupně zadávat do Grok 4.20.

Pište kód kolem kódu

Testy, databázové dotazy, revize kódu a dokumentace jsou přesně ty věci, které se při blížícím se deadlinu začnou odsouvat.

Napište testy pro okrajové případy, které jste vynechali

Nejprve si vyžádejte seznam případů a teprve potom samotný kód testů. Skutečná hodnota se skrývá právě v tomto seznamu.

Zde je funkce v [jazyk]: [vložte funkci]. Nejprve vypiš okrajové případy, které stojí za otestování (např. prázdný vstup, hraniční hodnoty, neplatné typy), a ke každému jednou větou uveď proč. Poté napiš testy pomocí [testovací framework], jeden test pro každý případ, s jasnými názvy.

Vygenerovat testy, spusťte je a ponechte si ty, které selhávají z pádných důvodů.

Nechte si udělat code review od přísného seniora

Grok se rád vžije do role ostříleného vývojáře, který už viděl každou chybu dvakrát. Přísnost nevadí, vágnost ano – proto vždy žádejte konkrétní čísla řádků.

Zreviduj tento diff jako přísný, ale férový senior vývojář. Upozorni na chyby, nejasné názvy, chybějící ošetření chyb a cokoliv, co nám za půl roku zkomplikuje život. U každého bodu uveď číslo řádku a návrh řešení. Seřaď problémy podle závažnosti a vynech nepodstatné stylistické drobnosti: [vložte diff]

Požádat o revizi dřív, než kód uvidí kolegové z týmu.

Převeďte schéma na SQL a README

Zadejte definice tabulek, popište běžnými slovy svůj dotaz a vyžádejte si k SQL kódu i stručné vysvětlení.

Zde jsou definice mých tabulek pro [databáze, např. PostgreSQL]: [vložte schéma]. Napiš dotaz, který vrátí [co potřebujete získat, vlastními slovy]. Jednou větou vysvětli každý join a filtr a doporuč, jaký index by dotaz zrychlil, až v tabulkách budou miliony řádků.

Napsat dotaz a pak požádejte o část souboru README, která tabulky zdokumentuje.

Čeho se vyvarovat

• Vkládání citlivých údajů. API klíče, hesla, tokeny a zákaznická data do žádného chatu nepatří. Nahraďte je zástupnými symboly.
• Slepá důvěra v detaily knihoven. Modely mají stanovené datum uzávěrky znalostí a nemají přístup k internetu, takže určitá funkce nebo parametr může být zastaralý či vymyšlený. Vždy si to ověřte v oficiální dokumentaci.
• Nasazování netestovaného kódu. Kód, který se dobře čte, může přesto selhat. Spusťte ho, otestujte a zkontrolujte.
• Posílání celých repozitářů. Příliš dlouhé zprávy se ořezávají. Posílejte jen tu funkci, o kterou skutečně jde.

Související stránky

• Dvacet dalších nápadů najdete v sekci prompty pro programování.
• Náš průvodce programováním s Grok a vysvětlení uvažujících modelů.
• Stavíte vlastní aplikaci? Přečtěte si více o Grok API.