--- title: "Duyệt code do AI viết: danh sách kiểm 15 điểm cho người đọc diff" url: https://www.thinnd.site/ky-thuat/duyet-code-do-ai-viet/ language: vi author: "Nhu Duy Thin (Thinnd)" published: 2026-10-29 updated: 2026-10-29 section: "Kỹ thuật phần mềm" tags: ["code review", "AI", "kiểm chứng", "bảo mật", "danh sách kiểm"] summary: "Khi AI viết code, nút thắt dời sang khâu duyệt, nên người duyệt cần một danh sách cố định thay vì đọc theo cảm giác. Danh sách 15 điểm gồm bốn nhóm: hiểu đúng việc, đúng và an toàn, kiểm thử có giá trị, và dễ bảo trì. Điểm hay bị bỏ sót nhất là thư viện có thật không, đầu vào có bị tin quá không, và test có thất bại khi code sai không." license: "Cite with the author name and the canonical URL above." --- # Duyệt code do AI viết: danh sách kiểm 15 điểm cho người đọc diff > Dành cho người duyệt code, kể cả người mới làm quen. Từ kỹ thuật nào cũng có giải thích ngắn. > > Số liệu lấy từ báo cáo và nghiên cứu công khai ở cuối bài. Nhiều số do hãng công nghệ công bố nên cần đọc thận trọng. Ví dụ ghi là "minh họa" được dựng lại cho dễ hình dung, không thuộc vụ việc cụ thể nào. --- ## Tóm tắt nhanh - Khi AI viết code nhanh, **nút thắt dời sang khâu duyệt**. Nhóm dùng AI nhiều gộp thêm nhiều thay đổi, nhưng mỗi thay đổi tốn thời gian duyệt hơn. - Code do AI viết **trông gọn và chạy được**, điều này làm người duyệt dễ chủ quan. Hãy dùng một danh sách cố định thay vì đọc theo cảm giác. - Danh sách này có **15 điểm, chia bốn nhóm**: hiểu đúng việc (3), đúng và an toàn (5), kiểm thử có giá trị (3), dễ bảo trì (4). - Ba điểm hay bị bỏ sót nhất: **thư viện có thật không**, **đầu vào có bị tin quá không**, **test có thất bại khi code sai không**. - AI có thể duyệt lượt đầu, nhưng **người vẫn chịu trách nhiệm**. Hỏi AI "tìm lỗi", đừng hỏi "có đúng không". - Một mô tả PR tốt ghi rõ **phần AI viết, phần người đã kiểm, và cách đã kiểm**. --- ## Từ khó, nói dễ | Thuật ngữ | Nói dễ hiểu | |---|---| | **Diff** | Bản so sánh hai phiên bản code: dòng xanh là thêm, dòng đỏ là xóa. Người duyệt đọc diff. | | **PR (pull request)** | Một đề nghị đưa thay đổi vào dự án, để người khác xem trước khi nhận. | | **XSS, injection** | Kiểu tấn công nhét mã độc vào ô nhập liệu. Code tốt phải coi mọi đầu vào là không đáng tin. | | **Dependency** (phụ thuộc) | Thư viện bên ngoài mà code gọi tới. | | **Test luôn xanh** | Bài kiểm tra luôn báo đạt dù code sai, vì nó chỉ kiểm tra chính nó. | | **Mutation testing** (kiểm thử đột biến) | Cố tình làm hỏng code để xem test có báo lỗi không. | --- ## 1. Vì sao phải duyệt kỹ hơn Có ba loại bằng chứng, đều cần đọc thận trọng. - **Nút thắt đã dời.** Báo cáo "AI Productivity Paradox" của Faros AI (7/2025, hơn 10.000 lập trình viên ở 1.255 nhóm) ghi nhận nhóm dùng AI nhiều gộp thêm khoảng 98% thay đổi, nhưng thời gian duyệt mỗi thay đổi tăng khoảng 91% và kích thước thay đổi tăng khoảng 154%. Đây là dữ liệu của hãng bán công cụ đo lường, là tương quan chứ chưa chắc nhân quả, và mình mới đọc các bài tóm tắt. - **Lỗi bảo mật.** Báo cáo GenAI Code Security 2025 của Veracode (80 tác vụ, hơn 100 mô hình) thấy mã do AI tạo ra có lỗ hổng ở khoảng 45% tác vụ. Với lỗi XSS và ghi log không an toàn, mô hình không bảo vệ đúng ở khoảng 86% và 88% trường hợp. Trước đó, nghiên cứu của Pearce và cộng sự (2021) thấy khoảng 40% trong 1.689 chương trình do Copilot viết có lỗ hổng. Đây là số liệu đo trên tác vụ thử nghiệm, không phải trên mã đang chạy thật. - **Niềm tin quá mức.** Nghiên cứu của Perry và cộng sự (Stanford, 2022) thấy người dùng trợ lý AI viết code kém an toàn hơn ở bốn trên năm bài nhưng tin hơn rằng code của mình an toàn. Nhóm nhỏ, mô hình đời cũ, nên đọc như một dấu hiệu. Các bằng chứng này nối với bài [vì sao không nên tin AI tuyệt đối](https://www.thinnd.site/ky-thuat/khong-nen-tin-ai-tuyet-doi/) và bài [làm việc nhóm IT thời AI](https://www.thinnd.site/kinh-nghiem/lam-viec-nhom-thoi-ai/): kết quả trông hoàn chỉnh nên khó thấy lỗi, và nút thắt giờ nằm ở chỗ đọc. Hướng dẫn duyệt code công khai của Google (eng-practices) có ba câu hỏi nền đáng nhớ: thiết kế có hợp với hệ thống không, hành vi có đúng ý và tốt cho người dùng không, và code có thể đơn giản hơn không. Danh sách dưới đây cụ thể hóa ba câu đó cho trường hợp code do AI viết. --- ## 2. Danh sách kiểm 15 điểm Mức độ: **Cao** là có thể gây sự cố hoặc mất dữ liệu, **Vừa** là gây nợ kỹ thuật hoặc lỗi nhỏ. ### Nhóm A. Hiểu đúng việc | # | Câu hỏi | Dấu hiệu lỗi hay gặp ở code AI | Cách kiểm | Mức độ | |---|---|---|---|---| | 1 | Code có làm đúng yêu cầu, không hơn không kém? | AI làm thêm thứ không ai xin, hoặc bỏ sót một nửa yêu cầu vì hiểu khác | Đọc mô tả việc trước, rồi tự nói bằng lời mong đợi, sau đó mới đọc diff | Cao | | 2 | Phạm vi thay đổi có gọn không? | Diff đụng vào file không liên quan, "tiện tay" đổi tên hoặc định dạng lại | Liệt kê file đổi, hỏi từng file "vì sao có mặt" | Vừa | | 3 | Các giả định có được nói ra không? | AI âm thầm chọn một cách hiểu mơ hồ rồi làm | Hỏi: "Bạn đã giả định gì?" và đối chiếu với mô tả việc | Cao | ### Nhóm B. Đúng và an toàn | # | Câu hỏi | Dấu hiệu lỗi hay gặp ở code AI | Cách kiểm | Mức độ | |---|---|---|---|---| | 4 | Thư viện, hàm, tham số AI gọi có thật và đúng phiên bản không? | Gọi hàm không tồn tại hoặc đã bị bỏ, hoặc cài một gói tên nghe hợp lý nhưng bịa | Mở trang chính thức của gói, xem người duy trì, ngày tạo, lượt tải. Chạy thật để xem có lỗi import không | Cao | | 5 | Mọi đầu vào từ bên ngoài đã được kiểm tra chưa? | Quên chống XSS, injection, đường dẫn file bất thường | Truy vết từng đầu vào từ nơi nhận tới nơi dùng. Thử với chuỗi xấu | Cao | | 6 | Có bí mật hay dữ liệu nhạy cảm bị lộ không? | Khóa, token dán thẳng vào code, ghi log cả dữ liệu cá nhân | Tìm chuỗi giống khóa, đọc các dòng ghi log | Cao | | 7 | Trường hợp biên và lỗi có được xử lý không? | Chỉ viết cho đường chạy thuận lợi: rỗng, null, múi giờ, số lớn, hai yêu cầu cùng lúc | Tự liệt kê ba trường hợp biên và tìm chỗ xử lý tương ứng | Cao | | 8 | Thao tác phá hủy có hàng rào không? | Xóa hoặc ghi đè không xác nhận, câu lệnh thiếu điều kiện | Tìm xóa, ghi đè, cập nhật hàng loạt. Hỏi "sai thì hoàn tác thế nào" | Cao | ### Nhóm C. Kiểm thử có giá trị | # | Câu hỏi | Dấu hiệu lỗi hay gặp ở code AI | Cách kiểm | Mức độ | |---|---|---|---|---| | 9 | Test có kiểm tra hành vi thật không? | Test dùng mock trả về đúng giá trị mà test kiểm tra, nên luôn xanh | Đọc test trước code. Hỏi: "Test này kiểm tra điều gì ngoài chính nó?" | Cao | | 10 | Test có thất bại khi code sai không? | Test qua cả khi bạn cố tình sửa sai code | Làm hỏng một dòng quan trọng rồi chạy test (kiểm thử đột biến thủ công) | Cao | | 11 | Chạy được trên máy sạch không? | Chạy được trên máy tác giả vì có sẵn thứ không ghi trong dự án | Tải bản mới, chạy theo hướng dẫn hoặc để CI chạy | Vừa | ### Nhóm D. Dễ bảo trì | # | Câu hỏi | Dấu hiệu lỗi hay gặp ở code AI | Cách kiểm | Mức độ | |---|---|---|---|---| | 12 | Có trùng lặp hoặc bỏ qua thứ có sẵn trong dự án không? | Viết lại hàm đã tồn tại, dán các đoạn gần giống nhau | Tìm trong dự án tên hàm và đoạn tương tự trước khi chấp nhận | Vừa | | 13 | Code có đơn giản, đọc hiểu được không? | Tầng trừu tượng thừa, lồng nhiều lớp cho việc đơn giản | Thử giải thích đoạn code cho người khác trong một phút | Vừa | | 14 | Có theo quy ước của dự án không? | Đặt tên, cấu trúc thư mục, kiểu xử lý lỗi khác với phần còn lại | Đối chiếu với [sổ tay cho AI](https://www.thinnd.site/ky-thuat/so-tay-cho-ai-agents-md/) và các file lân cận | Vừa | | 15 | PR nhỏ, một mục đích, mô tả rõ không? | Một PR gộp nhiều việc, mô tả chung chung | Yêu cầu chia nhỏ. Dùng mẫu mô tả ở mục 4 | Vừa | Hai điểm cần nói thêm về bằng chứng: - **Điểm 4** nối với nghiên cứu về tên thư viện bịa (Virginia Tech và cộng sự, 2025): cỡ một trên năm gợi ý thư viện không tồn tại, và khoảng 43% tên bịa lặp lại ở mọi lần hỏi, nên kẻ tấn công có thể đăng ký trước tên đó (slopsquatting). - **Điểm 12** nối với phân tích của GitClear (2025, hơn 211 triệu dòng thay đổi): các bài tóm tắt nêu số khối code trùng lặp tăng mạnh và tỷ lệ dòng được tái cấu trúc giảm trong năm 2024. Đây là dữ liệu của một hãng bán công cụ phân tích, là tương quan, và mình mới đọc các bài tóm tắt. --- ## 3. Thứ tự đọc một PR trong 15 phút 1. **Đọc mô tả và mô tả việc gốc (2 phút).** Nếu mô tả không nói rõ, dừng lại và hỏi. Điểm 1, 2, 3. 2. **Đọc test trước code (3 phút).** Test cho biết tác giả hiểu việc ra sao. Điểm 9, 10. 3. **Quét các điểm rủi ro cao trong diff (6 phút).** Đầu vào, bí mật, xóa và ghi đè, thư viện mới. Điểm 4, 5, 6, 7, 8. 4. **Chạy thử (3 phút).** Chạy test, chạy tính năng, thử một trường hợp xấu. Điểm 10, 11. 5. **Đọc phần còn lại để bảo trì (1 phút trở lên).** Trùng lặp, độ phức tạp, quy ước. Điểm 12 đến 15. Nếu mục 3 phát hiện vấn đề, đừng đọc tiếp để "gom đủ lỗi". Trả lại sớm để tác giả sửa, vì mỗi vòng đều tốn thời gian. --- ## 4. Mẫu mô tả PR cho code có AI tham gia Một mô tả tốt giúp người duyệt biết nên nhìn đâu. ```text Việc: thêm nút hủy đơn trên trang đơn hàng Xong là: có test, hoàn tiền được xử lý, có ảnh chụp màn hình AI viết: giao diện nút, hàm gọi API hủy, test cho trường hợp thường Người đã kiểm: đọc toàn bộ diff, chạy test, thử hủy đơn đã giao Người đã sửa: bỏ một thư viện không cần, thêm xử lý khi API lỗi Cách kiểm lại: chạy npm test, mở trang đơn hàng, bấm hủy một đơn thử Điều chưa chắc: hoàn tiền với đơn trả góp, cần người hiểu nghiệp vụ xem ``` Khi người duyệt thấy dòng "Điều chưa chắc", họ biết nên dồn sức vào đâu. Mô tả này cũng ép tác giả tự đọc lại diff trước khi gửi. --- ## 5. Dùng AI để duyệt hộ thì sao AI duyệt giúp được ở **lượt đầu**: tìm lỗi nhỏ, nhắc điểm quên, đọc nhanh phần dài. Nhưng đừng coi nó là người duyệt cuối, vì ba lý do: - **Xu hướng chiều ý.** Nghiên cứu của Anthropic về sycophancy (Sharma và cộng sự, 2024) thấy nhiều trợ lý AI hay nhận một lỗi không có thật khi bị chất vấn, và dễ đồng tình với người hỏi. Một AI được hỏi "code này đúng không" dễ trả lời "đúng". - **Cùng một nguồn lỗi.** AI duyệt có thể mắc đúng kiểu lỗi mà AI viết đã mắc. - **Không chịu trách nhiệm.** Người ký tên mới chịu trách nhiệm. Cách dùng đỡ rủi ro hơn là yêu cầu cụ thể: ```text Đọc diff này như một người duyệt khó tính. Tìm ba chỗ có thể sai và nói vì sao. Liệt kê mọi thư viện, hàm và tham số mới, và nói bạn chắc chắn tới đâu. Chỉ ra đầu vào nào chưa được kiểm tra. Nếu không tìm thấy lỗi, hãy nói rõ bạn đã xem những gì. ``` Rồi người đọc lại những chỗ AI chỉ ra, và đọc cả chỗ nó không nhắc tới. --- ## 6. Ba tình huống minh họa Dựng lại từ lỗi thường gặp, không thuộc vụ việc cụ thể nào. **Thư viện "nghe rất thật".** AI thêm `pip install fastparse-utils` để đọc một định dạng file. Mọi thứ trông hợp lý, nhưng người duyệt kiểm tra trang của gói (điểm 4): gói mới đăng ký tuần trước, chỉ một người duy trì. Gói thay thế phổ biến đã có sẵn trong dự án. **Test luôn xanh.** AI viết test cho hàm tính phí, nhưng test dùng mock trả về đúng con số mà test mong chờ (điểm 9). Người duyệt làm hỏng công thức một dòng (điểm 10), test vẫn qua. Họ yêu cầu viết lại test với số liệu thật. **Diff quá lớn.** Một PR gộp đổi tên, tái cấu trúc và tính năng mới, hơn một nghìn dòng. Người duyệt trả lại và yêu cầu chia ba (điểm 15). Ba PR nhỏ được duyệt xong nhanh hơn một PR lớn đang chờ. --- ## 7. Nhìn cân bằng Danh sách này không có nghĩa là code do AI viết kém hơn code do người viết. Con người cũng quên kiểm tra đầu vào và viết test yếu. Điểm khác là **tốc độ và vẻ ngoài**: AI tạo ra nhiều code nhanh hơn, và code trông gọn gàng nên lỗi khó lộ. Danh sách này vì thế có ích cho cả code của người. Số liệu về lỗi bảo mật đo trên các tác vụ thử nghiệm của một hãng bảo mật và có thể đã khác ở các mô hình mới. Số liệu Faros và GitClear là tương quan. Điều chắc chắn hơn là cấu trúc: **chi phí viết một bản nháp giảm, chi phí kiểm chứng thì không giảm theo**. Đầu tư vào quy trình duyệt, kiểm thử tự động và sổ tay chung thường có lợi hơn thêm người duyệt. --- ## 8. Mười lăm điểm trong một trang Tóm tắt để in ra. | Nhóm | Điểm | |---|---| | A. Hiểu đúng việc | 1 Đúng yêu cầu. 2 Phạm vi gọn. 3 Giả định được nói ra | | B. Đúng và an toàn | 4 Thư viện và hàm có thật. 5 Đầu vào được kiểm tra. 6 Không lộ bí mật. 7 Trường hợp biên và lỗi. 8 Thao tác phá hủy có hàng rào | | C. Kiểm thử | 9 Test kiểm tra hành vi thật. 10 Test thất bại khi code sai. 11 Chạy được trên máy sạch | | D. Bảo trì | 12 Không trùng lặp. 13 Đơn giản, dễ đọc. 14 Theo quy ước. 15 PR nhỏ, mô tả rõ | --- ## 9. Kết luận Khi AI làm cho việc viết code rẻ đi, việc duyệt trở thành khâu quyết định chất lượng. Một danh sách cố định giúp người duyệt không phải dựa vào cảm giác, và một mô tả PR trung thực giúp họ biết nên nhìn đâu. AI có thể đọc lượt đầu, nhưng người ký tên mới là người chịu trách nhiệm. Bắt đầu nhỏ: lấy ba điểm hay bị bỏ sót nhất (4, 5, 10), áp dụng cho PR tiếp theo, và ghi lại điều bạn bắt được. Một tuần sau, thêm những điểm còn lại theo lỗi mà nhóm thực sự gặp. --- ## Nguồn tham khảo Số liệu lấy từ nguồn công khai tính đến tháng 10/2026. Nhiều nguồn là báo cáo của các hãng hoặc bài tóm tắt, và một số con số được thuật lại hơi khác nhau, nên hãy mở nguồn gốc để kiểm tra trước khi trích dẫn. - Faros AI, AI Productivity Paradox (7/2025): [bài tóm tắt của Faros](https://www.faros.ai/blog/lab-vs-reality-ai-productivity-study-findings) và [bài tóm tắt của Software Seni](https://softwareseni.com/the-ai-productivity-paradox-in-software-development-and-what-the-research-actually-shows) (chưa đọc bản gốc) - Veracode, GenAI Code Security Report 2025: [thông cáo của Veracode](https://www.veracode.com/press-release/ai-generated-code-poses-major-security-risks-in-nearly-half-of-all-development-tasks-veracode-research-reveals/) và [Help Net Security](https://www.helpnetsecurity.com/2025/08/07/create-ai-code-security-risks/) - Pearce và cộng sự, [Asleep at the Keyboard? Assessing the Security of GitHub Copilot's Code Contributions](https://arxiv.org/pdf/2108.09293) (2021) - Perry và cộng sự, [Do Users Write More Insecure Code with AI Assistants?](https://arxiv.org/pdf/2211.03622) (Stanford, 2022) - Nghiên cứu về slopsquatting: [Dark Reading](https://darkreading.com/application-security/ai-code-tools-widely-hallucinate-packages) và [Infosecurity Magazine](https://www.infosecurity-magazine.com/news/ai-hallucinations-slopsquatting/) - GitClear, AI Copilot Code Quality 2025: [bài phân tích của LeadDev](https://leaddev.com/software-quality/how-ai-generated-code-accelerates-technical-debt) (bài tóm tắt, chưa đọc bản gốc) - Sharma và cộng sự, [Towards Understanding Sycophancy in Language Models](https://arxiv.org/pdf/2310.13548) (ICLR 2024) - Google, [Engineering Practices: The Code Reviewer's Guide](https://google.github.io/eng-practices/review/)