Đánh giá mã tự động năm 2026: Chạy trên mọi PR mà không cần mua ghế

Đánh giá mã tự động là một tác vụ CI gửi diff của bạn đến mô hình ngôn ngữ, đăng các phát hiện lên những dòng bị ảnh hưởng và khiến một status check thất bại khi tìm thấy vấn đề nghiêm trọng. Cách để chạy quy trình này trên mọi pull request mà không cần đăng ký theo số ghế là tự lưu trữ một bộ khung mã nguồn mở: sao chép một workflow dài khoảng mười lăm dòng vào kho lưu trữ của bạn, thêm một khóa API và chỉ trả phí cho các token mà mỗi lần đánh giá tiêu thụ. Không có số lượng ghế nào để mua, vì chẳng có ghế nào cả. Bản triển khai tham chiếu mà chúng tôi duy trì là kho lưu trữ Orca-Code-Review — công khai, được cấp phép MIT, và kể từ khi được tạo ra vào ngày 25 tháng 6 năm 2026, đây là mã nguồn đứng sau GitHub Action OrcaCode Review. Công thức định tuyến đi kèm mặc định dùng DeepSeek V4 Flash cho bước đánh giá và dùng GLM-5.3 cho bộ thẩm định xác minh độc lập, và bạn có toàn quyền thay đổi cả hai. Bài viết này điểm qua những gì thực sự chạy trên mỗi lần push, những gì bạn cấu hình, chi phí token là bao nhiêu và các kiểu lỗi bạn sẽ gặp trong tuần thứ hai.

Bản tóm tắt ngắn gọn. Mỗi lần push sẽ được review một lần. Các phát hiện được đăng ngay trên các dòng đã thay đổi. Các phát hiện P0 và P1 sẽ khiến check thất bại và chặn merge; nếu không có phát hiện nào thì check sẽ đạt. Bạn có thể yêu cầu review lại theo nhu cầu bằng cách bình luận /orcacode-review. Workflow nằm trong repo của bạn; logic review nằm trong action đã phát hành; lựa chọn model nằm trong routing recipe mà bạn có thể chỉnh sửa trong workspace của riêng bạn. Công cụ review chỉ đọc diff và các tệp trong repository, không bao giờ thực thi mã trong PR của bạn. Và một lời cảnh báo thẳng thắn ngay từ đầu: nó bắt được những bug thật sự nhưng vẫn bỏ sót những lỗi cần một con người hiểu được vì sao code lại như vậy.

• Một quy trình + một bí mật + một hóa đơn token. Không bao giờ có phí cấp phép theo người dùng.

• Bộ kiểm thử là mã nguồn mở. Sao chép nó, fork nó, rà soát nó, ghim nó vào một commit SHA.

• Mô hình là một cài đặt, không phải một nhà cung cấp. Thay đổi người đánh giá bằng cách chỉnh sửa công thức định tuyến, không phải bằng cách viết lại YAML hoặc thay đổi action.

• Diff quá khổ không tốn gì. Bộ kiểm tra kích thước chạy trước khi mô hình chạy.

• Nó đọc, chứ không bao giờ chạy, mã của bạn. Đó là thuộc tính an toàn khiến cho pull_request_target hoàn toàn an toàn để sử dụng.

Cách đánh giá mã tự động thực sự hoạt động

Mọi hệ thống đánh giá tự động đều là ba thành phần giống nhau mặc những bộ quần áo khác nhau: một sự kiện, một trình chạy và một bộ đánh giá.

The event is the trigger. The shipped workflow fires on pull request events — opened, synchronize (a new push), ready_for_review (a draft becomes ready) — and on a PR comment. Because it runs on pull_request_target, the workflow definition is read from the base branch, which is why the workflow must exist on the base branch before it can run for a PR. One review per push; the concurrency block cancels the previous run, so a rapid sequence of pushes does not queue five reviews of stale code.

Trình chạy là GitHub Actions trên ubuntu-latest. Công việc cần ba quyền: quyền đọc contents, quyền ghi pull requests (để đăng bình luận nội dòng) và quyền ghi issues (để đăng tóm tắt và dọn dẹp các bình luận cũ).

Trình đánh giá là một mô hình ngôn ngữ. Hành động tìm nạp phần đầu của PR, tập hợp diff và ngữ cảnh kho lưu trữ mà công cụ chọn, rồi gửi dữ liệu đó đến mô hình đánh giá. Kết quả là một tập hợp các phát hiện, mỗi phát hiện được gắn mức độ nghiêm trọng và neo vào một tệp và dòng cụ thể. Hành động đăng chúng dưới dạng bình luận nội tuyến trên PR và ghi một bình luận tóm tắt vào vùng đánh dấu ở đầu mô tả PR, được thay thế tại chỗ sau mỗi lần đẩy.

Gate là một kiểm tra trạng thái. GitHub không biết “review” nghĩa là gì; nó chỉ biết liệu kiểm tra review có vượt qua hay không. Bạn làm cho gate thực sự có hiệu lực bằng cách đánh dấu kiểm tra đó là bắt buộc trong bảo vệ nhánh. Đó là toàn bộ cơ chế chặn merge — không có lời gọi API quản trị, không có nhãn, chỉ là một kiểm tra bắt buộc thất bại.

Điều không xảy ra: không có gì thực thi mã của PR. Công cụ chỉ đọc. Chính bất biến đó khiến cho trigger đặc quyền pull_request_target an toàn khi sử dụng với khóa API trả phí.

Bộ khung mã nguồn mở chính là yếu tố tạo nên sự khác biệt.

Everything above is true of many tools. What is not true of most is that the whole thing is inspectable and self-hostable, which is what the Orca-Code-Review repository buys you. It is a public MIT-licensed GitHub repository (JavaScript, created June 25, 2026) that packages the review as a reusable composite GitHub Action plus an installer, and it is the same code the hosted OrcaCode Review app runs.

Hãy dành mười phút trong cây mã nguồn là bạn có thể kể tên mọi thành phần liên quan đến PR của mình.

• action.yml — action tổng hợp, khoảng mười lăm đầu vào được tài liệu hóa. Không có tên mô hình nào được mã hóa cứng ở bất kỳ đâu trong đó.

• workflows/orca-code-review.yml — ví dụ về workflow tiêu thụ, khoảng mười lăm dòng bạn sao chép vào .github/workflows/.

• recipes/ — DSL định tuyến. Đây là nơi mô hình thực sự được chọn.

• rules/ — thang đánh giá mức độ nghiêm trọng (P0–P3), định dạng đầu ra bắt buộc, và chỉ thị quy ước đưa tài liệu quy ước của dự án vào quá trình đánh giá như dữ liệu tham chiếu không đáng tin cậy.

• scripts/ — bộ lọc độ chính xác (L1 cùng với một bộ đánh giá L2), bộ bảo vệ diff, cổng merge, báo cáo chạy, và bộ đếm token. Mỗi cái là một tệp .mjs nhỏ, dễ đọc kèm theo các bài kiểm tra.

• skills/setup-orca-code-review — kỹ năng mà trình cài đặt đưa vào coding agent của bạn, bao gồm cài đặt, cấu hình lại, xử lý sự cố và gỡ cài đặt.

• .claude-plugin/ — cho phép Claude Code cài đặt kỹ năng như một plugin tự cập nhật.

Cài đặt chỉ là một câu lệnh duy nhất giúp dạy AI của bạn biết sản phẩm là gì, và sau đó dừng lại:

npx @orcarouter/code-review

CLI phát hiện các tác nhân lập trình bạn sử dụng — danh mục bao phủ 36 nền tảng, từ Claude Code, Cursor, Codex, OpenCode và Windsurf đến GitHub Copilot, Gemini CLI, Amazon Q Developer, Cline, RooCode và các nền tảng khác — cài đặt kỹ năng rồi bàn giao. Sau đó, bạn chỉ cần hỏi tác nhân của mình bằng ngôn ngữ tự nhiên: “thiết lập OrcaCode Review trong repo này,” “chỉ chặn P0 thôi,” “tại sao review không chạy?” Kỹ năng này đảm nhận toàn bộ vòng đời: nó viết quy trình làm việc, hướng dẫn bạn từng bước tạo khóa API, thiết lập cổng chặn và chỉ hỏi đúng những câu hỏi mà bạn cần trả lời.

Thay vào đó, Claude Code có thể cài đặt kỹ năng như một plugin, giúp kỹ năng luôn được cập nhật khi repo thay đổi:

/plugin marketplace add Continuum-AI-Corp/orca-code-review

/plugin cài đặt orca-code-review

Không có agent nào à? Cùng vòng đời đó chỉ đơn giản là các lệnh con — init ghi workflow, reconfigure thay đổi quy tắc chặn và giới hạn diff, doctor chẩn đoán các review không chạy hoặc không được đăng, uninstall gỡ bỏ nó (trước tiên bỏ check bắt buộc). Skill là cửa trước, không phải là cửa duy nhất. Hoặc tự kết nối bằng tay: sao chép workflow, thêm một secret tên là ORCAROUTER_API_KEY, và đánh dấu review check là bắt buộc.

Bộ máy bên dưới là Open Code Review của Alibaba, được khóa ở một phiên bản cụ thể và được cấp phép theo Apache-2.0. OrcaCode quyết định cách thức đánh giá; OrcaRouter quyết định mô hình nào sẽ thực hiện việc đánh giá đó. Bảng đối chiếu giữa tự lưu trữ và lưu trữ dịch vụ — cái giá thực sự của “miễn phí” khi bạn tự lưu trữ một công cụ đánh giá mã nguồn mở — được trình bày chi tiết trong bài viết của chúng tôi về đánh giá mã nguồn mở.

Điều gì chạy, theo thứ tự, trên mỗi lần push?

Biết được thứ tự sẽ hữu ích, vì mỗi bước có thể thất bại hoặc bị bỏ qua một cách độc lập:

• Bộ bảo vệ diff chạy trước tiên, trước khi mô hình được chạy. Nếu diff merge-base vượt quá 512 KB hoặc chạm tới hơn 300 tệp, quá trình đánh giá sẽ bị bỏ qua và một thông báo sẽ được đăng. Mặc định là on-oversized-diff: fail, vì vậy một diff bị độn vượt quá giới hạn sẽ không thể đi qua một cổng bắt buộc mà chưa được đánh giá. Đây cũng là biện pháp kiểm soát chi phí: một PR quá khổ tốn 0 token.

• Công cụ rà soát diff. Một lượt, độ đồng thời cho mỗi tệp mặc định là 24, với trần thời gian thực là 20 phút mỗi lượt.

• Bộ lọc chính xác xử lý hậu kỳ các kết quả thô. L1, một bộ lọc tất định, xác minh đoạn mã hiện có được trích dẫn của từng phát hiện so với commit đã rà soát, đồng thời chuyển về đúng chỗ hoặc loại bỏ các kết quả không khớp. L2, một trình đánh giá LLM, nhóm các phát hiện theo nguyên nhân gốc và loại bỏ các cụm có độ tin cậy thấp. Cả hai lớp đều theo chế độ soft-fail: nếu có lỗi, kết quả của giai đoạn trước vẫn được giữ nguyên và quá trình rà soát không bao giờ bị hủy bỏ.

• Cổng chặn được áp dụng. Các phát hiện P0 và P1 khiến quá trình kiểm tra thất bại; phần tóm tắt PR tính mọi phát hiện, kể cả những phát hiện đã bị tắt tiếng khỏi diff.

• The meter prints what it cost. The meter input records per-call token accounting — prompt, completion, cached tokens, and the model the router resolved — and prints a totals table in the job log.

• Một báo cáo chạy tùy chọn gửi số lượng mức độ nghiêm trọng và siêu dữ liệu cổng đến mặt phẳng điều khiển OrcaRouter cho bảng điều khiển phân tích. Nó không chứa mã, không chứa diff và không chứa nội dung phát hiện.

Những gì bạn thực sự cấu hình

Có ba bề mặt, và chúng có phạm vi ảnh hưởng rất khác nhau.

1. Tệp workflow. Workflow sử dụng action được cố ý giữ cho tối giản. Các input đáng chỉnh nằm trong action: block-on (những mức độ nghiêm trọng nào làm cho bước kiểm tra thất bại — mặc định P0,P1), fix-first (những mức độ nghiêm trọng nào dừng sớm một cuộc rà soát toàn diện), auto-review-authors (một danh sách cho phép xác định ai sẽ được tự động rà soát), max-diff-kb và max-diff-files và on-oversized-diff (bộ kiểm soát kích thước), timeout-minutes, concurrency, meter, và report. Mỗi tham số đều có giá trị mặc định được tài liệu hóa, vì vậy workflow mới chỉ cần năm dòng YAML cộng với một secret.

2. Bảng điều khiển. Với settings: true (mặc định), mỗi lần chạy sẽ lấy cài đặt riêng cho từng kho lưu trữ từ OrcaRouter → Apps → OrcaCode Review: mô hình, chế độ đánh giá, chính sách hợp nhất, mức độ nghiêm trọng của báo cáo, chế độ im lặng, đánh giá toàn diện, tiêu chí đánh giá tùy chỉnh và các rào chắn bảo vệ. Đặt settings: "false" và tệp quy trình làm việc có quyền quyết định — không có giá trị nào từ bảng điều khiển có thể ghi đè được. Nếu bạn không bao giờ mở bảng điều khiển, bạn vẫn không mất đi tính năng nào của bộ khung; bạn chỉ cần cấu hình trong YAML.

3. Công thức định tuyến — công thức mà mọi người thường bỏ sót. Hành động không bao giờ đặt tên cho một mô hình. Thay vào đó, nó đưa các dữ kiện thô vào dưới dạng tiêu đề yêu cầu — bậc mà lần chạy được ghi nhận, liệu lượt kiểm tra trước có phát hiện P0/P1 hay không, và một điểm đánh dấu thấu kính khi yêu cầu là bộ đánh giá L2 — và công thức DSL của bộ định tuyến không gian làm việc ánh xạ các tiêu đề đó tới một mô hình cụ thể. Công thức được cung cấp mặc định đặt bài đánh giá là DeepSeek V4 Flash và bộ đánh giá là GLM-5.3, cố tình định tuyến hai tác vụ tới hai mô hình riêng biệt. Thay đổi mô hình đánh giá mã của bạn là một chỉnh sửa đối với công thức đó trong không gian làm việc của riêng bạn: không cần tăng phiên bản hành động, không cần viết lại YAML, không cần triển khai lại.

Quy ước về mức độ nghiêm trọng là hai thiết lập độc lập, không phải một. Chính sách merge quyết định điều gì chặn việc merge; mức độ nghiêm trọng báo cáo quyết định điều gì được đăng lên diff. Các mặc định cài sẵn là P0/P1 chặn, P2/P3 cho qua. Một mức độ nghiêm trọng thuộc nhóm chặn thì luôn được đăng lên, bất kể cài đặt báo cáo nói gì — một bài kiểm tra thất bại mà không có gì trên diff để giải thích còn tệ hơn một bài kiểm tra nhiễu. P0 nghĩa là một lỗ hổng bảo mật có thể bị khai thác, mất dữ liệu, sự cố trên luồng bình thường, hoặc bản dựng bị hỏng; P1 nghĩa là một lỗi thực sự nhưng có phạm vi ảnh hưởng hạn chế; P2 nghĩa là một khiếm khuyết thực sự chỉ phát sinh khi gặp điều kiện tiên quyết bất thường; P3 là vấn đề phong cách. Khi phân vân giữa hai mức, thang đánh giá quy định chọn mức thấp hơn.

Chi phí là bao nhiêu

Tính theo token, không phải theo ghế. Bạn chọn mô hình trên OrcaRouter, việc thanh toán chạy theo từng token đã tiêu thụ, và bộ đếm làm cho con số theo mỗi lần chạy hiển thị rõ ràng thay vì mơ hồ. Các cơ chế GitHub, tính năng đánh giá mã có đo lường của Copilot’s kể từ ngày 1 tháng 6 năm 2026, và cách các nhà đánh giá bên thứ ba hòa nhập vào quy trình làm việc đó được trình bày trong hướng dẫn đánh giá mã GitHub của chúng tôi. So sánh chi phí đầy đủ theo từng trường — các sản phẩm tính theo ghế so với các sản phẩm tính theo token, kèm ví dụ minh họa — nằm trong bài so sánh công cụ đánh giá mã AI của chúng tôi, và câu hỏi về chi phí của một lượt đánh giá đơn lẻ là bao nhiêu token khi người đánh giá thực sự khám phá kho mã (sự khác biệt giữa bot và agent) được đề cập trong bài viết về các agent đánh giá mã của chúng tôi. Điểm mà bài viết này bổ sung là hình dạng của hóa đơn: nó tăng theo mã bạn đánh giá, không phải theo số lượng người đánh giá.

Hai biện pháp kiểm soát chi tiêu quan trọng ngay từ ngày đầu. Trên kho lưu trữ công khai, pull_request_target bỏ qua cổng phê duyệt fork của GitHub và khóa xem xét được tính phí qua ví — người lạ có thể mở PR và kích hoạt các lượt xem xét trả phí. Đặt ngân sách ví kèm cảnh báo trên khóa và đặt auto-review-authors thành giá trị như OWNER,MEMBER,COLLABORATOR,CONTRIBUTOR để những người đóng góp không xác định không bị tự động xem xét. Và như đã lưu ý, bộ bảo vệ diff giúp các PR quá khổ không tốn chi phí gì cả.

Cái gì bị hỏng

Đánh giá tự động là CI. Nó hỏng như CI, và các chế độ lỗi hầu hết không phải do mô hình gây ra:

• Workflow không bao giờ chạy.Đối với pull_request_target thì workflow được đọc từ nhánh cơ sở — một workflow chỉ được thêm trong nhánh PR sẽ không chạy cho đến khi được hợp nhất. Cũng kiểm tra rằng ứng dụng đã được bật, auto_review đang bật, PR không phải là bản nháp (các bản nháp bị bỏ qua trong chế độ ready_for_review), và Actions được bật trên repository (các repo fork thường bị tắt sẵn).

• /orcacode-review không làm gì cả. Cơ chế kích hoạt qua bình luận yêu cầu bình luận phải bắt đầu bằng một trong bốn cách viết — /orcacode-review, /orcacode review, @orcacode-review, @orcacode review — và người bình luận phải là OWNER, MEMBER hoặc COLLABORATOR. Khoảng trắng ở đầu sẽ làm cho lệnh không khớp. Lệnh của người đóng góp bên ngoài bị âm thầm bỏ qua, có chủ đích: lệnh đó chạy một quy trình làm việc có đặc quyền giữ khóa trả phí.

• Lỗi xác thực.Bí mật bị đặt sai tên hoặc bị thiếu, khóa đã bị thu hồi hoặc vượt ngân sách, hoặc luồng công việc đã được chuyển sang pull_request (không thể đọc bí mật từ fork).

• Kiểm tra có màu đỏ với thông báo “diff too large”. Đó là bộ kiểm tra kích thước, hoạt động theo cấu hình. Tách PR, hoặc tăng giới hạn, hoặc đặt on-oversized-diff: pass — và hiểu rằng với một kiểm tra bắt buộc, pass có nghĩa là một PR đủ lớn sẽ đi thẳng qua cổng mà không được xem xét.

• Quá trình review chạy nhưng không có bình luận nào xuất hiện. Ba nguyên nhân, tất cả đều vô hại hoặc do cấu hình: một lần chạy sạch sẽ đăng bản tóm tắt thay vì các bình luận nội tuyến; chế độ im lặng đang tắt tiếng P2 tại thời điểm đăng (cổng kiểm tra và báo cáo vẫn tính nó); hoặc bộ lọc độ chính xác đã loại bỏ các phát hiện — L1 loại bỏ các phát hiện có đoạn trích không khớp với commit, L2 loại bỏ các cụm có độ tin cậy thấp. Số đếm mức độ nghiêm trọng trong nhật ký công việc cho bạn biết nguyên nhân nào.

Tư thế bảo mật đáng để nêu rõ ràng vì chính nó làm cho toàn bộ thiết kế an toàn. Công cụ chỉ đọc các file diff và file trong kho lưu trữ; nó không bao giờ thực thi mã PR. Trình đánh giá không có quyền merge — các phát hiện có thể chặn một bản merge hoặc thêm bình luận, nhưng không có đường mã nào cho phép đầu ra của mô hình phê duyệt hoặc thay đổi kho lưu trữ. Một phát hiện không được gắn thẻ sẽ fail-safe, được coi là hành động chặn thay vì chỉ mang tính tư vấn. Và báo cáo chạy không chứa mã hoặc văn bản phát hiện. Thiết lập hai lớp giúp bắt được những gì quá trình đánh giá một lượt bỏ sót là chủ đề của bài viết về bảo mật đánh giá mã AI của chúng tôi; mô hình mối đe dọa ở trên được ghi lại trong SECURITY.md của kho lưu trữ.

Khi đánh giá tự động không phải là công cụ phù hợp

Nó thường sai nhiều hơn những gì các nhà cung cấp công cụ thừa nhận. Hãy đứng ngoài cuộc này khi:

• Vấn đề là ngữ cảnh, không phải khối lượng. Nếu việc review chậm vì người review cần hiểu tại sao mã lại được viết theo cách này, thì việc một LLM đọc diff cũng chẳng giúp được gì nhiều. Nó không có trí nhớ về chuỗi thảo luận của tháng trước và không có hiểu biết về lịch sử của hệ thống.

• Bản diff chủ yếu là mã được sinh tự động hoặc mã nhúng (vendored). Đầu ra được định dạng tự động, các tệp scaffold, các bản snapshot dependency. Rà soát nó ngốn token và gây nhiễu, và đây chính là nơi chỉ thị quy ước giúp ích ít nhất — mã nguồn không phải là phong cách mà dự án lựa chọn.

• Nhóm vốn đã review theo cặp mọi thứ. Review tự động là đòn bẩy về khối lượng. Nếu mọi thay đổi đã được review bởi một người trong cuộc, thì máy chỉ thêm một ý kiến thứ hai thường kém thông tin hơn ý kiến đầu tiên.

• Không ai đọc những phát hiện. Một bản đánh giá không ai hành động theo là một quy trình làm việc thất bại nhưng vẫn mãi mãi xanh. Đây là lỗi thầm lặng phổ biến nhất, và không có bộ lọc chính xác nào khắc phục được.

• Việc đánh giá phải chạy mã. Nếu điều bạn cần là một bộ kiểm thử cho PR, thì đánh giá bằng LLM là công cụ sai. Nó chỉ đọc; nó không thực thi. Một cuộc quét bảo mật cần xây dựng và chạy artifact nên thuộc về một công việc riêng, có phạm vi được khoanh vùng cẩn thận — hãy nhớ, quy trình đánh giá không bao giờ được mở rộng để chạy mã do PR kiểm soát.

• Kho lưu trữ rất nhỏ hoặc chỉ dùng tạm thời. Dưới một tần suất thay đổi nhất định, việc review tốn nhiều công sức hơn so với các lỗi mà nó phát hiện được.

Dương tính giả, và những gì lọc chính xác khắc phục được và không khắc phục được.

The accusation against every AI reviewer is that it cries wolf. The harness attacks this in two layers, and it helps to be precise about which layer fixes which failure.

Tầng xác định (L1) loại bỏ phát hiện ma: một công cụ đôi khi khẳng định có mã không hề tồn tại — một đoạn mã bị lệch vị trí, một phát hiện được sao chép sang một tệp anh em. L1 xác minh đoạn mã hiện có của từng phát hiện dựa trên commit thực tế được xem xét và di dời hoặc loại bỏ các kết quả không khớp. Điều đó khắc phục loại lỗi dương tính giả kiểu "dòng này thậm chí không tồn tại", vốn mang tính máy móc và có thể kiểm chứng.

Lớp đánh giá (L2) loại bỏ các phát hiện trùng lặp và các tuyên bố không có cơ sở: một bộ đánh giá LLM phân nhóm các phát hiện theo nguyên nhân gốc và loại bỏ các cụm có độ tin cậy dưới ngưỡng đánh giá (mặc định 0,5). Điều này khắc phục “cùng một lỗi được báo cáo theo ba cách” và phát hiện mang tính suy đoán.

Điều mà cả hai lớp đều không khắc phục được đáng nói ra. Một phát hiện sai nhưng tự tin vẫn sống sót trước người đánh giá — người đánh giá là một LLM, và một LLM tỏ ra chắc chắn không đồng nghĩa với một phát hiện đúng. Một người đánh giá chạy trên cùng mô hình của người xem xét sẽ đồng tình với chính nó và lượt kiểm tra trở nên vô hiệu trong khi vẫn báo cáo thành công, đó là lý do tại sao công thức được cung cấp định tuyến người đánh giá sang một mô hình khác với mô hình của người xem xét. Và thang đo mức độ nghiêm trọng được cố ý thiết kế theo hướng thận trọng — “khi phân vân giữa hai mức, hãy chọn mức thấp hơn” — nghĩa là một lỗi thực sự nhưng có điều kiện có nhiều khả năng được xếp vào mức tư vấn P2 hơn là P1 chặn. Đó là sự hiệu chỉnh phù hợp cho một công cụ không được phép chặn mọi thứ, nhưng đó là một sự hiệu chỉnh: nó đánh đổi việc bỏ sót các lỗi chặn để lấy ít cảnh báo giả hơn. Tóm tắt PR luôn tính mọi phát hiện, vì vậy các P2 bị hạ thấp vẫn có đó để đọc. Nếu sự đánh đổi này không phù hợp với nhóm của bạn, thang đo và ngưỡng người đánh giá là cấu hình, không phải phiếu hỗ trợ.

Điểm mấu chốt

Đối với một nhóm đã quen sống trong GitHub Actions, bộ công cụ mã nguồn mở là cách rẻ nhất để có được đánh giá mã tự động trên mọi PR: một file workflow, một secret, hóa đơn token tăng theo lượng mã được đánh giá, và quyền chọn mô hình mà bạn tự sở hữu. Hãy mua sản phẩm tính phí theo ghế khi bạn muốn không phải vận hành gì và có một nhà cung cấp để gọi — không phải vì đánh giá tốt hơn, mà vì bạn đang mua vấn đề của người khác thay vì tự xử lý vấn đề của mình. Và trước khi thiết lập bất kỳ điều gì trong số đó, hãy tự hỏi liệu đánh giá có được đọc hay không. Bộ công cụ có thể khiến đánh giá diễn ra tự động. Nó không thể khiến bất kỳ ai đọc nó.

Muốn dùng cùng trình đánh giá mà không cần tự chạy? OrcaCode Review chạy chính bộ khung này dưới dạng GitHub App được lưu trữ — cùng công thức mở, cùng hóa đơn theo token, không tính theo số ghế.