Sari la conținut

Folosește revizuirea bazată pe IA

Acest ghid îți arată cum să pui agenți recenzori să revizuiască un pull request și cum să publici rezultatul pe GitHub.

  1. Deschide PR-ul și mergi la tab-ul Prezentare
  2. Deschide meniul derulant ⋯ din rândul de acțiuni și alege Întreabă AI

Elementul apare doar cât timp PR-ul este deschis — este o acțiune dinaintea fuziunii. Același buton este oferit ca Întreabă AI în starea goală a tab-ului Revizuire, înainte să existe vreo revizuire.

Control Center pornește pipeline-ul predefinit pr_review și deschide tab-ul Revizuire al PR-ului, ca să îl poți urmări. Pipeline-ul:

  1. Deschide spațiul de revizuire propriu al PR-ului, al cărui worktree izolat are PR-ul extras la ref-ul său de vârf
  2. Distribuie recenzenții pentru nivelul de revizuire al spațiului de lucru — trei implicit (agenții predefiniți qa, architect și engineer, în paralel). Nu există detectare de limbaj sau domeniu
  3. Pune agentul lider (CEO) să le consolideze constatările într-o parcurgere ghidată
  4. Finalizează: sortează constatările în grupe de consens și calculează verdictul. Când asocierea ajunge la awaiting approval, Publică pe GitHub apare în tab-ul Revizuire

Cât de profund merge revizuirea este nivelul de revizuire al spațiului de lucru — light (un recenzent), balanced (trei, implicit) sau thorough (toți cinci, adăugând specialiștii de securitate și performanță) — setat în Setări → Spațiu de lucru → General, pe cardul Politică spațiu de lucru. Un nivel mai ușor înregistrează exact la fel de multe constatări; raportează mai puține dintre ele din start.

Toți recenzenții publică în singurul spațiu de revizuire al PR-ului, ceea ce face constatările lor comparabile. Vezi Revizuire IA pentru cum se leagă piesele.

pr_review vine doar cu un trigger manual. Ca să pornească la fiecare PR publicat, adaugă singur un trigger — vezi Trimite agenți revizori. Poți porni una și chiar din GitHub, fără trigger de pipeline: menționează botul serverului pe PR sau adaugă eticheta ai-review — vezi Vorbește cu Control Center dintr-un PR GitHub.

Dacă o notificare spune că o revizuire rulează deja pentru acest pull request, una este deja în curs; rămâi în tab-ul Revizuire sau deschide Pipeline-uri ca să o găsești.

Recenzenții înregistrează constatările ca noduri de revizuire în spațiul de revizuire. Fiecare conține:

Câmp Descriere
Tip bug, suggestion, recommendation, question sau ticket
Prioritate P0 (critic) → P3 (minor)
Categorie security, stability, data_integrity, correctness, performance sau maintainability
Fișier și linie Unde este ancorată constatarea
Cod original Codul la care se referă constatarea
Cod sugerat Remedierea propusă
Încredere Cât de sigur este recenzentul
Stare open → consensus-ready → resolved sau dismissed

O constatare ajunge la consensus-ready doar când un recenzent coleg o confirmă. Un agent nu își poate confirma propria constatare, așa că opinia unui singur recenzent nu avansează niciodată de una singură.

Tab-ul Revizuire afișează lista de constatări, filtrabilă după tip și stare, cu o comutare pentru constatările respinse, lângă artefactul publicat de agentul care consolidează. Vederea deterministă — cohorte, tabloul de bord cu mai multe axe, diff-urile de contract și vizuale — este calculată pe server, dar nu are nicio suprafață în aplicație; vezi Calculul revizuirii pentru ce produce trecerea.

Când doi recenzenți ancorează constatări la același fișier și aceeași linie, dar le notează foarte diferit — priorități la două sau mai multe niveluri distanță sau unul o numește bug în timp ce celălalt o numește suggestion — un panou de dezacorduri apare deasupra listei de constatări. Citește-le pe acelea mai întâi: acolo diverg opiniile recenzenților și acolo judecata ta valorează cel mai mult.

Când agentul lider finalizează, calculează un verdict:

Verdict Semnificație
Ship Nu s-a găsit nimic blocant
Hold Probleme care ar trebui rezolvate înainte de fuziune
Block Probleme critice care trebuie reparate

Verdictul poartă un scor de încredere agregat și numărători de constatări per prioritate.

Axele revizuirii se adaugă apoi la el și îl pot face doar mai sever. O axă cu poartă care eșuează forțează Block; o axă cu poartă care nu a putut fi finalizată (partial) sau nu a putut rula deloc (unavailable) forțează cel puțin Hold. Absența dovezilor nu trece niciodată o poartă.

Publicarea este un pas separat, condiționat în mod deliberat de utilizator. Pipeline-ul pr_review păstrează revizuirea în Control Center; nu o postează pe GitHub.

  1. În tab-ul Revizuire, așteaptă până când apare Publică pe GitHub
  2. Apasă Publică pe GitHub

Control Center trimite o singură revizuire GitHub. Constatările deja rezolvate sau respinse sunt sărite. Butonul include fiecare constatare deschisă rămasă și, la Ship, trimite APPROVE. (Instrumentul MCP publish_review_to_github folosește în continuare implicit doar constatările confirmate de colegi și nu aprobă decât dacă transmiți approve_on_ship.) Cele care poartă o ancoră de fișier și linie devin comentarii inline; tot restul se pliază în corpul rezumatului, fiecare cu un subsol “— Control Center AI review”, astfel încât sursa este neechivocă. Un verdict Block este trimis ca REQUEST_CHANGES; Hold ca COMMENT; Ship ca APPROVE din acest buton. O notificare afișează apoi Publicat. Revizuirea este postată sub identitatea de aplicație a serverului.

Dacă GitHub respinge o ancoră inline pentru că linia nu face parte din diff, întreaga revizuire este retrimisă cu fiecare constatare pliată în corp, astfel încât nimic nu este eliminat în tăcere.

Alte pipeline-uri integrate postează direct pe GitHub: cross_review, pr_triage, ticket_to_pr și pre_merge_gate se termină fiecare cu un pas de comentariu. Doar pr_review își ține rezultatul înapoi pentru tine.

Pentru control asupra rolurilor care revizuiesc PR-ul și asupra fișierelor la care se uită fiecare, folosește instrumentul MCP dispatch_reviewers într-un spațiu de revizuire existent sau adaugă noduri de recenzent într-un pipeline. Ambele căi, cu semnătura exactă a instrumentului, sunt în Trimite agenți revizori.