Hướng dẫn
Cách kiểm tra code AI viết khi bạn không biết lập trình
Đã đăng: · Đã cập nhật:
Bạn để AI viết giúp vài dòng code, và giờ ngồi nhìn nó mà chẳng biết nó tốt hay dở, an toàn hay sắp gây họa. Có một điều làm bạn nhẹ lòng: bạn không cần đọc được code mới đánh giá được nó, bạn chỉ cần đánh giá hệ quả của nó. Chỉ vài câu hỏi bằng lời thường là đủ bắt ra những chỗ thật sự rủi ro, cho dù đoạn code trông rối như mớ chữ tượng hình. Đây chính là cách người cẩn thận vẫn làm, kể lại cho người chưa đọc nổi một dòng code.
Đừng cố đọc nó từng dòng một
Ngồi đọc thứ code mình không hiểu vừa chậm vừa nản, mà lại còn sai cách. Người rà soát lão luyện cũng chẳng soi từng ký tự đâu; họ chỉ để mắt xem đoạn code này động chạm tới cái gì. Một lỗi gõ nhầm trong hàm hiển thị vô thưởng vô phạt thì có sao. Nhưng một lỗi trong đoạn code xóa dữ liệu lại là thảm họa. Vậy nên kỹ năng ở đây không nằm ở việc đọc, mà ở chỗ nhận ra phần nào mới đáng bận tâm. Và việc đó thì bạn thừa sức làm.
Bước 1: Bắt AI tự giải thích
Công cụ đầu tiên, và cũng là tốt nhất, chính là cái AI đã viết ra đoạn code. Cứ hỏi thẳng nó bằng lời thường:
- “Giải thích đoạn code này làm gì, thật đơn giản, như thể tôi không biết code.”
- “Có thể có chuyện gì hỏng với nó?”
- “Nó có chạm vào mật khẩu, key hay dữ liệu cá nhân nào không?”
- “Chuyện gì xảy ra nếu ai đó nhập vào một thứ bất ngờ?”
Một trợ lý AI tử tế sẽ trả lời thành thật, và chỉ riêng việc bạn hỏi đã ép những chi tiết quan trọng phải phơi ra. Nếu lời giải thích mơ hồ, hoặc AI thú nhận nó không chắc, thì đó là dấu hiệu để bạn chậm lại, chứ không phải để tin nó nhiều hơn.
Một điều cần dè chừng: AI hoàn toàn có thể nói sai về chính code của nó, y như cách nó ảo giác đủ thứ khác. Cho nên hãy xem lời nó giải thích như một chỉ dẫn, đừng coi là chân lý, nhất là với mấy vùng tác động mạnh ở dưới.
Bước 2: Soi bốn câu hỏi rủi ro cao
Dù AI có nói gì đi nữa, hãy đưa đoạn code qua bốn câu hỏi sau. Bất kỳ câu trả lời “có” nào cũng có nghĩa là chú ý chỗ này.
- Nó có xử lý bí mật không? Mật khẩu, API key, token đăng nhập. Những thứ này không bao giờ được để hớ hênh hay viết cứng ở nơi người khác nhìn thấy.
- Nó có chạm internet không? Gửi đi hay lấy về dữ liệu trực tuyến là mở cửa cho rò rỉ và can thiệp từ bên ngoài.
- Nó có thay đổi hay xóa dữ liệu không? Bất cứ gì ghi đè hay xóa thông tin đều có thể gây hại thật, khó mà sửa lại nếu nó làm sai.
- Nó có chạy lệnh trên máy bạn không? Code cài đặt thứ gì đó hoặc chạy lệnh hệ thống thì đáng cẩn trọng hơn hẳn.
Đoạn code không dính chút nào trong bốn thứ trên thì rủi ro thấp, cứ thong thả. Đoạn code dính bất kỳ điều nào cũng không tự nhiên thành xấu, nhưng đó lại là nơi sai sót gây đau, nên đáng để bạn soi thêm một lượt trước khi tin.
Câu hỏi thứ hai có một phiên bản rất Việt Nam. Nếu đoạn code gửi số CCCD, số điện thoại hay địa chỉ giao hàng của khách sang một API đặt ở nước ngoài, thì đó không còn là chuyện “chạm internet” nữa, mà là dữ liệu cá nhân rời khỏi tay bạn. Nhiều dự án ở đây còn cắm thẳng vào Zalo OA, VNPay hay MoMo, nơi một token lộ ra là mở luôn cả cổng thanh toán chứ không riêng phần code. Nên hỏi AI đúng ba câu: dữ liệu nào đi ra ngoài, đi tới đâu, và khoá đang nằm ở đâu.
Câu hỏi thứ tư có một chi tiết dễ bỏ qua nếu bạn dùng trợ lý chạy ngay trên máy, như Claude Code. Theo tài liệu bảo mật của Anthropic, các phiên trong cửa sổ dòng lệnh (terminal) và trong VS Code mặc định khởi động ở chế độ tự động: một mô hình AI khác duyệt từng hành động thay cho bạn và chặn những gì nó cho là không an toàn. Ở chế độ thủ công, Claude Code hỏi bạn trước khi sửa tệp hay chạy lệnh. Anthropic vẫn ghi rõ: bạn chịu trách nhiệm rà soát code và lệnh được đề xuất trước khi đồng ý. Nếu muốn tự mình thấy từng lời hỏi, hãy kiểm tra mình đang ở chế độ nào, và đừng bấm đồng ý khi chưa đọc.
Câu hỏi thứ tư còn một mặt dễ bị bỏ qua: thư viện bịa ra. Hầu như dự án nào cũng dùng thư viện do người khác viết sẵn. OWASP, một tổ chức chuyên về bảo mật phần mềm, xếp vào danh sách rủi ro của mô hình ngôn ngữ việc chúng gợi ý thư viện không an toàn hoặc không hề tồn tại, và mô tả luôn kiểu tấn công đi kèm: kẻ xấu tìm những cái tên mà trợ lý AI hay bịa, rồi đăng gói độc hại đúng với tên đó. Hãy bảo AI liệt kê mọi thứ nó đã cài và mỗi thứ dùng để làm gì, rồi tự tìm từng tên. Không thấy trang chính thức nào thì dừng lại, hỏi AI lấy thư viện đó ở đâu ra.
Bước 3: Bảo vệ bí mật của bạn trước khi chia sẻ bất cứ gì
Có một cái bẫy rất cụ thể mà người mới hay sập: khi dán code hoặc file cho AI nhờ giúp, bạn có thể vô tình trao luôn mật khẩu, key hay dữ liệu cá nhân lẫn trong đó. Nhất là khi bên trong có dữ liệu cá nhân của người khác, thứ mà Luật Bảo vệ dữ liệu cá nhân 91/2025/QH15 buộc bạn phải giữ gìn cẩn thận. Trước khi chia sẻ, bỏ chút công kiểm tra xem thật ra bên trong có những gì là rất đáng. Công cụ miễn phí Kiểm tra bảo mật của chúng mình cho bạn biết thứ sắp dán có chứa điều đáng lẽ không nên chia sẻ hay không, một hàng rào đơn giản chắn lại kiểu rò rỉ phổ biến nhất ở người mới.
Bước 4: Cân mức cẩn trọng với mức quan trọng
Mức độ cẩn thận vừa đủ phụ thuộc hoàn toàn vào việc đoạn code đó dùng để làm gì:
- Một món đồ chơi cho riêng mình (một app theo dõi chỉ mình bạn xài): rủi ro thấp. Cứ chạy, cứ học từ nó, đừng căng thẳng làm gì.
- Bất cứ thứ gì dính người dùng thật, dữ liệu thật hay tiền thật: rủi ro cao. Code AI có thể ẩn chứa lỗ hổng bảo mật mà người mới không tài nào thấy, và chính các nhà làm công cụ cũng không hứa điều ngược lại: GitHub dặn phải rà soát và chạy thử kỹ code được tạo ra, nhất là cho ứng dụng quan trọng hay nhạy cảm. Trước khi thứ này chạy thật, hãy nhờ một người đọc được code ngó qua, hoặc chí ít, chậm lại và chắc chắn rằng bạn hiểu hệ quả của từng câu “có” ở Bước 2.
Đây không phải chuyện sợ sệt, mà là chuyện liệu cơm gắp mắm. Với thứ vô hại thì cứ đi nhanh, còn đúng chỗ nào một sai lầm sẽ thành hệ trọng thì đạp phanh.
Tâm thế giữ bạn an toàn
Bạn sẽ nghe câu “phát hành ra là của bạn” rất nhiều, và nó đúng ngay cả khi bạn không tự gõ lấy một chữ. Sở hữu nó không có nghĩa là đọc từng dòng, mà là gánh lấy trách nhiệm về hệ quả. Nhờ AI giải thích, soi bốn câu hỏi rủi ro, giữ chặt bí mật của mình, và tìm người giúp thật sự trước khi bất cứ thứ gì thật được đưa vào chạy. Làm được vậy, bạn có thể tự tin xây dựng cùng AI từ rất lâu trước khi đọc code trôi chảy.
Xây dựng với một bộ thiết lập giúp bạn rà soát
Thói quen tốt sẽ nhẹ nhàng hơn nhiều khi có một bộ thiết lập tốt. Công cụ miễn phí AI cho lập trình viên của chúng mình giúp bạn chọn đúng trợ lý, cài đặt cho hệ điều hành của bạn, và có sẵn một thiết lập khởi đầu biến việc rà soát thay đổi, tức nhìn thấy chính xác AI vừa làm gì, thành một phần trong nhịp làm việc thường ngày. Ghép nó với cách đặt-hệ-quả-lên-đầu ở trên, thì “tôi không đọc được code” thôi còn là cái cớ khiến bạn bất an.
Đọc tiếp
Câu hỏi thường gặp
Làm sao kiểm tra code AI viết khi tôi không đọc được code? +
Hãy đánh giá theo hệ quả, đừng cố đọc từng dòng. Nhờ AI giải thích bằng lời thường xem nó làm gì, rồi soi mấy câu hỏi rủi ro cao: nó có xử lý mật khẩu hay bí mật không, có nối ra internet không, có thay đổi hay xóa dữ liệu không? Code không dính thứ nào trong đó là rủi ro thấp; code dính bất kỳ điều nào thì cần soi kỹ một lượt trước khi tin.
Code do AI tạo ra có an toàn để dùng không? +
Không thể mặc định là an toàn. Chính GitHub cảnh báo rằng Copilot Chat có thể tạo ra code trông hợp lệ nhưng thật ra sai, và khuyên luôn rà soát, chạy thử code được tạo ra, nhất là với ứng dụng quan trọng hay nhạy cảm. Code AI đủ ổn cho dự án cá nhân để học hỏi; còn với thứ đụng tới dữ liệu hay tiền của người thật, nó cần được rà soát tử tế trước đã.
Tôi nên hỏi AI điều gì về chính code của nó? +
Hãy nhờ nó giải thích bằng lời thường xem code làm gì, cái gì có thể hỏng, nó có chạm vào bí mật hay dữ liệu cá nhân nào không, và nó sẽ làm gì nếu nhận phải dữ liệu xấu. Một trợ lý tốt sẽ trả lời thành thật, và chính việc đặt câu hỏi thường lôi ra những rủi ro mà nếu không hỏi bạn sẽ bỏ sót.
Điều nguy hiểm nhất mà code AI có thể làm là gì? +
Các vùng rủi ro cao gồm: xử lý bí mật như mật khẩu và API key, xóa hay ghi đè dữ liệu, chạy lệnh trên máy của bạn, và gửi dữ liệu ra internet. Không cái nào tự nhiên thành xấu, nhưng cái nào cũng đáng soi kỹ. Nếu chưa chắc, đừng chạy hay phát hành nó cho tới khi có người đọc được code ngó qua.