Ngày 1 tháng 9 năm 2026, GitHub công bố ở bản xem trước công khai rằng Copilot Code Review không chỉ có thể cho biết một pull request có vẻ sẵn sàng, mà còn có thể gửi một phê duyệt được tính trong các quy tắc hợp nhất khi quản trị viên bật khả năng này. Tính năng bị tắt theo mặc định và có thể cấu hình ở cấp doanh nghiệp, tổ chức và kho lưu trữ, đồng thời có thể giới hạn theo đường dẫn tệp. Thay đổi này có thể đẩy nhanh các thay đổi thường lệ; quan trọng hơn, nó thay đổi ranh giới tin cậy của chuỗi phân phối.
Điểm cần nhớ: ý kiến của một tác nhân có thể bổ sung cho việc xem xét, nhưng không bao giờ được trở thành kiểm soát duy nhất cho một thay đổi nhạy cảm, cũng không được phê duyệt thay đổi do cùng chuỗi tạo ra khi chưa có xác thực độc lập. Nhánh được bảo vệ, kiểm thử, CODEOWNERS, phân tách trách nhiệm và khả năng truy vết vẫn là các biện pháp bảo vệ chính.
1. Phân biệt đánh giá và phê duyệt
GitHub đưa ra hai hành vi khác nhau. Mọi đánh giá của Copilot đều có thể bao gồm nhận định cho biết pull request có vẻ sẵn sàng để được phê duyệt hay không. Nhận định này xuất hiện trong bình luận tóm tắt nhưng không đáp ứng yêu cầu hợp nhất.
Khi tùy chọn được bật, Copilot có thể gửi một phê duyệt thực sự. Phê duyệt đó có thể được tính vào số lượng phê duyệt mà quy tắc bảo vệ yêu cầu. Nếu các commit mới được đẩy lên sau khi phê duyệt, GitHub cho biết phê duyệt sẽ bị thu hồi như phê duyệt của người đánh giá và phải yêu cầu một lần xem xét mới.
Sự khác biệt này phải luôn hiển thị trong giao diện và thủ tục. Nhà phát triển không được nhầm lẫn giữa «mô hình không tìm thấy vấn đề chặn» và «thay đổi được phép đưa vào sản xuất». Câu đầu mô tả một tín hiệu. Câu sau gắn với trách nhiệm và góp phần vào quyết định kiểm soát.
Ban đầu, có thể bật rộng rãi đánh giá không được tính để đo mức độ phù hợp của tín hiệu. Phê duyệt có hiệu lực phải chỉ giới hạn ở những kho lưu trữ và đường dẫn đã được đánh giá rủi ro.
2. Vì sao phê duyệt là một quyền hạn chứ không phải bình luận
Một lần xem xét mã tạo ra nhận xét. Một phê duyệt thay đổi trạng thái của pull request và có thể mở khóa việc hợp nhất tự động. Vì vậy đó là một lời gọi công cụ có hệ quả, tương tự như thêm nhãn triển khai hoặc xác thực một thay đổi hạ tầng.
Câu hỏi trọng tâm không phải là «Copilot có biết phát hiện lỗi không?». Mà là: trong điều kiện nào phán đoán của nó có thể thay thế một phần kiểm soát bắt buộc? Người đánh giá có thể biết mục tiêu nghiệp vụ, lịch sử thành phần, ràng buộc của khách hàng hoặc phụ thuộc vận hành không xuất hiện trong diff.
Mô hình cũng có thể bị ảnh hưởng bởi nội dung kho lưu trữ: bình luận, tài liệu, tên tệp hoặc chỉ dẫn nhúng. Ngay cả khi nền tảng áp dụng bảo vệ, dữ liệu được phân tích vẫn là đầu vào không đáng tin cậy. Một quy tắc quan trọng không được chỉ phụ thuộc vào hệ thống xác suất đang đọc chính thay đổi mà nó phải cho phép.
Cần tính đến cả các lỗi có tương quan. Nếu cùng một nhà cung cấp, mô hình hoặc chỉ dẫn tạo mã rồi phê duyệt nó, hai bước có thể có chung các điểm mù. Việc nhân số lượng tác nhân không tự động tạo ra tính độc lập.
3. Duy trì sự phân tách trách nhiệm
Nguyên tắc tối thiểu là: một thay đổi không được tạo và phê duyệt bởi cùng một danh tính logic nếu không có kiểm soát độc lập khác. Nếu Copilot hoặc một tác nhân mở pull request, phê duyệt của nó không được đủ để hợp nhất.
Quy tắc này có thể áp dụng theo nguồn gốc. Hãy thêm vào pull request thuộc tính cho biết thay đổi là do con người, có hỗ trợ hay do tác nhân tạo ra. Khi đó các quy tắc hợp nhất yêu cầu xác thực của con người cho đóng góp của tác nhân, kể cả khi có đánh giá Copilot.
Với thay đổi đơn giản do con người thực hiện, Copilot có thể đưa ra phê duyệt bổ sung. Tổ chức có thể quyết định nó được tính là một trong hai phê duyệt, nhưng không phải phê duyệt cuối cùng cho thành phần quan trọng. CODEOWNER vẫn chịu trách nhiệm về phạm vi.
Hãy tách riêng cả cấu hình. Tài khoản quản lý quy tắc phê duyệt không được phép bị sửa đổi bởi workflow đang được đánh giá. Các thay đổi đối với thiết lập doanh nghiệp, bảo vệ nhánh và tệp chính sách phải qua một nhóm hạn chế và xem xét của con người.
Cuối cùng, danh tính Copilot phải rõ ràng trong lịch sử. Một phê duyệt tự động không được trông như phê duyệt của thành viên nhóm. Nhật ký kiểm toán phải cho phép tìm mô hình, phiên bản tính năng, ngày tháng, các commit được xem xét và các kiểm soát sẵn có vào thời điểm quyết định.
4. Xác định các đường dẫn mà AI không thể tự phê duyệt
GitHub cho phép quản trị viên chọn các đường dẫn mà Copilot được phép phê duyệt. Khả năng này nên dùng như danh sách cho phép: phê duyệt chỉ có giá trị trong các khu vực được xác định rõ là ít rủi ro.
Phạm vi ban đầu có thể gồm thay đổi tài liệu, ví dụ, bản dịch, kiểm thử không thay đổi môi trường sản xuất, phụ thuộc phát triển hoặc sửa lỗi lặp lại trong một thành phần được bao phủ tốt. Ngay cả trong các khu vực đó, kiểm thử và giới hạn khối lượng vẫn cần thiết.
Tối thiểu phải loại trừ:
- tệp bí mật, danh tính và quyền;
- workflow CI/CD, kịch bản triển khai và hạ tầng;
- di chuyển cơ sở dữ liệu và lược đồ;
- mã xác thực, thanh toán, mã hóa hoặc kiểm soát truy cập;
- chính sách bảo mật, CODEOWNERS và cơ chế bảo vệ;
- phụ thuộc sản xuất và tệp khóa khi tác động của chúng chưa được phân tích;
- mã chịu quy định hoặc cần xác thực theo hợp đồng;
- thay đổi quy mô lớn, được tạo tự động hoặc khó xem xét.
Tính nhạy cảm không chỉ phụ thuộc vào đường dẫn. Tài liệu có thể chứa lệnh vận hành nguy hiểm; kiểm thử có thể vô hiệu hóa một assertion. Hãy thêm quy tắc về kích thước diff, kiểu tệp, quyền đã thay đổi và sự hiện diện của dấu hiệu rủi ro.
Các đường dẫn phải được xem xét lại mỗi khi kiến trúc thay đổi. Một thư mục từng tĩnh có thể trở thành nguồn cấu hình hoạt động.
5. Tăng cường bảo vệ nhánh và CI
Phê duyệt của Copilot không được bỏ qua các kiểm soát hiện có. Hãy yêu cầu nhánh được cập nhật, trạng thái CI bắt buộc, không có cuộc trao đổi chưa giải quyết, commit được ký khi chính sách yêu cầu và thu hồi phê duyệt sau khi sửa đổi.
Kiểm thử phải bao phủ nhiều hơn cú pháp. Hãy thêm phân tích tĩnh, phụ thuộc, bí mật, di chuyển, hợp đồng API, quyền và kiểm thử bảo mật phù hợp với thành phần. Đánh giá AI có thể bình luận về một ý định; CI cung cấp bằng chứng tái lập được.
Hãy dùng merge queue để ngăn việc một phê duyệt xác thực trạng thái khác với trạng thái thực sự được tích hợp. Hàng đợi chạy lại kiểm soát trên tổ hợp thay đổi cuối cùng và hạn chế xung đột giữa các pull request được phê duyệt riêng.
Với kho lưu trữ có tác động lớn, hãy yêu cầu môi trường tiền sản xuất hoặc xác thực triển khai riêng. Mã có thể đúng cục bộ nhưng tạo hiệu ứng bất ngờ trên dữ liệu, cấu hình hoặc khả năng quan sát.
Không trao cho tác nhân khả năng sửa các kiểm thử bắt buộc trong cùng quy trình mà nó phê duyệt. Khi thay đổi tác động đến CI, chính sách hoặc bộ dữ liệu đánh giá, cần có một lần xem xét chuyên biệt của con người.
6. Đánh giá chất lượng xem xét trước khi kích hoạt
Hãy bắt đầu bằng việc quan sát các đánh giá không được tính. Trong nhiều tuần, so sánh phán đoán của Copilot với kết quả của người đánh giá, sự cố sau hợp nhất và phản hồi từ môi trường sản xuất.
Xây dựng tập pull request lịch sử gồm các lỗi đã biết: lỗi logic, thiếu kiểm soát truy cập, di chuyển rủi ro, cạnh tranh, phá vỡ tương thích, rò rỉ dữ liệu, kiểm thử bị làm yếu và thay đổi tài liệu hợp lệ. Đo lường Copilot phát hiện gì, bỏ sót gì và chặn sai điều gì.
Các chỉ số hữu ích là độ bao phủ lỗi nghiêm trọng, tỷ lệ cảm giác an toàn sai, số lượng bình luận có thể hành động, thời gian xem xét và tỷ lệ bất đồng của con người. Tỷ lệ đồng thuận chung có thể cao nhưng vẫn che giấu những lỗi hiếm gặp nghiêm trọng nhất.
Hãy kiểm tra cả độ vững: chỉ dẫn mâu thuẫn trong kho, diff rất lớn, mã được tạo, đổi tên hàng loạt, mô-đun con và tệp nhị phân. Xác minh rằng hệ thống không đưa ra quyết định khi ngữ cảnh không đầy đủ hoặc pull request nằm ngoài phạm vi.
Lặp lại đánh giá sau mỗi thay đổi quan trọng về mô hình hoặc tính năng. Bản xem trước công khai luôn phát triển; kết quả có được vào tháng 9 năm 2026 không bảo đảm hành vi giống hệt nhiều tháng sau.
7. Triển khai theo từng giai đoạn và chuẩn bị hoàn tác
Giai đoạn đầu mang tính thông tin: Copilot bình luận và công bố đánh giá nhưng không được tính trong quy tắc. Giai đoạn hai cho phép phê duyệt trên kho ít rủi ro nhưng vẫn luôn yêu cầu phê duyệt của con người. Giai đoạn ba cho phép phê duyệt đáp ứng một quy tắc chỉ cho danh sách rất hạn chế các đường dẫn và thay đổi.
Không bật trên toàn doanh nghiệp trước khi quan sát hành vi theo loại kho. Hãy dùng hệ phân cấp cài đặt để các tổ chức hoặc kho chủ động tham gia thí điểm.
Xác định ngưỡng dừng: lỗi nghiêm trọng không bị phát hiện, tỷ lệ dương tính giả quá cao, khác biệt với người đánh giá, thay đổi hành vi không được tài liệu hóa hoặc sự cố sau hợp nhất. Việc tắt phải diễn ra ngay và không cần sửa từng kho riêng lẻ.
Lưu giữ lịch sử quyết định. Khi một nhóm mở rộng các đường dẫn được phép, họ cung cấp kết quả đánh giá và chủ sở hữu rủi ro. Quyền cho phép tự động hết hạn nếu không được xem xét lại.
Sau triển khai, hãy lấy mẫu các pull request được Copilot phê duyệt và thực hiện xem xét hậu kiểm. Không thấy sự cố không chứng minh không có lỗi; kiểm soát liên tục ngăn tính năng trở thành một cơ chế tự động bị lãng quên.
8. Chính sách tham chiếu cho tổ chức
Một chính sách đơn giản có thể được nêu như sau:
- đánh giá Copilot mặc định là tín hiệu tư vấn;
- phê duyệt thực tế bị tắt ở cấp doanh nghiệp, trừ khi được ủy quyền rõ ràng;
- chỉ các kho đăng ký thí điểm mới có thể bật nó;
- các đường dẫn được phép được xác định theo danh sách cho phép;
- đóng góp của tác nhân luôn cần phê duyệt của con người;
- tệp nhạy cảm và thay đổi chính sách bị loại trừ;
- trạng thái CI và CODEOWNERS vẫn bắt buộc;
- mọi commit mới thu hồi quyết định và kích hoạt xem xét mới;
- hành vi được đánh giá và kiểm toán định kỳ;
- cơ chế trung tâm cho phép tắt ngay lập tức.
Chính sách này phải đi kèm ví dụ, vì các nhóm cần hiểu thế nào là thay đổi đơn giản hoặc nhạy cảm. Nó cũng phải nêu rõ rằng phê duyệt kỹ thuật không thay thế xác thực về sản phẩm, pháp lý hoặc bảo mật mà một số dự án yêu cầu.
Kinh nghiệm từ Asana và việc dùng Codex cho một cuộc di chuyển nợ kỹ thuật nhắc lại tầm quan trọng của độ bao phủ kiểm thử mạnh và đánh giá của con người đối với từng thay đổi, ngay cả khi các tác nhân tăng tốc đáng kể công việc.
Kết luận
Khả năng Copilot phê duyệt pull request có thể giảm độ trễ của các thay đổi thường lệ, nhưng trao cho hệ thống xác suất một vai trò trong quyết định hợp nhất. Vai trò này phải được coi là sự ủy quyền quyền hạn chứ không phải chỉ là bình luận được làm phong phú.
Khung vững chắc dựa trên đường dẫn được phép, tách biệt tác giả và người phê duyệt, bảo vệ nhánh, CI độc lập, CODEOWNERS, đánh giá cục bộ và triển khai dần dần. Partitech hỗ trợ các nhóm thiết kế các chính sách này, tự động hóa GitHub và tích hợp tác nhân phát triển mà không làm suy yếu khả năng kiểm soát việc phân phối.
Tài liệu tham khảo đã kiểm chứng ngày 3 tháng 9 năm 2026
- GitHub — “Copilot code review can now approve pull requests”, ngày 1 tháng 9 năm 2026: https://github.blog/changelog/2026-09-01-copilot-code-review-can-now-approve-pull-requests/
- Tài liệu GitHub — bảo vệ nhánh và quy tắc pull request: https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository
- Tài liệu GitHub — CODEOWNERS: https://docs.github.com/en/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/about-code-owners