Semakan AI

Bentuk satu semakan

Semakan AI ialah satu larian pipeline pr_review bawaan terhadap satu pull request yang terbuka. Pipeline itu membuka ruang semakan PR berkenaan, menyebarkan ejen penyemak untuk membaca diff dalam checkout terasing ruang tersebut, masing-masing mencatat penemuannya sebagai nod semakan berstruktur, seorang ejen ketua mengkonsolidasikannya menjadi penerangan berpandu, dan pengakhir mengira satu keputusan: Ship, Hold atau Block. Apa yang tidak pernah dilakukan oleh pipeline ialah menerbitkan — menyiarkan ke GitHub ialah langkah berasingan yang disengajakan, yang dilakukan oleh manusia.

Selebihnya halaman ini menerangkan bahagian-bahagiannya dan mengapa ia dibentuk sebegini.

Satu ruang semakan bagi setiap PR

Konteks semakan sesuatu PR ialah ruang pemesejan — modus review, jenis pr — yang dipautkan kepada pull request itu oleh perkaitan ruang semakan. Ia dicipta secara idempoten: halaman PR, pipeline semakan dan permukaan sembang semuanya menyelesaikan satu ruang penyokong PR itu melalui laluan kod yang sama, jadi templat yang menyemak sesuatu PR dan manusia yang membukanya tidak akan pernah berakhir di dua bilik berbeza sambil melihat dua checkout berbeza.

Worktree terasing ruang itu mempunyai PR yang di-checkout pada ref head-nya. Satu bilik juga bermakna satu checkout: setiap penyemak bekerja dalam ruang yang sama dan bukan masing-masing mendapat klon ruang kerjanya sendiri.

Setiap penyemak menyiarkan ke strim bernamanya sendiri di dalam satu ruang itu, dan penemuan ialah mesej review_node dan bukan prosa biasa. Pengumpulan seluruh ruang pada akhirnya bersifat sengaja — keputusan yang dikira daripada penemuan satu utas akan secara senyap menjadi keputusan tentang seorang penyemak sahaja.

Perkaitan itu membawa tangga status — requested → in progress → awaiting approval → completed — dan itulah yang mengawal Terbitkan ke GitHub pada tab Semakan PR berkenaan.

Tahap semakan

Sejauh mana sesuatu semakan pergi ialah polisi ruang kerja dengan tiga tahap, yang ditetapkan di Tetapan → Ruang kerja → Umum, pada kad Polisi ruang kerja:

Tahap	Penyemak yang disebar	Pelaporan
light	Jurutera sahaja	Hanya apa yang benar-benar penting
balanced	Jurutera, QA, arkitek (lalai)	Pemeriksaan tetap
thorough	Kelima-limanya, termasuk keselamatan dan prestasi	Tiada yang diturunkan

Tahap itu menggerakkan dua dail sekali gus: penyemak mana yang disebar, yang dikuatkuasakan oleh pintu keadaan runWhen templat pipeline dan bukan oleh rumusan prompt — rumusan prompt boleh diabaikan, pintu tidak — dan di mana penemuan bawah ambang dipaparkan. Kedua-dua dail itu tidak pernah memadam penemuan: tahap yang melaporkan lebih sedikit tetap mencatat sebanyak yang sama dan mengelompokkan selebihnya.

Pemeriksaan keselamatan dan prestasi menggunakan semula ejen arkitek dan jurutera bawaan dan bukan memperkenalkan ejen baharu. Kepakaran itu terletak pada taklimat yang dibawa penyemak semasa dihantar, bukan pada ejen berasingan bagi setiap paksi — satu ejen bagi setiap paksi bermakna lima baris tambahan dalam setiap ruang kerja tanpa keupayaan tambahan. Pemilihan penyemak tidak pernah memeriksa diff dari segi bahasa atau domain.

Nod semakan: penemuan sebagai data, bukan prosa

Penemuan yang dicatat dengan add_review_node menjadi nod semakan pada PR — inilah yang dipaparkan oleh tab Semakan, yang menjadi asas pengiraan keputusan, dan yang diubah oleh “Terbitkan ke GitHub” menjadi komen sebaris. Penyemak yang hanya mengembalikan prosa menghasilkan larian pipeline yang kelihatan berjaya dan permukaan semakan yang kosong; pencatatan itulah bahagian yang menanggung beban.

Setiap nod membawa:

Medan	Nilai
Jenis	bug, suggestion, recommendation, question, ticket
Keutamaan	P0 (kritikal) → P3 (perkara kecil)
Tiga serangkai triaj	kategori (security, stability, …), keterukan, usaha
Sauh	Laluan fail, baris mula dan akhir
Pembawaan pembetulan	Baris penggantian yang dicadangkan, diff pilihan, prompt pembetulan pilihan
Keyakinan	Skor [0, 1]
Penaakulan	Analisis, yang ditulis sebelum penemuan

Dua perincian bersifat sengaja. Cadangan GitHub sekali klik hanya ditawarkan apabila penyemak menyediakan baris penggantian yang tepat — menyimpulkannya daripada diff bersatu akan tersilap secara senyap, dan commit sekali klik daripada simpulan yang salah lebih buruk daripada tiada butang langsung. Dan skema add_review_node meletakkan reasoning sebelum penemuan, jadi model yang mengisi objek mengikut urutan skema akan menulis analisis dahulu. Medan itu pilihan: meninggalkannya tidak menolak nod berkenaan. Nod yang muatannya cacat akan hilang dan bukan mencemarkan semakan.

Konsensus rakan sebaya

Sesuatu nod bergerak melalui open → consensus-ready → resolved atau dismissed. Langkah tengah itu ialah nadi model ini: sesuatu penemuan hanya naik taraf apabila penyemak rakan sebaya mengesahkannya, dan ejen tidak pernah boleh mengesahkan penemuannya sendiri. Alat MCP publish_review_to_github dan nilai lalai RPC masih menerbitkan penemuan yang disahkan rakan sebaya sahaja. Sebaliknya, butang Terbitkan ke GitHub pada tab Semakan menghantar setiap penemuan terbuka yang tinggal.

Peraturan itu dikuatkuasakan di tiga tempat yang bebas — alat pengesahan, pengakhir dan penerbit — jadi ia bertahan walaupun terdapat pemanggil bermasalah di mana-mana satu daripadanya. Semua perubahan status melalui satu perkhidmatan, dan itulah yang menjadikan sesuatu status bermakna: sebelum itu, dua laluan separuh boleh berselisih tentang sama ada penemuan yang sama telah diselesaikan.

Apabila penyemak berselisih — fail dan baris yang sama, keutamaan yang terpisah dua tahap atau lebih, atau seorang menyebutnya bug manakala yang lain menyebutnya suggestion — perselisihan itu dipaparkan di atas senarai penemuan. Di situlah pendapat penyemak menyimpang dan pertimbangan manusia paling bernilai.

Menutup sesuatu penemuan juga menulis fakta penindasan lembut ke dalam domain memori, pada keyakinan rendah — satu penutupan ialah keutamaan, bukan peraturan.

Kohort: asas pengelompokan semakan

Laluan pengiraan semakan mengelompokkan fail yang berubah dalam sesuatu PR kepada kohort yang diterbitkan daripada graf kod: fail yang berubah dipetakan kepada simbol yang disentuhnya, simbol kepada komponen yang bersambung, dan kohort itu disusun mengikut jejari letupan. Sesuatu kohort membawa urutan bacaan berpandu, gambar rajah dan cerapan, bukan sekadar senarai fail yang rata.

Dua peraturan kejujuran membentuk perkara ini. Kunci kohort diterbitkan daripada kandungan dan stabil merentas push, jadi penemuan dan kemajuan semakan bertahan melalui rebase atau force-push dan bukan menjadi yatim. Dan apabila repo tiada indeks kod, pengelompokan kembali kepada laluan biasa dan menyatakannya — perlakuan sandaran itu tidak pernah memalsukan keyakinan semantik.

Paksi dan pintu semakan

Di samping penemuan penyemak, sesuatu semakan mengumpul hasil paksi: enam paksi, daripada dua jenis.

Paksi	Jenis	Diambil daripada
correctness, security	Dipacu token	Penemuan penyemak sendiri
testGap	Dipacu token	Penemuan penyemak
visual, apiContract	Deterministik	Dikira tanpa membelanjakan token
performance	Deterministik	Hanya enum — tiada apa-apa dalam produk yang mengira hasilnya

Keputusan paksi ialah pass, warn, fail, partial atau unavailable — dan hanya pass atau warn yang melepasi pintu. Perbezaan antara fail, partial dan unavailable amat menentukan: paksi berpintu yang tidak dapat diselesaikan atau tidak dapat dijalankan langsung menahan keputusan keseluruhan dan bukan meloloskannya. Ketiadaan bukti tidak pernah bertukar menjadi pintu hijau.

Sesetengah paksi bersifat nasihat dengan sengaja. Paksi jurang ujian yang diterbitkan daripada kohort tidak dapat melihat liputan suntikan kebergantungan atau factory — repo tanpa indeks dengan suite menyeluruh dan repo tanpa ujian langsung kelihatan serupa dari situ, jadi mendakwa salah satu daripadanya ialah satu pembohongan; ia muncul dalam papan pemuka tanpa mengawal keputusan. Paksi token bersifat nasihat kerana keutamaan penemuan sudah menentukan keputusan, dan mengawal semula berdasarkan paksi itu akan mengira dua kali.

Keputusan

Pengakhir mengira keputusan berdasarkan penemuan yang berstatus open atau consensus-ready:

• sebarang penemuan P0 dengan keyakinan ≥ 0.7 → Block
• jika tidak, sebarang P0 (keyakinan rendah) atau sebarang P1 → Hold
• jika tidak → Ship

Keputusan itu membawa keyakinan agregat yang diterbitkan daripada sebaran keyakinan yang menyumbang — persetujuan menaikkannya, perbezaan menurunkannya.

Konsolidasi ejen ketua (CEO) ialah satu laluan editorial, bukan penyenaraian semula: salinan kedua penemuan yang ditulis dengan tangan itulah yang akan menyimpang daripada yang sebenar. Penemuan pendua diturunkan pangkat dan bukan diulang — beberapa penyemak diarahkan kepada satu diff dengan bidang tugas yang sengaja bertindih, jadi kecacatan yang sama sampai kepada pengakhir tiga kali bermakna sistem berfungsi; menerbitkannya tiga kali bermakna sistem membocorkan seni bina sendiri ke dalam peti masuk pembaca. Pada semakan semula, penemuan dijejak cap jari dan di-diff terhadap pusingan sebelumnya, jadi perbezaan itulah yang muncul ke permukaan.

Akhirnya paksi dilipat masuk, dan ia hanya boleh menjadikan keputusan lebih berat: paksi gagal yang berpintu memaksa Block — ia tidak boleh dikalahkan melalui undian penemuan — dan paksi berpintu yang tidak dapat diselesaikan memaksa sekurang-kurangnya Hold.

Penerbitan kekal di tangan anda

Pipeline sengaja tidak menyiarkan ke GitHub; penerbitan dikawal oleh pengguna supaya sesuatu semakan tidak pernah diterbitkan dua kali. Apabila anda menekan Terbitkan ke GitHub:

• Satu semakan GitHub diserahkan. Penemuan yang sudah diselesaikan atau ditutup dilangkau. Butang itu menerbitkan setiap penemuan terbuka yang tinggal (selection: all_open). Alat MCP publish_review_to_github masih secara lalai hanya menerbitkan penemuan yang disahkan rakan sebaya (consensus).
• Penemuan yang bersauh pada fail dan baris menjadi komen sebaris; semua yang lain dilipat ke dalam badan ringkasan, masing-masing membawa pengaki “— Control Center AI review” supaya sumbernya tidak kabur.
• Sauh disemak semula terhadap diff semasa PR pada masa penerbitan. Komen pada kod yang sudah ditulis semula ialah perkara paling merosakkan kepercayaan yang boleh ditinggalkan oleh penyemak; jika GitHub tetap menolak sauh sebaris, seluruh semakan dihantar semula dengan setiap penemuan dilipat ke dalam badan supaya tiada apa-apa digugurkan secara senyap.
• Keputusan Block diserahkan sebagai REQUEST_CHANGES; Hold sebagai COMMENT; Ship sebagai APPROVE daripada butang itu (approve_on_ship: true). Alat MCP membiarkan Ship sebagai COMMENT melainkan anda menghantar approve_on_ship.
• Semakan disiarkan di bawah identiti aplikasi pelayan. Siapa yang menekan Terbitkan direkodkan untuk pintu peranan dan log audit; ia bukan penulis GitHub.

Penerbitan mengisytiharkan kelas tindakan prPublish, jadi titik kawalan guardrail mengawalnya seperti sebarang tindakan yang mengubah keadaan — ia meminta persetujuan secara lalai dan gagal tertutup apabila tiada pelulus disambungkan. Lihat Guardrail.

Apa yang boleh dilakukan oleh penyemak

Ejen penyemak berjalan dalam modus review: kotak pasir baca sahaja dan senarai kebenaran alat yang dikurasi yang merangkumi penemuan, ulasan, tiket dan semakan rakan sebaya — tetapi tiada sebarang pengubahan. Penyemak tidak boleh membaiki kod yang dikritiknya; ia boleh melampirkan pembetulan yang dicadangkan untuk diterapkan oleh manusia. Mesej penolakan modus itu memberitahu ejen yang masih cuba bertindak supaya mengakhiri semakan dan membiarkan pengguna bertindak atas ringkasan yang diterbitkan.

Konsep berkaitan

• Guardrail — enjin polisi yang mengawal penerbitan
• Modus — apa yang diubah oleh modus review bagi ejen
• Pipeline dan automasi — enjin yang menjalankan semakan
• Kitaran hayat penghantaran ejen — dari mana worktree terasing berasal

Panduan berkaitan

• Gunakan semakan berkuasa AI — jalankan semakan dan terbitkannya
• Hantar ejen penyemak — pilih penyemak sendiri
• Pengiraan semakan — kohort, paksi dan diff