Tinjauan AI

Bentuk sebuah tinjauan

Tinjauan AI adalah satu eksekusi pipeline pr_review bawaan terhadap satu pull request yang terbuka. Pipeline membuka space tinjauan milik PR, menyebar agen peninjau untuk membaca diff di checkout terisolasi space tersebut, masing-masing mencatat temuannya sebagai node tinjauan terstruktur, seorang agen pemimpin mengonsolidasikannya menjadi penelusuran terpandu, dan komponen finalisasi menghitung satu putusan: Ship, Hold, atau Block. Yang tidak pernah dilakukan pipeline adalah memublikasikan — memposting ke GitHub adalah langkah terpisah dan disengaja yang dilakukan manusia.

Sisa halaman ini menjelaskan bagian-bagiannya dan mengapa bentuknya seperti ini.

Satu space tinjauan per PR

Konteks tinjauan sebuah PR adalah space perpesanan — mode review, jenis pr — yang ditautkan ke pull request melalui asosiasi space tinjauan. Space ini dibuat secara idempoten: halaman PR, pipeline tinjauan, dan permukaan chat semuanya me-resolve satu space pendukung PR melalui jalur kode yang sama, jadi templat yang meninjau sebuah PR dan manusia yang membukanya tidak akan pernah berakhir di dua ruangan berbeda sambil melihat dua checkout berbeda.

Worktree terisolasi milik space tersebut memuat PR dalam keadaan checkout pada ref head-nya. Satu ruangan juga berarti satu checkout: setiap peninjau bekerja di space yang sama, bukan masing-masing mendapatkan klon ruang kerjanya sendiri.

Setiap peninjau memposting ke stream bernamanya sendiri di dalam satu space itu, dan temuannya berupa pesan review_node, bukan prosa biasa. Pengumpulan seluruh space di akhir bersifat disengaja — putusan yang dihitung dari temuan satu thread saja secara diam-diam adalah putusan tentang satu peninjau.

Asosiasi ini membawa tangga status — requested → in progress → awaiting approval → completed — yang menjadi gerbang bagi Publikasikan ke GitHub pada tab Tinjau di PR.

Tingkat tinjauan

Seberapa dalam sebuah tinjauan berjalan adalah kebijakan ruang kerja dengan tiga tingkat, yang diatur di Pengaturan → Ruang kerja → Umum, pada kartu Kebijakan ruang kerja:

Tingkat	Peninjau yang disebar	Pelaporan
light	Hanya engineer	Hanya yang benar-benar penting
balanced	Engineer, QA, arsitek (bawaan)	Pemeriksaan standar
thorough	Kelima-limanya, termasuk keamanan dan performa	Tidak ada yang diturunkan

Tingkat ini menggerakkan dua tuas sekaligus: peninjau mana yang disebar, yang ditegakkan oleh gerbang status runWhen pada templat pipeline alih-alih oleh rumusan prompt — rumusan prompt bisa diabaikan, gerbang tidak — dan di mana temuan di bawah ambang ditampilkan. Tidak ada dari kedua tuas itu yang pernah menghapus temuan: tingkat yang melaporkan lebih sedikit tetap mencatat sebanyak yang sama dan mengelompokkan sisanya.

Pemeriksaan keamanan dan performa menggunakan kembali agen arsitek dan engineer bawaan alih-alih memperkenalkan agen baru. Spesialisasinya terletak pada arahan yang dibawa peninjau saat dikirim, bukan pada agen terpisah per sumbu — satu agen per sumbu berarti lima baris tambahan di setiap ruang kerja tanpa kemampuan tambahan. Pemilihan peninjau tidak pernah memeriksa diff dari segi bahasa atau domain.

Node tinjauan: temuan sebagai data, bukan prosa

Temuan yang dicatat dengan add_review_node menjadi node tinjauan pada PR — inilah yang dirender oleh tab Tinjau, yang menjadi dasar penghitungan putusan, dan yang diubah oleh “Publikasikan ke GitHub” menjadi komentar inline. Peninjau yang hanya mengembalikan prosa menghasilkan eksekusi pipeline yang tampak berhasil dan permukaan tinjauan yang kosong; pencatatanlah bagian yang menentukan.

Setiap node membawa:

Bidang	Nilai
Jenis	bug, suggestion, recommendation, question, ticket
Prioritas	P0 (kritis) → P3 (sepele)
Triplet triase	kategori (security, stability, …), keparahan, upaya
Anchor	Jalur file, baris awal dan akhir
Pembawaan perbaikan	Baris penggantian yang disarankan, diff opsional, prompt perbaikan opsional
Keyakinan	Skor [0, 1]
Penalaran	Analisis, yang ditulis sebelum temuan

Dua detail bersifat disengaja. Saran GitHub sekali klik hanya ditawarkan jika peninjau menyediakan baris penggantian yang persis — menyimpulkannya dari diff terpadu akan salah secara diam-diam, dan commit sekali klik dari simpulan yang salah lebih buruk daripada tidak ada tombol sama sekali. Lalu skema add_review_node menampilkan reasoning sebelum temuan, sehingga model yang mengisi objek menurut urutan skema akan menulis analisisnya terlebih dahulu. Bidang ini opsional: menghilangkannya tidak menolak node tersebut. Node yang payload-nya cacat akan hilang alih-alih mencemari tinjauan.

Konsensus sesama peninjau

Sebuah node bergerak melalui open → consensus-ready → resolved atau dismissed. Langkah di tengah adalah inti dari model ini: sebuah temuan baru naik kelas ketika peninjau rekan mengonfirmasinya, dan agen tidak akan pernah bisa mengonfirmasi temuannya sendiri. Alat MCP publish_review_to_github dan nilai bawaan RPC tetap hanya memublikasikan temuan yang dikonfirmasi rekan. Sebaliknya, tombol Publikasikan ke GitHub di tab Tinjau mengirimkan setiap temuan terbuka yang tersisa.

Aturan ini ditegakkan di tiga tempat yang independen — alat konfirmasi, komponen finalisasi, dan pemublikasi — sehingga tetap bertahan meskipun ada pemanggil yang bermasalah di salah satunya. Semua perubahan status melewati satu layanan, dan itulah yang membuat sebuah status bermakna: sebelum itu, dua jalur setengah jadi bisa berbeda pendapat tentang apakah temuan yang sama sudah diselesaikan.

Saat para peninjau tidak sepakat — file dan baris yang sama, prioritas yang terpaut dua tingkat atau lebih, atau satu menyebutnya bug sementara yang lain menyebutnya suggestion — ketidaksepakatan itu ditampilkan di atas daftar temuan. Di situlah pendapat para peninjau menyimpang dan penilaian manusia paling bernilai.

Menutup sebuah temuan juga menuliskan fakta penekanan lunak ke domain memori, dengan keyakinan rendah — satu penutupan adalah preferensi, bukan aturan.

Kohort: apa yang mengelompokkan tinjauan

Tahap komputasi tinjauan mengelompokkan file yang berubah pada sebuah PR ke dalam kohort yang diturunkan dari graf kode: file yang berubah dipetakan ke simbol yang disentuhnya, simbol ke komponen yang terhubung, dan kohort diurutkan berdasarkan radius dampak. Sebuah kohort membawa urutan baca terpandu, diagram, dan wawasan, bukan sekadar daftar file yang datar.

Dua aturan kejujuran membentuk hal ini. Kunci kohort diturunkan dari konten dan stabil di antara push, sehingga temuan dan kemajuan tinjauan bertahan melewati rebase atau force-push alih-alih menjadi yatim. Dan ketika repo tidak memiliki indeks kode, pengelompokan kembali ke jalur biasa dan mengatakannya — mekanisme cadangan itu tidak pernah memalsukan keyakinan semantik.

Sumbu tinjauan dan gerbang

Di samping temuan para peninjau, sebuah tinjauan mengakumulasi hasil sumbu: enam sumbu, dari dua jenis.

Sumbu	Jenis	Diambil dari
correctness, security	Berbasis token	Temuan para peninjau sendiri
testGap	Berbasis token	Temuan para peninjau
visual, apiContract	Deterministik	Dihitung tanpa menghabiskan token
performance	Deterministik	Hanya enum — tidak ada apa pun di produk yang menghitung hasilnya

Putusan sumbu adalah pass, warn, fail, partial, atau unavailable — dan hanya pass atau warn yang melewati gerbang. Perbedaan antara fail, partial, dan unavailable sangat menentukan: sumbu bergerbang yang tidak dapat diselesaikan atau tidak dapat dijalankan sama sekali akan menahan putusan keseluruhan alih-alih meloloskannya. Tidak adanya bukti tidak pernah berubah menjadi gerbang hijau.

Beberapa sumbu sengaja bersifat penasihat. Sumbu celah pengujian yang diturunkan dari kohort tidak dapat melihat cakupan injeksi dependensi atau factory — repo tanpa indeks dengan rangkaian pengujian menyeluruh dan repo tanpa pengujian sama sekali terlihat identik dari sana, jadi mengklaim salah satunya adalah kebohongan; sumbu itu muncul di dasbor tanpa menggerbangi. Sumbu token bersifat penasihat karena prioritas temuan sudah menentukan putusan, dan menggerbangi ulang berdasarkan sumbu tersebut akan menghitung ganda.

Putusan

Komponen finalisasi menghitung putusan atas temuan dengan status open atau consensus-ready:

• temuan P0 apa pun dengan keyakinan ≥ 0,7 → Block
• selain itu, P0 mana pun (keyakinan rendah) atau P1 mana pun → Hold
• selain itu → Ship

Putusan ini membawa keyakinan agregat yang diturunkan dari sebaran keyakinan yang berkontribusi — kesepakatan menaikkannya, perbedaan menurunkannya.

Konsolidasi agen pemimpin (CEO) adalah tahap editorial, bukan pendaftaran ulang: salinan kedua temuan yang ditulis dengan tangan justru persis yang akan menyimpang dari yang asli. Temuan duplikat diturunkan statusnya alih-alih diulang — beberapa peninjau diarahkan ke satu diff dengan cakupan yang sengaja tumpang tindih, jadi cacat yang sama mencapai komponen finalisasi tiga kali adalah tanda sistem bekerja; memublikasikannya tiga kali adalah tanda sistem membocorkan arsitekturnya sendiri ke kotak masuk pembaca. Pada tinjauan ulang, temuan dibuatkan sidik jari dan di-diff terhadap putaran sebelumnya, sehingga yang muncul ke permukaan adalah selisihnya.

Akhirnya sumbu-sumbu itu dilipat masuk, dan hanya bisa membuat putusan menjadi lebih berat: sumbu bergerbang yang gagal memaksa Block — sumbu itu tidak bisa dikalahkan lewat suara temuan — dan sumbu bergerbang yang tidak dapat diselesaikan memaksa setidaknya Hold.

Publikasi tetap di tangan Anda

Pipeline sengaja tidak memposting ke GitHub; publikasi dijaga oleh pengguna, sehingga sebuah tinjauan tidak akan pernah terpublikasi dua kali. Saat Anda menekan Publikasikan ke GitHub:

• Satu tinjauan GitHub dikirimkan. Temuan yang sudah diselesaikan atau ditutup dilewati. Tombol ini memublikasikan setiap temuan terbuka yang tersisa (selection: all_open). Alat MCP publish_review_to_github nilai bawaannya tetap hanya temuan yang dikonfirmasi rekan (consensus).
• Temuan yang di-anchor ke file dan baris menjadi komentar inline; sisanya dilipat ke badan ringkasan, masing-masing membawa footer “— Control Center AI review” agar sumbernya tidak ambigu.
• Anchor diverifikasi ulang terhadap diff saat ini milik PR pada waktu publikasi. Komentar pada kode yang sudah ditulis ulang adalah hal paling merusak kepercayaan yang bisa ditinggalkan seorang peninjau; jika GitHub tetap menolak anchor inline, seluruh tinjauan dikirim ulang dengan setiap temuan dilipat ke badan agar tidak ada yang hilang diam-diam.
• Putusan Block dikirim sebagai REQUEST_CHANGES; Hold sebagai COMMENT; Ship sebagai APPROVE dari tombol (approve_on_ship: true). Alat MCP membiarkan Ship sebagai COMMENT kecuali Anda meneruskan approve_on_ship.
• Tinjauan diposting dengan identitas aplikasi milik server. Siapa yang menekan Publikasikan dicatat untuk gerbang peran dan log audit; itu bukan penulis di GitHub.

Publikasi mendeklarasikan kelas tindakan prPublish, sehingga titik pengunci pagar pengaman menggerbanginya seperti tindakan yang mengubah data lainnya — ia meminta persetujuan secara bawaan dan gagal tertutup saat tidak ada pemberi persetujuan yang terhubung. Lihat Pagar pengaman.

Apa yang boleh dilakukan peninjau

Agen peninjau berjalan dalam mode review: sandbox hanya-baca dan daftar izin alat yang dikurasi, mencakup temuan, komentar, tiket, dan peninjauan rekan — tetapi tanpa mutasi. Peninjau tidak bisa memperbaiki kode yang dikritiknya; ia bisa melampirkan saran perbaikan yang diterapkan manusia. Pesan penolakan mode ini memberi tahu agen yang tetap mencoba bertindak untuk menyelesaikan tinjauan dan membiarkan pengguna menindaklanjuti ringkasan yang dipublikasikan.

Konsep terkait

• Pagar pengaman — mesin kebijakan yang menggerbangi publikasi
• Mode — apa yang diubah mode review bagi agen
• Pipeline dan otomatisasi — mesin yang menjalankan tinjauan
• Siklus hidup pengiriman agen — dari mana worktree terisolasi berasal

Panduan terkait

• Gunakan tinjauan bertenaga AI — jalankan tinjauan dan publikasikan
• Kirim agen peninjau — pilih sendiri para peninjau
• Komputasi tinjauan — kohort, sumbu, dan diff