Mga nadagdag:
- Kakayahang bawasan ang isang bug sa pinakamaliit na reproducible instance at ilipat ito sa AI na may buong patunay
- Kakayahang subukan ang mga hypotheses na batay sa ebidensya na may pinakamurang kontrol at hanapin ang ugat na dahilan
- Kakayahang lutasin ang ugat na sanhi at i-secure ito gamit ang isang regression test sa halip na i-patch ang sintomas
Ang pag-debug ay ang proseso ng pag-alam kung bakit hindi inaasahang kumikilos ang isang software at inaayos ito. Ito ang trabaho kung saan ang isang developer ay gumugugol ng pinakamaraming oras at pinakapagod; Dahil kadalasan ang pagkakamali ay wala kung saan ito lumilitaw, ngunit nakatago ng ilang hakbang sa likod. Ang AI ay isang makapangyarihang kasosyo sa pag-iisip na nagpapabilis sa pananaliksik na ito — ngunit kung bibigyan mo lang ito ng tamang ebidensya. Ang pag-debug nang walang ebidensya ay ang lugar kung saan ang AI ay gumagawa ng pinakamaraming guni-guni.
Sa unit na ito, nagtatatag kami ng isang disiplinadong daloy mula sa pagbuo ng error hanggang sa pagpunta sa ugat: paglilinaw sa sintomas, pangangalap ng ebidensya (mensahe ng error, stack trace, log, entry), pagbuo ng hypothesis, pagsubok sa hypothesis, at pagpapatunay ng pag-aayos. Tumutulong ang AI sa bawat hakbang; ngunit ang "naayos" na desisyon ay ginawa sa pamamagitan ng pag-alam na ang bug ay talagang nawala na.
Bakit Katibayan ang Lahat?
Ang isang LLM ay hindi nakakakita ng error sa paraang ginagawa mo; Siya lang ang nakakaalam kung ano ang sasabihin mo sa kanya. Ang isang pangungusap na tulad ng "Nag-crash ang application" ay nagbibigay ng halos walang impormasyon sa modelo, at pinupunan ng modelo ang puwang ng isang hula — iyon ay, isang guni-guni. Sa turn, ang buong mensahe ng error, stack trace — isang breakdown kung aling function ang tumatawag sa error na naganap, ang input na nag-trigger ng error, at kung ano ang inaasahan, atbp. Dahil sa naobserbahang gawi, maaaring i-rank ng modelo ang totoong probabilities.
Sa pag-debug, isipin ang AI bilang isang katulong sa isang detektib: kung mas maraming ebidensya ang ipapakita mo, mas tumpak ang hypothesis na nabuo nito. Kung walang katibayan, hulaan lamang ng katulong at maaari kang humantong sa maling landas.
Tip: Bago mag-port ng bug sa AI, bawasan ito sa pinakamaliit na halimbawang maaaring kopyahin. Ang pinakamaliit na code at input na nagti-trigger ng error ay ginagawang radikal na mas madali ang mga bagay para sa iyo at sa modelo; kadalasan sa panahon ng pagbabawas na ito, makikita mo mismo ang dahilan.
Hakbang sa Hakbang: Daloy ng Pagsusuri ng Root Cause
- Linawin ang sintomas. "Anong nangyayari, ano ang inaasahan mong mangyari?" Isulat ang dalawa sa isang pangungusap.
- Mangalap ng ebidensya. Buong mensahe ng error, stack trace, may-katuturang mga linya ng log, triggering entry, impormasyon ng bersyon.
- Ipagawa ang hypothesis. Mula sa AI "3 posibleng dahilan na nagpapaliwanag ng sintomas na ito at paano ko susuriin ang bawat isa?" magtanong.
- Subukan muna ang pinakamurang hypothesis. Magdagdag ng log, mag-print ng value, magpatakbo ng pagsubok. Kinukumpirma ba ng ebidensya ang hypothesis?
- Ayusin ang ugat, hindi ang sintomas. Sa halip na patahimikin ang sintomas gamit ang isang patch, tugunan ang ugat na sanhi.
- I-validate at idagdag ang regression testing. Tingnan ang error na mawala; Pagkatapos ay magsulat ng isang pagsubok na sasaluhin ang error na iyon upang hindi ito bumalik.
Tatlong Mini Case
Case 1 — Ang stack trace ay humantong sa tamang file. Nagbabalik ang isang application ng 500 error sa ilang partikular na kahilingan. Ibinigay ng developer ang buong stack trace at nagti-trigger na kahilingan sa AI; Ang modelo ay nag-hypothesize na ang error ay sanhi ng isang None value sa isang layer ng pag-parse ng petsa. Nagdagdag ang developer ng log sa linyang iyon, na-verify ito at nalutas ito sa loob ng 15 minuto; Nasayang ang 2 oras noong nakaraang araw sa mga hindi napatunayang eksperimento.
Kaso 2 — Ang hallucination ay humantong sa maling landas. Ang isa pang developer ay nagsulat lamang ng "ang koneksyon sa database ay bumababa". Inakusahan ng AI ang isang setting ng connection pool nang walang anumang ebidensya; Ang developer ay gumugol ng 40 minuto sa pag-iisip sa setting na ito. Ang tunay na dahilan ay isang timeout sa bahagi ng network at nahayag lamang sa pamamagitan ng pagtingin sa mga log. Aralin: ang isang hypothesis na kinuha nang walang ebidensya ay malamang lamang, hindi maaasahan.
Case 3 — Nahuli ang patumpik-tumpik na error. May isang pagsubok na paminsan-minsan ay nabigo. Binigyan ang AI ng test code, ang mensahe ng pagkabigo, at ang impormasyong "minsan pumasa ito, minsan nabigo"; ang modelo ay nagpahiwatig ng isang nakabahaging dependency sa oras/order ng mga pagsubok. Kinumpirma ng pagsusuri na ang pagsubok ay batay sa lokal na oras ng system. Kapag naayos na ang orasan (ginaya), naging stable ang pagsubok.
Apat na Nakokopyang Template
Pagbuo ng hypothesis na batay sa ebidensya:
Nagde-debug ako ng bug. Katibayan sa ibaba.- Inaasahang gawi: {{expected}}- Naobserbahang gawi: {{observed}}- Error message / stack trace: {{trace}}- Triggering input: {{input}}- Environment/bersyon: {{bersyon}}Ilista ang 3 MADALING-MALIRANG root cause na nagpapaliwanag ng sintomas na ito. Para sa bawat isa: paano ko susuriin (pinakamurang tseke) at kung paano ito ayusin kung totoo ito. Kung hindi sapat ang ebidensya, sabihin sa akin kung anong karagdagang impormasyon ang kailangan mo.
Pagbibigay-kahulugan sa stack trace:
Basahin ang stack trace na ito. Tukuyin ang pagkakaiba sa pagitan ng kung aling linya ang error MALAMANG nagsisimula sa (ugat) at kung aling mga linya ang pagpapatuloy lamang ng kadena. Magmungkahi ng 1-2 lugar na unang tingnan. Kaugnay na code:{{code}}Trace:{{trace}}
Minimal na pagbabawas ng repro:
Ang code sa ibaba ay gumagawa ng isang error. Bawasan ito sa PINAKAMALIIT na pagkakataon na nagti-trigger pa rin ng error ngunit itinatapon ang anumang hindi kailangan. Huwag ipagpalagay na ang bawat piraso na iyong aalisin ay hindi makakaapekto sa error, ngunit magdagdag ng isang tala na nagsasabing "kung ang error ay mawala kapag inalis mo ito, iyon ang dahilan kung bakit".{{code}}
Post-correction validation at regression testing:
Ipagpalagay na ang pangunahing sanhi ay {{cause}} at ginagawa ko ang sumusunod na pag-aayos: {{fix}}.1) Ang pag-aayos ba na ito ay aktwal na nag-aayos ng sintomas, magkakaroon ba ito ng anumang mga side effect?2) Sumulat ng isang regression test na sasaluhin ang bug na ito sa hinaharap.
Mahinang prompt / Malakas na prompt
Mahina: "Hindi gumagana ang code, bakit?"
Malakas: "Ang Node 20 / Express. Ang POST /orders ay nagbabalik ng 500 kapag ang mga item ay isang walang laman na string sa katawan; dapat ay nagbalik ng 400. Stack trace: TypeError: Cannot read properties of undefined (reading '0') — attached is the full trace and associated handler. Bigyan mo ako ng 3 pinaka-malamang na mga sanhi na nagpapaliwanag sa bawat sintomas na ito]" [at kung paano ipaliwanag ang bawat sintomas na ito]" [tra]
Napakahusay na bersyon; Nagbibigay ito ng kapaligiran, endpoint, trigger input, eksaktong uri ng error, at inaasahang pag-uugali. Ang modelo ay hindi na maaaring gumawa ng mga hula, ngunit pagsusuri.
hakbang
kontribusyon ng AI
iyong kontrol
pangangalap ng ebidensya
Anong ebidensya ang kailangan, paalala
Nangongolekta talaga ng ebidensya
pagbuo ng hypothesis
Ilista ang mga posibleng dahilan
Nag-uuna sa konteksto
pagsubok ng hypothesis
Inirerekomenda ang paraan ng pagsubok
Nagpapatakbo at nagmamasid nang personal
pagwawasto
inirerekomenda ng patch
Nalutas ba nito ang ugat na sanhi? totoo naman.
regression
nagsusulat ng pagsubok
Bine-verify na nasira ang pagsubok
Paglutas ng Pinag-ugatan, Hindi ang Sintomas
Kadalasan, magmumungkahi ang AI ng patch na mabilis na magpapatahimik sa sintomas: magdagdag ng try/catch, maglagay ng null check, lunukin ang error. Ito ay minsan totoo, kadalasang mapanganib; dahil ang orihinal na dahilan ay nananatili sa lugar at sumabog muli mula sa ibang lugar. Sa bawat pag-aayos, tanungin ang iyong sarili: "Naaayos ba nito ang sanhi ng error, o ginagawa ba itong hindi nakikita?" Kapag nahanap mo na ang ugat, ang pag-aayos ay karaniwang mas maliit, mas matatag at permanente.
Babala: Ang tahimik na paglunok ng exception (empty catch) ay hindi malulutas ang error; ito ay nagtatago lamang at ginagawang imposible ang pagsusuri sa hinaharap. Kung ang AI ay nagmumungkahi ng ganoong "solusyon", huwag tanggapin ito nang hindi tinatanong ang ugat na dahilan.
Mga karaniwang pagkakamali
- Nagtatanong ng walang ebidensya. Ang mga hindi maliwanag na pangungusap ay nagtutulak sa modelo sa guni-guni; Magbigay ng buong error, bakas at input.
- Pag-lock sa unang hypothesis. Ang unang mungkahi ng AI ay maaaring hindi ang pinaka-malamang; Magsimula sa pinakamurang nakokontrol na hypothesis.
- Pag-aayos ng sintomas at nawawala ang ugat na sanhi. Bumalik ang natahimik na error.
- Isinasara ang pag-aayos nang hindi ito bini-verify. Tingnan sa tulad ng produksyon na kondisyon na ang error ay talagang nawawala.
- Hindi sumusulat ng mga pagsusulit sa pagbabalik. Kung walang idinagdag na pagsubok, tahimik na babalik ang parehong error sa mga susunod na bersyon.
Sa buod
Sa pag-debug, ang kapangyarihan ng AI ay direktang proporsyonal sa katibayan na ibinibigay mo dito: nang walang buong mensahe ng error, stack trace, triggering input, at inaasahang pag-uugali, ang modelo ay nag-iisip lamang. Disiplinadong daloy—linawin ang sintomas, mangalap ng ebidensya, bumuo ng hypothesis, sumubok na may pinakamurang kontrol, ayusin ang ugat na sanhi, i-verify, at magdagdag ng pagsusuri sa regression—magsasara ng bug nang mabilis at permanente. Ang AI ay isang hypothesis generator; Ikaw ang magpapasya na ang bug ay talagang nalutas na.
Gawain ng aplikasyon
Pumili ng isang tunay na bug na nakatagpo mo kamakailan (o gumawa ng isang pagsubok na bug). Gawin muna ang "minimum reproduction" na hakbang; Alisin ang pinakamaliit na code at input na nagti-trigger ng error. Pagkatapos ay kumuha ng 3 posibleng dahilan at mga paraan ng pagsubok mula sa AI na may template na "pagbuo ng hypothesis na batay sa ebidensya." Subukan ang pinakamurang hypothesis sa iyong sarili, hanapin ang ugat na sanhi, ayusin ito, at sa wakas ay magsulat ng isang regression test na sasaluhin ang bug na ito sa hinaharap at i-verify na ang pagsubok ay talagang sira.
checklist
- [ ] Binabawasan ko ang error sa pinakamaliit na maaaring kopyahin na sample bago ito ilipat sa AI.
- [ ] Idinaragdag ko ang buong mensahe ng error, stack trace, input at inaasahang pag-uugali sa prompt.
- [ ] Nagsisimula ako sa pinakamurang nakokontrol, nang hindi naka-lock sa isang hypothesis.
- [ ] Bine-verify ko na naresolba ko ang ugat sa halip na i-patch ang sintomas.
- [ ] Napansin ko na ang pag-aayos ay aktwal na nag-aayos ng bug.
- [ ] Nagdaragdag ako ng regression test para sa bawat nalutas na bug.