# Nhờ AI review pull request, code của bạn đi đâu?

Mỗi lần AI review một PR, cái diff đó phải đi đâu đó để model đọc được, có khi kèm cả mấy file nó import. Mình từng thắc mắc về chuyện này, và chắc bạn cũng vậy.

Nhóm mình có làm một con bot như thế, tên là Owlet Lens, mã nguồn mở, Apache-2.0. Trong bài này mình kể ba chuyện làm tụi mình băn khoăn nhất khi làm nó, và cách tụi mình giải quyết.

1. Lỡ có secret trong diff thì sao?

Chuyện này cũng dễ xảy ra, nhất là những lúc vội. Vì vậy trước khi gửi gì đi, tool quét diff, các file được import và cả câu trả lời của dev. API key, token, mật khẩu trong chuỗi kết nối, khóa riêng PEM... gặp là đổi thành [REDACTED]. Mỗi lần che đều được ghi vào log, nên bạn có thể xem nó có làm việc thật không.

Nhưng mình cũng muốn nói thẳng: đây là so khớp mẫu chứ không phải phép màu. Secret nào không giống mẫu nào thì vẫn có thể lọt, và file bạn chủ động đưa vào làm ngữ cảnh sẽ được gửi nguyên văn. Tụi mình có ghi rõ điều này trong tài liệu.

Ở giữa cũng không có máy chủ nào của tụi mình. Bạn dùng key của mình (Anthropic, Gemini, DeepSeek, OpenRouter, hoặc endpoint nào tương thích OpenAI), hay trỏ tới một model tự host đều được.

2. Bot mà cứ nhắc lại mãi thì dễ bị bỏ qua

Ảnh minh họa luồng hoạt động.

Ai dùng bot review rồi chắc cũng biết cảm giác push một cái là nó nhắc lại y chang cái cũ. Nên ở đây, finding nào còn mở thì lần push sau sẽ không bị đăng lại.

Phần mình thích nhất là chế độ learn. Khi dev trả lời kiểu "chỗ này ổn, vì...", tool ghi nhận là team đã từ chối finding đó. Khi cùng một kiểu xuất hiện đủ nhiều lần, nó mở một PR đề xuất thêm một quy tắc vào tiêu chuẩn code của bạn.

Không có gì tự merge cả. Luôn có một người đọc PR đó trước: bot đề xuất, người quyết định.

3. Khi bản nháp chưa sẵn sàng

Có team không muốn bot xen vào từng lần push lúc PR còn đang nháp. Với TL gate, bot sẽ chờ. PR đang bị giữ thì không gọi LLM nên không tốn chi phí. Khi team lead thấy ổn, họ bấm nút Re-run all jobs có sẵn của GitHub, và từ đó PR được review ở mỗi lần push.

review:
  tlGate:
    enabled: true
    leads: ["12345", "67890"]   # ID người dùng dạng số

Công tắc này được đọc từ nhánh đích, nên một PR không tự tắt cổng của mình bằng cách sửa file cấu hình. Dù vậy, một PR vẫn có thể sửa file workflow, nên tụi mình xem đây là một quy ước tiện cho team hơn là một lớp bảo mật.

Nếu bạn muốn thử

Công cụ review PR trên GitHub, GitLab, Bitbucket Cloud và Azure DevOps, chạy được như một GitHub Action hoặc từ dòng lệnh:

npm i -g @openwt-vn/owlet-lens

Tụi mình có thử một bài nhỏ: tự mở một PR rồi cài vào 4 bug, và nó chỉ ra cả 4. Đó là bài thử do chính nhóm mình viết, nên mình không dám nói nó hơn công cụ nào khác. Tụi mình chưa benchmark, và về chi phí thì mới có hai PR nhỏ, tốn khoảng $0.006 và $0.009 tiền token.

• Repo và tài liệu: https://github.com/openwt-vn/owlet-lens
• npm: https://www.npmjs.com/package/@openwt-vn/owlet-lens

Nếu bạn có dịp thử trên code của mình, tụi mình rất vui được nghe cảm nhận. Kể cả khi nó bỏ sót một lỗi, hoặc đưa ra một nhận xét không đúng, một issue ngắn kể lại trường hợp đó cũng giúp tụi mình rất nhiều. Cảm ơn bạn đã đọc đến đây.