Code Review với Claude Code: Bắt lỗi trước khi lên sản xuất

Claude Code Review là gì?

Claude Code Review là hệ thống rà soát mã đa tác nhân, xem xét PR trong ngữ cảnh của repo và báo cáo lỗi tiềm ẩn, vấn đề bảo mật và hồi quy. GitHub Code Review chạy các tác nhân đó trên một PR GitHub, trong khi /code-review cục bộ cho bạn bài rà soát diff hiện tại trực tiếp từ Claude Code.

Từ khóa quan trọng ở đây là ngữ cảnh. Rà soát diff truyền thống yêu cầu ai đó xem các dòng thay đổi. Tác nhân rà soát của Claude xem các thay đổi đó trong bối cảnh cả repo. Quy trình GitHub có nhiều tác nhân chuyên biệt chạy song song, sau đó là bước kiểm chứng, loại bỏ trùng lặp và xếp hạng mức độ nghiêm trọng.

Chẳng hạn, một thay đổi 10 dòng trong phép biến đổi pandas có thể phụ thuộc vào lược đồ do một mô hình dbt thượng nguồn tạo, đơn vị của một bảng Snowflake, và các giả định gắn trong dashboard hạ nguồn.

Claude không phê duyệt cũng không chặn PR. GitHub Code Review báo cáo kết luận kiểm tra trung lập, nên quy tắc bảo vệ nhánh hiện có của bạn vẫn giữ nguyên trừ khi bạn tự xây logic CI quanh đầu ra của check.

Ba bề mặt rà soát

Hiện có 3 cách chính để rà soát mã với Claude Code.

Lệnh /code-review cục bộ xem xét các commit trên nhánh của bạn. Bạn cũng có thể đưa vào một tệp, nhánh, số PR, hoặc dải Git ref cụ thể.

GitHub Code Review được thiết kế xoay quanh chính PR. Tùy cấu hình repo, nó có thể rà soát một lần sau khi tạo PR, sau mỗi lần push, hoặc chỉ khi ai đó yêu cầu bằng @claude review.

/code-review ultra là lựa chọn nặng hơn. Anthropic gọi tính năng này là ultrareview, và /ultrareview hoạt động như bí danh khi tính năng khả dụng cho tài khoản của bạn. Nó chạy một đội tác nhân rà soát trong sandbox từ xa, với mỗi lỗi được báo cáo đều được tái hiện và kiểm chứng trước khi xuất hiện trong phát hiện. Hiện là bản xem trước nghiên cứu, và một lượt rà soát điển hình mất khoảng 5 đến 10 phút.

Claude đánh dấu gì và bỏ qua gì

Claude Code Review tập trung trước hết vào tính đúng đắn. Tài liệu của Anthropic phân biệt rõ lỗi ảnh hưởng sản xuất với sở thích định dạng và thiếu độ bao phủ kiểm thử.

Các phát hiện dùng 3 mức độ nghiêm trọng:

Sự phân biệt đó hữu ích vì các nhà khoa học dữ liệu thường có quan điểm rất khác nhau về việc gì đáng tốn thời gian rà soát. Gợi ý đặt tên revenue_df so với weekly_revenue không cùng hạng với việc nhân đôi doanh thu do một join nhiều-nhiều lọt vào một phép biến đổi.

Thiết lập Code Review trong Claude Code như thế nào?

Thiết lập Claude Code Review yêu cầu các bước khác nhau tùy bạn muốn rà soát cục bộ hay rà soát mã PR trên GitHub. /code-review cục bộ không cần GitHub App và có thể thực hiện trước cả khi bạn mở PR. 

GitHub Code Review yêu cầu Chủ sở hữu (Owner) hoặc Chủ sở hữu chính (Primary Owner) của tổ chức cấu hình Claude GitHub App và chọn repo. Khi thực hiện rà soát PR, bạn sẽ muốn tạo tệp chuyên dụng REVIEW.md chứa các quy tắc chỉ dành cho rà soát.

CLAUDE.md và REVIEW.md

CLAUDE.md và REVIEW.md phục vụ các mục đích khác nhau, và trộn chúng lại rất dễ tạo ra các bài rà soát ồn ào.

CLAUDE.md chứa hướng dẫn dự án tổng quát mà Claude dùng cho nhiều tác vụ. Rà soát mã cũng đọc các hướng dẫn đó, và vi phạm mới sẽ được báo cáo là các mục vặt. REVIEW.md thì dành riêng cho hành vi rà soát và cho biết các tác nhân nên đánh dấu, bỏ qua, hoặc coi là Quan trọng điều gì.

Với một repo dữ liệu Python, tôi sẽ giữ CLAUDE.md tập trung vào những thứ như cấu trúc repo, cách chạy pytest, các phép biến đổi dùng pandas hay polars, và nơi đặt các mô hình SQL. 

Tôi sẽ đặt quy tắc rà soát trong REVIEW.md. Một vài ví dụ quy tắc tiềm năng:

• “Kiểm tra mọi phép biến đổi mới có bài kiểm thử tương ứng.”
• “Không bao giờ ghi log thông tin xác thực.”
• “Bỏ qua file sinh tự động.”

Một REVIEW.md nhỏ có thể trông như sau:

# Review instructions

## Important findings

Report as Important:
- Incorrect joins or filters that can change dataset grain
- Missing tenant or customer scoping
- Secrets or credentials written to logs
- Silent changes to revenue or customer metrics

## Do not report
- Formatting already enforced by Ruff
- Generated files
- *.lock files

## Always check
- New transformations have tests
- Joins use the intended keys
- Datetime operations specify timezone assumptions
- Missing values are handled explicitly

Tôi khuyên bạn nên giữ REVIEW.md gọn vì hướng dẫn quá dài có thể làm loãng các quy tắc quan trọng. Bản triển khai hiện tại cũng đọc tệp như hướng dẫn thuần văn bản, vì vậy bạn nên đặt quy tắc trực tiếp vào đó thay vì dùng lối tắt @. 

Nhân tiện, khi bạn phát triển cục bộ, /code-review không đọc REVIEW.md. Nó theo CLAUDE.md, trong khi pipeline GitHub Code Review dùng REVIEW.md cho hướng dẫn cụ thể của rà soát.

Nếu bạn muốn có cùng quy tắc rà soát ở cục bộ và trên GitHub, hãy đặt quy tắc chung trong CLAUDE.md và lặp lại các quy tắc dành riêng cho rà soát trong REVIEW.md khi cần.

Để tìm hiểu sâu hơn, tôi khuyên đọc hướng dẫn viết tệp CLAUDE.md tốt nhất của chúng tôi.

GitHub App và chế độ kích hoạt

GitHub Code Review được cấu hình bởi Chủ sở hữu hoặc Chủ sở hữu chính của tổ chức thông qua phần cài đặt quản trị của Claude. Quản trị viên cần cài Claude GitHub App, cấp quyền truy cập repo, chọn repo để rà soát, rồi gán hành vi rà soát cho từng repo.

Có 3 chế độ kích hoạt:

Một ngoại lệ cho cả 3: Claude không bao giờ tự động rà soát pull request đến từ fork. Ai đó phải bình luận @claude review vào đó.

Tính đến bản cập nhật tháng 7/2026, các lệnh thủ công cũng đã thay đổi: 

• @claude review khởi động một lượt rà soát và không đăng ký PR cho các lần push sau. 

• @claude review always khởi động một lượt và đăng ký PR để sau này mỗi lần push sẽ kích hoạt rà soát.

• @claude review once hoạt động giống lệnh trần.

Nếu bạn học Claude Code Review hồi đầu 2026, các hướng dẫn cũ có thể nói rằng @claude review sẽ đăng ký PR cho lần rà soát sau, nhưng hành vi đó đã thay đổi từ tháng 7/2026 và vẫn đúng đến tháng 9/2026.

Người dùng Pro và Max không có quyền với GitHub Code Review của tổ chức có thể bỏ qua App hoàn toàn và dùng /code-review cục bộ, với /code-review ultra cho rà soát sâu hơn.

Bạn rà soát một diff cục bộ với /code-review như thế nào?

Lệnh /code-review cục bộ rà soát nhánh hiện tại của bạn trước khi bạn mở PR. Tôi luôn bắt đầu bằng cách này vì nó bắt lỗi khi tôi còn đang làm việc và có thể ngăn CI thất bại.

Tình huống để rà soát

Giả sử chúng ta có repo thương mại điện tử với bảng đơn hàng chứa order_id, customer_id, order_date, status, và revenue, và ta tạo weekly_revenue.py để tính doanh thu theo tuần:

orders = load_orders()
customers = load_customers()

# Derive the reporting week from the order date
orders["week"] = orders["order_date"].dt.to_period("W").dt.start_time

weekly_revenue = (
    orders
    .merge(customers, on="customer_id", how="inner")
    .groupby("week", as_index=False)["revenue"]
    .sum()
)

Nhìn qua thì chẳng có gì lạ. merge() rõ ràng, group dễ đọc, và doanh thu được tổng hợp sau khi join.

Vấn đề là bảng khách hàng có nhiều bản ghi lịch sử cho một số khách. Một khách có 2 bản ghi giờ tạo ra 2 dòng sau phép join, nhân đôi doanh thu gắn với khách đó. Đây chính xác là kiểu lỗi dễ bỏ sót khi bạn đọc phép biến đổi cục bộ mà không kiểm tra đơn vị của bảng.

Giới hạn phạm vi diff

Từ phiên Claude Code của bạn, chạy /code-review.

Lệnh rà soát các commit của nhánh hiện tại so với nhánh thượng nguồn, cùng với thay đổi chưa commit. Bạn cũng có thể nhắm tới một tệp, nhánh, PR, hoặc dải, như main...feature/weekly-revenue.

Ví dụ:

/code-review weekly_revenue.py

hoặc:

/code-review main...feature/weekly-revenue

Bạn cũng có thể truyền mức độ nỗ lực, như /code-review high. Ở low và medium, bài rà soát chỉ báo các phát hiện mà nó tự tin nhất, trong khi high đến max mở rộng phạm vi với cái giá là có thể tăng dương tính giả. 

Dùng cờ để điều hướng rà soát

Khi đã quen quy trình, hai cờ sau sẽ hữu ích: 

• --fix áp dụng các phát hiện vào working tree của bạn sau khi rà soát.

• --comment đăng chúng thành bình luận nội tuyến.

Claude chạy bài rà soát như một tác nhân nền, nên bạn có thể tiếp tục làm việc trong lúc thay đổi được xử lý. Các phát hiện sẽ trả về phiên của bạn khi rà soát xong.

Bài rà soát có thể báo như sau:

🔴 Important
weekly_revenue.py:9

The merge on customer_id can duplicate order rows because
customers contains multiple records per customer. This can
inflate revenue when a customer has more than one matching
customer record.

Verify that customer_id is unique in customers or join against
the intended current-record subset before aggregating revenue.

Bài rà soát tìm được một kịch bản hỏng cụ thể và đưa tôi thứ có thể kiểm chứng với lược đồ thực, thay vì yêu cầu tôi tin vào phán đoán của Claude.

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

Tôi vẫn sẽ rà soát thủ công mọi thứ trước khi chạy /code-review --fix. Đầu tiên, tìm đoạn mã xây customers, kiểm tra ràng buộc duy nhất, và xem các kiểm thử quanh weekly_revenue.py.

Nếu customers.customer_id thực sự là duy nhất, phát hiện của Claude là dương tính giả. Nếu bảng chứa một dòng cho mỗi khách theo ngày hiệu lực, phát hiện là thật, và phép biến đổi cần thay đổi.

Điểm mấu chốt là người rà soát của Claude xem xét hành vi mã, còn tôi vẫn chịu trách nhiệm biết dữ liệu đại diện cho điều gì.

Bạn có thể yêu cầu Claude điều tra sau khi rà soát:

Investigate the customer_id join finding.
Check how the customers table is built and determine whether
customer_id is unique at the point of this merge. Do not modify
the code yet.

Bước thứ hai này thường hữu ích hơn là bảo Claude sửa bình luận một cách mù quáng. Nó biến rà soát thành một cuộc điều tra ngắn thay vì một bài sinh mã.

Chạy Claude Code Review trên một PR GitHub như thế nào?

GitHub Code Review đặt phát hiện của Claude trực tiếp lên PR, để người rà soát có thể thấy vấn đề ngay cạnh đoạn mã thay đổi. 

Thứ tự quan trọng vì bài rà soát gắn với một PR đã tồn tại:

1. Push nhánh weekly-revenue lên GitHub qua git push.

2. Mở pull request. Claude chỉ có thể rà soát một PR đã mở, nên trước đó sẽ chưa có gì xảy ra.

3. Nếu repo đặt tự động, rà soát sẽ tự chạy. Nếu đặt Thủ công, đăng @claude review như một bình luận PR cấp cao nhất để bắt đầu.

Ba yêu cầu hay làm mọi người nhầm. Lệnh phải là bình luận PR cấp cao nhất chứ không phải trả lời một bình luận rà soát nội tuyến, và bạn cần quyền write, maintain, hoặc admin trên repo. Lệnh cũng phải đứng đầu bình luận, với once hoặc always trên cùng dòng nếu thêm vào.

Kích hoạt rà soát

Lựa chọn thực sự khiến bạn tốn tiền là giữa hai lệnh thủ công, không phải giữa thủ công và tự động.

@claude review chạy một lượt rà soát và để PR không đăng ký theo dõi. @claude review always chạy một lượt và đăng ký PR, nên mọi lần push sau sẽ bắt đầu lượt mới.

Đây là hành vi sau tháng 7/2026 và tính đến tháng 9/2026. Trước cập nhật đó, lệnh @claude review trần sẽ đăng ký PR cho các lượt sau, nên nếu bạn theo hướng dẫn cũ, hãy kiểm tra điểm này trước.

Bài rà soát thường mất khoảng 20 phút, dù Anthropic nói chi phí và thời lượng phụ thuộc kích cỡ và độ phức tạp PR. Mỗi lượt rà soát cũng được tính phí riêng qua credits sử dụng, thay vì tiêu hao usage đi kèm gói Team hay Enterprise. Nếu bạn muốn tìm hiểu thêm về cấu trúc chi phí, tôi khuyên đọc hướng dẫn giới hạn sử dụng Claude Code của chúng tôi.

Đọc bình luận nội tuyến và check run

Khi rà soát xong, Claude đăng bình luận nội tuyến tại các dòng liên quan. Check run trên GitHub cũng kèm tóm tắt mức độ nghiêm trọng, hữu ích khi một PR có nhiều phát hiện trải khắp weekly_revenue.py, các mô hình SQL, và tệp kiểm thử.

Ví dụ:

Bình luận nội tuyến là nơi tôi sẽ điều tra vấn đề thực tế. Check run là nơi tôi nắm bức tranh tổng thể của bài rà soát.

Lưu ý, bấm 👍 hoặc 👎 không kích hoạt lượt rà soát khác, và trả lời bình luận nội tuyến không khiến Claude phản hồi. Để có lượt khác, hãy sửa mã và push, hoặc đăng @claude review như bình luận PR cấp cao nhất mới.

Bài rà soát cũng không tự chặn hợp nhất. Check đưa ra kết luận trung lập, dù đầu ra check có kèm thông tin mức độ nghiêm trọng có thể đọc bằng máy mà đội ngũ có thể tiêu thụ qua gh và jq nếu muốn xây cổng hợp nhất riêng.

Bạn phân loại bình luận rà soát của Claude như thế nào?

Mục tiêu là giữ con người trong vòng lặp trong chu trình rà soát. Điều này có nghĩa mỗi bài rà soát của Claude đều cần quyết định liệu từng phát hiện là lỗi thật, cải tiến không chặn, hay dương tính giả. Vì người rà soát mã có thể kiểm tra hành vi triển khai mà không biết mọi giả định nghiệp vụ phía sau một tập dữ liệu hay chỉ số.

Tôi dùng quyết định 3 hướng đơn giản:

Hạng mục cuối quan trọng. Người rà soát báo 30 phát hiện không nhất thiết tốt hơn người báo 5. Một bình luận dương tính giả về phép merge trong pandas có thể tốn nhiều thời gian hơn chính thay đổi mã ban đầu.

Sửa, bỏ qua, hay phản biện

Nếu lỗi nhân đôi dòng khách hàng là thật, tôi có thể yêu cầu Claude kiểm tra mô hình thượng nguồn rồi áp dụng sửa sau:

The customer_id finding is valid. Inspect the existing customer
model and update weekly_revenue.py to join only the current
customer record. Add a regression test for a customer with
multiple historical records, then run the relevant tests.

Claude có thể kiểm tra repo, thay đổi mã Python, thêm kiểm thử và chạy bộ kiểm thử.

Nếu bạn muốn làm từ bình luận rà soát trên GitHub, Claude Code cũng có thể tương tác với repo qua GitHub CLI (gh). Điểm khác quan trọng là tôi sẽ chọn lọc những sửa đổi cụ thể mà bạn cho là hợp lệ, thay vì đưa toàn bộ bài rà soát để “sửa hết”.

Điều này giữ nhà phát triển trong vòng lặp rà soát:

1. Claude tìm vấn đề có thể xảy ra.
2. Tôi kiểm chứng vấn đề với mã và giả định dữ liệu.
3. Claude thực hiện sửa đổi được yêu cầu.
4. Chạy kiểm thử.
5. Claude rà soát lại diff kết quả.

Vòng lặp này an toàn hơn nhiều so với coi đầu ra rà soát đầu tiên như một hàng đợi tái cấu trúc tự động.

Một PR dữ liệu vẫn cần con người cho việc gì?

Dạng hỏng mà Claude không bao quát là mã chạy đúng nhưng vẫn làm sai việc. Ba biến thể của điều đó lặp lại hết lần này đến lần khác:

• Giả định nằm ngoài diff. Claude đọc repo của bạn, không đọc kho dữ liệu, dịch vụ cấu hình, hay hợp đồng đội khác sở hữu. Một phép join có thể dùng đúng khóa nhưng vẫn thay đổi đơn vị kết quả, vì số dòng trên mỗi khóa là thuộc tính của bảng thượng nguồn, không phải của đoạn mã trước mắt.

• Định nghĩa chỉ đội bạn nắm. Doanh thu nên tính ở cấp đơn hàng, khách hàng, hay tuần là quyết định kinh doanh. Claude có thể nói groupby() sẽ cộng bất cứ dòng nào nó được đưa. Nó không thể nói số nào đội tài chính phê chuẩn.

• Giả định về thời gian và kiểu. 2026-08-27 là ngày UTC, ngày làm việc địa phương, hay ngày báo cáo do mô hình thượng nguồn đặt? Ép kiểu âm thầm cũng tương tự: thao tác giữa cột object, số nguyên nullable, datetime có múi giờ, và chuỗi có thể trả về thứ trông hợp lý nhưng âm thầm thay đổi cách so sánh hoạt động.

Rò rỉ dữ liệu là ví dụ sắc bén nhất của loại đầu tiên. Một phép biến đổi đặc trưng có thể join tập huấn luyện với bảng chứa thông tin chỉ tồn tại sau ngày dự đoán. Join hợp lệ, số dòng đúng như mong đợi, và mô hình bị nhiễm bẩn.

Vì vậy tôi coi Claude là người rà soát hành vi triển khai, không phải chủ sở hữu định nghĩa.

Khi nào nên dùng Code Review và khi nào dùng Ultrareview?

Dùng /code-review để có phản hồi nhanh cục bộ và /code-review ultra cho lượt rà soát sâu hơn trước khi hợp nhất. Cả hai cùng rà soát mã, nhưng /code-review thiết kế cho vòng lặp, còn bài ultra chạy nhiều tác nhân từ xa và độc lập kiểm chứng lỗi được báo cáo.

Anthropic hiện mô tả ultra review là bản xem trước nghiên cứu. Thuê bao Pro và Max nhận 3 lượt miễn phí một lần (không làm mới), sau đó một lượt thường có giá $5 đến $25 tùy kích thước thay đổi. Người dùng Team và Enterprise không nhận các lượt miễn phí này, và tính năng không khả dụng trên Amazon Bedrock, Google Cloud's Agent Platform, Microsoft Foundry, cũng như với tổ chức bật Zero Data Retention.

Khác biệt quan trọng là kiểm chứng. /code-review ultra gửi trạng thái repo lên sandbox từ xa và chạy một đội tác nhân rà soát, với lỗi được báo cáo được tái hiện độc lập trước khi trả về.

Tôi sẽ không chạy nó trên mọi commit. Nếu tôi đổi tên biến trong notebook Python hay điều chỉnh định dạng mô hình dbt, /code-review cục bộ là đủ. Nếu tôi thay đổi logic sinh đặc trưng cho mô hình sản xuất, viết lại phép biến đổi doanh thu, hoặc sửa tổng hợp cấp khách hàng, lượt rà soát bổ sung này hợp lý hơn.

Cũng có một chi tiết đặt tên đáng lưu ý. Lệnh được ghi nhận là /code-review ultra, và /ultrareview là bí danh hoạt động khi ultrareview khả dụng cho tài khoản của bạn. Các hướng dẫn cũ thường đưa /ultrareview là lệnh chính, nhưng tài liệu của Anthropic nay coi lượt rà soát đám mây sâu là một phần của họ lệnh /code-review, và /code-review ultra sẽ quay về rà soát cục bộ khi tính năng đám mây không khả dụng.

Chạy ultra review trên cùng PR

Từ repo, chạy:

/code-review ultra

Để rà soát trực tiếp một PR GitHub:

/code-review ultra <pr#>

Không có đối số, /code-review ultra so sánh nhánh hiện tại của bạn với nhánh mặc định và bao gồm cả thay đổi chưa commit và đã staged. Một lượt rà soát nhánh mặc định giới hạn khoảng 500 tệp thay đổi và 8.000 dòng thay đổi, dù Anthropic lưu ý các con số này có thể thay đổi. Nếu diff của bạn quá lớn, hãy push nhánh và rà soát như PR.

Với số PR, môi trường từ xa sẽ clone PR từ GitHub, và không có gì được tải lên từ máy của bạn.

Trước khi bắt đầu, Claude hiển thị phạm vi rà soát, số lượt miễn phí còn lại, và chi phí ước tính. Sau khi xác nhận, lượt rà soát chạy nền, nên bạn có thể tiếp tục dùng Claude Code trong lúc tác nhân từ xa làm việc.

Với ví dụ weekly_revenue.py, tôi sẽ so sánh các phát hiện thay vì mặc định cho rằng lượt rà soát sâu hơn luôn đúng.

Nếu /code-review gắn cờ join khách hàng và ultra review độc lập tái hiện việc nhân đôi doanh thu, niềm tin của tôi vào phát hiện đó tăng lên. Nếu ultra review bỏ qua vì bảng thượng nguồn đảm bảo tính duy nhất, tôi sẽ kiểm tra bằng chứng từ cả hai lượt và định nghĩa mô hình thực tế trước khi sửa mã.

Đó là lợi ích của nhiều người rà soát: bất đồng cho bạn điều để điều tra.

Cũng có cân nhắc chi phí. GitHub Code Review hiện trung bình $15 đến $25 mỗi lượt, trong khi ultra review thường tốn $5 đến $25 sau các lượt Pro và Max miễn phí. Chi phí GitHub Code Review tách biệt với usage đi kèm gói, và Anthropic cung cấp kiểm soát chi tiêu cho tổ chức.

Nếu bạn làm một mình, /code-review cục bộ cộng thêm một vài lượt /code-review ultra là quy trình khởi đầu hợp lý. Nếu bạn ở gói Team hoặc Enterprise và muốn mỗi PR đều có rà soát tự động, GitHub Code Review hợp lý hơn.

Quy trình Claude Code Review thực tiễn

Quy trình hữu ích không phải “chạy Claude trước mọi lần hợp nhất.” Mà là chuỗi trong đó mỗi lượt rà soát diễn ra ở thời điểm khác nhau của phát triển, vì mỗi lượt có chi phí khác nhau và bắt được lớp vấn đề khác nhau.

Đây là quy trình tôi dùng cho thay đổi sản xuất:

Write code
	   ↓
Run tests and data checks
	   ↓
/code-review
	   ↓
Fix verified findings
	   ↓
Open GitHub PR
	   ↓
GitHub Code Review
	   ↓
Human triage
	   ↓
/code-review ultra for higher-risk changes
	   ↓
Final tests
	   ↓
Human merge

Rà soát cục bộ bắt lỗi khi còn rẻ để sửa. Rà soát trên GitHub cung cấp cho đội ngũ bản ghi chung về các phát hiện, còn ultra review đưa ra ý kiến thứ hai với nỗ lực cao hơn trước một lần hợp nhất hệ trọng.

Các kiểm tra bổ sung cho nhà khoa học dữ liệu

Với công việc dữ liệu, tôi sẽ thêm 4 kiểm tra quanh Claude thay vì kỳ vọng mô hình thực hiện toàn bộ rà soát:

• Kiểm tra số dòng và đơn vị tập dữ liệu trước và sau các phép join quan trọng
• Chạy unit hoặc integration test quanh phép biến đổi và logic đặc trưng.
• Kiểm tra rò rỉ khi xây dựng đặc trưng học máy.
• Đối soát chỉ số kinh doanh với truy vấn hoặc dashboard chuẩn.

Claude có thể tham gia cả 4 hoạt động, nhưng kết quả kỳ vọng nên đến từ mã, kiểm thử, hoặc dữ liệu chứ không phải lời giải thích của Claude.

Tổng kết

Claude Code Review hiệu quả nhất khi tôi coi nó như một kỹ sư khác trong luồng rà soát, không phải con dấu phê duyệt tự động.

Lệnh /code-review cục bộ cho bạn rà soát nhanh trước khi PR tồn tại. GitHub Code Review đưa phát hiện đa tác nhân vào PR cho tổ chức Team và Enterprise, trong khi /code-review ultra cho bạn lượt rà soát từ xa sâu hơn khi thay đổi xứng đáng.

Tôi sẽ bắt đầu từ nhỏ. Đưa /code-review vào quy trình nhánh bình thường, viết một REVIEW.md ngắn cho các lượt GitHub, và thử /code-review ultra trên những thay đổi mà một lần hợp nhất lỗi sẽ thực sự khiến bạn tốn kém.

Về các khái niệm mô hình nền tảng, khóa học Giới thiệu về các mô hình Claude cung cấp bối cảnh rộng hơn, trong khi GitHub Foundations và Intermediate GitHub Concepts đề cập quy trình Git và GitHub mà Code Review dựa trên đó. Để có thêm cảm hứng về cách phân loại repo GitHub với Claude, tôi cũng khuyên đọc hướng dẫn Claude Code connector của chúng tôi.