MI-alapú átnézés használata

Ez az útmutató bemutatja, hogyan végeztethet átnézést átnéző ügynökökkel egy pull requesten, és hogyan teheti közzé az eredményt a GitHubon.

MI-átnézés indítása

Nyissa meg a PR-t, és lépjen az Áttekintés fülére
Nyissa meg a ⋯ túlcsordulásmenüt a műveletsorban, és válassza a Kérdezze az AI-t lehetőséget

A menüpont csak addig jelenik meg, amíg a PR nyitva van — ez egy összefésülés előtti művelet. Ugyanez a gomb Kérdezze az AI-t néven jelenik meg az Átnézés fül üres állapotában, mielőtt még bármilyen átnézés létezne.

A Control Center elindítja az alapból létrehozott pr_review pipeline-t, és megnyitja a PR Átnézés fülét, hogy figyelemmel kísérhesse. A pipeline:

Megnyitja a PR saját átnézési terét, amelynek elszigetelt worktree-jében a PR a head refjén van checkoutolva
Szétosztja az átnézőket a munkaterület átnézési szintje szerint — alapértelmezés szerint hármat (az alapból létrehozott qa, architect és engineer ügynököt, párhuzamosan). Nincs nyelv- vagy domainfelismerés
A vezető (CEO) ügynökkel bejárássá konszolidáltatja a megállapításaikat
Véglegesít: a megállapításokat konszenzuscsoportokba rendezi, és kiszámítja az ítéletet. Amikor a társítás eléri az awaiting approval állapotot, az Átnézés fülön megjelenik a Közzététel a GitHubon

Hogy milyen mélyre megy az átnézés, azt a munkaterület átnézési szintje dönti el — light (egy átnéző), balanced (három, az alapértelmezett) vagy thorough (mind az öt, a biztonsági és teljesítményi szakértőkkel együtt) —, amelyet a Beállítások → Munkaterület → Általános helyen, a Munkaterület-szabályzat kártyán állít be. Egy könnyebb szint pontosan ugyanannyi megállapítást rögzít; kevesebbet jelent belőlük előre.

Minden átnéző a PR egyetlen átnézési terébe posztol, és éppen ez teszi összehasonlíthatóvá a megállapításaikat. Azt, hogy az alkotóelemek hogyan illeszkednek össze, lásd: MI-átnézés.

A pr_review kizárólag kézi eseményindítóval érkezik. Ha azt szeretné, hogy minden közzétett PR-nál lefusson, adjon hozzá saját eseményindítót — lásd: Átnéző ügynökök indítása. Elindíthat egyet magából a GitHubból is, pipeline-eseményindító nélkül: említse meg a szerver botját a PR-en, vagy adja hozzá az ai-review címkét — lásd: Beszélgetés a Control Centerrel GitHub PR-ből.

Ha egy felugró értesítés azt írja, hogy ehhez a pull requesthez már fut egy átnézés, akkor az már úton van; maradjon az Átnézés fülön, vagy nyissa meg a Pipeline-ok oldalt, hogy megkeresse.

A megállapítások elolvasása

Az átnézők átnézési csomópontokként rögzítik a megállapításaikat az átnézési térben. Mindegyikük a következőket hordozza:

Mező	Leírás
Típus	`bug`, `suggestion`, `recommendation`, `question` vagy `ticket`
Prioritás	P0 (kritikus) → P3 (apróság)
Kategória	`security`, `stability`, `data_integrity`, `correctness`, `performance` vagy `maintainability`
Fájl és sor	Hol van horgonyozva a megállapítás
Eredeti kód	A kód, amelyre a megállapítás vonatkozik
Javasolt kód	A javasolt javítás
Megbízhatóság	Mennyire biztos az átnéző
Állapot	`open` → `consensus-ready` → `resolved` vagy `dismissed`

Egy megállapítás csak akkor ér el a consensus-ready állapotba, ha egy társ-átnéző megerősíti. Egy ügynök nem erősítheti meg a saját megállapítását, így egyetlen átnéző véleménye soha nem lép tovább magától.

Az Átnézés fül a megállapítások listáját mutatja, típus és állapot szerint szűrhetően, az elvetett megállapításokhoz tartozó kapcsolóval, a konszolidáló ügynök által közzétett artefaktum mellett. A determinisztikus nézetet — kohorszok, a többtengelyes irányítópult, szerződés- és vizuális diffek — a szerver oldalán számítjuk ki, de az alkalmazásban nincs felülete; arról, hogy mit állít elő a kör, lásd: Átnézési számítás.

A nézeteltérési panel ellenőrzése

Amikor két átnéző ugyanahhoz a fájlhoz és sorhoz horgonyoz megállapításokat, de nagyon eltérően értékeli őket — a prioritások legalább két szintnyire vannak egymástól, vagy az egyik bug-nak, míg a másik suggestion-nek nevezi —, a megállapítások listája fölött egy nézeteltérési panel jelenik meg. Először ezeket olvassa el: itt térnek el az átnézők véleményei, és itt éri meg a legtöbbet az Ön mérlegelése.

Az ítélet elolvasása

Amikor a vezető ügynök véglegesít, kiszámít egy ítéletet:

Ítélet	Jelentés
Ship	Nem találtunk semmit, ami blokkolna
Hold	Az összefésülés előtt kezelendő problémák
Block	Kijavítandó kritikus problémák

Az ítélet egy összesített megbízhatósági pontszámot és prioritásonkénti megállapításszámokat hordoz.

Ezután az átnézési tengelyek is behajlanak az ítéletbe, és csak súlyosabbá tehetik azt. Egy kapuzott tengely, amely megbukik, Blockot kényszerít; egy kapuzott tengely, amely nem tudott befejeződni (partial), vagy egyáltalán nem tudott lefutni (unavailable), legalább Holdot kényszerít. A bizonyíték hiánya soha nem nyit ki egy kaput.

Az átnézés közzététele a GitHubon

A közzététel külön, szándékosan a felhasználó által kapuzott lépés. A pr_review pipeline a Control Centerben tartja az átnézést; nem posztol a GitHubra.

Az Átnézés fülön várja meg, amíg megjelenik a Közzététel a GitHubon
Nyomja meg a Közzététel a GitHubon gombot

A Control Center egyetlen GitHub-átnézést küld. A már megoldott vagy elvetett megállapítások kimaradnak. A gomb minden még nyitott megállapítást tartalmaz, és Ship esetén APPROVE-ot küld. (A publish_review_to_github MCP eszköz továbbra is csak a társak által megerősített megállapításokat veszi alapul, és nem hagy jóvá, hacsak nem adja át az approve_on_ship értéket.) Azok, amelyek fájl- és sorhorgonyt hordoznak, soron belüli megjegyzésekké válnak; minden más az összefoglaló törzsébe hajlik, mindegyik egy „— Control Center AI review” láblécet kap, hogy a forrás egyértelmű legyen. A Block ítélet REQUEST_CHANGES-ként, a Hold COMMENT-ként, a Ship pedig ezzel a gombbal APPROVE-ként kerül beküldésre. Ekkor egy felugró értesítés ezt írja: Közzétéve. Az átnézés a szerver alkalmazásidentitása alatt kerül közzétételre.

Ha a GitHub elutasít egy soron belüli horgonyt, mert a sor nem része a diffnek, a teljes átnézés újraküldésre kerül, minden megállapítást az összefoglaló törzsébe hajtva, hogy semmi ne vesszen el csendben.

Más beépített pipeline-ok közvetlenül posztolnak a GitHubra: a cross_review, a pr_triage, a ticket_to_pr és a pre_merge_gate mind egy hozzászólás-lépéssel zárul. Egyedül a pr_review tartja vissza a kimenetét az Ön számára.

Átnézők indítása saját maga

Ha Ön szeretné kézben tartani, hogy mely szerepkörök nézzék át a PR-t, és melyikük mely fájlokat vizsgálja, használja a dispatch_reviewers MCP eszközt egy meglévő átnézési térben, vagy adjon átnézőcsomópontokat egy pipeline-hoz. Mindkét útvonal, az eszköz pontos szignatúrájával együtt, itt található: Átnéző ügynökök indítása.