Cách Nhóm Claude Code Thực Hiện Đánh Giá Mã: Bảy Bước và Không Có Cơ Chế Ngắt Mạch

Ngày 15 tháng 10 năm 2026, nhóm Claude Code đã công bố bài tường thuật của chính mình về cách họ đánh giá mã, một bài viết kỹ thuật dài mười bốn phút được ghi tên Addy Osmani, Morgan Westlee Lunt và Qing Wang. Câu giải thích vì sao có người đang tìm kiếm điều này xuất hiện ngay đầu bài: Claude viết khoảng 90 phần trăm mã nguồn của chính Claude Code. Bài viết không phải là lời bào chữa cho con số đó mà là mô tả cỗ máy phải tồn tại bên dưới nó trước khi nó có thể đứng vững, và những phần đáng đọc kỹ lại là những phần vẫn còn thiếu.

Hầu hết các bản tóm tắt chỉ dừng ở hai con số nổi bật: số pull request được hợp nhất vào codebase của Claude Code đã tăng hơn gấp đôi từ tháng 6 đến tháng 9 năm 2026, trong khi tỷ lệ phải hoàn nguyên giảm hơn 40 phần trăm. Cả hai đều đến từ chính đội ngũ, và cả hai đều có thể được tạo ra bởi nhiều cách tổ chức khác nhau, kể cả cách mà mọi người vẫn giả định, rằng việc đánh giá đã bị âm thầm gỡ bỏ. Bài đăng nói rằng không phải vậy. Họ đã chuyển phần lớn việc đọc sang máy móc, tối ưu cho thời gian và sự chú ý của con người, và đầu tư để sai sót có thể được hoàn tác nhanh và dễ dàng. Mọi thứ còn lại là chi tiết về cách làm.

Tại sao việc xem xét lại lại trở thành điểm nghẽn ngay từ đầu

Áp lực không đến từ một quyết định chính sách. Nó đến từ khối lượng. Theo bài viết, trong monorepo của Anthropic, số thay đổi được đưa vào mỗi ngày đã tăng từ khoảng 2.500 vào tháng 5 lên hơn 30.000 vào tháng 9 năm 2026. Claude Code nằm trong kho lưu trữ riêng, tách biệt với monorepo đó, nhưng nó cũng chịu áp lực tương tự ở quy mô nhỏ hơn.

Ở tốc độ đó, bài viết thừa nhận rằng việc rà soát thủ công từng dòng một là cực kỳ khó khăn, nếu không muốn nói là bất khả thi. Không ai ở đó đang cho rằng việc một con người đọc mọi diff là không cần thiết. Họ đang cho rằng việc đọc mọi diff không còn khả thi về quy mô, và rằng "liệu một con người đã đọc mã hay chưa" luôn chỉ là một cách đại diện thiếu chính xác cho câu hỏi thực sự quan trọng: thay đổi này có thể hỏng ở đâu, và kiểm tra nào, tự động hay thủ công, là cách đúng để bắt được nó.

Khi được diễn đạt theo cách đó, cánh cổng sẽ dịch chuyển. Việc xem xét không còn là một cánh cửa ở cuối con đường mà trở nên liên tục, gần giống với kiểm tra chính tả trong lúc bạn viết. Hầu hết các thay đổi đã được Claude đọc và sửa trước khi một người xem xét.

Họ tối ưu hóa cho điều gì và điều gì được coi là thất bại

Mục tiêu được nêu là hầu hết các pull request trong các kho lưu trữ Claude Code — mà bài viết mô tả là CLI, các ứng dụng desktop và web cùng các ứng dụng di động — được merge với tối đa một người trong vòng lặp, người đó có thể là tác giả, mà không làm tăng số lần revert hoặc sự cố. Điều khoản thứ ba chính là điều khiến đây trở thành một mục tiêu thực sự thay vì một động thái cắt giảm chi phí.

Họ đo thời gian của con người ở cả hai phía của sổ cái: thời gian mọi người dành để đánh giá và thời gian họ dành để sửa những gì mã xấu làm hỏng. Cắt giảm phần đầu tiên không giúp ích gì nếu chi phí lại xuất hiện ở phần thứ hai, và nhóm nói thẳng điều đó. Vì vậy, các con số được theo dõi là số phê duyệt của con người trên mỗi yêu cầu kéo (pull request), được báo cáo dưới dạng trung vị và phân vị thứ 95, số bình luận của con người, và thời gian một yêu cầu kéo phải chờ một người. Tỷ lệ hoàn nguyên và sự cố nằm bên dưới tất cả những điều đó như một rào chắn: nếu chúng tăng lên, thời gian của con người không được tiết kiệm, mà chỉ bị dịch chuyển.

Các chỉ số chi phí đánh giá rất dễ bị thao túng khi xét riêng lẻ; một người đánh giá duyệt mọi thứ sẽ tạo ra những biểu đồ thời gian phê duyệt đẹp như tranh. Chính rào chắn bảo vệ là thứ ngăn biểu đồ nói dối.

Bảy bước, không phải một cổng chặn

Bài viết trình bày quy trình của một thay đổi điển hình thành bảy bước được đánh số. Mỗi lớp phát hiện được một số vấn đề và bỏ sót những vấn đề khác, và các bước kiểm tra ít tốn kém hơn được thực hiện trước những bước kiểm tra tốn kém hơn.

• Xác minh trước khi pull request tồn tại.Claude chạy các bài kiểm thử, bản build và linter, đồng thời một agent thứ hai xem xét diff trong một ngữ cảnh mới. Nhiều kỹ sư cũng chạy các kỹ năng nội bộ: một kỹ năng săn lỗi, một kỹ năng đơn giản hóa diff, một kỹ năng kiểm tra hành vi từ đầu đến cuối. Boris Cherny, người tạo ra Claude Code, đã nhận định rằng trao cho Claude một cách để tự xác minh công việc của mình có lẽ là điều quan trọng nhất để có kết quả tốt, và ước tính nó giúp kết quả cuối cùng tốt hơn hai đến ba lần.

• Đánh giá bằng AI trên mọi yêu cầu kéo. Đánh giá của Claude đọc phần khác biệt so với toàn bộ kho lưu trữ và mục đích đã nêu của yêu cầu kéo. Nhiều tác nhân tìm lỗi song song, sau đó một nhóm riêng bỏ phiếu cho từng phát hiện và chỉ đăng nếu đủ người đồng ý rằng đó là thật. Các phát hiện về phong cách, chẩn đoán hoặc dọn dẹp bị loại bỏ. Những gì còn lại xuất hiện dưới dạng nhận xét nội tuyến được gắn thẻ Quan trọng, Nhỏ nhặt hoặc Có từ trước. Khi bản xem trước nghiên cứu ra mắt, tỷ lệ yêu cầu kéo nội bộ nhận được nhận xét đánh giá có nội dung thực chất đã tăng từ 16 phần trăm lên 54 phần trăm. Quản trị viên đặt từng kho lưu trữ ở chế độ Nhanh, Tiêu chuẩn hoặc Chuyên sâu.

• Đánh giá bảo mật. Một lượt tự động riêng biệt. Không thể hợp nhất pull request khi còn một phát hiện từ một trong hai đánh giá đang mở; bạn sửa nó hoặc đóng luồng với lý do ngắn gọn. Cùng một kiểm tra đó được công khai dưới dạng GitHub Action đánh giá bảo mật mã nguồn mở hoặc lệnh /security-review.

• Các kiểm tra tự động có tính chặn. Lint, kiểm tra kiểu, kiểm thử trên mọi nền tảng và một bản build.

• Phê duyệt của con người, được điều chỉnh theo mức độ rủi ro. Một bộ phân loại đọc thay đổi và đặt cấp độ thay vì để tác giả tự đặt. Bước này có phần riêng bên dưới, vì đây là nơi chứa phần lớn thiết kế thú vị.

• Hàng đợi hợp nhất, cờ và phát hành dần dần. Hàng đợi chạy lại mọi bước kiểm tra trên nhánh main với thay đổi được áp dụng, nên hai pull request mà mỗi cái đều vượt qua kiểm tra không thể kết hợp thành một nhánh main bị hỏng. Hành vi mới được phát hành ẩn sau một cờ cho nhân viên Anthropic trước, rồi đến kênh mới nhất, với kênh ổn định theo sau.

• Phát hiện và khôi phục nhanh. Các cờ tính năng được tắt mà không cần triển khai, có lịch trực luân phiên hàng tuần, và các buổi đánh giá sự cố sẽ hỏi lớp nào lẽ ra phải bắt được vấn đề. Một số sai sót vẫn sẽ lọt qua, nên lớp cuối cùng là để nhận ra chúng nhanh chóng thay vì ngăn chặn chúng.

Thay đổi quyết định cấp độ, không phải tác giả.

{{1}}Bản sửa tài liệu{{/1}} và {{2}}thay đổi trình cập nhật tự động{{/2}} không mang cùng mức rủi ro, nên chúng không được đánh giá theo cùng một cách. Bảng trong bài có ba cấp và mỗi cấp trả lời một câu hỏi duy nhất: cần bao nhiêu người, nếu có, phải phê duyệt thay đổi này trước khi nó được hợp nhất.

Thấp bao gồm tài liệu, nội dung văn bản, tính năng chỉ dành cho nội bộ và các thay đổi bổ sung nằm sau một cờ tính năng; khi đánh giá tự động và bảo mật đều đạt, không cần bất kỳ người nào. Trung bình bao gồm các thay đổi sản phẩm thông thường cùng các khu vực nhạy cảm như bộ nhớ đệm, trình tự động cập nhật và lời nhắc hệ thống, và cần một người. Cao bao gồm mã có rủi ro cao nhất và một tập nhỏ các đường dẫn luôn cần hai người.

Bộ phân loại chỉ là một nửa của thiết kế. Một bộ phân loại thứ hai hỏi liệu thay đổi cụ thể này có cần thêm một người khác hay không ngay cả khi cấp của nó nói là không cần. Một số đường đi luôn cần một người bất kể cấp: bất kỳ thứ gì chủ sở hữu đã đánh dấu là nhạy cảm và mọi tệp quy trình CI. Chỉ những tác giả nằm trong danh sách tin cậy của kho lưu trữ, chủ yếu là nhóm sở hữu, mới được đi theo các đường nhẹ hơn; tất cả những người khác đều cần thêm một người. Phê duyệt của tác nhân không bao giờ được tính như của người, vì vậy đánh giá tự động có thể thông qua một thay đổi rủi ro thấp nhưng không thể lấp vào chỗ yêu cầu con người. Ai là người khởi xướng thay đổi thì phải chịu trách nhiệm về nó. Và một phê duyệt chỉ áp dụng cho một commit cụ thể, nên một commit mới, kể cả cú push của tác nhân hoặc một lần hợp nhất được giải quyết thủ công, lại cần phê duyệt lần nữa.

Có hai chi tiết đáng để học hỏi ngay cả khi bạn không bao giờ xây dựng một bộ phân loại. Mức xếp hạng đến từ thay đổi, không phải từ tác giả, và sự tin cậy là một cổng riêng biệt, hẹp hơn nằm bên trên nó. Và một phê duyệt được gắn với một commit thay vì với một pull request, điều này bịt lỗ hổng phổ biến nhất trong các hệ thống đánh giá: một dấu tích xanh đạt được sớm trong một nhánh lại được dùng cho đoạn mã chưa ai từng xem xét.

Người đánh giá được huấn luyện dựa trên chính các sự cố của họ.

Đây là phần mà hầu hết các bài viết đều bỏ qua, và nó giải thích vì sao cách sắp xếp này vẫn tiếp tục vận hành hiệu quả thay vì bị trôi dạt.

Nhóm đã thu thập các pull request trong quá khứ từng gây ra sự cố, cùng với các bản fix-forward và revert của chúng, rồi cho các kỹ sư hiểu rõ đoạn mã đó xác nhận từng lỗi và vị trí lỗi nằm ở đâu. Bộ sưu tập đó giờ là một bài đánh giá. Trình đánh giá chạy với nó hằng ngày. Khi lời nhắc, công cụ hoặc mô hình của nó thay đổi, thay đổi đó phải trụ được với toàn bộ tập: giữ lại nếu điểm tăng, bỏ đi nếu không. Những thất bại của họ đã trở thành bộ kiểm thử cho thứ lẽ ra phải bắt được thất bại của họ.

Đó là một cách tiếp cận khác với việc tinh chỉnh một linter, vốn được đánh giá dựa trên một bộ quy tắc cố định. Reviewer này được đánh giá dựa trên những cách cụ thể mà codebase này đã từng hỏng, vì vậy bộ đánh giá sẽ phát triển mỗi khi có sự cố xảy ra. Không có điểm số nào cho nó xuất hiện trong bất kỳ tài liệu nào Anthropic đã công bố mà chúng tôi đã đọc, và bài viết không tuyên bố rằng reviewer đã hoàn thiện.

Lớp chưa được xây dựng

Đây là lời thừa nhận khiến bài đăng trở nên đáng tin. Mọi thứ ở trên mô tả một hệ thống bắt và đảo ngược sai sót, chứ không phải một hệ thống tự nhận ra tỷ lệ lỗi của chính nó đang thay đổi. Nhóm chưa có các cầu dao tự động thắt chặt phê duyệt khi số lần hoàn tác hoặc sự cố thay đổi, và các kỹ sư ở đó muốn có chúng trước khi nhiều mã hơn được chuyển sang quy trình hợp nhất không cần con người.

Thay vào đó, thứ hiện diện là sự nhận biết của con người. Các cờ tính năng được tắt mà không cần triển khai, lịch trực on-call hằng tuần theo dõi, và các buổi đánh giá sự cố hỏi lớp nào lẽ ra đã phát hiện ra vấn đề. Câu nói của một đồng nghiệp là câu hữu ích nhất cho bất kỳ ai đang lên kế hoạch triển khai tương tự: chậm lại đúng là làm giảm tỷ lệ lỗi của bạn, nhưng phần lớn là vì bạn đang làm ít hơn mọi thứ. Nhóm thà trở nên nhanh hơn trong việc nhận ra và sửa chữa vấn đề còn hơn là chậm hơn trong việc tạo ra chúng.

Đọc lại bảy bước với điều đó trong đầu. Sáu bước quyết định liệu một thay đổi có được tiến hành hay không. Bước thứ bảy là một tập hợp các thói quen để chú ý sau đó. Không có vòng phản hồi nào được nối từ kết quả ngược trở lại cổng kiểm soát, và những người đã xây dựng hệ thống cũng nói như vậy.

Nhiệm vụ thứ hai của việc đánh giá, điều mà bài viết phần lớn gạt sang một bên

Bài viết nói rõ rằng review mã đảm nhận hai vai trò: tìm và sửa vấn đề trước khi chúng được phát hành, và xây dựng hiểu biết chung trong toàn đội. Bài viết tập trung vào vai trò thứ nhất, rồi quay lại vai trò thứ hai với một câu trả lời trung thực đến bất thường: không có quy trình chính thức cho việc đó, không ai giữ một mô hình tinh thần đầy đủ về Claude Code trong đầu, và họ không nghĩ ai cần làm vậy. Muốn hiểu một phần của codebase? Hãy nhờ Claude giải thích đúng phần đó.

Hai tệp hướng dẫn mang ngữ cảnh vốn từng nằm trong đầu những người đánh giá. CLAUDE.md cho Claude biết dự án là gì, tech stack, các quy ước, mục tiêu và phi mục tiêu, được cố ý giữ ngắn gọn. REVIEW.md do các chủ sở hữu mã viết, nói rõ thất bại trông như thế nào trong phần mã của họ, những đường dẫn nào cần bỏ qua, và yêu cầu chỉ ra tệp và dòng thay vì đoán mò.

Trách nhiệm giải trình có một dòng riêng: bạn đưa thay đổi vào, bạn chịu trách nhiệm về nó. Hợp nhất một thay đổi nhỏ hoặc trung bình mà có sự cố xảy ra, thì chuẩn mực là bạn phải sửa nó. Điều đó hiệu quả vì các thay đổi nhỏ, vì cờ tính năng và hoàn tác gỡ bỏ hầu hết sai sót trong vài phút, và vì phạm vi ảnh hưởng đặt ra mức yêu cầu về số lượng kiểm tra mà một thay đổi phải trải qua. Đây là một chuẩn mực được xếp chồng lên quy tắc phê duyệt, không phải sự thay thế cho quy tắc đó.

Bộ định tuyến phù hợp ở đâu và không phù hợp ở đâu

Quy trình trên là một chuỗi lệnh gọi mô hình: một tác nhân đánh giá đọc một diff so với toàn bộ kho mã, nhiều tác nhân săn lỗi chạy song song, một nhóm bỏ phiếu cho từng phát hiện, một lượt kiểm tra bảo mật, và trình đánh giá được chạy lại hằng ngày dựa trên một bộ đánh giá ngày càng lớn. Đó là vấn đề định tuyến trước khi là vấn đề đánh giá, vì một nhà cung cấp gặp một buổi chiều tồi tệ không nên chặn hàng đợi hợp nhất.

OrcaRouter là một điểm cuối tương thích OpenAI cho hơn 200 mô hình chỉ với một khóa, với tính năng tự động chuyển đổi dự phòng giữa các nhà cung cấp và không cộng thêm phí, nghĩa là giá niêm yết của nhà cung cấp được chuyển thẳng đến người dùng. Các nhóm đang vận hành phiên bản riêng của quy trình này có một mối quan hệ thanh toán duy nhất và một nơi duy nhất để chuyển đổi mô hình khi chất lượng của người đánh giá thay đổi, đây chính xác là điều mà đánh giá hàng ngày được thiết kế để phát hiện.

Ranh giới rất quan trọng. Chúng tôi lưu trữ các mô hình. Chúng tôi không lưu trữ Claude Code, chúng tôi không chạy Code Review cho Claude Code, và chúng tôi không có quyền truy cập vào pipeline mà bài viết này nói đến. Code Review cho Claude Code là sản phẩm của Anthropic, thường có sẵn trên các gói Team và Enterprise, với một phiên bản nhẹ hơn có sẵn cục bộ dưới dạng /code-review. Nếu điều bạn muốn là pipeline đó, thì nó nằm ở đó; trên phiên bản của chính nhóm bạn, router là một quyết định về hạ tầng chứ không phải quyết định về đánh giá.

Một nhóm nhỏ hơn thực sự có thể sao chép được gì

Viết các quy tắc review ra nơi người review có thể đọc được: một CLAUDE.md ngắn gọn cho dự án và một REVIEW.md cho từng khu vực, nêu rõ thất bại trông như thế nào và yêu cầu nêu tệp và dòng thay vì phỏng đoán. Ghi các tầng rủi ro bằng văn bản, biến chúng thành thuộc tính của thay đổi thay vì của tác giả, bắt đầu nghiêm ngặt và chỉ nới lỏng khi có bằng chứng. Đặt giới hạn cho những gì review tự động có thể phê duyệt và không bao giờ để phê duyệt của agent được tính là của một người. Ràng buộc phê duyệt với commit. Chạy merge queue. Biến sự cố và các lần revert thành ca kiểm thử và chấm lại điểm người review mỗi khi bạn thay đổi nó, vì một người review không được đo lường chỉ là một linter có marketing tốt hơn.

Sau đó hãy theo dõi rào chắn, chứ không phải thời gian phê duyệt. Cách đội ngũ tự đặt vấn đề cho bạn phép thử cho bất kỳ thay đổi quy trình review nào bạn đang cân nhắc: tỷ lệ revert và sự cố có giữ nguyên không, hay thời gian chỉ đơn giản chuyển từ người review sang người dọn dẹp sau đó? Câu hỏi đó có thể trả lời bằng dữ liệu mà hầu hết các đội đã có, và nó phân biệt một quy trình đã trở nên nhanh hơn với một quy trình chỉ trông nhanh hơn trong một quý.