Hướng dẫn sử dụng Claude Code toàn tập: Từ cài đặt đến cách để AI tự động hoàn thành một tính năng

11 giờ đêm, một văn phòng startup ở Nội Hồ (Neihu) chỉ còn lại hai người. Một kỹ sư nhận được yêu cầu phải sửa một con bug trước giờ ra mắt vào ngày mai, lỗi nằm ở một module do đồng nghiệp đã nghỉ việc từ ba năm trước viết lại, không có chú thích, không có unit test. Anh gõ yêu cầu vào terminal rồi đứng dậy đi lấy cà phê. Khi quay lại, màn hình đã liệt kê sẵn 5 file liên quan, chỉ ra nguyên nhân tiềm ẩn, đồng thời đã sửa xong một chỗ và chạy qua bài test.

Đây không phải là cảnh trong quảng cáo, mà là cách sử dụng Claude Code hàng ngày. Tuy nhiên, chính vì nó thực sự có thể tự tay sửa đổi mã nguồn của bạn, nên cái giá của việc dùng sai cách sẽ cao hơn rất nhiều so với các công cụ AI thông thường. Bài viết này tổng hợp lại quy trình thực tế mà tôi đang sử dụng, bao gồm cả một số điểm mà tôi từng phải chịu thiệt.

Đây là cái gì: Tác tử (Agent), không phải tính năng tự động điền (Autocomplete)

Hãy làm rõ định vị của nó ngay từ đầu, bởi điều này quyết định cách bạn nên sử dụng nó.

Phần lớn các công cụ AI lập trình quen thuộc với mọi người là dạng "tự động điền": bạn gõ phím, nó đoán dòng tiếp theo và bạn nhấn Tab để chấp nhận. GitHub Copilot trong giai đoạn đầu đi theo mô hình này, bạn theo dõi toàn bộ quá trình và nó giúp bạn tiết kiệm thời gian gõ phím.

Claude Code là dạng "tác tử" (agent). Bạn đưa ra một mục tiêu — sửa con bug này, thêm tính năng phân trang cho API này — nó sẽ tự quyết định đọc file nào, chạy lệnh gì, khi test thất bại thì sửa ra sao, và sau khi hoàn thành toàn bộ vòng lặp, việc của bạn là nghiệm thu.

Ý nghĩa thực tế là: Vai trò của bạn đã chuyển từ "người gõ phím" thành "người kiểm duyệt". Thời gian tiết kiệm được không phải là thời gian gõ phím, mà là thời gian tìm hiểu mã nguồn xa lạ và quá trình thử và sai (trial and error). Và nếu ai đó không có đủ năng lực kiểm duyệt, việc sử dụng công cụ này sẽ trở nên nguy hiểm.

Có thể sử dụng ở đâu

Giao diện hiện tại đa dạng hơn nhiều người nghĩ:

• Terminal CLI: Tính năng đầy đủ nhất, lệnh cài đặt là curl -fsSL https://claude.ai/install.sh | bash
• Phiên bản Desktop: Có sẵn trên macOS, Linux và Windows
• Phiên bản trình duyệt: claude.ai/code, không cần cài đặt
• Plugin IDE: VS Code và JetBrains
• Điện thoại: Ứng dụng trên iOS và Android
• Slack bot: Trực tiếp tạo tác vụ ngay trong khung chat
• GitHub Actions: Thực hiện việc review PR tự động

Cá nhân tôi chủ yếu dùng CLI và dùng điện thoại để theo dõi tiến độ. Ưu điểm của CLI nằm ở chỗ nó nằm ngay trong thư mục dự án (project directory), các biến môi trường, trạng thái git, lệnh chạy test đều có sẵn sàng.

Cách sử dụng: Bốn bước

Bước một: Cài đặt và khởi động trong thư mục dự án

Sau khi cài đặt xong, nhất định phải cd vào thư mục gốc của dự án rồi mới khởi động. Rất nhiều người khởi động nó từ thư mục gốc của người dùng (home directory), khiến nó không nhìn thấy cấu trúc dự án và chỉ có thể đoán mò. Lần khởi động đầu tiên sẽ yêu cầu đăng nhập, nếu có gói thuê bao Claude thì liên kết trực tiếp, còn nếu dùng API key thì tính phí theo token.

Bước hai: Để nó hiểu rõ dự án trước, rồi mới giao việc sau

Sai lầm phổ biến nhất của người mới là vừa vào đã ném ngay yêu cầu vào. Câu đầu tiên tốt hơn nên là:

Hãy xem qua cấu trúc của dự án này trước, cho tôi biết tech stack, các module chính được phân chia thế nào và cách chạy test ra sao. Tuyệt đối chưa sửa bất cứ thứ gì.

Câu "Tuyệt đối chưa sửa bất cứ thứ gì" rất quan trọng — mặc định nó có tính chủ động cao, nếu bạn không hô dừng lại thì nó có thể đã bắt tay vào làm rồi. Sau khi xác nhận nó không hiểu nhầm, hãy bước sang giai đoạn tiếp theo.

Bước ba: Viết file CLAUDE.md — đây là bước quan trọng nhất của toàn bộ công cụ

Hãy đặt một file CLAUDE.md trong thư mục gốc của dự án, bên trong viết các quy tắc của dự án. Mỗi lần khởi động, nó đều đọc file này. Chất lượng của file này sẽ quyết định trực tiếp việc bạn dùng có mượt mà hay phát điên.

Những gì thực tế nên được viết vào đó:

Quy ước dự án

• Front-end dùng TypeScript + React, Back-end dùng Node.js
• Dùng vitest để chạy test, lệnh thực thi là npm run test
• Thông điệp commit viết bằng tiếng Trung (hoặc tiếng Anh tùy dự án), định dạng: Loại: Mô tả

Giới hạn quan trọng

• Chỉ làm những việc tôi yêu cầu rõ ràng. Không tự ý refactor, không thêm các tầng trừu tượng (abstraction layer) chưa được yêu cầu.
• Không thêm các thư viện của bên thứ ba, khi cần phải hỏi tôi trước.
• Không được động đến mã nguồn dưới thư mục src/legacy/, đó là hệ thống cũ chuẩn bị loại bỏ.
• Sau khi sửa xong bắt buộc phải chạy npm run test, nếu test chưa qua thì đừng nói là đã làm xong.

Tôi cho rằng quy tắc "Chỉ làm những việc tôi yêu cầu rõ ràng" là điều nên được viết vào nhất trong tất cả các quy tắc. Khi bạn bảo nó sửa một con bug, nó có thể tiện tay refactor luôn ba file, thêm phần xử lý lỗi, bổ sung thêm kiểu dữ liệu (type). Nhìn riêng lẻ thì không có gì sai, nhưng phần code review của bạn sẽ biến thành một thảm họa và bạn không thể phân biệt được đâu là phần bắt buộc phải sửa để fix bug, đâu là phần nó tự biên tự diễn.

Bước bốn: Giao nhiệm vụ và nghiệm thu

Mô tả nhiệm vụ càng cụ thể càng tốt. Sự khác biệt giữa cách hỏi tồi và cách hỏi tốt:

• ❌ "Giúp tôi tối ưu hóa đoạn code này" — nó không biết bạn muốn tối ưu cái gì, có thể nó cải thiện hiệu năng hoặc cũng có thể cải thiện khả năng đọc hiểu.
• ✅ "Hàm này sẽ bị timeout khi lượng dữ liệu vượt quá 10.000 bản ghi, hãy tìm điểm nghẽn và khắc phục, không làm thay đổi giao diện bên ngoài của nó, sau khi sửa xong hãy chạy test."

Cách viết thứ hai cung cấp cho nó mục tiêu, giới hạn và tiêu chuẩn nghiệm thu.

Mẹo nâng cao

Dùng /clear để cắt đứt ngữ cảnh (context). Khi chuyển sang nhiệm vụ mới mà không xóa đi, bối cảnh của nhiệm vụ trước sẽ gây nhiễu phán đoán. Một nhiệm vụ là một cuộc trò chuyện sạch sẽ.

Tận dụng chế độ lập kế hoạch (Plan mode). Gặp những thay đổi lớn, trước tiên hãy yêu cầu nó "chỉ đề xuất kế hoạch, không được động tay", sau khi xét duyệt xong mới cho phép thực hiện, điều này sẽ tiết kiệm thời gian hơn rất nhiều so với việc sửa xong rồi mới quay lại hoàn tác (rollback).

Để nó tự đọc thông báo lỗi. Không cần phải sao chép và dán lỗi, hãy trực tiếp bảo nó chạy test, nó sẽ tự đọc phần output và tự sửa.

Quản lý hạn mức (Quota). Gói Pro (khoảng 17–20 USD/tháng) khi chạy các đợt refactor lớn rất dễ dùng hết hạn mức chỉ trong vài giờ. Những ai sử dụng nghiêm túc thường phải nâng cấp lên gói Max 5x (100 USD) hoặc Max 20x (200 USD). Lời khuyên là hãy dùng gói Pro chạy thử trong một tháng trước, ghi lại tần suất chạm trần giới hạn rồi mới quyết định.

Những điểm cần lưu ý

Nó sẽ tạo ra mã nguồn trông có vẻ rất đúng nhưng thực tế lại có lỗi. Những gì nó viết ra có cú pháp chính xác, phong cách đồng nhất, rất chuyên nghiệp, nhưng logic có thể sai, đặc biệt là trong các điều kiện biên (edge cases) và vấn đề đồng thời (concurrency). Bạn bắt buộc phải có khả năng kiểm duyệt đầu ra của nó, đây không phải là một tùy chọn.

Vấn đề rò rỉ dữ liệu cần được xác nhận trước. Mã nguồn sẽ được gửi lên mô hình đám mây. Đối với các dự án tài chính, y tế và có hợp đồng bảo mật, trước khi ứng dụng bắt buộc phải xác nhận chính sách của công ty và các điều khoản hợp đồng — rất nhiều đội ngũ tại Đài Loan đã dùng trước rồi mới nghĩ đến sau, thứ tự đã bị đảo ngược.

Đừng để nó chạm vào việc di dời cơ sở dữ liệu (database migration) và triển khai môi trường production. Những thao tác kiểu này là không thể đảo ngược, cái giá phải trả khi xảy ra lỗi cao hơn rất nhiều so với thời gian tiết kiệm được. Nguyên tắc của tôi là: Việc gì đảo ngược được thì cứ để nó làm, việc không thể đảo ngược thì tự mình làm.

Đừng kỳ vọng nó thay bạn tư duy về kiến trúc. Nó rất giỏi thực thi, nhưng các quyết định như "tính năng này có nên làm hay không, có nên tách microservice hay không, thiết kế mô hình dữ liệu ra sao" vẫn là công việc của bạn. Nếu muốn so sánh chéo, bạn có thể kết hợp với các giải pháp tích hợp trình soạn thảo như Cursor.

Quy trình làm việc gợi ý kết hợp

Nhịp độ của tôi là: Buổi sáng ném các nhiệm vụ có phạm vi rõ ràng cho nó chạy, tự mình xử lý phần cần đưa ra phán đoán, đến buổi chiều tập trung review phần diff mà nó tạo ra. Để biết thêm nhiều phương pháp đưa AI vào công việc hàng ngày, bạn có thể xem Hướng dẫn nhiệm vụ AI hoặc Thư viện mẫu Prompt.

Đánh giá từ Học viện TheAI (TheAI學院)

Thành thật mà nói, tôi vẫn luôn cảm thấy khó chịu với câu nói "AI thay thế kỹ sư", nhưng sau khi sử dụng vài tháng, tôi thừa nhận rằng nội dung công việc của kỹ sư thực sự đang thay đổi. Thứ thay đổi không phải là "liệu có còn cần kỹ sư nữa không", mà là giá trị đã dịch chuyển từ "viết ra được" sang "phán đoán xem viết có đúng hay không".

Đánh giá: Claude Code hiện là tác tử lập trình AI trưởng thành nhất, nhưng thứ mà nó phóng đại chính là năng lực phán đoán sẵn có của bạn — người có năng lực phán đoán mạnh thì năng suất tăng gấp đôi, còn người có năng lực phán đoán yếu thì chỉ tạo ra nợ kỹ thuật nhanh hơn mà thôi.

Gợi ý cụ thể cho độc giả: Các kỹ sư có trên 3 năm kinh nghiệm nên đưa nó vào quy trình làm việc ngay bây giờ, hãy bắt đầu từ việc "viết test" và "sửa các bug rõ ràng", đây là hạng mục có tỷ suất hoàn vốn (ROI) cao nhất và rủi ro thấp nhất. Ngược lại, đối với những người mới vào nghề, tôi khuyên nên tự viết trước rồi mới lấy nó ra để đối chiếu, đừng bỏ qua giai đoạn xây dựng năng lực phán đoán đó. Còn đối với việc áp dụng cho cả đội ngũ, hãy để một hoặc hai kỹ sư thâm niên thử nghiệm trong một tháng trước, tính toán ROI dựa trên thời gian tiết kiệm được sẽ chuẩn xác hơn bất kỳ bài đánh giá nào.

Nguồn dữ liệu

• Trang sản phẩm chính thức của Claude Code (Cách cài đặt, nền tảng hỗ trợ, các gói cước)

Được tổng hợp dựa trên thông tin công khai, lấy thông tin chính thức làm chuẩn. Các tính năng thực tế và giá cả có thể được điều chỉnh theo phiên bản.