Dùng đánh giá hỗ trợ AI

Hướng dẫn này chỉ cho bạn cách để các agent đánh giá xem xét một pull request và cách xuất bản kết quả lên GitHub.

Bắt đầu một lượt đánh giá AI

Mở PR và chuyển đến tab Tổng quan của nó
Mở menu tràn ⋯ trong hàng hành động và chọn Hỏi AI

Mục này chỉ xuất hiện khi PR còn mở — đây là một hành động trước khi merge. Nút tương tự cũng có mặt dưới dạng Hỏi AI ở trạng thái rỗng của tab Đánh giá, khi chưa có đánh giá nào.

Control Center khởi động quy trình pr_review có sẵn và mở tab Đánh giá của PR để bạn theo dõi. Quy trình này:

Mở space đánh giá riêng của PR, nơi worktree cách ly đã có PR được checkout tại head của nó
Triển khai những người đánh giá theo mức đánh giá của không gian làm việc — mặc định là ba (các agent qa, architect và engineer được tạo sẵn, chạy song song). Không có bước phát hiện ngôn ngữ hay lĩnh vực nào
Cho agent chủ trì (CEO) hợp nhất các phát hiện của họ thành một bản dẫn dắt
Hoàn tất: phân loại các phát hiện vào các nhóm đồng thuận và tính ra kết luận. Khi liên kết đạt awaiting approval, Xuất bản lên GitHub xuất hiện trên tab Đánh giá

Độ sâu của lượt đánh giá là mức đánh giá của không gian làm việc — light (một người đánh giá), balanced (ba, mặc định) hoặc thorough (cả năm, thêm các chuyên gia bảo mật và hiệu năng) — đặt tại Cài đặt → Không gian làm việc → Chung, trên thẻ Chính sách không gian làm việc. Một mức nhẹ hơn vẫn ghi nhận đủ ngần ấy phát hiện; chỉ là nó báo ít phát hiện hơn ở vị trí nổi bật.

Mọi người đánh giá đều đăng vào một space đánh giá duy nhất của PR, và chính điều đó khiến các phát hiện của họ có thể so sánh được. Xem Đánh giá bằng AI để hiểu cách các mảnh ghép khớp với nhau.

pr_review chỉ đi kèm trình kích hoạt thủ công. Để nó chạy trên mọi PR đã xuất bản, hãy tự thêm một trình kích hoạt — xem Điều phối agent đánh giá. Bạn cũng có thể khởi động một lượt đánh giá ngay từ GitHub, không cần trình kích hoạt quy trình: nhắc đến bot của máy chủ trên PR hoặc thêm nhãn ai-review — xem Nói chuyện với Control Center từ một PR GitHub.

Nếu có thông báo nổi cho biết một đánh giá đang chạy cho pull request này, thì đã có một lượt đang tiến hành; hãy ở lại tab Đánh giá hoặc mở Pipelines để tìm nó.

Đọc các phát hiện

Người đánh giá ghi lại phát hiện dưới dạng node đánh giá trong space đánh giá. Mỗi node mang theo:

Trường	Mô tả
Loại	`bug`, `suggestion`, `recommendation`, `question` hoặc `ticket`
Mức ưu tiên	P0 (nghiêm trọng) → P3 (nhỏ nhặt)
Danh mục	`security`, `stability`, `data_integrity`, `correctness`, `performance` hoặc `maintainability`
Tệp và dòng	Nơi phát hiện được neo vào
Mã gốc	Đoạn mã mà phát hiện nói tới
Mã đề xuất	Bản sửa được đề xuất
Độ tin cậy	Mức độ tin cậy của người đánh giá
Trạng thái	`open` → `consensus-ready` → `resolved` hoặc `dismissed`

Một phát hiện chỉ đạt sẵn sàng đồng thuận khi một người đánh giá ngang hàng xác nhận nó. Một agent không thể xác nhận phát hiện của chính mình, nên ý kiến của một người đánh giá đơn lẻ không bao giờ tự mình được công nhận.

Tab Đánh giá hiển thị danh sách phát hiện, có thể lọc theo loại và trạng thái, kèm một công tắc cho các phát hiện đã bỏ qua, bên cạnh artifact mà agent tổng hợp đã xuất bản. Chế độ xem tất định — các cohort, bảng điều khiển đa trục, diff hợp đồng và diff hình ảnh — được tính ở phía máy chủ nhưng không có bề mặt nào trong ứng dụng; xem Tính toán đánh giá để biết lượt chạy đó tạo ra những gì.

Kiểm tra bảng bất đồng

Khi hai người đánh giá neo phát hiện vào cùng một tệp và dòng nhưng đánh giá chúng rất khác nhau — mức ưu tiên cách nhau từ hai bậc trở lên, hoặc một người gọi đó là bug còn người kia gọi là suggestion — thì một bảng bất đồng xuất hiện phía trên danh sách phát hiện. Hãy đọc những mục đó trước: đây là nơi ý kiến của những người đánh giá rẽ khác nhau và phán đoán của bạn có giá trị nhất.

Đọc kết luận

Khi agent chủ trì hoàn tất, nó tính ra một kết luận:

Kết luận	Ý nghĩa
Ship	Không tìm thấy điều gì chặn merge
Hold	Có vấn đề cần xử lý trước khi merge
Block	Có vấn đề nghiêm trọng buộc phải sửa

Kết luận mang theo điểm tin cậy tổng hợp và số lượng phát hiện theo từng mức ưu tiên.

Sau đó các trục đánh giá được gộp vào kết luận và chúng chỉ có thể khiến nó nghiêm trọng hơn. Một trục có cổng mà thất bại sẽ buộc Block; một trục có cổng không thể hoàn tất (partial) hoặc hoàn toàn không chạy được (unavailable) buộc ít nhất là Hold. Thiếu bằng chứng không bao giờ mở được một cổng.

Xuất bản đánh giá lên GitHub

Xuất bản là một bước riêng, được đặt sau cổng kiểm soát của người dùng một cách có chủ đích. Quy trình pr_review giữ đánh giá lại trong Control Center; nó không đăng lên GitHub.

Trên tab Đánh giá, chờ cho đến khi Xuất bản lên GitHub xuất hiện
Nhấn Xuất bản lên GitHub

Control Center gửi một đánh giá GitHub duy nhất. Những phát hiện đã được giải quyết hoặc đã bỏ qua sẽ bị bỏ qua. Nút này bao gồm mọi phát hiện đang mở còn lại và, khi Ship, gửi APPROVE. (Công cụ MCP publish_review_to_github vẫn mặc định chỉ dùng các phát hiện đã được xác nhận ngang hàng và không phê duyệt trừ khi bạn truyền approve_on_ship.) Những phát hiện có neo tệp và dòng sẽ trở thành bình luận nội tuyến; mọi thứ còn lại được gộp vào phần thân tóm tắt, mỗi mục kèm một chân trang “— Control Center AI review” để nguồn gốc rõ ràng. Một kết luận Block được gửi dưới dạng REQUEST_CHANGES; Hold là COMMENT; Ship là APPROVE từ nút này. Sau đó một thông báo nổi hiện Đã xuất bản. Đánh giá được đăng dưới danh tính ứng dụng của máy chủ.

Nếu GitHub từ chối một neo nội tuyến vì dòng đó không thuộc diff, toàn bộ đánh giá sẽ được gửi lại với mọi phát hiện được gộp vào phần thân, để không có gì bị lặng lẽ bỏ mất.

Các quy trình tích hợp sẵn khác thì đăng thẳng lên GitHub: cross_review, pr_triage, ticket_to_pr và pre_merge_gate đều kết thúc bằng một bước bình luận. Chỉ riêng pr_review giữ kết quả lại cho bạn.

Tự điều phối người đánh giá

Để kiểm soát vai trò nào đánh giá PR và mỗi vai trò xem những tệp nào, hãy dùng công cụ MCP dispatch_reviewers bên trong một space đánh giá sẵn có, hoặc thêm node đánh giá vào một quy trình. Cả hai cách, kèm chữ ký chính xác của công cụ, đều có trong Điều phối agent đánh giá.