Debug Bằng AI

Level: L6 — AI Coding & Vibe Coding (Bài 7/12 theo thứ tự sản xuất — · Đối tượng: Người đã học bài 53-58, đã có 1 prototype chạy được cục bộ

1. Mục tiêu học tập

Sau bài này, bạn có thể:

Phân biệt triệu chứng (symptom — điều bạn quan sát thấy sai) với nguyên nhân gốc (root cause — lý do thực sự gây ra triệu chứng đó).
Thực hiện quy trình debug phổ quát: tái hiện lỗi → cô lập phạm vi → đặt giả thuyết → sửa → xác minh.
Dùng Claude Code để chẩn đoán và sửa lỗi theo đúng quy trình 3 bước chính thức (chia sẻ lỗi → xin đề xuất → áp dụng), không giao toàn quyền tự sửa.
Áp dụng debug cho dự án tích lũy: chẩn đoán và sửa lỗi mất dữ liệu ghi chú sau khi tải lại trang.

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) [S98]:

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 [S98].

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.

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.

Tái hiện lỗi theo đúng bước, xác nhận nhất quán — thêm ghi chú → tải lại trang → quan sát ghi chú có còn không. Lặp lại 2-3 lần để chắc chắn lỗi xảy ra luôn (consistent), không phải ngẫu nhiên.
Chia sẻ lỗi với Claude Code kèm đủ ngữ cảnh — ví dụ: “Tôi thêm 1 ghi chú, sau đó tải lại trang thì ghi chú biến mất. Lỗi này luôn xảy ra, không phải thỉnh thoảng.”
Xin đề xuất trước khi sửa — “gợi ý vài hướng có thể gây ra lỗi này.” Claude Code (đúng mô hình 4 lớp bài 55) có thể chỉ ra: ghi chú chỉ đang được lưu tạm ở Frontend (bộ nhớ trình duyệt), chưa thực sự được ghi xuống Database.
Chọn hướng, yêu cầu áp dụng — nếu đúng nguyên nhân gốc là “chưa ghi xuống Database”, yêu cầu Claude Code sửa để bước thêm ghi chú thực sự gọi đúng API lưu dữ liệu (bài 55), không chỉ cập nhật giao diện.
Đọc lại thay đổi, xác minh bằng cách lặp lại đúng bước 1 — thêm ghi chú → tải lại trang → xác nhận ghi chú vẫn còn. Thử thêm với ghi chú khác để chắc chắn không phải trùng hợp.

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

Khung chia sẻ lỗi tái sử dụng:

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.

Checklist xác minh sau 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

Hình 6.7 — Debug: tảng băng triệu chứng/nguyên nhân gốc, và quy trình 5 bước.

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.

11. Checklist

Phân biệt được triệu chứng và nguyên nhân gốc.
Thực hiện được quy trình debug 5 bước phổ quát.
Biết chia sẻ lỗi đủ ngữ cảnh (bước tái hiện, ngẫu nhiên hay không).
Luôn tự tay xác minh lại, không chỉ tin "AI báo đã xong."
Không nhầm Debug với Refactor (bài 60).

12. Lỗi thường gặp

Báo lỗi mơ hồ (“nó bị lỗi”, “không chạy”) — thiếu ngữ cảnh khiến AI phải đoán, dễ chẩn đoán sai.
Chấp nhận sửa đầu tiên AI đề xuất mà không xin thêm phương án — bỏ lỡ khả năng AI chỉ đang vá triệu chứng thay vì sửa nguyên nhân gốc.
Không tự tay tái hiện lại sau khi sửa — tin lời “đã xong” của AI mà không kiểm chứng, đúng rủi ro đã nêu ở bài 56 (mục 2).
Nhầm Debug với Refactor — cố “dọn dẹp” code trong lúc đang sửa lỗi, làm phạm vi thay đổi lớn hơn cần thiết, khó xác minh đúng lỗi nào đã hết.

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 (mục 4, 6) 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.

15. Best practices

Luôn xin nhiều hơn 1 giả thuyết/phương án trước khi chọn — 1 đề xuất duy nhất dễ khiến bạn chấp nhận mà không cân nhắc.
Ghi lại đúng các bước tái hiện lỗi trước khi báo cho AI — càng cụ thể, chẩn đoán càng chính xác.
Sau khi sửa 1 lỗi, thử lại cả các tính năng khác đã hoạt động đúng trước đó (không chỉ tính năng vừa sửa) — đảm bảo bản sửa không vô tình làm hỏng phần khác.

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 [S98]. Với lỗi ngẫu nhiên, bước “cô lập phạm vi” (mục 2) 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.

17. Nguồn tham khảo

[S98] 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 của Claude Code, cùng nguyên lý với quy trình debug ở bài này).

18. Ngày kiểm chứng

Quy trình chính thức kiểm chứng qua nguồn Tier 1 (S98) ngày 2026-07-12. Quy trình debug phổ quát (mục 2, phần đầu) là kiến thức chuyên môn nền tảng, không phụ thuộc thời điểm — rủi ro lỗi thời thấp hơn các bài gắn chặt tính năng sản phẩm (ví dụ bài 57, 58).