Cách dùng Grok phân tích code
Bùi Tấn Lực - 107
- 07/10/2026
Grok không chỉ phù hợp để tạo mã nguồn mới mà còn có thể hỗ trợ đọc, giải thích và tìm vấn đề trong code hiện có. Khi được cung cấp đúng đoạn mã cùng bối cảnh cần thiết, Grok có thể giúp lập trình viên nhìn ra luồng xử lý, phát hiện điểm bất hợp lý, phân tích lỗi và đề xuất hướng cải thiện.
Điểm quan trọng là không nên chỉ gửi code rồi yêu cầu chung chung như “phân tích code này”. Cách làm hiệu quả hơn là xác định rõ muốn Grok kiểm tra điều gì, cung cấp đủ phần mã liên quan và yêu cầu kết quả theo từng bước. Grok hiện hỗ trợ xử lý nhiều loại tệp mã nguồn khi tải lên cuộc trò chuyện, đồng thời có thể phân tích nhiều tệp trong cùng một yêu cầu.
Grok có thể phân tích code theo những cách nào?
Phân tích code bằng Grok có thể bắt đầu từ một đoạn mã rất nhỏ nhưng cũng có thể mở rộng sang nhiều file của một dự án. Mỗi cách sử dụng phù hợp với một mục tiêu khác nhau, vì vậy việc xác định đúng loại phân tích sẽ giúp câu trả lời thực tế hơn.
Giải thích code và luồng xử lý
Đây là cách đơn giản nhất khi bạn đang gặp một đoạn code khó đọc hoặc phải tiếp nhận dự án do người khác phát triển. Thay vì yêu cầu Grok viết lại, hãy yêu cầu nó giải thích lần lượt dữ liệu đầu vào, các bước xử lý, điều kiện rẽ nhánh và kết quả đầu ra.
Ví dụ, với đoạn PHP sau:
<?php
if (isset($_POST['email'])) {
$email = trim($_POST['email']);
if (filter_var($email, FILTER_VALIDATE_EMAIL)) {
saveUser($email);
}
}
?>
Bạn có thể yêu cầu Grok:
Phân tích đoạn PHP trên theo từng bước.
Hãy giải thích:
1. Dữ liệu được lấy từ đâu.
2. Từng điều kiện if đang kiểm tra điều gì.
3. Khi nào hàm saveUser() được gọi.
4. Có trường hợp nào dữ liệu không được xử lý không.
5. Có vấn đề bảo mật hoặc logic nào cần chú ý không.
Chỉ phân tích trước, chưa viết lại code.
Cách yêu cầu này giúp tách phần “hiểu code” khỏi phần “sửa code”. Đây là điểm rất hữu ích khi bạn chưa chắc vấn đề nằm ở đâu và không muốn AI tự ý thay đổi cấu trúc chương trình.
Tìm lỗi trong code
Nếu chương trình đang báo lỗi, hãy cung cấp cả đoạn code gây lỗi và thông báo lỗi thay vì chỉ gửi riêng một trong hai. Với các lỗi phức tạp hơn, log, stack trace, request mẫu hoặc thông tin môi trường cũng có thể giúp Grok xác định nguyên nhân chính xác hơn. xAI cũng mô tả quy trình sử dụng Grok để phân tích stack trace, log và lỗi trong quá trình vận hành nhằm tìm nguyên nhân gốc thay vì chỉ xử lý triệu chứng.
Ví dụ, thay vì viết:
Sửa lỗi code PHP này giúp tôi.
Nên cung cấp yêu cầu cụ thể hơn:
Đây là đoạn PHP đang gây lỗi.
Hãy:
1. Xác định nguyên nhân trực tiếp.
2. Kiểm tra xem nguyên nhân đó có thể xuất phát từ phần code nào khác không.
3. Giải thích vì sao lỗi xảy ra.
4. Đề xuất cách sửa ít ảnh hưởng nhất đến cấu trúc hiện tại.
5. Chỉ đưa code đã sửa sau khi giải thích nguyên nhân.
Không tự ý thay đổi tên biến hoặc kiến trúc chương trình nếu không cần thiết.
Với cách này, kết quả nhận được không chỉ là một đoạn code mới mà còn có phần lý giải để bạn biết vì sao cần sửa.
Kiểm tra logic thay vì chỉ kiểm tra cú pháp
Một đoạn code có thể chạy bình thường nhưng vẫn xử lý sai nghiệp vụ. Đây là trường hợp phân tích bằng AI đặc biệt hữu ích.
Chẳng hạn, một đoạn mã tính giá đơn hàng có thể không báo bất kỳ lỗi cú pháp nào nhưng lại áp dụng giảm giá hai lần. Nếu chỉ yêu cầu “code có lỗi không?”, Grok có thể tập trung vào lỗi kỹ thuật mà bỏ qua yêu cầu nghiệp vụ.
Hãy mô tả quy tắc mà code phải tuân thủ:
Hãy kiểm tra logic của đoạn code này theo quy tắc:
- Đơn hàng dưới 500.000 đồng không được giảm giá.
- Từ 500.000 đồng đến dưới 1.000.000 đồng giảm 5%.
- Từ 1.000.000 đồng trở lên giảm 10%.
- Mã giảm giá không được cộng thêm nếu khách đã nhận mức giảm cao nhất.
Hãy đối chiếu từng nhánh xử lý với các quy tắc trên.
Nếu có điểm sai, chỉ rõ điều kiện nào gây ra sai lệch.
Đây là cách chuyển yêu cầu từ “kiểm tra code” thành “đối chiếu code với hành vi mong muốn”. Kết quả thường hữu ích hơn nhiều đối với những dự án có logic nghiệp vụ phức tạp.
Cách chuẩn bị code trước khi đưa cho Grok
Chất lượng phân tích phụ thuộc rất lớn vào thông tin mà Grok được cung cấp. Một đoạn code đứng riêng có thể không đủ để hiểu nguyên nhân lỗi, đặc biệt khi hàm đang gọi đến một file khác, phụ thuộc vào database hoặc nhận dữ liệu từ một API.
Gửi đúng phần code liên quan
Không phải lúc nào gửi toàn bộ dự án cũng là lựa chọn tốt. Nếu lỗi nằm trong một hàm xử lý dữ liệu, trước tiên hãy gửi hàm đó cùng những phần trực tiếp liên quan.
Ví dụ, nếu muốn kiểm tra hàm xử lý đăng nhập, nên cung cấp:
- Hàm đăng nhập.
- Đoạn kiểm tra dữ liệu đầu vào.
- Phần truy vấn hoặc gọi service liên quan.
- Cách kết quả được sử dụng sau khi đăng nhập.
- Thông báo lỗi hoặc kết quả thực tế nếu có.
Nếu vấn đề liên quan đến nhiều file, có thể tải nhiều tệp mã nguồn để Grok đối chiếu chúng với nhau. Tài liệu của xAI cho biết các tệp đính kèm có thể được tìm kiếm trong nhiều file và ngữ cảnh file có thể được duy trì qua các lượt trao đổi tiếp theo.
Cho Grok biết vai trò của từng file
Khi phân tích nhiều file, đừng chỉ tải lên rồi yêu cầu “phân tích toàn bộ”. Hãy nói rõ quan hệ giữa chúng.
Tôi gửi 4 file:
- login.php: nhận thông tin đăng nhập từ người dùng.
- auth.php: kiểm tra tài khoản và tạo session.
- database.php: kết nối cơ sở dữ liệu.
- dashboard.php: kiểm tra session sau khi đăng nhập.
Hãy phân tích luồng đăng nhập từ login.php đến dashboard.php.
Tập trung tìm nguyên nhân khiến người dùng đăng nhập thành công
nhưng dashboard.php vẫn báo chưa đăng nhập.
Chưa sửa code ở bước đầu tiên.
Hãy chỉ ra file và vị trí có khả năng gây lỗi trước.
Yêu cầu như vậy giúp Grok có một nhiệm vụ rõ ràng thay vì phải tự đoán mục tiêu phân tích.
Cung cấp kết quả thực tế khi code chạy
Code và kết quả thực tế là hai mảnh thông tin khác nhau. Một đoạn JavaScript có thể nhìn hoàn toàn hợp lý nhưng chỉ khi chạy trên trình duyệt mới xuất hiện lỗi. Tương tự, PHP có thể hoạt động trên máy chủ này nhưng lỗi trên máy chủ khác vì phiên bản PHP, cấu hình hoặc extension khác nhau.
Vì vậy, khi gặp lỗi, nên cung cấp thêm:
- Thông báo lỗi đầy đủ.
- Đoạn log liên quan.
- Input đã sử dụng.
- Kết quả thực tế.
- Kết quả mà bạn mong muốn.
- Phiên bản ngôn ngữ hoặc framework nếu có ảnh hưởng.
Ví dụ, thay vì nói “API trả về sai”, hãy mô tả rõ:
API nhận email hợp lệ nhưng trả về HTTP 500.
Input:
email = user@example.com
Kết quả thực tế:
HTTP 500
Response: {"error":"Internal Server Error"}
Kết quả mong muốn:
HTTP 200
Response chứa thông tin tài khoản.
Hãy phân tích code bên dưới để tìm nguyên nhân.
Ưu tiên kiểm tra dữ liệu đầu vào, truy vấn database và cách xử lý exception.
Thông tin này giúp Grok phân biệt được lỗi nằm ở dữ liệu đầu vào, xử lý bên trong hay kết quả trả về.
Cách viết prompt để Grok phân tích code chính xác hơn
Prompt tốt không nhất thiết phải dài. Điều quan trọng là nó phải xác định được mục tiêu, phạm vi và cách Grok cần trả lời. Với code, một prompt có cấu trúc thường hiệu quả hơn một câu hỏi ngắn nhưng mơ hồ.
Công thức prompt dễ áp dụng
Có thể xây dựng prompt theo 5 thành phần: vai trò của code + mục tiêu phân tích + bối cảnh + yêu cầu kiểm tra + định dạng kết quả.
Bạn đang đóng vai trò lập trình viên chuyên kiểm tra code.
Bối cảnh:
Đây là đoạn PHP xử lý đăng nhập người dùng.
Mục tiêu:
Tìm nguyên nhân khiến một số tài khoản đăng nhập thất bại.
Hãy kiểm tra:
1. Dữ liệu đầu vào.
2. Điều kiện xử lý.
3. Truy vấn database.
4. Cách kiểm tra mật khẩu.
5. Session sau khi đăng nhập.
6. Các trường hợp có thể gây lỗi.
Kết quả cần trả về:
- Vấn đề phát hiện được.
- Mức độ nghiêm trọng.
- Nguyên nhân.
- Dòng code liên quan.
- Cách khắc phục.
- Code đề xuất sau khi phân tích.
Không thay đổi kiến trúc nếu chưa cần thiết.
Cấu trúc này đặc biệt phù hợp khi bạn muốn Grok đóng vai trò như một người review code thay vì chỉ làm nhiệm vụ sinh code.
Yêu cầu Grok phân tích trước, sửa sau
Một lỗi phổ biến khi dùng AI hỗ trợ lập trình là yêu cầu phân tích và sửa code trong cùng một câu. Khi đó, AI có thể nhanh chóng đưa ra phiên bản mới nhưng người dùng lại không biết vấn đề ban đầu nằm ở đâu.
Đối với code đang chạy trên website, nên chia thành hai bước:
- Yêu cầu Grok tìm và giải thích vấn đề.
- Sau khi xác định nguyên nhân, yêu cầu Grok đề xuất bản sửa.
Ví dụ:
Trước tiên chỉ phân tích, chưa sửa code.
Hãy tìm tất cả vấn đề có thể khiến đoạn code này hoạt động sai.
Phân loại thành:
- Lỗi chắc chắn.
- Rủi ro có thể xảy ra.
- Điểm cần kiểm tra thêm.
Sau đó giải thích nguyên nhân của từng vấn đề.
Khi đã nhận được phân tích, có thể tiếp tục:
Dựa trên các vấn đề đã xác định, hãy sửa code.
Yêu cầu:
- Giữ nguyên chức năng hiện tại.
- Không thay đổi tên biến nếu không cần.
- Không thay đổi cấu trúc file.
- Chỉ sửa những phần liên quan đến lỗi.
- Đưa ra toàn bộ đoạn code sau khi sửa.
- Giải thích ngắn gọn từng thay đổi.
Cách làm hai bước giúp hạn chế việc thay đổi quá nhiều phần của chương trình chỉ để xử lý một lỗi nhỏ. Với những dự án lớn, Grok Build còn hỗ trợ lập kế hoạch thay đổi code trước khi thực hiện, phù hợp với các nhiệm vụ như refactor, migration hoặc thay đổi trải rộng trên nhiều file.
Phân tích code theo từng lớp để tìm đúng nguyên nhân
Khi một đoạn code gặp vấn đề, không nên chỉ nhìn vào dòng đang báo lỗi. Một lỗi xuất hiện ở cuối quy trình có thể bắt nguồn từ dữ liệu đầu vào, hàm xử lý, truy vấn database hoặc một giá trị được truyền từ file khác.
Vì vậy, có thể yêu cầu Grok phân tích code theo từng lớp thay vì kiểm tra tất cả cùng lúc. Cách này đặc biệt hữu ích với PHP, JavaScript, Python hoặc những ứng dụng có nhiều bước xử lý dữ liệu.
Kiểm tra dữ liệu đầu vào
Trước tiên cần xác định dữ liệu mà chương trình nhận được có đúng như dự kiến hay không. Nhiều lỗi tưởng như nằm ở hàm xử lý nhưng thực tế bắt nguồn từ giá trị rỗng, sai kiểu dữ liệu hoặc dữ liệu chưa được chuẩn hóa.
Hãy chỉ kiểm tra dữ liệu đầu vào của đoạn code này.
Xác định:
- Dữ liệu đến từ đâu.
- Kiểu dữ liệu dự kiến.
- Những trường hợp dữ liệu có thể bị thiếu.
- Những giá trị có thể gây lỗi.
- Code hiện tại đã kiểm tra dữ liệu đầu vào đầy đủ chưa.
Chưa phân tích các phần khác và chưa sửa code.
Cách yêu cầu này giúp khoanh vùng vấn đề. Sau khi xác định dữ liệu đầu vào ổn định, mới chuyển sang kiểm tra phần xử lý.
Kiểm tra luồng xử lý
Sau dữ liệu đầu vào, hãy yêu cầu Grok mô phỏng đường đi của dữ liệu qua từng điều kiện và hàm. Đây là phương pháp hữu ích khi code có nhiều if, else, vòng lặp hoặc nhiều hàm gọi lẫn nhau.
Hãy mô phỏng luồng chạy của đoạn code với dữ liệu sau:
quantity = 3
price = 200000
discount = 10
Theo dõi giá trị của các biến sau mỗi bước xử lý.
Chỉ ra điều kiện nào được thực thi và điều kiện nào bị bỏ qua.
Cuối cùng cho biết giá trị kết quả.
Nếu phát hiện logic bất thường, giải thích tại đúng bước xảy ra vấn đề.
Thay vì chỉ đọc code theo cách tĩnh, Grok được yêu cầu đóng vai trò như đang chạy thử chương trình với một bộ dữ liệu cụ thể. Điều này thường làm lộ những lỗi logic khó nhận ra khi nhìn từng dòng riêng lẻ.
Kiểm tra sự phụ thuộc giữa các hàm
Một hàm có thể hoàn toàn đúng khi đứng riêng nhưng lại hoạt động sai vì nhận kết quả không đúng từ hàm phía trước. Với trường hợp này, hãy yêu cầu Grok lập mối quan hệ giữa các hàm.
Hãy lập sơ đồ luồng gọi hàm dựa trên code tôi cung cấp.
Với mỗi hàm, cho biết:
- Hàm được gọi từ đâu.
- Nhận tham số nào.
- Trả về dữ liệu gì.
- Dữ liệu trả về được sử dụng ở đâu.
- Có trường hợp nào kiểu hoặc cấu trúc dữ liệu bị thay đổi không.
Tập trung tìm điểm có thể làm dữ liệu sai giữa hai hàm.
Cách phân tích này phù hợp với những dự án đã phát triển lâu ngày, trong đó một hàm có thể được sử dụng ở nhiều vị trí khác nhau.
Dùng Grok kiểm tra lỗi bảo mật trong code
Phân tích code không chỉ nhằm tìm lỗi khiến chương trình không chạy. Với website và ứng dụng web, cần xem xét cả những đoạn code có thể tạo ra rủi ro bảo mật.
Grok có thể được yêu cầu rà soát những khu vực như dữ liệu người dùng nhập vào, truy vấn database, xác thực, phân quyền, session, upload file hoặc xử lý dữ liệu từ API.
Kiểm tra dữ liệu người dùng nhập
Đối với dữ liệu đến từ form, URL, cookie hoặc request, hãy yêu cầu Grok xác định dữ liệu đó đi qua những bước nào trước khi được sử dụng.
Hãy review đoạn PHP này dưới góc độ bảo mật.
Tập trung vào:
- Dữ liệu GET và POST.
- Dữ liệu người dùng nhập trực tiếp.
- Kiểm tra và chuẩn hóa dữ liệu.
- Truy vấn database.
- Nội dung được xuất ra HTML.
Với mỗi rủi ro:
1. Chỉ ra vị trí liên quan.
2. Giải thích tình huống có thể xảy ra.
3. Đánh giá mức độ nghiêm trọng.
4. Đề xuất cách khắc phục.
Không thay đổi code ở bước phân tích.
Điều quan trọng là không nên coi kết quả của Grok như một cuộc kiểm tra bảo mật tuyệt đối. AI có thể bỏ sót vấn đề hoặc đánh giá chưa chính xác một tình huống phụ thuộc vào cấu hình máy chủ. Với website đang vận hành, những phát hiện liên quan đến bảo mật nên được kiểm tra lại bằng phương pháp và công cụ chuyên dụng.
Kiểm tra truy vấn database
Những đoạn code tương tác với database nên được phân tích riêng vì lỗi có thể liên quan đồng thời đến logic, hiệu suất và bảo mật.
Hãy review phần code truy vấn database này.
Kiểm tra:
- Cách nhận dữ liệu đầu vào.
- Cách truyền tham số vào truy vấn.
- Khả năng xảy ra SQL injection.
- Trường hợp dữ liệu không tồn tại.
- Trường hợp truy vấn trả về nhiều bản ghi.
- Khả năng gây lỗi khi database không phản hồi.
- Những điểm có thể làm truy vấn chậm.
Không tối ưu hóa khi chưa xác định nguyên nhân cụ thể.
Yêu cầu theo danh sách giúp Grok không chỉ tập trung vào một loại lỗi. Đặc biệt, “code chạy được” không đồng nghĩa với “code an toàn” hoặc “code có hiệu suất tốt”.
Dùng Grok so sánh code cũ và code mới
Khi vừa sửa một chức năng, bạn có thể đưa cả phiên bản cũ và phiên bản mới cho Grok để kiểm tra xem thay đổi có làm ảnh hưởng đến chức năng khác hay không.
Kiểm tra thay đổi có đúng mục tiêu
Tôi cung cấp phiên bản code trước và sau khi sửa.
Hãy so sánh hai phiên bản.
Yêu cầu:
- Liệt kê những thay đổi quan trọng.
- Cho biết mỗi thay đổi ảnh hưởng đến chức năng nào.
- Xác định thay đổi nào cần thiết cho yêu cầu hiện tại.
- Tìm những phần bị thay đổi ngoài phạm vi yêu cầu.
- Kiểm tra xem phiên bản mới có làm mất chức năng cũ không.
Không viết lại code.
Cách này đặc biệt hữu ích khi bạn nhận được code do AI tạo ra. Thay vì chấp nhận toàn bộ phiên bản mới, có thể dùng Grok để đối chiếu và phát hiện những thay đổi không cần thiết.
Kiểm tra regression sau khi sửa lỗi
Một lỗi được sửa có thể kéo theo lỗi mới. Vì vậy, sau khi chỉnh sửa code, hãy yêu cầu Grok suy nghĩ về những chức năng có khả năng bị ảnh hưởng.
Đây là code trước và sau khi sửa lỗi.
Mục tiêu của lần sửa là:
Ngăn người dùng gửi biểu mẫu nhiều lần trong cùng một phiên.
Hãy kiểm tra phiên bản mới xem có ảnh hưởng đến:
- Gửi biểu mẫu lần đầu.
- Gửi lại sau khi tải lại trang.
- Người dùng mở biểu mẫu ở tab khác.
- Người dùng bị mất session.
- Các biểu mẫu khác trong cùng website.
Chỉ ra các trường hợp cần kiểm thử thêm.
Điểm đáng chú ý là yêu cầu này không chỉ hỏi “code mới có đúng không”, mà yêu cầu Grok xem xét những tình huống xung quanh thay đổi. Đây là cách tư duy gần với quy trình kiểm thử thực tế hơn.
Cách dùng Grok phân tích code của website PHP
Với website PHP, việc phân tích nên đặt code vào đúng bối cảnh hoạt động của website. Một file PHP có thể vừa xử lý request, vừa truy vấn database, vừa tạo HTML nên nếu chỉ gửi một đoạn nhỏ, Grok có thể thiếu thông tin để kết luận.
Phân tích một file PHP
Khi bắt đầu với một file đơn lẻ, hãy yêu cầu Grok xác định vai trò của file trước. Sau đó mới đi sâu vào từng phần.
Hãy phân tích file PHP này theo thứ tự:
1. File này có nhiệm vụ gì?
2. Dữ liệu đầu vào đến từ đâu?
3. Những hàm chính là gì?
4. Luồng xử lý chính diễn ra như thế nào?
5. File này phụ thuộc vào những thành phần nào?
6. Có điểm nào dễ gây lỗi không?
7. Có vấn đề bảo mật hoặc hiệu suất đáng chú ý không?
Chỉ phân tích, chưa viết lại code.
Cách làm này giúp bạn có được “bản đồ” của file trước khi đi vào từng lỗi cụ thể.
Phân tích nhiều file PHP có liên quan
Nếu chức năng trải qua nhiều file, hãy mô tả quan hệ giữa chúng. Ví dụ, một quy trình có thể bắt đầu từ file nhận request, gọi hàm xử lý, truy vấn database rồi chuyển người dùng sang một trang khác.
Tôi muốn phân tích chức năng đăng nhập của website.
Các file có liên quan:
- login.php: nhận form đăng nhập.
- auth.php: kiểm tra tài khoản.
- db.php: kết nối database.
- session.php: xử lý session.
- dashboard.php: trang sau khi đăng nhập.
Hãy phân tích toàn bộ luồng từ lúc người dùng gửi form
đến khi dashboard.php xác định người dùng đã đăng nhập.
Tìm:
- Điểm truyền dữ liệu giữa các file.
- Điểm có thể làm mất dữ liệu.
- Điều kiện có thể khiến đăng nhập thất bại.
- Vấn đề về session.
- Rủi ro bảo mật.
Chưa sửa code.
Sau khi có kết quả phân tích tổng thể, bạn có thể yêu cầu Grok đi sâu vào đúng file đang gây vấn đề. Điều này tốt hơn việc sửa từng file một cách độc lập mà không hiểu toàn bộ luồng.
Những lỗi thường gặp khi nhờ Grok phân tích code
Grok có thể hỗ trợ rất nhiều trong công việc lập trình, nhưng kết quả không phải lúc nào cũng chính xác nếu đầu vào thiếu bối cảnh. Phần lớn vấn đề nằm ở cách đặt yêu cầu hơn là khả năng đọc code.
Chỉ gửi code mà không nói mục tiêu
Đây là lỗi phổ biến nhất. Một đoạn code có thể được kiểm tra theo nhiều hướng: cú pháp, logic, hiệu suất, bảo mật, khả năng mở rộng hoặc khả năng đọc.
Nếu chỉ viết “phân tích code này”, Grok phải tự đoán mục tiêu. Hãy nói rõ bạn muốn kiểm tra điều gì.
Yêu cầu sửa ngay khi chưa xác định nguyên nhân
Nếu chưa biết lỗi nằm ở đâu mà đã yêu cầu viết lại toàn bộ, bạn có thể nhận được một phiên bản code hoàn toàn khác với code ban đầu. Code mới có thể giải quyết một vấn đề nhưng đồng thời tạo ra những thay đổi không mong muốn.
Quy trình an toàn hơn là:
- Cho Grok hiểu mục đích của code.
- Yêu cầu tìm vấn đề.
- Xác nhận nguyên nhân.
- Yêu cầu đề xuất cách sửa.
- So sánh code trước và sau.
- Kiểm tra lại các trường hợp có thể bị ảnh hưởng.
Cung cấp thông tin nhạy cảm trong code
Khi gửi code lên bất kỳ hệ thống AI nào, cần kiểm tra và loại bỏ thông tin không cần thiết như mật khẩu, API key, token, khóa bí mật, thông tin tài khoản hoặc dữ liệu khách hàng thực tế.
Thay vì gửi:
$apiKey = "API_KEY_THAT_SHOULD_NOT_BE_SHARED";
có thể thay bằng:
$apiKey = "YOUR_API_KEY";
Tương tự, dữ liệu người dùng thực tế nên được thay bằng dữ liệu giả lập trước khi đưa vào yêu cầu phân tích. Việc che thông tin nhạy cảm vừa giúp bảo vệ hệ thống vừa không làm ảnh hưởng đáng kể đến khả năng phân tích code.
Cách kiểm tra kết quả phân tích code từ Grok
Không nên xem câu trả lời của Grok là kết luận cuối cùng, đặc biệt khi nó đề xuất thay đổi những phần quan trọng của website. Một kết quả phân tích tốt cần được đối chiếu với code thực tế, yêu cầu ban đầu và cách chương trình đang vận hành.
Phân biệt lỗi chắc chắn và giả thuyết
Khi phân tích một đoạn code, Grok có thể đưa ra nhiều khả năng khác nhau. Không phải khả năng nào cũng là lỗi đang thực sự xảy ra.
Bạn có thể yêu cầu Grok phân loại kết quả:
Hãy phân loại các vấn đề bạn vừa tìm được thành 3 nhóm:
1. Lỗi chắc chắn có thể xác định trực tiếp từ code.
2. Rủi ro có thể xảy ra nhưng cần thêm thông tin để xác nhận.
3. Giả thuyết cần kiểm tra bằng cách chạy thử.
Với mỗi vấn đề, giải thích căn cứ để bạn đưa ra kết luận đó.
Cách này giúp tránh tình trạng một khả năng được trình bày như thể đó là nguyên nhân chắc chắn.
Yêu cầu Grok đưa ra trường hợp tái hiện lỗi
Nếu Grok cho rằng một đoạn code có lỗi logic, hãy yêu cầu nó đưa ra input cụ thể có thể làm lỗi xảy ra. Đây là một cách rất tốt để kiểm chứng nhận định.
Bạn cho rằng điều kiện này có thể gây sai kết quả.
Hãy tạo một bộ dữ liệu đầu vào cụ thể để tái hiện lỗi.
Cho biết:
- Input.
- Giá trị của từng biến quan trọng.
- Điều kiện nào được thực hiện.
- Kết quả thực tế theo code hiện tại.
- Kết quả đúng mà chương trình nên trả về.
Nếu không thể tạo trường hợp tái hiện từ code hiện có,
hãy nói rõ điều đó.
Nếu Grok không thể chỉ ra được một trường hợp cụ thể dù đã có đủ thông tin, bạn nên xem xét lại mức độ chắc chắn của nhận định đó.
Dùng Grok tìm nguyên nhân gốc thay vì sửa triệu chứng
Một chương trình có thể xuất hiện lỗi ở một vị trí nhưng nguyên nhân thực sự lại nằm ở bước trước đó. Nếu chỉ sửa dòng đang báo lỗi, vấn đề có thể quay trở lại hoặc chuyển sang một dạng khác.
Yêu cầu phân tích nguyên nhân gốc
Hãy mô tả hiện tượng trước rồi yêu cầu Grok lần ngược luồng xử lý.
Hiện tượng:
Người dùng gửi form thành công nhưng dữ liệu không xuất hiện trong danh sách.
Hãy truy ngược luồng xử lý từ kết quả cuối cùng.
Kiểm tra lần lượt:
1. Form có gửi đúng dữ liệu không?
2. PHP có nhận đủ dữ liệu không?
3. Dữ liệu có được xử lý đúng không?
4. Query INSERT có được thực thi không?
5. Database có ghi bản ghi không?
6. Query lấy danh sách có đọc đúng bản ghi không?
7. Phần HTML có hiển thị đúng dữ liệu không?
Hãy xác định điểm đầu tiên khiến kết quả bị sai.
Điểm “đầu tiên khiến kết quả bị sai” rất quan trọng. Nếu một giá trị đã sai từ bước đầu, việc sửa phần hiển thị phía sau sẽ không giải quyết được nguyên nhân.
Yêu cầu đưa ra giả thuyết rồi loại trừ từng khả năng
Với lỗi khó, có thể yêu cầu Grok lập danh sách nguyên nhân tiềm năng rồi dùng những thông tin hiện có để loại trừ từng nguyên nhân.
Hãy lập danh sách các nguyên nhân có thể khiến chức năng này thất bại.
Sau đó:
- Xác định nguyên nhân nào đã có bằng chứng trong code.
- Loại bỏ những nguyên nhân không phù hợp với thông tin tôi cung cấp.
- Cho biết thông tin nào còn thiếu để xác nhận nguyên nhân cuối cùng.
- Xếp hạng các nguyên nhân còn lại theo mức độ khả nghi.
Không sửa code cho đến khi xác định được nguyên nhân có khả năng cao nhất.
Phương pháp này phù hợp với những lỗi không thể xác định chỉ bằng cách nhìn một vài dòng code.
Dùng Grok tối ưu code sau khi đã hiểu chức năng
Không nên tối ưu code chỉ vì thấy một đoạn mã dài hoặc có vẻ chưa đẹp. Một đoạn code rõ ràng, dễ bảo trì đôi khi đáng giữ nguyên hơn một phiên bản ngắn nhưng khó hiểu.
Tối ưu mà không làm thay đổi hành vi
Khi muốn refactor, hãy xác định rõ rằng hành vi hiện tại phải được giữ nguyên.
Hãy refactor đoạn code này nhưng không thay đổi hành vi.
Yêu cầu:
- Giữ nguyên input và output.
- Giữ nguyên các quy tắc nghiệp vụ.
- Không thay đổi cấu trúc database.
- Không thay đổi tên API đang được sử dụng bên ngoài.
- Giảm code lặp lại nếu có.
- Làm rõ những phần khó đọc.
- Không tối ưu một phần nếu lợi ích không đáng kể.
Sau khi refactor, giải thích từng thay đổi quan trọng.
Đây là cách phù hợp khi bạn muốn cải thiện code cũ mà không muốn biến một lần tối ưu thành một lần viết lại toàn bộ chức năng.
Ưu tiên khả năng bảo trì
Code ngắn chưa chắc là code tốt. Khi yêu cầu Grok tối ưu, nên nói rõ tiêu chí bạn quan tâm. Với website lâu dài, khả năng đọc và sửa code thường quan trọng không kém số dòng code.
Hãy đánh giá đoạn code này về khả năng bảo trì.
Tập trung vào:
- Tên biến và tên hàm.
- Code lặp lại.
- Hàm có quá nhiều trách nhiệm hay không.
- Điều kiện lồng nhau.
- Phần khó kiểm thử.
- Những phụ thuộc không rõ ràng.
- Những thay đổi có thể gây ảnh hưởng dây chuyền.
Chỉ đề xuất refactor ở những điểm mang lại lợi ích rõ ràng.
Dùng Grok tạo checklist kiểm thử sau khi sửa code
Sau khi đã sửa lỗi, đừng chỉ kiểm tra trường hợp khiến lỗi xuất hiện ban đầu. Hãy kiểm tra cả những trường hợp bình thường, dữ liệu thiếu, dữ liệu biên và những tình huống bất thường.
Tạo test case từ yêu cầu thực tế
Dựa trên chức năng xử lý đăng ký tài khoản này,
hãy tạo checklist kiểm thử.
Bao gồm:
- Trường hợp thành công.
- Dữ liệu bắt buộc bị thiếu.
- Email không hợp lệ.
- Email đã tồn tại.
- Mật khẩu không đạt yêu cầu.
- Dữ liệu có ký tự đặc biệt.
- Người dùng gửi request nhiều lần.
- Database xảy ra lỗi.
- Người dùng không có quyền thực hiện thao tác.
Với mỗi trường hợp, ghi:
Input | Điều kiện | Kết quả mong đợi.
Checklist do AI tạo có thể trở thành cơ sở để bạn kiểm tra thủ công hoặc chuyển thành test tự động nếu dự án có hệ thống kiểm thử.
Kiểm tra các trường hợp biên
Nhiều lỗi chỉ xuất hiện khi dữ liệu nằm ở giới hạn. Ví dụ, code xử lý tốt với số lượng từ 1 đến 100 nhưng có thể sai khi giá trị bằng 0, âm, rất lớn hoặc bị bỏ trống.
Hãy tìm các trường hợp biên của chức năng này.
Đặc biệt kiểm tra:
- Giá trị bằng 0.
- Giá trị âm.
- Giá trị nhỏ nhất.
- Giá trị lớn nhất.
- Chuỗi rỗng.
- Giá trị null.
- Dữ liệu sai kiểu.
- Dữ liệu vượt giới hạn dự kiến.
Với mỗi trường hợp, cho biết code hiện tại sẽ xử lý như thế nào.
Đây là một trong những cách hữu ích để phát hiện lỗi mà việc thử vài dữ liệu thông thường khó tìm ra.
Cách dùng Grok phân tích code hiệu quả trong công việc thực tế
Thay vì coi Grok như công cụ chỉ dùng khi code bị lỗi, bạn có thể đưa nó vào nhiều giai đoạn của quá trình phát triển website. Quan trọng là mỗi lần sử dụng cần có mục tiêu rõ ràng.
Khi nhận một đoạn code cũ
Đầu tiên hãy yêu cầu Grok giải thích cấu trúc và luồng hoạt động. Sau đó mới kiểm tra lỗi, bảo mật và khả năng bảo trì. Không nên refactor ngay khi chưa hiểu chức năng của code.
Khi gặp lỗi khó xác định
Cung cấp hiện tượng, thông báo lỗi, input, output thực tế và những phần code liên quan. Yêu cầu Grok tìm nguyên nhân gốc, đưa ra giả thuyết và đề xuất cách kiểm chứng trước khi sửa.
Khi muốn sửa một chức năng
Nêu rõ hành vi hiện tại, hành vi mong muốn và những phần không được phép thay đổi. Sau khi Grok đưa ra code mới, hãy yêu cầu nó so sánh với phiên bản cũ để kiểm tra những thay đổi ngoài phạm vi.
Khi muốn cải thiện code
Đừng chỉ yêu cầu “tối ưu code”. Hãy xác định mục tiêu là tăng khả năng đọc, giảm code lặp, cải thiện hiệu suất, tăng tính bảo trì hoặc tăng mức độ an toàn. Mỗi mục tiêu có cách tối ưu khác nhau.
Quy trình dùng Grok phân tích code nên áp dụng
Một quy trình đơn giản nhưng chặt chẽ sẽ giúp hạn chế việc sửa code theo phỏng đoán. Có thể áp dụng thứ tự sau cho hầu hết các tình huống:
- Xác định vấn đề: mô tả chính xác code đang làm gì và kết quả nào đang sai.
- Cung cấp bối cảnh: đưa những file, hàm, input, output và thông báo lỗi có liên quan.
- Phân tích: yêu cầu Grok giải thích luồng xử lý và tìm nguyên nhân.
- Xác minh: yêu cầu tạo trường hợp tái hiện hoặc chỉ ra bằng chứng trực tiếp từ code.
- Sửa: chỉ yêu cầu thay đổi sau khi đã xác định nguyên nhân.
- So sánh: đối chiếu code trước và sau khi sửa.
- Kiểm thử: kiểm tra trường hợp bình thường, trường hợp biên và những chức năng liên quan.
Quy trình này biến Grok từ một công cụ “sửa code theo yêu cầu” thành một trợ lý hỗ trợ phân tích xuyên suốt quá trình xử lý vấn đề. Người lập trình vẫn là người quyết định thay đổi nào được áp dụng vào dự án.
- 0 Bình luận
Email, Điện thoại của bạn sẽ không được hiển thị công khai. Các trường bắt buộc được đánh dấu *
