Đánh giá bằng AI

Hình dạng của một lượt đánh giá

Một lượt đánh giá AI là một lần chạy quy trình pr_review có sẵn trên một pull request đang mở. Quy trình mở space đánh giá của PR, triển khai các agent đánh giá để đọc diff trong bản checkout cách ly của space đó, mỗi agent ghi nhận phát hiện của mình dưới dạng node đánh giá có cấu trúc, một agent chủ trì hợp nhất chúng thành một bản dẫn dắt, và bộ hoàn thiện tính ra một kết luận duy nhất: Ship, Hold hoặc Block. Điều quy trình không bao giờ làm là xuất bản — đăng lên GitHub là một bước riêng, có chủ đích, do con người thực hiện.

Phần còn lại của trang này giải thích các thành phần và lý do chúng được định hình như vậy.

Mỗi PR một space đánh giá

Ngữ cảnh đánh giá của một PR là một space nhắn tin — chế độ review, loại pr — được nối với pull request bằng một liên kết space đánh giá. Space được tạo theo cách idempotent: trang PR, quy trình đánh giá và các bề mặt chat đều phân giải một space nền tảng của PR qua cùng một đường mã, nên một mẫu đánh giá PR và một người mở nó không bao giờ có thể rơi vào hai phòng khác nhau mà nhìn hai bản checkout khác nhau.

Worktree cách ly của space có PR được checkout tại head ref của nó. Một phòng cũng có nghĩa là một bản checkout: mọi người đánh giá làm việc trong cùng một space thay vì mỗi người nhận một bản sao riêng của không gian làm việc.

Mỗi người đánh giá đăng vào luồng có tên riêng của mình trong space duy nhất đó, và các phát hiện là thông điệp review_node chứ không phải văn xuôi đơn thuần. Việc gom toàn space ở cuối là có chủ đích — một kết luận tính từ phát hiện của một luồng sẽ âm thầm trở thành kết luận về một người đánh giá.

Liên kết này mang một thang trạng thái — requested → in progress → awaiting approval → completed — chính là thứ kiểm soát nút Xuất bản lên GitHub trên tab Đánh giá của PR.

Mức đánh giá

Độ sâu của một lượt đánh giá là một chính sách không gian làm việc với ba mức, đặ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ức	Các agent đánh giá được triển khai	Phạm vi báo cáo
light	Chỉ kỹ sư	Chỉ những gì thực sự quan trọng
balanced	Kỹ sư, QA, kiến trúc sư (mặc định)	Lượt đánh giá tiêu chuẩn
thorough	Cả năm, gồm bảo mật và hiệu năng	Không hạ mức phát hiện nào

Mức này điều khiển hai núm cùng lúc: những người đánh giá nào được triển khai, được thi hành bằng cổng trạng thái runWhen của mẫu quy trình chứ không phải bằng câu chữ trong prompt — câu chữ trong prompt có thể bị bỏ qua, còn cổng thì không — và nơi các phát hiện dưới ngưỡng được hiển thị. Không núm nào xóa phát hiện: một mức báo cáo ít hơn vẫn ghi nhận đúng ngần ấy phát hiện rồi gom phần còn lại.

Các lượt kiểm tra bảo mật và hiệu năng tái dùng chính các agent kiến trúc sư và kỹ sư có sẵn thay vì thêm agent mới. Tính chuyên biệt nằm ở bản giao việc mà người đánh giá nhận được, không phải một agent riêng cho mỗi trục — một agent cho mỗi trục sẽ là thêm năm dòng trong mọi không gian làm việc mà chẳng thêm năng lực nào. Việc chọn người đánh giá không bao giờ soi diff để tìm ngôn ngữ hay lĩnh vực.

Node đánh giá: phát hiện là dữ liệu, không phải văn xuôi

Một phát hiện được ghi bằng add_review_node trở thành một node đánh giá trên PR — đây là thứ tab Đánh giá hiển thị, là thứ mà kết luận được tính từ đó, và là thứ mà “Xuất bản lên GitHub” biến thành bình luận nội tuyến. Một người đánh giá chỉ trả về văn xuôi sẽ tạo ra một lần chạy quy trình trông thì thành công và một bề mặt đánh giá trống rỗng; việc ghi nhận mới là phần chịu lực.

Mỗi node mang:

Trường	Giá trị
Loại	bug, suggestion, recommendation, question, ticket
Mức ưu tiên	P0 (nghiêm trọng) → P3 (nhỏ nhặt)
Bộ ba phân loại	danh mục (security, stability, …), mức độ nghiêm trọng, công sức
Điểm neo	Đường dẫn tệp, dòng bắt đầu và kết thúc
Bản sửa kèm theo	Các dòng thay thế được đề xuất, một diff tùy chọn, một prompt sửa tùy chọn
Độ tin cậy	Điểm trong [0, 1]
Lập luận	Phần phân tích, được viết trước phát hiện

Hai chi tiết là có chủ đích. Gợi ý GitHub một cú nhấp chỉ được đưa ra khi người đánh giá cung cấp các dòng thay thế chính xác — suy ra chúng từ một diff hợp nhất sẽ sai một cách âm thầm, và một cú nhấp commit một suy luận sai còn tệ hơn là không có nút nào. Và lược đồ add_review_node trình bày reasoning trước phát hiện, nên một mô hình điền đối tượng theo thứ tự lược đồ sẽ viết phần phân tích trước. Trường này là tùy chọn: bỏ qua nó không làm node bị từ chối. Một node có payload sai định dạng sẽ biến mất thay vì làm bẩn lượt đánh giá.

Đồng thuận ngang hàng

Một node đi qua open → consensus-ready → resolved hoặc dismissed. Bước giữa là trái tim của mô hình: một phát hiện chỉ được nâng cấp khi một người đánh giá ngang hàng xác nhận nó, và một agent không bao giờ có thể xác nhận phát hiện của chính mình. Công cụ MCP publish_review_to_github và mặc định của RPC vẫn chỉ xuất bản các phát hiện đã được xác nhận ngang hàng. Nút Xuất bản lên GitHub trên tab Đánh giá thì gửi mọi phát hiện đang mở còn lại.

Quy tắc được thi hành ở ba nơi độc lập — công cụ xác nhận, bộ hoàn thiện và bộ xuất bản — nên nó vẫn đứng vững dù một trong số đó có lỗi. Mọi thay đổi trạng thái đều đi qua một dịch vụ duy nhất, và đó là điều khiến một trạng thái có ý nghĩa: trước đó, hai nửa đường đi có thể bất đồng về việc cùng một phát hiện đã được xử lý hay chưa.

Khi những người đánh giá bất đồng — cùng tệp và dòng, mức ưu tiên lệ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 — sự bất đồng được đưa lên trên danh sách phát hiện. Đó là nơi ý kiến của những người đánh giá rẽ khác nhau và phán đoán của con người có giá trị nhất.

Bỏ qua một phát hiện cũng ghi một dữ kiện ức chế mềm vào miền bộ nhớ, ở độ tin cậy thấp — một lần bỏ qua là một sở thích, không phải một quy tắc.

Cohort: thứ mà lượt đánh giá được gom quanh

Lượt tính toán đánh giá gom các tệp đã đổi của một PR thành các cohort suy ra từ đồ thị mã: tệp đã đổi ánh xạ tới các ký hiệu mà chúng chạm tới, ký hiệu tới các thành phần được nối, và các cohort được xếp hạng theo phạm vi ảnh hưởng. Mỗi cohort mang một thứ tự đọc có dẫn dắt, sơ đồ và thông tin chi tiết chứ không phải một danh sách tệp phẳng.

Hai quy tắc trung thực định hình điều này. Khóa cohort được suy ra từ nội dung và ổn định qua các lần push, nên phát hiện và tiến độ đánh giá sống sót qua một lần rebase hay force-push thay vì bị mồ côi. Và khi kho mã chưa có chỉ mục mã, việc gom nhóm lùi về đường dẫn thuần và nói rõ điều đó — đường lùi không bao giờ giả tạo sự tự tin ngữ nghĩa.

Trục đánh giá và cổng

Song song với phát hiện của những người đánh giá, một lượt đánh giá tích lũy kết quả trục: sáu trục, thuộc hai loại.

Trục	Loại	Lấy từ
correctness, security	Dùng token	Phát hiện của chính những người đánh giá
testGap	Dùng token	Phát hiện của những người đánh giá
visual, apiContract	Tất định	Được tính mà không tốn token
performance	Tất định	Chỉ có enum — không gì trong sản phẩm tính ra kết quả

Kết luận của một trục là pass, warn, fail, partial hoặc unavailable — và chỉ pass hoặc warn mới mở được cổng. Sự khác biệt giữa fail, partial và unavailable là phần chịu lực: một trục có cổng nhưng không thể hoàn tất hoặc hoàn toàn không chạy được sẽ giữ kết luận tổng lại thay vì cho qua. Thiếu bằng chứng không bao giờ biến thành một cổng xanh.

Một số trục cố ý chỉ mang tính tham khảo. Trục khoảng trống kiểm thử suy ra từ cohort không thể thấy được mức bao phủ của dependency injection hay factory — một kho mã chưa được lập chỉ mục có bộ kiểm thử kỹ lưỡng và một kho mã không có kiểm thử nào trông giống hệt nhau từ đó, nên khẳng định bên nào cũng sẽ là nói dối; trục này hiện trên bảng điều khiển mà không chặn cổng. Các trục dùng token chỉ mang tính tham khảo vì mức ưu tiên của phát hiện đã dẫn dắt kết luận, và đặt cổng lại dựa trên chúng sẽ là tính trùng hai lần.

Kết luận

Bộ hoàn thiện tính kết luận dựa trên các phát hiện có trạng thái open hoặc consensus-ready:

• phát hiện P0 nào có độ tin cậy ≥ 0.7 → Block
• nếu không, bất kỳ P0 (độ tin cậy thấp) hoặc bất kỳ P1 nào → Hold
• còn lại → Ship

Kết luận mang một độ tin cậy tổng hợp suy ra từ độ phân tán của các độ tin cậy góp phần — đồng thuận làm tăng nó, khác biệt làm giảm nó.

Việc hợp nhất của agent chủ trì (CEO) là một lượt biên tập, không phải liệt kê lại: một bản sao thứ hai do tay người viết chính là thứ lệch khỏi bản thật. Các phát hiện trùng lặp bị hạ mức thay vì lặp lại — nhiều người đánh giá cùng được trỏ vào một diff với phạm vi phụ trách cố ý chồng lấn, nên cùng một khiếm khuyết đến tay bộ hoàn thiện ba lần nghĩa là hệ thống đang chạy đúng; xuất bản nó ba lần mới là hệ thống đang rò rỉ kiến trúc của chính nó vào hộp thư của người đọc. Ở một lượt đánh giá lại, các phát hiện được lấy dấu vân tay và đối chiếu khác biệt với vòng trước, nên phần chênh lệch mới là thứ hiện ra.

Cuối cùng các trục được gộp vào, và chúng chỉ có thể khiến kết luận nghiêm trọng hơn: một trục có cổng bị lỗi buộc phải Block — nó không thể bị các phát hiện ghi đè — và một trục có cổng không thể hoàn tất buộc ít nhất là Hold.

Xuất bản vẫn thuộc về bạn

Quy trình cố ý không đăng lên GitHub; việc xuất bản do người dùng quyết định để một lượt đánh giá không bao giờ xuất bản trùng. Khi bạn nhấn Xuất bản lên GitHub:

• Một lượt đánh giá GitHub được gửi đi. Các phát hiện đã được xử lý hoặc bỏ qua sẽ bị bỏ qua. Nút này xuất bản mọi phát hiện đang mở còn lại (selection: all_open). Công cụ MCP publish_review_to_github vẫn mặc định chỉ với các phát hiện đã được xác nhận ngang hàng (consensus).
• Các phát hiện neo vào một tệp và dòng trở thành bình luận nội tuyến; mọi thứ khác gộp vào phần thân tóm tắt, mỗi mục mang một chân trang “— Control Center AI review” để nguồn không còn mơ hồ.
• Các điểm neo được xác minh lại dựa trên diff hiện tại của PR vào lúc xuất bản. Một bình luận trên đoạn mã đã bị viết lại là thứ phá hủy lòng tin mạnh nhất mà một người đánh giá có thể để lại; nếu GitHub vẫn từ chối một điểm neo nội tuyến, toàn bộ lượt đánh giá sẽ được gửi lại với mọi phát hiện gộp vào phần thân để không thứ gì bị âm thầm bỏ đi.
• Kết luận Block được gửi dưới dạng REQUEST_CHANGES; Hold là COMMENT; Ship là APPROVE khi bấm nút (approve_on_ship: true). Công cụ MCP để Ship là COMMENT trừ khi bạn truyền approve_on_ship.
• Lượt đánh giá được đăng dưới danh tính ứng dụng của máy chủ. Ai đã nhấn Xuất bản được ghi lại cho cổng vai trò và nhật ký kiểm tra; người đó không phải tác giả trên GitHub.

Xuất bản khai báo lớp hành động prPublish, nên điểm chặn của rào chắn kiểm soát nó như mọi hành động thay đổi dữ liệu — nó hỏi trước theo mặc định và từ chối khi không có người phê duyệt nào được kết nối. Xem Rào chắn.

Người đánh giá được làm gì

Các agent đánh giá chạy ở chế độ review: một sandbox chỉ đọc và một danh sách công cụ được phép chọn lọc gồm phát hiện, bình luận, phiếu và đánh giá ngang hàng — nhưng không được thay đổi gì. Một người đánh giá không thể sửa đoạn mã mà nó phê bình; nó có thể đính kèm một bản sửa đề xuất để con người áp dụng. Thông báo từ chối của chế độ này bảo một agent cố hành động bất chấp rằng hãy hoàn tất lượt đánh giá và để người dùng xử lý bản tóm tắt đã xuất bản.

Khái niệm liên quan

• Rào chắn — công cụ chính sách kiểm soát việc xuất bản
• Chế độ — chế độ review thay đổi điều gì ở một agent
• Quy trình và tự động hóa — công cụ mà lượt đánh giá chạy trên đó
• Vòng đời điều phối agent — worktree cách ly đến từ đâu

Hướng dẫn liên quan

• Dùng đánh giá hỗ trợ AI — chạy một lượt đánh giá và xuất bản nó
• Điều phối agent đánh giá — tự bạn chọn những người đánh giá
• Tính toán đánh giá — cohort, trục và diff