Mã do AI viết hiếm khi sai theo kiểu lộ liễu; nó sai theo kiểu hợp lý. Tên biến đẹp, cấu trúc gọn, có chú thích, chạy được với ví dụ đầu tiên. Chính sự trơn tru đó làm người rà hạ cảnh giác. Đọc mã AI viết cần một bộ dấu hiệu khác với đọc mã của đồng nghiệp mới vào nghề, vì những chỗ người hay sai và những chỗ AI hay sai không trùng nhau.
Bài này gom các dấu hiệu theo ba nhóm: dùng sai thư viện, lỗi logic ẩn, và không hợp với dự án, kèm một ví dụ giả định bằng Python có bốn lỗi trong sáu dòng, và quy trình rà theo mức rủi ro. Bảo mật của mã AI viết có chuyên mục riêng trên trang; ở đây chỉ nhắc khi cần.
Vì sao mã AI viết khó rà hơn mã người viết
Khi rà mã của một người, bạn có nhiều tín hiệu phụ: chỗ họ viết lúng túng, chỗ đặt tên vội, chỗ chú thích "tạm thời". Những tín hiệu đó chỉ ra nơi người viết không chắc. Mã AI không có tín hiệu này. Phần nó hiểu đúng và phần nó đoán bừa trông giống hệt nhau về văn phong, cùng một độ tự tin.
Thứ hai, lỗi của AI thường là lỗi "có lý". Nó gọi một hàm có tên rất giống hàm thật của thư viện, truyền một tham số mà phiên bản khác có, hoặc áp một mẫu phổ biến vào chỗ không phù hợp. Người đọc lướt thấy quen thì gật đầu.
Thứ ba, khối lượng. Một lượt AI có thể sinh ra vài trăm dòng thay đổi trên nhiều tệp, nhiều hơn hẳn lượng người rà đọc kỹ được trong một lần. Kết quả hay gặp là người rà đọc kỹ phần đầu rồi lướt phần còn lại. Cách chống lại là giao việc nhỏ hơn và rà có chủ đích theo danh sách dấu hiệu, thay vì đọc từ trên xuống dưới với hy vọng tự nhiên thấy lỗi.
Nhóm dấu hiệu về thư viện và hàm gọi
Tên hàm hoặc tham số mà bạn chưa từng thấy. Đây là dấu hiệu số một. Mỗi tên lạ đều phải tra tài liệu chính thức của đúng phiên bản dự án đang dùng, không hỏi lại chính AI đó vì nó sẽ khẳng định lại. Trình soạn thảo có kiểm kiểu và gợi ý cũng bắt được phần lớn trường hợp, miễn là bạn để ý dòng gạch đỏ.
Cách dùng của phiên bản cũ. AI học từ mã nhiều năm, nên hay viết theo cách đã bị bỏ hoặc bị đánh dấu sắp bỏ. Mã vẫn chạy hôm nay nhưng hỏng khi nâng cấp. Để ý cảnh báo khi chạy kiểm thử.
Thư viện mới xuất hiện để làm việc nhỏ. Thêm một gói phụ thuộc chỉ để định dạng ngày hay ghép chuỗi là cái giá dài hạn. Hỏi xem thư viện chuẩn hoặc thư viện dự án đã có có làm được không. Kiểm cả tên gói có thật và đúng là gói bạn nghĩ.
Hành vi mặc định khác với điều AI giả định. Ví dụ kinh điển của JavaScript: gọi sort trên mảng số mà không truyền hàm so sánh sẽ sắp theo chuỗi, nên 10 đứng trước 9. Mã trông đúng, chạy với dữ liệu thử một chữ số cũng đúng, chỉ sai khi số có hai chữ số trở lên.
Nhóm dấu hiệu về logic ẩn
Khối bắt lỗi nuốt ngoại lệ. Bắt mọi loại lỗi rồi trả về danh sách rỗng, số 0 hoặc bỏ qua im lặng. Người dùng thấy "không có dữ liệu" trong khi thật ra cơ sở dữ liệu đang hỏng. Lỗi bị che sẽ hiện ra muộn hơn, ở chỗ khác, khó lần hơn nhiều.
Tham số mặc định là đối tượng thay đổi được. Trong Python, một danh sách làm giá trị mặc định chỉ được tạo một lần và dùng chung cho mọi lần gọi. Hàm thêm phần tử vào đó sẽ tích luỹ qua các lần gọi. Mẫu đúng là mặc định None rồi tạo mới bên trong hàm.
Điều kiện lệch một. Nhỏ hơn thay vì nhỏ hơn hoặc bằng, chỉ số bắt đầu từ 1 thay vì 0, khoảng đóng thay vì nửa mở. Đối chiếu từng mốc với đặc tả, không với trực giác.
Tên hàm hứa nhiều hơn mã làm. Hàm tên "lấy đơn gần nhất" nhưng không sắp xếp theo ngày; hàm tên "kiểm tra hợp lệ" chỉ kiểm có rỗng hay không. Đọc tên rồi đọc thân, hỏi thân hàm có thật sự làm điều cái tên nói không.
Chú thích không khớp mã. AI viết chú thích theo ý định, rồi viết mã hơi khác. Chú thích nói "bỏ qua đơn đã huỷ" mà điều kiện lại so với trạng thái khác. Khi chú thích và mã lệch nhau, cả hai đều đáng ngờ.
Ví dụ giả định: bốn lỗi trong sáu dòng
Bạn nhờ AI viết hàm lấy mười đơn gần nhất của một khách, bỏ đơn đã huỷ. Kết quả trông như sau và chạy được với dữ liệu thử:
def lay_don_gan_nhat(khach_id, so_luong=10, bo_loc=[]):
try:
don = db.truy_van_don(khach_id)
except Exception:
return []
bo_loc.append("da_huy")
return [d for d in don if d.trang_thai not in bo_loc][:so_luong]
Thứ nhất, bo_loc là danh sách mặc định dùng chung: mỗi lần gọi lại thêm một "da_huy", và nếu nơi gọi truyền danh sách của nó vào, danh sách đó bị sửa ngầm. Thứ hai, khối bắt lỗi biến sự cố cơ sở dữ liệu thành "khách chưa có đơn". Thứ ba, tên hàm nói "gần nhất" nhưng không có sắp xếp; kết quả phụ thuộc thứ tự cơ sở dữ liệu trả về. Thứ tư, hàm lấy toàn bộ đơn rồi mới cắt mười cái, với khách có hàng nghìn đơn là chậm vô ích. Bản sửa:
def lay_don_gan_nhat(khach_id, so_luong=10, bo_loc=None):
loai_tru = set(bo_loc or ()) | {"da_huy"}
don = [d for d in db.truy_van_don(khach_id) if d.trang_thai not in loai_tru]
don.sort(key=lambda d: d.ngay_tao, reverse=True)
return don[:so_luong]
Bản này để lỗi cơ sở dữ liệu nổi lên cho tầng trên xử lý. Tốt hơn nữa là đẩy điều kiện lọc, sắp xếp và giới hạn số lượng vào câu truy vấn; đó là câu hỏi bạn đặt cho AI ở lượt sau, kèm kiểm thử cho khách không có đơn và khách có nhiều đơn.
Nhóm dấu hiệu "không hợp với dự án"
Có những thay đổi đúng về kỹ thuật nhưng sai về chỗ đứng. AI chỉ thấy phần ngữ cảnh bạn đưa cho nó, nên hay mắc nhóm lỗi này:
- Viết lại một hàm tiện ích mà dự án đã có ở thư mục khác, nay có hai bản làm cùng một việc và sẽ trôi xa nhau.
- Xử lý lỗi theo kiểu khác với phần còn lại của dự án: chỗ này ném ngoại lệ, chỗ kia trả mã lỗi, chỗ khác ghi nhật ký rồi đi tiếp.
- Đặt tên theo quy ước khác: trộn tiếng Anh và tiếng Việt không dấu, trộn kiểu viết hoa.
- Sửa cả những tệp ngoài phạm vi yêu cầu, như định dạng lại một tệp cấu hình hay đổi thứ tự nhập thư viện, làm khó đọc phần thay đổi thật.
- Thêm cấu hình, biến môi trường hoặc bảng mới mà không có bước cập nhật tài liệu, tệp mẫu cấu hình hay kịch bản chuyển đổi cơ sở dữ liệu.
- Để lại chú thích kiểu "cần xử lý thêm" hoặc hàm rỗng chờ viết sau, trong khi mô tả thay đổi nói là đã xong.
Phần lớn nhóm lỗi này bớt hẳn khi dự án có tệp hướng dẫn cho AI ghi quy ước chính và chỉ chỗ các hàm dùng chung. Nhưng người rà vẫn phải hỏi câu cuối cùng: thay đổi này có làm dự án dễ hiểu hơn hay khó hiểu hơn.
Trình tự rà một thay đổi do AI viết
Đọc từ trên xuống dưới theo thứ tự tệp là cách dễ bỏ sót nhất. Trình tự sau đưa những câu hỏi quan trọng lên trước, khi bạn còn tỉnh táo:
- Đọc lại yêu cầu gốc và tự nói ra bằng một câu thay đổi này phải làm gì. Không có câu này thì không có gì để đối chiếu.
- Xem danh sách tệp bị sửa. Tệp nào nằm ngoài phạm vi yêu cầu thì hỏi vì sao trước khi đọc nội dung; tệp kiểm thử bị sửa cùng lúc với mã thì đọc kỹ gấp đôi.
- Đọc kiểm thử trước mã. Kiểm thử nói hành vi mong đợi là gì, có ca mép không, giá trị mong đợi có tính lại được không.
- Tự chạy kiểm thử và chạy thử tính năng trên máy, với cả dữ liệu bình thường lẫn dữ liệu rỗng.
- Đọc mã theo luồng dữ liệu: dữ liệu vào từ đâu, được kiểm ở đâu, biến đổi ra sao, ghi xuống đâu. Soi theo ba nhóm dấu hiệu ở trên.
- Mỗi tên hàm, tham số, gói thư viện lạ: tra tài liệu chính thức, đánh dấu đã kiểm.
- Với dòng khó hiểu, có thể nhờ AI giải thích, nhưng coi lời giải thích là giả thuyết cần kiểm chứ không phải kết luận.
Toàn bộ trình tự này với một thay đổi vừa phải mất mười lăm đến ba mươi phút. Nếu nó mất lâu hơn nhiều, thay đổi đang quá lớn và nên được tách ra trước khi rà tiếp.
Rà kỹ đến đâu: theo mức rủi ro của thay đổi
Không thể đọc mọi dòng AI viết với cùng một mức kỹ. Chia theo rủi ro để dồn sức đúng chỗ:
| Mức | Ví dụ thay đổi | Cách rà |
|---|---|---|
| Thấp | Kịch bản dùng một lần, công cụ nội bộ chạy trên máy, đổi chữ hiển thị | Chạy thử, đọc lướt, kiểm các lệnh xoá hoặc ghi đè |
| Vừa | Tính năng mới có kiểm thử, sửa giao diện, thêm điểm cuối API đọc dữ liệu | Đọc kiểm thử trước, đọc toàn bộ thay đổi theo danh sách dấu hiệu, chạy trên máy |
| Cao | Tiền, phân quyền, xoá dữ liệu, chuyển đổi cơ sở dữ liệu, xử lý dữ liệu cá nhân | Hai người rà, đọc từng dòng, tự viết thêm ca kiểm thử, thử trên môi trường thử nghiệm với dữ liệu giả |
Mức rủi ro nên được ghi ngay trong mô tả thay đổi để người rà biết phải đọc kỹ cỡ nào. Một quy ước đơn giản mà nhiều nhóm dùng: thay đổi đụng tới tiền hoặc dữ liệu khách thì không bao giờ được gộp chỉ dựa trên một lượt duyệt, dù mã do người hay do AI viết.
Câu hỏi thường gặp
Có nên hỏi chính AI vừa viết mã xem mã có lỗi không?
Hỏi được, đôi khi nó tự thấy lỗi khi được yêu cầu soát kỹ. Nhưng không coi đó là lượt rà: cùng một mô hình với cùng ngữ cảnh dễ lặp lại cùng giả định sai. Câu trả lời của nó chỉ là gợi ý để bạn kiểm tiếp.
Làm sao biết một hàm thư viện là có thật?
Tra tài liệu chính thức của đúng phiên bản dự án đang dùng, hoặc để trình soạn thảo có kiểm kiểu báo lỗi. Chạy thử đoạn mã cũng lộ ra ngay. Đừng dựa vào việc tên hàm nghe hợp lý, vì đó đúng là điểm mạnh của mã bịa.
Mã AI viết có sạch hơn mã người viết không?
Thường gọn và đều tay hơn về hình thức, nhưng hình thức không nói lên tính đúng. Lỗi của AI khác lỗi của người, chứ không ít hơn một cách chắc chắn. Mức rà nên dựa trên rủi ro của thay đổi chứ không dựa trên ai viết.
Thay đổi do AI viết quá dài thì rà thế nào?
Yêu cầu tách nhỏ. Một thay đổi vài trăm dòng trên nhiều tệp nên chia thành nhiều lần gộp nhỏ, mỗi lần một ý. Nếu không tách được, rà theo luồng dữ liệu của tính năng thay vì theo thứ tự tệp, và dùng danh sách dấu hiệu để soi có chủ đích.
Có công cụ nào tự bắt các dấu hiệu này không?
Một phần. Công cụ phân tích tĩnh, kiểm kiểu và định dạng bắt được hàm không tồn tại, biến không dùng, tham số mặc định thay đổi được và nhiều lỗi kiểu dữ liệu. Những lỗi về nghiệp vụ, tên hàm hứa nhiều hơn mã làm, hay không hợp với dự án thì vẫn cần người.
Người mới vào nghề có nên rà mã AI viết không?
Nên, đó là cách học tốt, nhưng thay đổi rủi ro cao vẫn cần người có kinh nghiệm duyệt cuối. Người mới có thể bắt đầu bằng danh sách dấu hiệu trong bài, ghi lại lỗi tìm được, và hỏi lại người rà chính về những chỗ mình không chắc.