Trả lời nhanh: Xem lại code do agent viết cần chú ý những lỗi khác với code người viết. Bốn lỗi đặc trưng: làm nhiều hơn mức được yêu cầu, thêm thư viện thay vì dùng thứ đã có, xử lý đường đi thuận lợi rất tốt nhưng bỏ trường hợp biên, và tạo ra thứ trông đúng nhưng không khớp quy ước dự án. Thứ tự đọc hiệu quả: xem danh sách file trước, rồi phần thay đổi hợp đồng, rồi mới tới logic.
Code do agent viết thường sạch sẽ và có chú thích đầy đủ, nên nó tạo cảm giác dễ duyệt hơn code người viết vội. Chính cảm giác đó là cái bẫy: nó khiến bạn đọc lướt, trong khi những lỗi của nó nằm ở chỗ khác với lỗi của người.
Bốn lỗi đặc trưng
Làm nhiều hơn mức được yêu cầu. Bạn nhờ sửa một hàm, nó tiện tay dọn luôn ba file bên cạnh. Thay đổi thêm có thể đúng, nhưng chúng nằm ngoài phạm vi bạn đang tập trung xem, và đó là nơi lỗi lọt qua.
Thêm thư viện thay vì dùng thứ đã có. Đây là đường ngắn nhất tới kết quả, nên nó rất hay chọn. Kiểm tra file khai báo phụ thuộc ở mỗi lần duyệt.
Xử lý đường thuận lợi rất tốt, bỏ trường hợp biên. Danh sách rỗng, mạng lỗi giữa chừng, dữ liệu có giá trị bất thường. Code trông hoàn chỉnh nhưng chỉ đúng khi mọi thứ diễn ra như mong đợi.
Trông đúng nhưng lệch quy ước. Dùng một kiểu quản lý trạng thái khác, đặt file ở chỗ khác, gọi database trực tiếp thay vì qua lớp truy cập. Mỗi lần như vậy là một vết nứt trong tính nhất quán.
Thứ tự đọc hiệu quả
Đừng đọc từ trên xuống. Ba bước theo thứ tự này bắt được nhiều lỗi nhất trong ít thời gian nhất:
- Danh sách file đã đổi. Có file nào bạn không ngờ tới không. Đây là chỗ lộ ra việc làm quá phạm vi, và nó mất mười giây.
- Thay đổi hợp đồng. Đổi tham số của một hàm dùng chung, đổi cấu trúc dữ liệu trả về, đổi lược đồ database. Những thứ này ảnh hưởng ra ngoài phạm vi thay đổi.
- Logic nghiệp vụ. Bây giờ mới đọc chi tiết, và chỉ ở những chỗ thật sự chứa quyết định.
Phần chú thích và cách đặt tên thì đọc lướt. Đó là chỗ code AI sinh thường làm tốt, và cũng là chỗ ít gây hại nhất khi có sai sót.
Dùng agent làm lớp lọc trước
Cách hiệu quả là để một phiên khác rà trước, rồi bạn đọc kết quả. Yêu cầu nên cụ thể:
Ra soat cac thay doi chua commit.Soi dung bon cho:1. File nao bi sua ma nam ngoai pham vi "them luong hoan tien"2. Thu vien moi duoc them vao3. Cho nhan du lieu ma khong kiem tra truong hop rong hoac loi4. Cho khong theo quy uoc trong file quy uoc du an Toi da 8 phat hien, moi dong: duong dan, so dong, van de.Khong sua gi.Điểm quan trọng: phiên rà soát phải khác phiên đã viết code. Cùng một phiên thì nó có xu hướng bảo vệ những gì vừa làm, và nó cũng mang theo mọi giả định đã hình thành trong lúc viết.
Đây là lớp lọc, không phải lớp quyết định. Nó bắt tốt các lỗi máy móc, còn phần đánh giá thiết kế vẫn là việc của bạn.
Ba câu hỏi cuối trước khi gộp
Tôi có giải thích được từng thay đổi không? Nếu có một đoạn mà bạn không hiểu vì sao nó ở đó, hãy hỏi lại trước khi gộp. Đoạn code không ai hiểu là nợ kỹ thuật ngay từ ngày đầu.
Có gì trong này mà tôi không yêu cầu? Thay đổi thêm không phải lúc nào cũng xấu, nhưng chúng cần được nhận diện và duyệt riêng.
Nếu nó sai, tôi phát hiện bằng cách nào? Có kiểm thử che phần này không, hay bạn chỉ dựa vào việc đọc. Với phần quan trọng mà chưa có kiểm thử, hãy yêu cầu viết trước khi gộp.
Ba câu này mất một phút và chúng thay thế được rất nhiều thời gian đọc dòng lệnh chi tiết.
Với luồng tự động
Khi bạn đã dựng luồng rà soát tự động cho mỗi pull request theo bài về GitHub Actions, hãy nhớ hai điều:
- Nhận xét tự động không thay việc xem lại của đồng nghiệp. Nó là lớp đầu tiên, không phải lớp cuối.
- Giới hạn số nhận xét. Một bình luận với hai chục điểm sẽ bị lướt qua. Năm điểm quan trọng nhất có tác dụng hơn nhiều.
Và nguyên tắc bao trùm, nhắc lại vì nó quan trọng nhất: người gửi thay đổi chịu trách nhiệm về nó, dù nó do ai hay cái gì viết ra. Cách đặt quy ước này cho cả đội nằm ở bài dùng agent theo đội.
Thứ tự đọc theo mức rủi ro
| Thứ tự | Đọc gì | Vì sao ưu tiên |
|---|---|---|
| 1 | Phần chạm vào xác thực, phân quyền, thanh toán | Sai ở đây là mất tiền hoặc lộ dữ liệu, không phải lỗi hiển thị |
| 2 | Truy vấn cơ sở dữ liệu mới thêm | Truy vấn thiếu điều kiện lọc theo người dùng là lỗ hổng phổ biến nhất |
| 3 | Xử lý lỗi và trường hợp biên | Đây là chỗ hay bị bỏ trống nhất trong mã sinh tự động |
| 4 | Thư viện mới được thêm vào | Mỗi thư viện thêm vào là thêm bề mặt rủi ro, hỏi xem có thật sự cần không |
| 5 | Cách đặt tên và định dạng | Quan trọng nhưng để cuối, công cụ tự động lo được phần lớn |
Bốn lỗi đặc trưng cần soi kỹ
- Truy vấn lấy dữ liệu không giới hạn theo người đang đăng nhập. Chạy đúng khi thử với một tài khoản, lộ dữ liệu khi có nhiều tài khoản.
- Bắt lỗi rồi nuốt luôn. Khối bắt lỗi rỗng làm sự cố biến mất khỏi nhật ký, sau này không ai truy được nguyên nhân.
- Xử lý theo vòng lặp thay vì một lần. Gọi cơ sở dữ liệu bên trong vòng lặp chạy tốt với mười bản ghi và sập với mười nghìn.
- Giá trị cấu hình viết thẳng trong mã. Địa chỉ máy chủ, khóa dịch vụ, ngưỡng thời gian chờ đều phải nằm ở cấu hình.
Ba câu tự hỏi trước khi bấm gộp
# Cau 1: neu doan nay chay sai, ai phat hien va bang cach nao# Khong tra loi duoc nghia la thieu ghi nhat ky hoac thieu canh bao # Cau 2: thay doi nay quay lui duoc trong bao lau# Neu co thay doi cau truc du lieu kem theo thi cau tra loi la KHONG # Cau 3: ai trong doi hieu doan nay du de sua luc 2 gio sang# Neu chi co mot nguoi thi can them chu thich hoac them tai lieu # Kiem tra bat buoc truoc khi gop, khong phu thuoc vao ai review:git diff main --stat # pham vi thay doi co dung nhu mo ta khonggrep -rn "password\|secret\|api_key" --include="*.php" . | head -n 20npm testCâu hỏi thường gặp
Code do AI viết có cần review kỹ hơn không?
Cần review khác chứ không hẳn kỹ hơn. Nó ít lỗi cú pháp và trình bày, nhưng hay làm quá phạm vi, thêm thư viện không cần, và bỏ qua trường hợp biên. Hãy soi đúng bốn chỗ đó.
Có nên để agent tự review code của chính nó không?
Nên dùng một phiên khác, vì phiên đã viết code mang theo mọi giả định đã hình thành trong lúc viết và có xu hướng bảo vệ những gì vừa làm.
Nhận xét tự động có thay được người review không?
Không. Nó bắt tốt các lỗi máy móc và là lớp lọc đầu tiên rất hữu ích, nhưng phần đánh giá thiết kế và hiểu nghiệp vụ vẫn cần người, đặc biệt với thay đổi lớn.
Duyệt nhanh mà vẫn chắc thì làm thế nào?
Xem danh sách file trước, rồi phần thay đổi hợp đồng, rồi mới tới logic. Cuối cùng hỏi ba câu: có giải thích được mọi thay đổi không, có gì ngoài yêu cầu không, và nếu sai thì phát hiện bằng cách nào.