Grok para sa mga developer

Ang Grok ay isang maaasahang rubber duck na sumasagot. Sa grok.online, libre ito at hindi kailangan ng account: mabilis ang Grok 4.20 para sa maiikling tanong, nag-iisip muna ang Grok 4.3 Thinking bago sumagot kaya mas bagay ito sa mga bug, at ang Grok 4.7, ang pinakabagong model, ay nandiyan para sa pinakamahihirap na problema gamit ang 10 sa iyong 30 arawang mensahe. Nakakabasa ng screenshots ang tatlo. Narito ang pitong gamit, bawat isa ay may prompt na maaari mong buksan sa chat at i-adjust.

Maghanap at mag-ayos ng mga problema

Karamihan sa oras ng pag-debug ay napupunta sa pag-unawa kung ano ang nangyayari. Pinapabilis ng mga prompt na ito ang bahaging iyon.

I-decode ang isang stack trace

I-paste ang buong error, hindi paraphrase, kasama ang mga linyang tinutukoy nito. Hingin ang sanhi sa simpleng salita bago ang anumang fix, para masuri mo ito.

Gumagamit ako ng [wika at bersyon] kasama ang [framework]. Narito ang buong error at stack trace: [i-paste ang error]. Narito ang code na tinutukoy nito: [i-paste ang code]. Ipaliwanag sa simpleng salita kung ano ang naging mali at bakit, unahin ang pinakamalamang na sanhi, pagkatapos ay ipakita ang pinakamaliit na pagbabagong mag-aayos dito.

Buksan ito sa chat. Ginagawa rin ito ng Code Assistant sa iisang panel.

Kumuha ng gabay sa code na hindi mo isinulat

Ang paghawak sa file na walang comments ay normal na bahagi ng buhay developer. Bago ka magbago ng anuman, humingi ng guided tour na tutukoy sa mga delikadong parte.

Kakahawak ko lang sa [wika] file na ito at kailangan kong baguhin ang [feature]. Bigyan mo ako ng maikling overview: para saan ang file, ang mga pangunahing function ayon sa pagkakasunod-sunod ng pagtakbo ng mga ito, aling global state o side effects ang dapat bantayan, at ang pinakaligtas na lugar para gawin ang aking pagbabago: [i-paste ang code]

Kunin ang tour, pagkatapos ay magtanong tungkol sa anumang function na mukhang kakaiba pa rin.

Mag-hunt ng logic bug gamit ang thinking model

Kapag walang nagka-crash pero mali ang output, kailangan mo ng maingat na pag-trace. Sinusuri ng Grok 4.3 Thinking ang bawat hakbang ng code bago ito sumagot, na swak para sa mga off-by-one error at sirang kundisyon.

Ang [wika] function na ito ay dapat [inaasahang gawi], ngunit para sa input na [input], ibinabalik nito ang [aktwal na output] sa halip na [inaasahang output]. I-trace ang execution nang sunod-sunod gamit ang input na iyon, ipakita ang mga value ng mahahalagang variable sa bawat hakbang, at ituro ang eksaktong linya kung saan ito nagkamali: [i-paste ang function]

I-trace ito gamit ang Grok 4.3 Thinking.

Ayusin ang sirang layout mula sa screenshot

Mag-attach ng screenshot ng kasalukuyang itsura ng page, i-paste ang kaugnay na HTML at CSS, at ilarawan kung ano dapat ang itsura nito.

Nag-attach ako ng screenshot ng isang page kung saan [ilarawan ang problema, hal. sumasapaw ang sidebar sa content sa maliliit na screen]. Narito ang HTML at CSS para sa bahaging iyon: [i-paste ang code]. Ipaliwanag kung ano ang nagdudulot nito at ibigay ang naitamang CSS, na may pinakakaunting pagbabago hangga't maaari.

Buksan ang prompt na ito at i-attach ang iyong screenshot.

Magplano ng delikadong refactor

Ang pag-ayos ng magulong malaking module ang pagkakataong sulit gamitin ang isa sa limitadong arawang mensahe ng pinakabagong model. Plano ang hingin, hindi rewrite.

Nasa ibaba ang isang [wika] module na naging mahirap nang baguhin: [i-paste ang code]. Huwag mo muna itong i-rewrite. Ilarawan ang mga responsibilidad nito, ang mga nakatagong dependency, at isang plano sa pag-refactor gamit ang maliliit na hakbang kung saan gumagana pa rin ang code pagkatapos ng bawat isa. Sabihin kung aling mga test ang dapat kong idagdag bago ang unang hakbang.

Iplano ito gamit ang Grok 4.7, pagkatapos ay isa-isang ipadala ang mga hakbang sa Grok 4.20.

Isulat ang sumusuportang code

Ang mga test, query, review, at docs ang kadalasang naisasaisantabi kapag papalapit na ang deadline.

Sumulat ng tests para sa mga edge case na nalaktawan mo

Hingin muna ang listahan ng mga kaso bago ang test code. Nasa listahan ang tunay na halaga.

Narito ang isang [wika] function: [i-paste ang function]. Ilista muna ang mga edge case na sulit i-test, tulad ng empty input, boundaries, at invalid types, na may tig-iisang linya kung bakit. Pagkatapos ay isulat ang mga test gamit ang [test framework], isang test bawat kaso, na may malilinaw na pangalan.

I-generate ang mga test, patakbuhin ang mga ito, at panatilihin ang mga nag-fail dahil sa valid na dahilan.

Kumuha ng masungit na code review mula sa senior

Kayang-kayang gampanan ng Grok ang papel ng reviewer na nakita na ang bawat bug nang makalawang beses. Ayos lang ang masungit; ang malabo ay hindi, kaya humingi ng line references.

I-review ang diff na ito tulad ng isang masungit pero patas na senior engineer. Ituro ang mga bug, malabong pangalan, kulang na error handling, at anumang magdudulot ng problema pagkalipas ng anim na buwan, bawat isa ay may line reference at iminungkahing fix. I-rank ang mga isyu ayon sa tindi at laktawan ang mga simpleng puna sa style: [i-paste ang diff]

Hilingin ang review bago pa ito makita ng mga kasamahan mo sa team.

Gawing SQL at README ang isang schema

Ibigay ang mga table definition at ang tanong sa simpleng salita, at humingi ng maikling paliwanag kasama ang query.

Narito ang mga table definition ko para sa [database, hal. PostgreSQL]: [i-paste ang schema]. Sumulat ng query na nagbabalik ng [kung ano ang kailangan mo sa simpleng salita]. Ipaliwanag ang bawat join at filter sa isang linya, at sabihin sa akin kung aling index ang maaaring magpabilis dito kapag umabot na sa milyun-milyong rows ang mga table.

Isulat ang query, pagkatapos ay humingi ng seksyon sa README na nagdodokumento sa mga table.

Mga dapat iwasan

• Pag-paste ng mga lihim na impormasyon. Ang mga API key, password, token, at talaan ng customer ay hindi dapat inilalagay sa anumang chat. Palitan ang mga ito ng mga placeholder.
• Bulag na pagtitiwala sa mga detalye ng library. May knowledge cut-off ang mga model at walang internet access, kaya maaaring luma o gawa-gawa lang ang isang function o opsyon. Tingnan ang opisyal na docs.
• Pag-deploy ng output na hindi pa nasusubukan. Ang code na magandang basahin ay maaari pa ring mag-fail. Patakbuhin ito, i-test ito, at suriin ito.
• Pagpapadala ng buong repositories. Pinuputol ang napakahahabang mensahe. Ipadala lang ang function na may kinalaman sa problema.

Kaugnay na mga pahina

• Dalawampu pang panimulang punto sa coding prompts.
• Ang aming gabay sa coding gamit ang Grok at paliwanag sa reasoning models.
• Bumubuo ng sarili mong app? Magbasa pa tungkol sa Grok API.