Olen tutkinut työkaluja, jotka tekevät koodin tarkistusprosessista sujuvamman, ja löysin äskettäin avoimen lähdekoodin PR-Agentin (ja sen hallitun version, Qodo Mergen). Se on yksi jännittävimmistä lähestymistavoista PR-automaatioon, johon olen viime aikoina törmännyt. Se toimii kuin hyödyllinen komentorivin tekoälyavustaja suoraan Git-palveluntarjoajassasi. Huomioni kiinnittyi sen arkkitehtuuriin ja siihen, miten se käsittelee pyyntöjä. Kuinka se toimii Kun kommentoit /tarkistat tai /kysyt "mikä on tämän muutoksen vaikutus?" pull-pyyntöön, asiakaspalvelija käynnistää älykkään työnkulun: - Digest Request: Se analysoi ensin PR:n koodimuutokset (hunkit) ja ymmärtää antamasi komennon. - Suunnitelma: Pyyntösi perusteella se laatii suunnitelman. Tämä edellyttää token-tietoista pakkausta ja priorisointia, mikä on ratkaisevan tärkeää, jotta voidaan käsitellä suuria PR:itä tehokkaasti ja keskittyä olennaiseen. - Toiminnon valinta: Se ohjaa sitten pyynnön älykkäästi sopivaan erikoistyökaluun. Tämä modulaarinen lähestymistapa on loistava, koska se omistaa erityisen logiikan kuvaamiseen, tarkistamiseen, parannusten ehdottamiseen, kysymyksiin vastaamiseen, asiakirjojen luomiseen ja muuhun. Yleisen PR-kuvauksen (/describe) luomisen lisäksi jotkin komennot ovat uskomattoman tehokkaita päivittäisessä kehittäjätyönkulussa: /review: Tämä antaa säädettävää palautetta, joka ylittää staattisen analyysin. Se voi kommentoida mahdollisia ongelmia ja turvallisuusongelmia ja jopa arvioida ihmisjoukkuetoverilta vaadittavaa tarkistustyötä. /improve: Sen sijaan, että se osoittaisi ongelman, se tarjoaa konkreettisia, sisäisiä koodiehdotuksia, jotka voit hyväksyä suoraan. Tämä vähentää merkittävästi edestakaisin. /ask: Tämä on pelin muuttaja. Voit esittää vapaamuotoisia kysymyksiä PR:stä (esim. "Miksi tämä kirjasto valittiin?" tai "Selitä my_function:n logiikka"). Se käyttää PR:n kontekstia antaakseen sinulle asiaankuuluvan vastauksen. Syvemmät integraatiot: Siinä on myös työkaluja CHANGELOG md -tiedoston (/update_changelog) automaattiseen päivittämiseen, yksikkötestien luomiseen muuttuneille komponenteille (/test) ja jopa palautteen saamiseen epäonnistuneista CI-töistä (/ci_feedback). Se tuntuu askeleelta oikeaan suuntaan tekoälyavusteisessa kehityksessä, vähemmän kehittäjän vaihtamisesta ja enemmän tarkistusprosessin laajentamisesta nopeammaksi ja perusteellisemmaksi. Mikä on sinulle tylsin osa PR-prosessia?