Thông báo lỗi màu đỏ rất dễ làm người mới muốn sao chép cả dự án vào ChatGPT rồi hỏi “sửa giúp tôi”. Đôi khi cách đó chạy được, nhưng nhiều lần AI trả lại một phiên bản mới, đổi cả cấu trúc khiến ta không biết lỗi ban đầu nằm đâu. Tôi thường coi gỡ lỗi như điều tra: ghi nhận hiện tượng, thu thập bằng chứng nhỏ nhất, đưa ra giả thuyết rồi kiểm tra từng giả thuyết. ChatGPT có thể hỗ trợ rất tốt nếu bạn đưa đúng dấu vết.
Gửi thông tin đủ để tái hiện
Hãy cung cấp ngôn ngữ và phiên bản nếu biết, môi trường chạy, lệnh vừa thực hiện, hành vi mong muốn, hành vi thực tế và nguyên văn thông báo lỗi. Nếu lỗi xuất hiện sau một thay đổi, nói rõ bạn vừa sửa gì. Không cần gửi toàn bộ mã nguồn nếu chỉ một hàm hoặc một đoạn cấu hình liên quan. Trước khi chia sẻ, xóa khóa API, mật khẩu, token truy cập, email riêng hoặc dữ liệu khách hàng. Nếu không chắc file nào chứa lỗi, hỏi ChatGPT cách thu thập thêm thông tin an toàn trước.
Prompt mẫu: “Tôi đang chạy ứng dụng JavaScript bằng Node phiên bản 22 trên Windows. Khi chạy `npm start`, tôi mong trang mở ở localhost nhưng terminal báo lỗi dưới đây: [dán lỗi]. Đây là đoạn cấu hình liên quan: [đoạn mã đã bỏ bí mật]. Hãy giải thích lỗi bằng lời dễ hiểu, nêu tối đa ba nguyên nhân có khả năng, chỉ tôi cách kiểm tra từng nguyên nhân trước khi đề xuất bản sửa nhỏ nhất.” Yêu cầu giải thích và kiểm tra trước giúp bạn học cách đọc lỗi, thay vì chỉ nhận miếng code mới.
Đừng sửa nhiều thứ cùng lúc
Sau khi AI đề xuất thay đổi, yêu cầu nó chỉ ra chính xác file và dòng logic cần đổi, sau đó sửa một nguyên nhân mỗi lần. Chạy lại cùng lệnh để xem vấn đề đã hết chưa. Nếu phát sinh lỗi mới, giữ nguyên thông báo mới và nói rõ thay đổi vừa thực hiện. Tránh để AI “tối ưu luôn cho sạch” khi bạn đang cố tìm một bug cụ thể. Mỗi thay đổi không liên quan làm tăng số khả năng cần xem xét, nhất là khi bạn chưa có kiểm thử tự động.
Nếu ChatGPT đề xuất một bản sửa mà bạn không hiểu, hãy hỏi: “Giải thích sự khác nhau trước và sau bằng một ví dụ đầu vào; nếu sửa này thất bại thì tôi sẽ thấy dấu hiệu gì?” Có thể yêu cầu nó viết một trường hợp kiểm tra nhỏ tái hiện lỗi, rồi kiểm tra trường hợp đó sau khi sửa. Với lỗi giao diện, gửi ảnh màn hình kèm kích thước cửa sổ, trình duyệt và thao tác dẫn tới lỗi. Với lỗi dữ liệu, cung cấp vài dòng mẫu đã làm giả, giữ nguyên hình dạng nhưng bỏ thông tin thật.
Biết lúc nào cần quay lại
Hãy lưu bản đang chạy trước khi thử sửa lớn. Git giúp lưu mốc và so sánh thay đổi; nếu chưa dùng Git, ít nhất hãy sao chép dự án thành một bản dự phòng trước khi thay nhiều tệp. Khi câu trả lời của AI tiếp tục đổi giải pháp mà lỗi vẫn còn, quay về trạng thái ban đầu và thu nhỏ ví dụ cho đến khi có thể tái hiện vấn đề bằng một đoạn độc lập. Đó thường là cách nhanh hơn để tìm nguyên nhân, đồng thời giúp bạn phân biệt lỗi trong code với vấn đề cấu hình hoặc phiên bản thư viện.
AI có thể nhầm về cách một thư viện hoạt động, nên đừng chạy lệnh xóa dữ liệu hoặc thay đổi hệ thống nếu chưa hiểu tác động. Hãy nhờ giải thích từng lệnh trước. Quy trình này cũng là nền tảng khi dùng Codex sửa trực tiếp trong dự án: [hướng dẫn prompting Codex](https://developers.openai.com/cookbook/examples/gpt-5/codex_prompting_guide) khuyến khích mô tả mục tiêu, bối cảnh và cách xác nhận kết quả. Mục tiêu của gỡ lỗi không chỉ là làm thông báo biến mất; đó là tìm ra nguyên nhân đủ rõ để lỗi không quay lại ngay ở lần chạy tiếp theo.
