Để debug bằng AI, mô tả hành vi mong đợi và thực tế, cung cấp mã tối thiểu cùng lỗi đã khử bí mật, rồi yêu cầu giả thuyết trước khi sửa. Áp dụng thay đổi nhỏ trên nhánh riêng, chạy test tái hiện và regression, kiểm tra diff; chỉ nhận bản sửa khi hiểu nguyên nhân.
AI hỗ trợ debug ở đâu?
AI coding assistant có thể giải thích stack trace, đọc đoạn code, đề xuất nguyên nhân khả dĩ, gợi ý test tái hiện và nhận xét bản sửa. Nó hữu ích khi bạn cần một góc nhìn thứ hai hoặc chưa quen thư viện. Nhưng phản hồi là giả thuyết, không phải kết luận: model có thể bỏ qua runtime, cấu hình, dữ liệu thực tế hoặc thay đổi gần đây vốn quyết định lỗi.
Phân biệt ba khái niệm trước khi hỏi. Triệu chứng là điều quan sát được như test fail hay HTTP 500. Nguyên nhân là điều kiện khiến triệu chứng xảy ra, có thể nằm ở caller, dữ liệu hoặc môi trường. Bản sửa là thay đổi loại bỏ nguyên nhân mà không phá hành vi hợp lệ khác. Một câu trả lời chỉ chặn exception nhưng không tìm lý do dữ liệu sai có thể làm lỗi biến mất khỏi log mà hệ thống vẫn sai.
GitHub Docs hướng dẫn người dùng Copilot cung cấp lỗi và bối cảnh dự án để hỏi chẩn đoán. Tài liệu mô tả hành vi của Copilot; các nguyên tắc tái hiện, thử giả thuyết và xác minh dưới đây là quy trình kỹ thuật tổng quát, không phụ thuộc vào một nhà cung cấp.
Quy trình sáu bước
- Tái hiện: ghi lệnh, bước, đầu vào mẫu đã làm sạch và kết quả. Xác nhận lỗi xuất hiện ổn định; nếu lỗi chập chờn, ghi tần suất và điều kiện.
- Thu bằng chứng: lấy thông báo lỗi, stack trace liên quan, log trước/sau, test fail, phiên bản runtime và vùng mã trực tiếp liên quan. Phân biệt dữ liệu bị lược bỏ với nội dung thực.
- Khử bí mật: xóa token, cookie, mật khẩu, khóa riêng, dữ liệu khách hàng và đường dẫn nội bộ. Thay bằng giá trị giả nhất quán; chỉ gửi mã theo chính sách nhóm và điều khoản công cụ đã rà soát.
- Hỏi chẩn đoán trước: yêu cầu tối đa vài giả thuyết, bằng chứng hỗ trợ, cách bác bỏ và phép thử nhỏ. Chưa yêu cầu model sửa code ngay.
- Thử một thay đổi: sau khi xác nhận giả thuyết, đề xuất diff hẹp trong nhánh riêng. Không cho phép xóa assertion, tắt xác thực, bắt mọi lỗi rồi bỏ qua hoặc thêm dependency ngoài ý muốn.
- Chứng minh: chạy test tái hiện trên code gốc để chắc nó bắt lỗi; chạy lại sau sửa, test lân cận, regression suite và kiểm tra diff. Người phát triển review trước khi merge.
Quy trình này giúp tách việc “AI nói hợp lý” khỏi việc “bằng chứng cho thấy thay đổi đúng”. Lưu lệnh kiểm thử và kết quả trong mô tả thay đổi để reviewer có thể lặp lại.
Mẫu prompt debug có cấu trúc
Thay phần trong ngoặc vuông bằng thông tin đã được phép chia sẻ. Đưa dữ liệu tối thiểu nhưng đủ liên hệ đầu vào, stack trace và đoạn mã.
Bạn hỗ trợ chẩn đoán, chưa sửa mã cho đến khi tôi yêu cầu.
Mục tiêu/hành vi mong đợi: [mô tả]
Hành vi thực tế và tần suất: [mô tả]
Cách tái hiện: [lệnh và bước với dữ liệu giả]
Môi trường: [runtime, framework, hệ điều hành nếu liên quan]
Log đã khử bí mật:
[dán phần liên quan]
Mã tối thiểu:
[dán hàm/test liên quan]
Thay đổi gần đây đã biết: [nếu có]
Trước tiên hãy nêu tối đa ba giả thuyết và gắn từng giả thuyết với bằng chứng.
Nêu thông tin còn thiếu và phép thử phân biệt chúng.
Không khẳng định nguyên nhân nếu chưa có bằng chứng.
Sau khi tôi xác nhận, đề xuất diff nhỏ nhất và test tái hiện/regression.
Không thêm thư viện, không xóa kiểm tra bảo mật, không yêu cầu bí mật.Yêu cầu AI giải thích test nào sẽ thất bại nếu giả thuyết đúng. Nếu mọi giả thuyết đều không thể kiểm tra, đầu vào còn thiếu hoặc câu hỏi quá rộng. Hãy thu hẹp ví dụ thay vì dán thêm toàn bộ repository.
Ngữ cảnh an toàn, đủ dùng
Stack trace cho thấy nơi lỗi nổi lên, chưa chắc nơi gây lỗi. Với exception, giữ frame liên quan và phần thông báo cần thiết; với race condition, nêu thứ tự sự kiện và thời gian tương đối; với lỗi build, cho biết lệnh, phiên bản compiler và thay đổi dependency. Đừng bỏ phần quan trọng rồi kỳ vọng AI suy ra chính xác.
Không gửi tệp cấu hình chứa secret như biến môi trường, khóa API, cookie phiên hay thông tin cá nhân. Thay ID thật bằng nhãn ổn định để bảo toàn quan hệ trong log; ví dụ cùng một khách hàng giả luôn mang mã CLIENT_A. Xóa bí mật khỏi một prompt sau khi đã gửi không đồng nghĩa credential đã bị vô hiệu hóa; nếu sự cố xảy ra, theo quy trình ứng phó và xoay vòng khóa phù hợp.
Ngữ cảnh hữu ích có thể gồm: mô tả hành vi đúng theo đặc tả; hành vi sai; test liên quan; đoạn code gọi hàm và hàm được gọi; dependency/version; môi trường phát sinh; và một mẫu dữ liệu đã làm sạch. Chỉ thêm một tệp khi nó trả lời câu hỏi cụ thể. Đưa nhiều tệp không liên quan thường tăng nhiễu và nguy cơ chia sẻ dư thừa.
- Stack trace: chuỗi frame ghi lại đường đi đến exception.
- Minimal reproducible example: ví dụ nhỏ nhất vẫn làm lỗi xuất hiện.
- Regression test: kiểm tra để thay đổi mới không làm lỗi cũ quay lại hoặc phá chức năng đã có.
- Diff: phần thay đổi so với phiên bản gốc, dùng để review phạm vi patch.
- CI: hệ thống tự chạy build/test; kết quả xanh chỉ có ý nghĩa trong phạm vi các kiểm tra được cấu hình.
- False positive: test báo lỗi dù hành vi được kiểm tra thực tế không sai; cần xác minh test và hợp đồng chức năng.
Ví dụ: xử lý lỗi thay vì vá triệu chứng
Giả sử một endpoint nhận trường ngày từ JSON và test gặp TypeError khi giá trị rỗng. Không đủ thông tin để kết luận trường đó bắt buộc hay tùy chọn. Hỏi AI kiểm tra luồng từ parser đến validator, nêu giả thuyết như dữ liệu null không được kiểm tra hoặc test gửi sai cấu trúc, rồi đề nghị test cho null, chuỗi rỗng, định dạng không hợp lệ và giá trị đúng.
Nếu đặc tả nói ngày bắt buộc, bản sửa có thể trả lỗi validation rõ ràng trước khi gọi hàm phía sau. Nếu ngày được phép thiếu, cách xử lý phải theo hợp đồng API đã thống nhất. AI không được tự đặt mặc định nghiệp vụ. Tạo test lỗi ban đầu và test các biên; chạy trên commit gốc để thấy test thất bại, sau đó chạy bản sửa để thấy test qua.
Nếu AI đề xuất bao toàn bộ hàm bằng try/catch rồi trả về giá trị mặc định, hỏi liệu cách đó có che lỗi dữ liệu hoặc làm caller tưởng yêu cầu thành công không. Bản sửa gọn hơn chưa chắc đúng; tiêu chí là giữ hợp đồng, nêu được nguyên nhân và có kiểm thử chứng minh.
Xác minh bản sửa
| Kiểm tra | Điều cần xác nhận | Bằng chứng mong đợi | Chưa đạt nếu |
|---|---|---|---|
| Test tái hiện | Lỗi cũ xuất hiện trên code gốc? | Test đỏ trước sửa, xanh sau sửa | Test xanh ở cả hai phiên bản |
| Trường hợp biên | Input rỗng, sai định dạng, giới hạn được xử lý? | Test phản ánh hợp đồng chức năng | Chỉ test happy path |
| Regression | Caller và luồng lân cận còn hoạt động? | Test vùng ảnh hưởng và suite phù hợp | Chỉ chạy đúng một test mới |
| Static/build | Kiểu dữ liệu, lint, build có lỗi mới? | Kết quả kiểm tra của dự án | Bỏ qua lỗi không giải thích |
| Review diff | Thay đổi có hẹp và giữ guardrail? | Mỗi dòng sửa đều có lý do | Tắt auth, xóa assertion, catch-all |
| Dependency | Có thêm gói không cần thiết? | Kiểm tra tài liệu và chính sách dự án | Cài gói chỉ vì model nêu tên |
Test xanh không đảm bảo hệ thống đúng hoàn toàn: test có thể thiếu coverage hoặc kiểm tra sai yêu cầu. Đối với thay đổi bảo mật, dữ liệu quan trọng hoặc hệ thống vận hành, áp dụng review và phê duyệt theo chuẩn nhóm. Đừng để AI tự tuyên bố “đã sửa 100%”; hãy đưa lệnh và bằng chứng cho người review.
Khi kết quả không như ý
- Giả thuyết sai: cung cấp kết quả phép thử vừa chạy, yêu cầu cập nhật chẩn đoán dựa trên bằng chứng mới, không gửi lại toàn bộ dự án.
- Không tái hiện được: ghi môi trường, tần suất và thứ tự thao tác; dùng log có cấu trúc phù hợp. Không nhận patch chỉ vì lỗi tạm thời biến mất.
- Patch quá lớn: yêu cầu loại refactor ngoài phạm vi, chia nhỏ và chỉ rõ mỗi thay đổi giải quyết giả thuyết nào.
- CI đỏ: so sánh lệnh và môi trường local/CI, kiểm tra lockfile, biến cấu hình giả và test harness. Không xóa test để làm pipeline xanh.
- Đề xuất thư viện lạ: xác minh tên, tài liệu chính thức, mức duy trì, tương thích và license theo quy trình trước khi cài.
- Patch không hiểu được: chưa merge. Yêu cầu giải thích hoặc tự viết lại sau khi tìm được nguyên nhân.
Nếu lỗi chỉ xảy ra production, tạo bản sao dữ liệu đã khử định danh hoặc một tình huống giả tương đương; không sao chép nguyên log sản xuất vào công cụ chưa được phê duyệt. Giữ bản sửa có thể rollback và ghi điều kiện dừng nếu phát hiện tác động phụ.
Câu hỏi thường gặp
AI có tìm đúng nguyên nhân gốc không?
AI có thể đưa giả thuyết hữu ích nhưng không đảm bảo đúng, đặc biệt khi thiếu trạng thái runtime hoặc dữ liệu tái hiện. Hãy chọn phép thử có thể bác bỏ giả thuyết thay vì chỉ đọc phần giải thích.
Có nên gửi toàn bộ repository?
Chỉ khi quyền, chính sách và điều khoản công cụ cho phép. Thường nên bắt đầu từ ví dụ tối thiểu, file liên quan và log đã làm sạch để giảm nhiễu cùng lượng dữ liệu chia sẻ.
Test xanh thì có thể merge không?
Chưa đủ. Đọc diff, kiểm tra test tái hiện có đỏ trên code cũ không, chạy kiểm tra hồi quy và làm review theo quy trình dự án. Test chỉ chứng minh phạm vi mà nó thực sự kiểm tra.
Người mới có nên dùng AI debug?
Có thể dùng để học cách đọc lỗi và đặt giả thuyết. Hãy yêu cầu giải thích, tự dự đoán kết quả test và đối chiếu tài liệu ngôn ngữ; tránh sao chép patch mà không hiểu.
Nên đưa phần nào của log?
Đưa thông báo và các frame cần thiết, lệnh tái hiện, môi trường liên quan; bỏ token, thông tin cá nhân và đường dẫn nhạy cảm. Giữ mã giả nhất quán để các dòng vẫn liên hệ được.
Có nên để AI tự sửa trực tiếp trên nhánh chính?
Nên làm trong nhánh hoặc bản sao có thể hoàn tác, review diff trước khi áp dụng và chạy test. Với repo dùng chung, tuân thủ quy trình pull request và quyền ghi hiện có.
Nguồn tham khảo
- GitHub Docs — Learning to debug with GitHub Copilot — ví dụ dùng Copilot đọc lỗi và cung cấp ngữ cảnh.
- GitHub Docs — Get started with Copilot Chat in your IDE — các yêu cầu sửa code và viết test trong IDE.
Đọc thêm
Công cụ phát triển AI cho người mới · Kiểm thử phần mềm là gì
Bình luận (0
)