Hướng dẫn Claude Code - Phần 4: Các trường hợp sử dụng Claude Code là gì?

Các trường hợp sử dụng điển hình

Tôi chia các trường hợp sử dụng thành bốn loại, sắp xếp theo tần suất từ cao đến thấp.

Loại thứ nhất: Hiểu code

Đây có lẽ là loại được sử dụng nhiều nhất. Khi tiếp nhận dự án của người khác, xem một module cũ, hoặc mở một kho lưu trữ không có tài liệu, hãy hỏi trực tiếp nó.

Cách thực hiện cụ thể:

claude "Dự án này làm gì? Điểm vào ở đâu?" — Nó sẽ đọc package.json, cấu trúc thư mục, các file quan trọng và đưa ra tổng quan.
Mở một hàm, yêu cầu nó giải thích logic, vẽ luồng (bằng mô tả văn bản).
Yêu cầu nó theo dõi đường đi đầy đủ của một API request từ frontend đến database.

Ở đây, công việc của nó thực chất là giúp bạn làm "việc bẩn của việc đọc code". Bạn không cần tự mình grep hàng giờ rồi ghép hình trong đầu. Nó sắp xếp đường đi, bạn đưa ra phán đoán.

Đối tượng thay thế của loại tình huống này là: Tự tay tìm kiếm trong code, ghi chú, vẽ sơ đồ gọi hàm.

Loại thứ hai: Viết code, sửa code

Đây là loại được thảo luận nhiều nhất, nhưng thực ra không phải được sử dụng nhiều nhất. Các tình huống viết code thường như sau:

Tạo tính năng mới: "Thêm một API đổi email trong module user, phải kiểm tra định dạng email, viết unit test."
Tái cấu trúc đa tệp: "Thay tất cả moment() trong ba file này bằng dayjs(), không thay đổi logic khác."
Di chuyển và nâng cấp: "Chuyển component Vue 2 này sang cú pháp Vue 3 Composition API."

Code nó tạo ra không phải lúc nào cũng đúng ngay, nhưng nó có thể thực hiện toàn bộ thay đổi đa tệp trong một lần, và bạn có thể diff từng file, chấp nhận hoặc từ chối từng cái.

Đối tượng thay thế của loại tình huống này là: Tự viết code lặp đi lặp lại, tự tìm kiếm và thay thế các tham chiếu đa tệp.

Loại thứ ba: Gỡ lỗi và sửa lỗi

Khi bug xuất hiện, quy trình làm việc thông thường là: Xem lỗi, xác định file, đoán nguyên nhân, thử sửa, nếu không được thì quay lại. Claude Code có thể nhận toàn bộ stack trace lỗi, kết hợp với code dự án để tự xác định vị trí.

Cách sử dụng điển hình:

Đưa output kiểm thử thất bại cho nó, nó sẽ đọc code liên quan, đưa ra giải pháp sửa, sửa xong chạy lại kiểm thử để xem có qua không.
Gặp lỗi CI, dán log vào, yêu cầu nó sửa, sửa xong chạy git diff để xác nhận thay đổi.

Ở đây, vai trò của nó giống như "người kiểm tra vòng đầu". Bạn là người dành thời gian suy nghĩ vấn đề, nhưng nó là người lật file, so sánh khác biệt, chạy lệnh xác minh.

Đối tượng thay thế của loại tình huống này là: Chạy đi chạy lại kiểm thử, đọc log lỗi, tự tay so sánh khác biệt code.

Loại thứ tư: Tự động hóa linh tinh

Loại tình huống này ít nổi bật nhất, nhưng khi kết hợp lại, thời gian tiết kiệm được là nhiều nhất.

Ví dụ:

Viết thông điệp commit Git: claude "Dựa vào git diff hiện tại, viết một thông điệp commit theo định dạng Conventional Commits"
Tạo mô tả PR: Yêu cầu nó so sánh sự khác biệt giữa nhánh hiện tại và main, tạo tóm tắt thay đổi và hướng dẫn kiểm thử.
Viết ghi chú phát hành: Yêu cầu Claude Code đọc lịch sử commit tuần gần nhất, tạo CHANGELOG.
Trả lời vấn đề môi trường: "Cài dependency này báo lỗi, giúp tôi xem output terminal, tìm nguyên nhân."

Điểm chung của những việc này là: Không phức tạp, nhưng lặt vặt. Tự làm thì phải chuyển cửa sổ, gõ nhiều chữ. Giao cho nó, vài giây xong.

Đối tượng thay thế của loại tình huống này là: Tự chỉnh sửa văn bản, viết tài liệu theo chuẩn, tìm kiếm vấn đề cấu hình môi trường.

Một "bản đồ"

Đặt bốn loại tình huống này vào quy trình làm việc hàng ngày, sẽ có một bản đồ như sau:

Nhận một dự án không quen thuộc
    │
    ▼
[Hiểu code] ─── Tìm hiểu cấu trúc, điểm vào, logic chính
    │
    ▼
Bắt đầu viết tính năng mới hoặc sửa module
    │
    ▼
[Viết code/Sửa code] ─── Tạo triển khai, tái cấu trúc đa tệp
    │
    ▼
Chạy kiểm thử, gặp lỗi
    │
    ▼
[Gỡ lỗi và sửa lỗi] ─── Phân tích lỗi, xác định vị trí, sửa, chạy lại
    │
    ▼
Chuẩn bị commit
    │
    ▼
[Tự động hóa khác] ─── Viết commit, mô tả PR, ghi chú phát hành
    │
    ▼
Commit, hoàn thành

Bạn không cần sử dụng nó trong cả bốn góc phần tư. Một số nhóm chỉ dùng nó để hiểu code, một số người chỉ dùng nó để viết kiểm thử và gửi PR. Giai đoạn nào làm bạn khó khăn nhất, hãy bắt đầu từ tình huống đó.

Hai tiêu chí đánh giá hữu ích

Nếu bạn không chắc có nên giao một việc cho Claude Code hay không, hãy tự hỏi hai câu:

1. Việc này có tính "cơ học" hơn là "sáng tạo" không?

Thay đổi hàng trăm tham chiếu, định dạng output, tạo code mẫu — những việc này tự làm sẽ tốn nhiều thời gian, nhưng bạn đã có ý tưởng. Phù hợp để giao cho nó.

2. "Chi phí xác minh" của việc này có cao không?

Nếu một sửa đổi cần phải nhảy qua nhảy lại, chạy kiểm thử, xem log mới xác nhận được, thì tự mình thử sai sẽ rất chậm. Claude Code có thể tự hoàn thành vòng lặp "sửa-chạy-xem-sửa lại", bạn sẽ nhẹ nhàng hơn nhiều.