Debug Bằng AI
Debug Bằng AI
Triệu chứng (điều bạn nhìn thấy) vs nguyên nhân gốc (lý do thực sự): quy trình debug 5 bước tái hiện → cô lập → giả thuyết → sửa → xác minh. Luôn tự tay tái hiện lại sau khi sửa — 'AI báo đã xong' không phải bằng chứng.
Nắm vững nguyên lý và khái niệm nền tảng trước khi đi vào công cụ thực tế.
Áp dụng quy trình từng bước, case study thực chiến và template mẫu có sẵn.
Kiểm tra checklist hoàn thành, né tránh các sai lầm kinh điển để vận hành bền vững.
Nắm vững các khái niệm nền tảng, cơ chế hoạt động và mô hình tư duy cốt lõi.
1. Mục tiêu học tập
Sau bài này, bạn có thể:
2. Khái niệm cốt lõi
Triệu chứng vs nguyên nhân gốc — đây là mô hình tinh thần quan trọng nhất của bài này, và là lý do debug thường khó hơn cảm giác ban đầu. Triệu chứng là điều bạn nhìn thấy: “ghi chú biến mất sau khi tải lại trang.” Nguyên nhân gốc là lý do thực sự gây ra điều đó: có thể ghi chú chưa từng được lưu vào Database (bài 55) mà chỉ tồn tại tạm trong Frontend, hoặc lưu đúng nhưng bước đọc lại dữ liệu (khi tải trang) gọi sai API. Sửa đúng triệu chứng không có nghĩa đã sửa đúng nguyên nhân gốc — ví dụ thêm 1 thông báo “đã lưu” giả để triệu chứng “trông có vẻ ổn” biến mất, trong khi dữ liệu vẫn chưa thực sự được lưu.
Quy trình debug phổ quát (kiến thức chuyên môn nền tảng, không gắn 1 công cụ AI nào):
- Tái hiện lỗi — làm lỗi xảy ra lại được theo đúng các bước, một cách nhất quán (hoặc xác định rõ lỗi chỉ xảy ra ngẫu nhiên/theo điều kiện cụ thể). Không thể sửa đúng 1 lỗi mà bạn chưa tái hiện được.
- Cô lập phạm vi — thu hẹp: lỗi nằm ở Frontend, Backend, hay Database (mô hình 4 lớp đã học bài 55)? Xảy ra ở bước nào trong chu trình request-response?
- Đặt giả thuyết — đưa ra 1 lý do có khả năng nhất gây ra lỗi, dựa trên phạm vi đã cô lập.
- Sửa — thực hiện thay đổi nhắm đúng vào nguyên nhân gốc đã giả thuyết, không phải vá triệu chứng.
- Xác minh — tái hiện lại đúng các bước ở bước 1, xác nhận lỗi đã hết và không có lỗi mới phát sinh.
Quy trình chính thức khi làm việc với Claude Code (Lớp thực hành):
- Chia sẻ lỗi kèm ngữ cảnh cụ thể — ví dụ nguyên văn tài liệu chính thức: “I’m seeing an error when I run npm test” — không chỉ mô tả chung chung “nó bị lỗi.”
- Xin đề xuất cách sửa trước, chưa yêu cầu sửa ngay — ví dụ: “suggest a few ways to fix…” — để AI đưa nhiều phương án, bạn chọn hướng phù hợp thay vì để AI tự quyết định 1 mình.
- Áp dụng bản sửa đã chọn.
Nguồn chính thức lưu ý thêm: cho Claude Code lệnh để tự tái hiện lỗi kèm stack trace nếu có, mô tả rõ các bước tái hiện, và cho biết lỗi là ngẫu nhiên (intermittent) hay luôn xảy ra (consistent) — thông tin này ảnh hưởng trực tiếp cách AI chẩn đoán.
3. Tại sao nội dung này quan trọng
Bài 56 đã trích số liệu thật: code AI-đồng-tác-giả không qua review có tỷ lệ lỗi nghiêm trọng cao hơn 1,7 lần. Debug chính là kỹ năng bù đắp trực tiếp rủi ro đó — không phải nội dung phụ, mà là phần đối trọng bắt buộc của tốc độ xây dựng nhanh đã học ở bài 56.
4. Cơ chế hoạt động
Phân định AI vs con người:
| Điều bạn cần hiểu | Điều AI có thể thực hiện | Điều bạn phải xác nhận | |
|---|---|---|---|
| Tái hiện lỗi | Lỗi cần tái hiện được (nhất quán hoặc rõ điều kiện) trước khi sửa | Tự chạy lệnh, đọc log, tái hiện lỗi nếu được cho đủ ngữ cảnh | Bước tái hiện AI mô tả có đúng thực tế không |
| Chẩn đoán | Phân biệt triệu chứng vs nguyên nhân gốc | Đề xuất nhiều giả thuyết/phương án sửa | Giả thuyết AI chọn có nhắm đúng nguyên nhân gốc, hay chỉ vá triệu chứng |
| Áp dụng sửa | Bạn chọn phương án, không phải AI tự quyết | Viết code sửa theo phương án đã chọn | Đọc lại thay đổi trước khi chấp nhận (nguyên tắc đã học bài 56) |
| Xác minh | “AI báo đã xong” không đồng nghĩa lỗi đã hết | Chạy lại để kiểm tra | Tự tay tái hiện lại đúng các bước gây lỗi ban đầu, xác nhận thật sự hết — đây là bước con người không nên bỏ qua |
5. Mental model
Nếu bài 56 là lúc bạn xây xong vài phòng đầu tiên, bài này là lúc bạn phát hiện một vết rò nước trong ngôi nhà vừa xây. Vá tạm chỗ nước đọng trên sàn (triệu chứng) sẽ hết nước tạm thời — nhưng nếu ống nước phía sau tường vẫn bị nứt (nguyên nhân gốc), nước sẽ tiếp tục rò và có thể còn tệ hơn. Thợ xây giỏi (AI) có thể chẩn đoán và đề xuất chỗ sửa, nhưng bạn là người kiểm tra lại xem nước có thật sự đã ngừng rò trước khi coi là xong.
Quy trình thực thi từng bước, case study cụ thể và bộ prompt/template áp dụng ngay.
6. Hướng dẫn từng bước
Áp dụng cho dự án tích lũy: Trợ Lý Ghi Chú Cá Nhân Có AI Tóm Tắt.
Sau bài 56, dự án có prototype chạy được với 3 tính năng: thêm, xem danh sách, xóa ghi chú. Giả sử bạn phát hiện lỗi: thêm 1 ghi chú, tải lại trang (refresh) — ghi chú biến mất.
7. Ví dụ thực tế
Phân biệt vá triệu chứng vs sửa nguyên nhân gốc trong chính lỗi trên: nếu Claude Code đề xuất “thêm 1 thông báo ‘Đã lưu!’ ngay khi bấm nút thêm” — đây là vá triệu chứng: cảm giác “đã lưu” xuất hiện nhưng dữ liệu vẫn có thể mất khi tải lại trang. Sửa đúng là khiến ghi chú thực sự được ghi vào Database trước khi coi là đã lưu — đây là lý do bước 5 (xác minh bằng tái hiện lại) không thể bỏ qua, kể cả khi giao diện “trông có vẻ ổn.”
8. Prompt/template/workflow
Tôi gặp lỗi: [mô tả điều bạn thấy sai].Các bước tái hiện: [bước 1, bước 2, bước 3...].Lỗi này [luôn xảy ra / chỉ thỉnh thoảng xảy ra].Gợi ý vài hướng nguyên nhân có thể gây ra lỗi này trước khi sửa.[ ] Đã đọc lại thay đổi Claude Code vừa thực hiện chưa?[ ] Đã tự tay tái hiện lại đúng các bước gây lỗi ban đầu chưa?[ ] Lỗi ban đầu đã thực sự hết (không chỉ "trông có vẻ hết")?[ ] Có phát sinh lỗi mới ở tính năng khác không (thử lại thêm/xem/xóa)?9. Visual hoặc diagram cần thiết
10. Bài tập thực hành
- Trong dự án ghi chú của bạn, cố ý tạo 1 lỗi tương tự (hoặc tìm 1 lỗi thật đang có) và tái hiện lại nhất quán trước khi báo cho Claude Code.
- Dùng khung ở mục 8 để chia sẻ lỗi, xin ít nhất 2 hướng giả thuyết trước khi chọn.
- Sau khi sửa, tự tay tái hiện lại đúng các bước ban đầu — không chỉ tin lời AI báo “đã sửa xong.”
- Viết lại 1 câu phân biệt triệu chứng và nguyên nhân gốc cho đúng lỗi bạn vừa sửa.
Checklist kiểm tra mức độ sẵn sàng, nhận diện các bẫy sai lầm và nguyên tắc vàng vận hành.
11. Checklist
12. Lỗi thường gặp
15. Best practices
16. Nội dung nâng cao (không bắt buộc)
Nguyên tắc “tái hiện lỗi trước khi sửa” áp dụng cả khi lỗi là ngẫu nhiên (intermittent) — trường hợp khó hơn nhiều so với lỗi luôn xảy ra. Với lỗi ngẫu nhiên, bước “cô lập phạm vi” cần tìm ra điều kiện khiến lỗi xuất hiện (ví dụ: chỉ xảy ra khi tải lại trang rất nhanh sau khi thêm ghi chú) thay vì chỉ tìm vị trí lỗi — đây là kỹ năng debug nâng cao hơn, thường cần nhiều vòng chẩn đoán hơn quy trình cơ bản ở bài này.
⚠️ 13. Giới hạn & khi nào KHÔNG nên áp dụng
- Bài này không dạy cải thiện code đã đúng nhưng cấu trúc chưa tốt — đó là bài 60 (Refactor).
- Bài này không dạy viết test tự động để phát hiện lỗi sớm hơn — đó là bài 61 (Testing); ở đây debug vẫn chủ yếu dựa vào quan sát thủ công.
- Với lỗi liên quan tới bảo mật (ví dụ dữ liệu nhạy cảm bị lộ), quy trình debug thông thường ở bài này chưa đủ — cần thêm góc nhìn bảo mật riêng (bài 62).
🔐 14. An toàn & quản trị (Safety/Governance)
Bước xác minh là phòng tuyến an toàn quan trọng nhất bài này: “AI báo đã sửa xong” không phải bằng chứng lỗi đã hết — đúng tinh thần nguyên tắc bất biến đã đặt ra ở kế hoạch Level 6: AI không bao giờ là người xác nhận cuối cùng. Với lỗi liên quan tới mất dữ liệu (như ví dụ ở bài này), xác minh cẩn thận đặc biệt quan trọng — 1 lỗi “trông như đã sửa” nhưng thực chất vẫn mất dữ liệu có thể gây hại nghiêm trọng hơn khi sản phẩm dùng thật.
📚 17. Nguồn tham khảo
Common Workflows, Anthropic (code.claude.com/docs) — quy trình chính thức “Fix bugs efficiently” (chia sẻ lỗi → xin đề xuất → áp dụng), lưu ý về stack trace và intermittent vs consistent · Dẫn chiếu (không trích dẫn mới): bài 55 (mô hình 4 lớp, dùng để cô lập phạm vi lỗi), bài 56 (nguyên tắc luôn đọc lại thay đổi), bài 57 (vòng lặp agentic gather→act→verify).