MI-átnézés

Egy átnézés felépítése

Az MI-átnézés a beépített pr_review pipeline egyetlen futása egyetlen nyitott pull requesttel szemben. A pipeline megnyitja a PR átnézési terét, átnéző ügynököket oszt szét, hogy elolvassák a diffet a tér elszigetelt checkoutjában, mindegyikük strukturált átnézési csomópontokként rögzíti a megállapításait, egy vezető ügynök bejárássá konszolidálja ezeket, végül egy véglegesítő kiszámít egyetlen ítéletet: Ship, Hold vagy Block. Amit a pipeline soha nem tesz meg, az a közzététel — a GitHubra posztolás külön, szándékos lépés, amelyet egy ember tesz meg.

Az oldal hátralévő része elmagyarázza az alkotóelemeket, és hogy miért pont így épülnek fel.

PR-enként egy átnézési tér

A PR átnézési kontextusa egy üzenetküldő tér — review mód, pr típus —, amelyet egy átnézési tértársítás kapcsol a pull requesthez. Idempotensen jön létre: a PR oldala, az átnézési pipeline és a csevegőfelületek ugyanazon a kódúton oldják fel a PR egyetlen mögöttes terét, így egy PR-t átnéző sablon és egy azt megnyitó ember soha nem kerülhet két különböző szobába, két különböző checkoutot nézve.

A tér elszigetelt worktree-jében a PR a head refjén van checkoutolva. Az egy szoba egyben egy checkoutot is jelent: minden átnéző ugyanabban a térben dolgozik, ahelyett hogy mindegyik a munkaterület saját klónját kapná.

Minden átnéző a saját elnevezett adatfolyamába posztol azon az egyetlen téren belül, és a megállapítások review_node üzenetek, nem pedig egyszerű próza. A tér szintű összegyűjtés a végén szándékos — az egyetlen szál megállapításaiból számított ítélet csendben egyetlen átnézőről szóló ítélet lenne.

A társítás egy állapotlétrát hordoz — requested → in progress → awaiting approval → completed —, és ez az, ami a Közzététel a GitHubon gombot kapuzza a PR Átnézés fülén.

Átnézési szintek

Az, hogy milyen mélyre megy egy átnézés, egy munkaterület-szabályzat három szinttel, amelyet a Beállítások → Munkaterület → Általános helyen, a Munkaterület-szabályzat kártyán állít be:

Szint	Szétosztott átnézők	Jelentés
light	Csak mérnök	Csak ami érdemben számít
balanced	Mérnök, QA, architekt (az alapértelmezett)	A szokásos kör
thorough	Mind az öt, a biztonságit és a teljesítményit is beleértve	Semmi sem lefokozva

A szint egyszerre két tárcsát mozgat: hogy mely átnézők kerülnek szétosztásra — amit a pipeline-sablon runWhen állapotkapui kényszerítenek ki, nem pedig a prompt szövegezése (a prompt szövegét figyelmen kívül lehet hagyni, egy kaput nem) —, és hogy hol jelennek meg a küszöb alatti megállapítások. Egyik tárcsa sem töröl soha megállapítást: a kevesebbet jelentő szint pontosan ugyanannyit rögzít, és a maradékot csoportosítja.

A biztonsági és teljesítményi vizsgálatok a beépített architekt- és mérnökügynököket használják újra, nem vezetnek be újakat. A szakterület az a megbízás, amellyel az átnézőt kiküldik, nem pedig külön ügynök tengelyenként — egy tengelyenkénti ügynök minden munkaterületen öt további sor lenne, minden többletképesség nélkül. Az átnézők kiválasztása soha nem vizsgálja a diffet nyelv vagy domain szerint.

Átnézési csomópontok: a megállapítások adatként, nem prózaként

Az add_review_node eszközzel rögzített megállapítás átnézési csomóponttá válik a PR-en — ezt rendereli az Átnézés fül, ebből számítjuk ki az ítéletet, és ezt alakítja soron belüli megjegyzéssé a „Közzététel a GitHubon”. Az az átnéző, amelyik csak prózát ad vissza, sikeresnek látszó pipeline-futtatást és üres átnézési felületet eredményez; a rögzítés a lényeg.

Minden csomópont a következőket hordozza:

Mező	Értékek
Típus	bug, suggestion, recommendation, question, ticket
Prioritás	P0 (kritikus) → P3 (apróság)
Triázs-hármas	kategória (security, stability, …), súlyosság, ráfordítás
Horgony	Fájlútvonal, kezdő és záró sor
Javítás hordozása	Javasolt cseresorok, opcionális diff, opcionális javítási prompt
Megbízhatóság	Egy [0, 1] pontszám
Indoklás	Az elemzés, amely a megállapítás előtt íródik

Két részlet szándékos. Egy kattintásos GitHub-javaslatot csak akkor kínálunk fel, ha az átnéző pontos cseresorokat adott meg — ezeket egy unified diffből kikövetkeztetni csendben elromlik, és egy hibás következtetés egy kattintásos commitolása rosszabb, mint ha egyáltalán nincs gomb. Az add_review_node séma pedig a reasoning mezőt a megállapítás előtt mutatja, így az a modell, amely séma szerinti sorrendben tölti ki az objektumot, először az elemzést írja meg. A mező opcionális: a kihagyása nem utasítja el a csomópontot. Az a csomópont, amelynek a hasznos tartalma hibás formátumú, eltűnik, ahelyett hogy beszennyezné az átnézést.

Társi konszenzus

Egy csomópont az open → consensus-ready → resolved vagy dismissed úton halad át. A középső lépés a modell szíve: egy megállapítás csak akkor lép tovább, ha egy társ-átnéző megerősíti, és egy ügynök soha nem erősítheti meg a saját megállapítását. A publish_review_to_github MCP eszköz és az RPC alapértelmezése továbbra is csak a társak által megerősített megállapításokat teszi közzé. Az Átnézés fül Közzététel a GitHubon gombja ezzel szemben minden még nyitott megállapítást elküld.

A szabály három egymástól független helyen érvényesül — a megerősítő eszközben, a véglegesítőben és a közzétevőben —, így túlél egy hibás hívót bármelyikben. Az állapotváltozások mind egyetlen szolgáltatáson keresztül mennek át, és ez az, amitől egy állapot jelent valamit: ez előtt két félig kész útvonal is vitatkozhatott róla, hogy ugyanaz a megállapítás megoldódott-e.

Amikor az átnézők nézeteltérnek — ugyanaz a fájl és sor, legalább két szintnyire eltérő prioritások, vagy az egyik bug-nak, míg a másik suggestion-nek nevezi —, a nézeteltérés a megállapítások listája fölött jelenik meg. Ott térnek el az átnézők véleményei, és ott éri meg a legtöbbet egy ember mérlegelése.

Egy megállapítás elvetése egy puha elnyomási tényt is ír a memóriadomainbe, alacsony megbízhatósággal — egy elvetés preferencia, nem szabály.

Kohorszok: mi köré csoportosul az átnézés

Az átnézési számítási kör a PR módosított fájljait kohorszokba csoportosítja, amelyeket a kódgráfból származtat: a módosított fájlok ahhoz a szimbólumhoz rendelődnek, amelyeket érintenek, a szimbólumok a kapcsolódó komponensekhez, a kohorszokat pedig a változás hatósugara szerint rangsorolja. Egy kohorsz vezetett olvasási sorrendet, diagramokat és betekintéseket hordoz, nem pedig egy lapos fájllistát.

Két őszinteségi szabály alakítja ezt. A kohorszkulcsok tartalom-alapúak és stabilak a push-ok között, így a megállapítások és az átnézési folyamat túlélnek egy rebase-t vagy force-push-t, ahelyett hogy elárvulnának. Ha pedig a repóban nincs kódindex, a csoportosítás egyszerű útvonalakra esik vissza, és ezt ki is mondja — a visszaesés soha nem színlel szemantikai megbízhatóságot.

Átnézési tengelyek és kapuk

Az átnézők megállapításai mellett egy átnézés tengelyeredményeket is gyűjt: hat tengelyt, kétfélét.

Tengely	Típus	Honnan származik
correctness, security	Tokenvezérelt	Az átnézők saját megállapításaiból
testGap	Tokenvezérelt	Az átnézők megállapításaiból
visual, apiContract	Determinisztikus	Tokenek elköltése nélkül számítva
performance	Determinisztikus	Csak enum — a termék nem számít eredményt

Egy tengely ítélete pass, warn, fail, partial vagy unavailable — és csak a pass vagy a warn nyit át egy kaput. A fail, partial és unavailable közti különbség lényeges: a kapuzott tengely, amely nem tudott befejeződni, vagy egyáltalán nem tudott lefutni, visszatartja a végső ítéletet, ahelyett hogy átengedné. A bizonyíték hiánya soha nem alakul zöld kapuvá.

Néhány tengely szándékosan tanácsadó jellegű. A kohorszokból származtatott teszthiány-tengely nem látja a dependency injection vagy factory lefedettséget — egy index nélküli repó alapos tesztekkel és egy tesztek nélküli repó ugyanúgy néz ki onnan, így bármelyik állítása hazugság lenne; az irányítópulton megjelenik, de nem kapuz. A tokenes tengelyek azért tanácsadók, mert a megállapítások prioritásai már vezérlik az ítéletet, és az azokra való újbóli kapuzás duplán számolná.

Az ítélet

A véglegesítő az open vagy consensus-ready állapotú megállapítások fölött számítja ki az ítéletet:

• bármely ≥ 0,7 megbízhatóságú P0 megállapítás → Block
• egyébként bármely P0 (alacsony megbízhatóságú) vagy bármely P1 → Hold
• egyébként → Ship

Az ítélet egy összesített megbízhatóságot hordoz, amelyet a hozzájáruló megbízhatóságok szórásából származtatunk — az egyetértés növeli, a széttartás csökkenti.

A vezető (CEO) ügynök konszolidációja szerkesztői kör, nem újbóli felsorolás: egy kézzel írt második példány a megállapításokról pontosan az, ami eltávolodik az igazitól. Az ismétlődő megállapítások lefokozódnak, nem megismétlődnek — több átnézőt irányítanak ugyanarra a diffre szándékosan átfedő hatáskörrel, így az, hogy ugyanaz a hiba háromszor ér el a véglegesítőig, a rendszer működése; háromszori közzététele viszont az, hogy a rendszer kiszivárogtatja a saját architektúráját az olvasó postaládájába. Ismételt átnézésnél a megállapítások ujjlenyomatot kapnak, és az előző körhöz vetjük őket, így a delta az, ami megjelenik.

Végül behajlanak a tengelyek, és csak súlyosabbá tehetik az ítéletet: egy kapuzott, bukó tengely Blockot kényszerít — a megállapítások nem szavazhatják felül —, és egy kapuzott tengely, amely nem tudott befejeződni, legalább Holdot kényszerít.

A közzététel az Ön kezében marad

A pipeline szándékosan nem posztol a GitHubra; a közzététel felhasználó által kapuzott, így egy átnézés soha nem tehető közzé kétszer. Amikor megnyomja a Közzététel a GitHubon gombot:

• Egy GitHub-átnézés kerül beküldésre. A már megoldott vagy elvetett megállapítások kimaradnak. A gomb minden még nyitott megállapítást közzétesz (selection: all_open). 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 (consensus).
• A fájlhoz és sorhoz horgonyzott megállapítások 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 horgonyokat közzétételkor újra ellenőrizzük a PR aktuális diffjével szemben. Egy hozzászólás olyan kódról, amelyet már újraírtak, a leginkább bizalomromboló dolog, amit egy átnéző hagyhat; ha a GitHub mégis elutasít egy soron belüli horgonyt, a teljes átnézés újraküldésre kerül, minden megállapítást az összefoglalóba hajtva, hogy semmi ne vesszen el csendben.
• A Block ítélet REQUEST_CHANGES-ként, a Hold COMMENT-ként, a Ship APPROVE-ként kerül beküldésre a gombbal (approve_on_ship: true). Az MCP eszköz a Shipet COMMENT-ként hagyja, hacsak nem adja át az approve_on_ship értéket.
• Az átnézés a szerver alkalmazásidentitása alatt kerül közzétételre. Az, hogy ki nyomta meg a Közzétételt, a szerepkör-kapu és az auditnapló számára kerül rögzítésre; ez nem a GitHub szerzője.

A közzététel a prPublish műveletosztályt deklarálja, így a korlátok központi ellenőrzési pontja ugyanúgy kapuzza, mint bármely módosító műveletet — alapértelmezés szerint rákérdez, és nincs csatlakoztatott jóváhagyó esetén elutasítja. Lásd: Korlátok.

Mit tehet egy átnéző

Az átnéző ügynökök review módban futnak: írásvédett homokozó és gondosan válogatott eszköz-engedélyezési lista, amely lefedi a megállapításokat, a hozzászólásokat, a jegyeket és a társ-átnézést — de mindenféle módosítást nem. Az átnéző nem javíthatja ki azt a kódot, amelyet kritizál; csatolhat viszont egy javasolt javítást, amelyet egy ember alkalmaz. A mód elutasító üzenete megmondja az ügynöknek, amelyik mégis cselekedni próbál, hogy fejezze be az átnézést, és hagyja, hogy a felhasználó cselekedjen a közzétett összefoglalón.

Kapcsolódó fogalmak

• Korlátok — a szabályzatmotor, amely a közzétételt kapuzza
• Módok — mit változtat meg a review mód egy ügynöknél
• Pipeline-ok és automatizálás — a motor, amelyen az átnézés fut
• Ügynökindítás életciklusa — honnan származik az elszigetelt worktree

Kapcsolódó útmutatók

• MI-alapú átnézés használata — futtasson egy átnézést, és tegye közzé
• Átnéző ügynökök indítása — válassza ki Ön az átnézőket
• Átnézési számítás — kohorszok, tengelyek és diffek