Để AI giải thích một đoạn mã khó cho đúng, bạn cần đưa đủ ngữ cảnh xung quanh, nói rõ mình muốn hiểu ở mức nào, và bắt nó chứng minh lời giải thích bằng ví dụ vào ra cụ thể. Phần ví dụ là phần quyết định: một lời giải thích trôi chảy có thể sai, nhưng một ví dụ "đầu vào này cho ra kết quả kia" thì bạn chạy thử được trong một phút.
Bài này đi qua bốn loại đoạn mã hay làm người đọc mã cũ chùn tay: hàm dài hàng trăm dòng, biểu thức chính quy viết dồn một dòng, câu SQL lồng nhiều tầng, và đoạn xử lý bit hoặc tính toán ngày giờ. Mỗi loại có cách hỏi riêng. Mọi ví dụ trong bài là ví dụ giả định.
Vì sao "giải thích đoạn này" chưa đủ
Câu hỏi trống trơn cho ra lời giải thích theo kiểu dịch từng dòng sang tiếng Việt: dòng này gán biến, dòng kia lặp qua mảng. Bạn đọc xong vẫn không biết hàm này tồn tại để làm gì và có an toàn để sửa không. Lý do là AI không biết bạn đang ở đâu: người mới học cần giải thích cú pháp, người đang sửa lỗi cần biết nhánh nào chạy khi nào, người định tái cấu trúc cần biết hàm có tác dụng phụ gì.
Vì vậy câu hỏi tốt luôn có ba phần: đoạn mã, ngữ cảnh (đoạn này được gọi từ đâu, dữ liệu vào trông thế nào), và mục đích của bạn. Ví dụ: Hàm dưới đây được gọi khi tính phí giao hàng cho đơn hàng. Mục đích: cần thêm một loại phí mới mà không làm sai các loại cũ. Hãy giải thích hàm theo các nhánh điều kiện, mỗi nhánh nêu điều kiện vào, kết quả trả về, và biến nào bị thay đổi ngoài phạm vi hàm. Câu này dài hơn nhưng tiết kiệm cho bạn ba lượt hỏi lại.
Một điều nên nói thẳng với AI là mức hiểu của bạn. Thêm câu "giả sử người đọc đã biết Python nhưng chưa biết thư viện xử lý ngày giờ này" sẽ giúp lời giải thích bỏ phần thừa và tập trung đúng chỗ bạn thiếu.
Hàm dài trăm dòng: tách trước, giải thích sau
Hỏi bố cục trước nội dung. Yêu cầu AI chia hàm thành các khối theo việc làm, mỗi khối một câu mô tả và khoảng dòng tương ứng. Bạn có ngay một mục lục cho hàm, thứ mà người viết ban đầu không để lại.
Hỏi về trạng thái. Câu hỏi "những biến nào được gán ở khối đầu và đọc lại ở khối cuối" thường lộ ra phụ thuộc ngầm, lý do chính khiến hàm dài khó sửa.
Hỏi về tác dụng phụ. Hàm có ghi cơ sở dữ liệu, gửi thư, ghi tệp, sửa biến toàn cục, sửa tham số truyền vào không. Liệt kê kèm số dòng. Đây là danh sách bạn cần thuộc trước khi đụng vào hàm.
Hỏi về nhánh chết. Có nhánh điều kiện nào trông như không bao giờ đúng không. AI đọc logic điều kiện khá tốt, nhưng điều kiện phụ thuộc dữ liệu thật thì nó chỉ đoán được, nên bạn vẫn phải kiểm bằng log.
Ghi lại thành chú thích. Khi đã kiểm xong, nhờ AI viết chú thích ngắn ở đầu mỗi khối. Chỉ giữ những chú thích nói vì sao, bỏ những chú thích lặp lại điều mã đã nói rõ.
Biểu thức chính quy: bắt AI tách từng mảnh và đưa ca thử
Biểu thức chính quy trong mã cũ thường là một dòng dày đặc ký hiệu mà không ai dám sửa. AI giải thích loại này khá tốt vì cú pháp có quy tắc rõ ràng, với điều kiện bạn nói nó chạy trong môi trường nào: biểu thức chính quy của PHP, của JavaScript, của Python và của lệnh grep có những khác biệt nhỏ, ví dụ cách viết nhóm có tên hay việc hỗ trợ nhìn ngược phía sau.
Câu hỏi mẫu: Biểu thức chính quy sau dùng trong hàm preg_match của PHP để kiểm mã đơn hàng. Hãy tách thành từng mảnh, giải thích mỗi mảnh khớp với gì. Sau đó đưa năm chuỗi sẽ khớp và năm chuỗi sẽ không khớp, trong đó có ít nhất hai chuỗi sát ranh giới. Mười chuỗi thử đó chính là phần quý nhất. Bạn chạy chúng thật, bằng một tập lệnh nhỏ hoặc một trang thử biểu thức chính quy chạy trong trình duyệt, chọn đúng phiên bản ngôn ngữ. Chuỗi nào cho kết quả khác lời AI nói, lời giải thích sai ở mảnh tương ứng.
Sau khi hiểu, giữ lại các chuỗi thử thành một kiểm thử đơn vị nhỏ. Lần sau ai cần sửa biểu thức đó sẽ có ngay hàng rào bảo vệ. Đây là cách biến một lần đọc hiểu thành tài sản lâu dài của dự án.
Câu SQL lồng nhau: giải thích theo tầng và kiểm bằng dữ liệu nhỏ
Câu SQL lồng ba bốn tầng, có nhiều phép nối và hàm gộp, là loại khó đọc bằng mắt nhất. Bảng dưới là thứ tự câu hỏi nên đặt cho AI.
| Thứ tự | Câu hỏi cho AI | Bạn kiểm thế nào |
|---|---|---|
| 1 | Câu truy vấn trong cùng trả về những cột nào, mỗi dòng đại diện cho cái gì | Chạy riêng câu trong cùng, có giới hạn số dòng, trên cơ sở dữ liệu thử |
| 2 | Mỗi phép nối có thể làm nhân số dòng không | Đếm số dòng trước và sau phép nối |
| 3 | Điều kiện lọc đặt ở ON hay ở WHERE, khác nhau ra sao với phép nối trái | Thử với một bản ghi không có dữ liệu bên phải |
| 4 | Nhóm theo cột nào, có cột nào được chọn mà không nằm trong nhóm | Kiểm chế độ SQL của máy chủ, có máy cho phép, có máy báo lỗi |
| 5 | Viết lại câu này bằng các bước trung gian có tên cho dễ đọc | So kết quả hai câu trên cùng dữ liệu, phải giống hệt |
Bước 3 đáng chú ý nhất. Trong phép nối trái, đặt điều kiện lọc của bảng bên phải ở WHERE thay vì ở ON sẽ loại mất những dòng không có dữ liệu bên phải, biến phép nối trái thành phép nối trong mà không ai để ý. Đây là lỗi kinh điển trong mã cũ, và AI thường chỉ ra được nếu bạn hỏi đúng câu.
Khi đưa câu SQL cho AI, đưa kèm cấu trúc các bảng liên quan (lệnh tạo bảng, không kèm dữ liệu) và tên hệ quản trị cơ sở dữ liệu cùng phiên bản. Không dán dữ liệu khách hàng thật; nếu cần ví dụ, tự tạo vài dòng giả.
Tính toán ngày giờ, xử lý bit và các phép tính "ma thuật"
Có những đoạn mã ngắn nhưng chứa con số khó hiểu: 86400, 0x7FFF, dịch bit sang trái năm vị trí, cộng thêm 7 rồi chia lấy dư. Với loại này, hỏi AI theo các hướng sau:
- Con số này có ý nghĩa thông dụng không, ví dụ 86400 là số giây trong một ngày, 0x7FFF là giá trị lớn nhất của số nguyên có dấu 16 bit.
- Phép tính có giả định ngầm nào: múi giờ của máy chủ, năm nhuận, ngày đổi giờ mùa hè ở thị trường nước ngoài, độ dài số nguyên trên máy 32 bit.
- Cho ba bộ giá trị vào và kết quả mong đợi, trong đó có một bộ ở ranh giới như cuối tháng, cuối năm, giá trị âm.
- Đề xuất đặt tên hằng số cho con số đó, nhưng chưa sửa cho tới khi có kiểm thử.
Đoạn tính ngày giờ là nơi AI dễ sai nhất trong lời giải thích, vì kết quả phụ thuộc cấu hình máy chạy. Luôn chạy thử các bộ giá trị trên đúng môi trường của dự án, không tin vào phép tính nhẩm của AI.
Mã viết theo lối cũ hoặc bằng khung bạn chưa từng dùng
Một loại "khó hiểu" khác không nằm ở logic mà ở thời đại của mã. Dự án PHP lâu năm có thể còn những hàm họ mysql_ đã bị gỡ khỏi ngôn ngữ từ PHP 7.0; giao diện có thể viết bằng jQuery với các hàm gắn sự kiện kiểu cũ; mã JavaScript có thể dùng var và hàm gọi lại lồng nhau thay vì async và await. Người học lập trình vài năm gần đây đọc những đoạn này thấy lạ, dù logic không hề phức tạp.
Với loại này, hỏi AI theo hướng đối chiếu: Đoạn mã dưới đây viết theo lối cũ của [ngôn ngữ hoặc thư viện]. Giải thích nó làm gì, rồi cho biết cách viết tương đương theo lối hiện nay để tham khảo. Chưa đề xuất sửa vào dự án. Phần đối chiếu giúp bạn hiểu nhanh vì quy về thứ đã quen. Cụm "chưa đề xuất sửa" giữ cho cuộc trò chuyện ở mức đọc hiểu; việc nâng cấp lối viết cũ là một dự án riêng, cần kiểm thử và kế hoạch, có bài riêng trong danh mục này.
Một trường hợp đặc biệt là mã đã bị thu gọn hoặc do công cụ sinh tự động: tệp JavaScript gom một dòng dài, mã sinh từ bộ tạo giao diện lập trình. Đừng tốn công nhờ AI giải thích những tệp đó. Hãy tìm mã nguồn gốc hoặc tệp cấu hình của bộ sinh mã; nếu không còn, đánh dấu tệp đó là vùng không sửa tay trong tài liệu dự án.
Cách nhận ra lời giải thích sai và việc nên làm khi đó
Có vài dấu hiệu đáng ngờ. AI nhắc tới hàm hoặc biến không có trong đoạn bạn đưa. AI nói đoạn mã "xử lý trường hợp rỗng" mà bạn không thấy dòng kiểm tra nào. AI giải thích cực kỳ tự tin một hàm của thư viện nội bộ mà nó không thể biết nội dung. Gặp những dấu hiệu này, hỏi lại: Chỉ ra dòng cụ thể trong đoạn trên làm điều đó. Nếu nó không chỉ được, coi đó là suy đoán.
Cách chắc nhất vẫn là cho mã chạy. Đặt đoạn mã vào một tập lệnh tách riêng hoặc một kiểm thử, gọi với các ví dụ AI đưa ra, so kết quả. Mười phút chạy thử đáng giá hơn một giờ tranh luận với chatbot. Và khi đã hiểu đúng, hãy viết lời giải thích bằng câu của chính bạn vào chú thích hoặc tài liệu, đó là cách kiểm tra cuối cùng xem mình hiểu thật hay chỉ đang chép lại lời AI.
Câu hỏi thường gặp
AI giải thích mã có chính xác không?
Với mã dùng thư viện phổ biến và logic rõ ràng, lời giải thích thường đúng phần lớn. Độ chính xác giảm khi đoạn mã gọi hàm nội bộ mà AI không thấy, phụ thuộc cấu hình máy chủ, hoặc liên quan ngày giờ. Luôn kiểm bằng ví dụ chạy thật.
Nên dán bao nhiêu mã cho mỗi lần hỏi?
Đủ để AI thấy đoạn cần hiểu cùng những hàm nó gọi trực tiếp và nơi gọi nó. Thường là một đến vài trăm dòng. Dán cả nghìn dòng làm câu trả lời loãng; dán quá ít thì AI phải đoán phần thiếu.
Có nên nhờ AI viết chú thích cho toàn bộ hàm cũ?
Chỉ sau khi bạn đã kiểm lời giải thích. Chú thích sai còn hại hơn không có, vì người sau tin vào nó. Giữ chú thích ngắn, nói lý do và điều kiện đặc biệt, không mô tả lại từng dòng.
Biểu thức chính quy AI giải thích xong có nên để nó viết lại cho gọn?
Có thể, nhưng chỉ khi đã có bộ chuỗi thử khớp và không khớp chạy được tự động. Viết lại biểu thức chính quy mà không có ca thử là cách nhanh nhất để lọt dữ liệu sai vào hệ thống.
Dán câu SQL có tên bảng thật của công ty vào chatbot có sao không?
Tên bảng và cột thường ít nhạy cảm hơn dữ liệu, nhưng vẫn có thể tiết lộ nghiệp vụ. Làm theo quy định của công ty về công cụ được phép dùng. Tuyệt đối không dán dữ liệu thật, chuỗi kết nối, mật khẩu cơ sở dữ liệu.
AI và người đọc lâu năm giải thích khác nhau thì tin ai?
Tin máy chạy thật. Viết một ca thử nhỏ thể hiện điểm khác nhau và chạy nó. Người lâu năm có thể nhớ hành vi của phiên bản cũ, AI có thể suy luận sai, còn kết quả chạy trên môi trường hiện tại thì không thiên vị ai.