debugger

Tổng quan về debugger skill

debugger skill làm được gì

debugger skill cung cấp cho AI agent một quy trình có cấu trúc để chẩn đoán lỗi phần mềm, thay vì nhảy thẳng tới các phỏng đoán. Skill này được thiết kế cho công việc debugging như code bị lỗi, stack trace, crash, hành vi bất thường, lỗi xảy ra ngắt quãng, và các tình huống xử lý sự cố kiểu production — nơi việc tìm đúng nguyên nhân gốc quan trọng hơn nhiều so với việc vá tạm cho xong.

Ai nên cài debugger skill

debugger skill phù hợp nhất với:

• lập trình viên muốn có một quy trình debug lặp lại được
• các team dùng AI để điều tra bug, không chỉ để viết code
• người dùng có thể cung cấp log, thông báo lỗi, bước tái hiện, hoặc bối cảnh mã nguồn
• những ai muốn phân tích theo giả thuyết thay vì chỉ nhận các lời khuyên chung chung kiểu “thử cài lại đi”

Nếu nhu cầu chính của bạn là sinh code mới hoàn toàn từ đầu, đây không phải lựa chọn mạnh nhất. Skill này phát huy tốt hơn nhiều khi hệ thống đã tồn tại và đang gặp lỗi.

Nhu cầu thực sự mà skill này giải quyết

Phần lớn người dùng không cần “mẹo debug”. Họ cần được hỗ trợ trả lời các câu hỏi như:

• chính xác thứ gì đang bị hỏng
• lỗi nhiều khả năng bắt đầu từ đâu
• bằng chứng nào củng cố kết luận đó
• nên kiểm tra gì tiếp theo
• sửa thế nào để không che mất vấn đề thật

debugger skill có giá trị vì nó buộc agent đi theo một chuỗi hợp lý: hiểu vấn đề, thu thập bằng chứng, hình thành giả thuyết, kiểm chứng, xác định nguyên nhân gốc, rồi mới sửa và xác minh lại.

Vì sao debugger này khác với một prompt thông thường

Một prompt bình thường thường chỉ tạo ra checklist xử lý sự cố khá nông hoặc một bản vá mang tính suy đoán. debugger for Debugging mạnh hơn khi bạn muốn agent:

• hỏi thêm những bằng chứng còn thiếu
• tách triệu chứng ra khỏi nguyên nhân
• xếp hạng các khả năng có thể xảy ra
• đề xuất các phép thử có mục tiêu
• xác minh bản sửa sau khi đã đề xuất

Cấu trúc đó giúp giảm các vòng lặp lãng phí, nhất là với những lỗi rối, có nhiều nguyên nhân khả dĩ.

Điều quan trọng nhất trước khi cài debugger skill

Skill này khá gọn: repository chủ yếu chỉ có một file SKILL.md mô tả quy trình debug và hướng dẫn khi nào nên dùng. Không có script bổ sung, tài liệu tham chiếu, hay thư mục rules nào bạn phải học trước. Điều đó giúp việc áp dụng rất dễ, nhưng cũng đồng nghĩa chất lượng đầu ra phụ thuộc rất nhiều vào chất lượng ngữ cảnh bạn cung cấp.

Rào cản lớn nhất khi áp dụng không nằm ở độ phức tạp khi cài đặt. Vấn đề nằm ở input yếu: không có bước tái hiện, không có log, không có chi tiết môi trường, và không nói rõ hành vi mong đợi là gì.

Cách dùng debugger skill

Cách cài debugger skill

Nếu môi trường agent của bạn hỗ trợ cài Skills từ GitHub, hãy cài debugger skill từ đường dẫn repository chứa awesome_agent_skills/debugger. Cách dùng phổ biến là:

npx skills add Shubhamsaboo/awesome-llm-apps --skill debugger

Nếu hệ thống của bạn dùng một skill loader khác, hãy trỏ nó tới thư mục skill debugger trong repository:
awesome_agent_skills/debugger

Nên đọc gì trước trong repository

Hãy bắt đầu với:

• SKILL.md

File này chứa gần như toàn bộ logic vận hành quan trọng:

• khi nào nên áp dụng skill
• quy trình debug
• những loại bằng chứng agent nên yêu cầu
• chuỗi xử lý mong đợi từ chẩn đoán đến xác minh

Vì không có file hỗ trợ nào khác, chỉ cần đọc nhanh SKILL.md là đã đủ hiểu cách skill này “tư duy”.

Khi nào nên gọi debugger thay vì dùng agent code tổng quát

Hãy dùng debugger usage khi bạn đã có tín hiệu lỗi rõ ràng, chẳng hạn:

• một exception hoặc stack trace
• một test vừa bắt đầu fail
• crash hoặc treo ứng dụng
• hiệu năng giảm với nghi ngờ có regression
• hành vi thay đổi sau khi deploy, cập nhật dependency, hoặc đổi config
• một bug xảy ra chập chờn cần được khoanh vùng

Đừng dùng nó như công cụ đầu tiên cho thiết kế tính năng hoặc refactor diện rộng. Skill này được tối ưu cho việc cô lập lỗi.

Bộ input tối thiểu mà debugger skill cần

Để nhận được đầu ra hữu ích từ debugger guide, hãy cung cấp:

• hành vi mong đợi
• hành vi thực tế
• thông báo lỗi hoặc triệu chứng chính xác
• các bước tái hiện
• đoạn code hoặc đường dẫn file liên quan
• chi tiết môi trường: OS, runtime, phiên bản framework, khác biệt về config
• các thay đổi gần đây: deploy, nâng version dependency, feature flag, thay đổi schema

Nếu thiếu những phần này, skill vẫn có thể hỗ trợ, nhưng agent sẽ phải dành phần lớn thời gian để hỏi làm rõ.

Biến một bug report sơ sài thành prompt mạnh cho debugger skill

Prompt yếu:

My app is not working. Can you debug it?

Prompt tốt hơn:

Use the debugger skill. Expected behavior: POST /checkout returns 200. Actual behavior: returns 500 for carts with discount codes. Started after upgrading stripe from 12.x to 13.x. Repro: apply code SAVE10, submit payment. Error log: TypeError: cannot read properties of undefined (reading 'amount_total') in payments/checkout.ts:84. Environment: Node 20, Next.js 14, production only. Please rank likely causes, identify the most probable root cause, and suggest the smallest safe fix plus validation steps.

Phiên bản tốt hơn cho agent đủ bằng chứng để suy luận, thay vì đoán mò.

Quy trình debugger thực tế hoạt động hiệu quả

Một luồng debugger usage đáng tin cậy là:

1. Nêu rõ hành vi mong đợi so với hành vi thực tế.
2. Cung cấp bước tái hiện và bằng chứng lỗi.
3. Yêu cầu agent liệt kê các giả thuyết theo thứ tự xác suất.
4. Hỏi phép thử phân biệt nhanh nhất cho 2–3 giả thuyết hàng đầu.
5. Chia sẻ kết quả của các phép thử đó.
6. Chỉ yêu cầu bản sửa khi đã khoanh vùng được nguyên nhân gốc có khả năng cao nhất.
7. Yêu cầu các bước xác minh và kiểm tra regression.

Cách này khớp với thiết kế cốt lõi của skill và thường cho quyết định tốt hơn so với việc đòi bản vá ngay từ đầu.

debugger skill nhiều khả năng sẽ yêu cầu bạn cung cấp gì

Quy trình của skill tập trung vào việc thu thập:

• stack trace và thông báo lỗi
• log
• chi tiết môi trường và cấu hình
• dữ liệu đầu vào gây ra lỗi
• trạng thái hệ thống trước, trong, và sau khi lỗi xảy ra

Nếu bạn đưa sẵn các thông tin này ngay từ đầu, quá trình trao đổi sẽ nhanh hơn và cụ thể hơn rất nhiều.

Cách dùng debugger cho các lỗi xảy ra ngắt quãng

Với bug chập chờn hoặc không tái hiện ổn định, hãy cho agent biết:

• lỗi xuất hiện thường xuyên đến mức nào
• nó có liên quan tới tải, timing, concurrency, hay một bộ dữ liệu cụ thể hay không
• những gì bạn đã loại trừ được
• lỗi chỉ xảy ra ở local, chỉ ở production, hay chỉ trong một môi trường nhất định

Sau đó hãy yêu cầu:

• các nguyên nhân khả dĩ được nhóm theo từng loại
• ý tưởng instrumentation
• kế hoạch khoanh vùng theo kiểu binary search
• lượng log bổ sung tối thiểu cần có để tách các giả thuyết khỏi nhau

Đây chính là tình huống mà debugger skill hữu ích hơn hẳn một prompt xin bản sửa trong một lần.

Cách dùng debugger cho stack trace và log

Khi chia sẻ stack trace, đừng chỉ dán dòng exception cuối cùng. Hãy kèm theo:

• dòng lỗi đầu tiên
• các frame liên quan quanh phần code của bạn
• input hoặc request gây ra lỗi
• timestamp nếu có nhiều hệ thống cùng tham gia
• mọi warning liên quan xuất hiện ngay trước thời điểm lỗi

Hãy yêu cầu skill giải thích:

• triệu chứng xuất hiện ở đâu
• điều kiện upstream nào có khả năng gây ra nó
• frame nào đáng xử lý nhất
• còn thiếu bằng chứng gì

Cách yêu cầu bản sửa mà không làm mất chẩn đoán

Một sai lầm phổ biến là ép agent vá lỗi quá sớm. Cách diễn đạt tốt hơn:

Use the debugger skill. First identify the most likely root cause and the evidence for it. Then propose the smallest fix. Finally give me validation steps and one regression test to add.

Prompt này giữ quy trình theo hướng ưu tiên bằng chứng trước, nhưng vẫn tiến dần tới phương án giải quyết.

Câu hỏi thường gặp về debugger skill

debugger skill có thân thiện với người mới không?

Có, miễn là bạn cung cấp được bằng chứng cụ thể. Người mới thường hưởng lợi vì skill này sắp xếp quá trình điều tra thành các bước dễ hiểu. Nhưng nó không phải phép màu: nếu bạn không mô tả được điều gì đã thay đổi, cách tái hiện lỗi, hoặc thông báo lỗi là gì, chất lượng đầu ra sẽ giảm rõ rệt.

debugger skill xử lý tốt nhất những loại vấn đề nào?

debugger mạnh nhất với:

• lỗi runtime
• test bị hỏng
• crash
• regression sau một thay đổi
• log có dấu hiệu bất thường
• triage sự cố production
• các tình huống kiểu “chạy local thì ổn nhưng lên production thì lỗi”

Nó kém phù hợp hơn với các yêu cầu mơ hồ kiểu “bạn review giúp toàn bộ kiến trúc của tôi được không?”

debugger khác gì so với prompting thông thường?

Prompting thông thường thường nhảy từ triệu chứng sang bản sửa. debugger skill được định hướng rõ ràng quanh việc thu thập bằng chứng, xếp hạng giả thuyết, phân tích nguyên nhân gốc, và xác minh. Kết quả thường là ít câu trả lời suy đoán hơn và hướng hành động tiếp theo tốt hơn.

Khi cài debugger skill có kèm tool hay script không?

Không. Trong skill directory này không thấy có bộ công cụ hỗ trợ đáng kể nào đi kèm. Skill chủ yếu là một quy trình hướng dẫn trong SKILL.md, chứ không phải một debugger binary đóng gói sẵn hay một bộ script. Có thể xem nó như một khung suy luận cho hoạt động debug có AI hỗ trợ.

Khi nào không nên dùng debugger skill?

Hãy bỏ qua skill này nếu:

• bạn cần triển khai tính năng, không phải chẩn đoán lỗi
• vấn đề đã được cô lập hoàn toàn và bạn chỉ muốn sinh code
• bạn không thể chia sẻ bất kỳ ngữ cảnh có ý nghĩa nào
• vấn đề thật sự của bạn là sự mơ hồ về sản phẩm, không phải lỗi phần mềm

Trong những trường hợp đó, skill về coding, architecture hoặc planning có thể phù hợp hơn.

debugger có thể hỗ trợ xử lý vấn đề hiệu năng không?

Có, nhưng chỉ khi bạn cung cấp số liệu hoặc triệu chứng: endpoint chậm, spike latency, mức dùng CPU, memory tăng dần, thay đổi gần đây, và điều kiện tái hiện. Khi đó, skill có thể giúp xây dựng giả thuyết và đề xuất các phép thử có mục tiêu thay vì chỉ đưa lời khuyên tối ưu hóa chung chung.

Cách cải thiện hiệu quả của debugger skill

Hãy đưa cho debugger bằng chứng, đừng chỉ đưa kết luận

Input kém:

The database is probably the problem.

Input tốt hơn:

API latency increased from 120ms to 2.4s after adding a join. EXPLAIN ANALYZE shows a sequential scan on orders. CPU is stable, DB IOPS spiked, and the slowdown happens only for accounts with more than 50k rows.

Phiên bản thứ hai cho phép debugger suy luận từ dữ kiện, thay vì phải kế thừa giả định của bạn.

Luôn neo mọi yêu cầu bằng hành vi mong đợi và hành vi thực tế

Đây là cải thiện có tác động lớn nhất. Luôn nêu rõ:

• điều gì đáng ra phải xảy ra
• thực tế đang xảy ra điều gì
• bạn biết điều đó bằng cách nào
• tần suất xảy ra là bao nhiêu

Việc này giúp agent không tối ưu sai mục tiêu.

Hãy yêu cầu xếp hạng giả thuyết, đừng chỉ đòi một đáp án duy nhất

Một prompt mạnh cho debugger for Debugging là:

Rank the top 3 likely causes from most to least probable, explain the evidence for each, and give one test that would eliminate each hypothesis.

Cách này tạo ra vòng lặp debug tốt hơn nhiều so với câu hỏi “có gì đang sai vậy?”

Cung cấp lịch sử thay đổi càng sớm càng tốt

Rất nhiều bug bắt nguồn từ:

• cập nhật dependency
• thay đổi config
• môi trường bị lệch
• deploy
• thay đổi schema hoặc API contract

Hãy cho skill biết gần đây đã thay đổi những gì. Thông tin đó thường rút ngắn đường đến nguyên nhân gốc hiệu quả hơn cả việc dán thêm nhiều đoạn code.

Nâng chất lượng đầu ra của debugger bằng các artifact có trọng tâm

Những artifact hữu ích nhất là:

• output của test bị fail
• stack trace kèm các frame lân cận
• log quanh khoảng thời gian lỗi xảy ra
• request payload hoặc dữ liệu input chính xác
• diff của thay đổi gần đây
• các file config liên quan

Nếu bạn chỉ có thể cung cấp một artifact, hãy bắt đầu bằng ví dụ lỗi nhỏ nhất nhưng tái hiện được.

Lỗi thường gặp: xin bản sửa quá sớm

Nếu câu trả lời đầu tiên nghe còn chung chung, đừng hỏi “nói chi tiết hơn đi”. Thay vào đó hãy hỏi:

What evidence is missing?
What is the fastest test to separate the top two hypotheses?
What would make you change your current diagnosis?

Những câu hỏi này buộc quá trình debug đi theo hướng sắc nét hơn.

Lỗi thường gặp: đổ vào quá nhiều ngữ cảnh một lúc

Dán cả repository thường làm tín hiệu bị loãng. Hãy bắt đầu với:

• file hoặc function đang fail
• lỗi chính xác
• các bước tái hiện
• thay đổi gần đây
• một hoặc hai file liên quan trực tiếp

Sau đó chỉ mở rộng thêm nếu agent xác định được một dependency path thực sự cần thêm ngữ cảnh.

Cách lặp lại sau phản hồi đầu tiên của debugger skill

Sau vòng đầu tiên:

1. chạy phép thử phân biệt mà agent đề xuất
2. chỉ trả lại kết quả
3. yêu cầu agent cập nhật lại thứ hạng giả thuyết
4. yêu cầu bản sửa an toàn nhỏ nhất
5. hỏi thêm về bước xác minh và phạm vi regression cần bao phủ

Cách này giữ debugger guide luôn tập trung và tránh việc phải phân tích lại từ đầu.

Cách lấy bản sửa tốt hơn từ debugger

Khi đã sẵn sàng nhận patch, hãy yêu cầu:

• tóm tắt nguyên nhân gốc trong một câu
• thay đổi code tối thiểu
• vì sao thay đổi đó xử lý đúng nguyên nhân chứ không chỉ vá triệu chứng
• các tác dụng phụ có thể có
• các bước xác minh
• một regression test để ngăn lỗi tái diễn

Bước cuối cùng này chính là yếu tố biến một chẩn đoán khá ổn thành debugger usage đáng tin cậy trong quy trình làm việc thực tế.