Tool tích hợp sẵn

Những điều bạn cần biết

Claude Code cung cấp sáu tool tích hợp sẵn để làm việc với kho mã: Read, Write, Edit, Bash, Grep, và Glob. Mỗi tool có một mục đích cụ thể, và dùng sai tool cho một tác vụ sẽ lãng phí thời gian, token context, hoặc cả hai. Đề thi cố tình đưa ra các tình huống mà việc nhầm lẫn giữa các tool này dẫn đến câu trả lời sai.

Grep so với Glob: Sự phân biệt cốt lõi

Đây là sự phân biệt quan trọng nhất trong toàn bộ task statement này. Nhầm chỗ này là bạn sẽ mất điểm.

Grep tìm kiếm mẫu trong NỘI DUNG file. Dùng Grep khi bạn cần tìm văn bản bên trong file. Nơi gọi hàm. Thông báo lỗi. Câu lệnh import. Phép gán biến. Bất cứ khi nào bạn tìm kiếm thứ mà các file CHỨA, Grep là tool phù hợp.

// Tìm tất cả file gọi processLegacyOrder() Grep: "processLegacyOrder" // Tìm tất cả thông báo lỗi chứa "timeout" Grep: "timeout" // Tìm tất cả file import một module cụ thể Grep: "import.*from 'utils/auth'"

Glob khớp ĐƯỜNG DẪN file theo mẫu đặt tên. Dùng Glob khi bạn cần tìm file theo tên, phần mở rộng, hoặc cấu trúc thư mục. File test. File cấu hình. Tất cả file TypeScript trong một thư mục cụ thể. Bất cứ khi nào bạn tìm kiếm file dựa trên đường dẫn của chúng, Glob là tool phù hợp.

// Tìm tất cả file test Glob: "**/*.test.tsx" // Tìm tất cả file cấu hình Glob: "**/config.*" // Tìm tất cả file MDX trong thư mục domains Glob: "content/domains/**/*.mdx"

Sự phân biệt trong một câu: Grep tìm những gì ở BÊN TRONG file. Glob tìm file theo TÊN của chúng.

Đề thi đưa ra các tình huống mà một lập trình viên dùng sai tool. Nếu ai đó dùng Glob để tìm nơi gọi hàm, nó sẽ thất bại — Glob khớp đường dẫn, không phải nội dung. Nếu ai đó dùng Grep để tìm file test theo mẫu đặt tên, về mặt kỹ thuật nó có thể hoạt động (bằng cách tìm kiếm "test" trong tên file qua nội dung), nhưng đó là sai tool và đề thi kỳ vọng bạn xác định đúng tool cần dùng.

Read, Write, và Edit

Ba tool này xử lý các thao tác trên file, mỗi tool được tối ưu cho một use case khác nhau.

Edit thực hiện chỉnh sửa có mục tiêu bằng cách khớp văn bản duy nhất. Bạn chỉ định chính xác văn bản cần tìm và văn bản thay thế. Nó nhanh và chính xác vì chỉ chạm vào đúng đoạn văn bản bạn chỉ định.

Edit: old_string: "function processOrder(id: string)" new_string: "function processOrder(id: string, validate: boolean = true)"

Khi nào Edit thất bại: Edit đòi hỏi khớp văn bản duy nhất. Nếu văn bản bạn chỉ định xuất hiện ở nhiều nơi trong file, Edit không thể xác định nên thay đổi vị trí nào và sẽ thất bại. Đây không phải là lỗi (bug) — đó là một cơ chế an toàn nhằm ngăn chặn các thay đổi ngoài ý muốn.

Khi Edit không tìm được điểm neo duy nhất. Theo tài liệu về tool Edit, cách khắc phục là mở rộng old_string với thêm ngữ cảnh xung quanh cho đến khi nó xác định được đúng một vị trí, hoặc đặt replace_all: true nếu bạn thực sự muốn cập nhật mọi lần xuất hiện. Cả hai cách đều giữ bạn ở lại với Edit và tốn gần như không thêm context nào. Read + Write (tải toàn bộ file, ghi lại toàn bộ file) là phương án cuối cùng. Nó vẫn hoạt động. Nhưng bạn đã tốn cả một file token cho một thay đổi thường chỉ là một dòng.

Thứ tự ưu tiên:

1. Thử Edit với điểm neo ngắn nhất có khả năng là duy nhất.
2. Khi gặp khớp không duy nhất, mở rộng old_string cho đến khi nó khớp đúng một vị trí, hoặc dùng replace_all: true nếu bạn muốn thay đổi mọi lần xuất hiện.
3. Chỉ chuyển sang Read + Write khi cả hai cách trên đều không thể xác định rõ mục tiêu.

Đừng mặc định dùng Read + Write cho mọi thay đổi. Đề thi trừ điểm điều đó vì nó tiêu tốn token context. Nó cũng trừ điểm việc nhảy thẳng từ một lần Edit thất bại do khớp không duy nhất sang Read + Write. Mở rộng điểm neo hoặc dùng replace_all là phản hồi đã được ghi nhận chính thức. Read + Write là phương án dự phòng, không phải bước tiếp theo.

Hiểu kho mã theo cách tăng dần

Cách bạn khám phá một kho mã quan trọng không kém việc bạn dùng tool nào. Có một cách đúng và một cách sai.

Sai: Đọc tất cả file ngay từ đầu. Tải mọi file vào context trước khi bạn hiểu mình cần gì là một kẻ hủy diệt ngân sách context. Nếu một kho mã có 200 file và bạn đọc hết tất cả, bạn đã tiêu tốn toàn bộ context window vào những file phần lớn không liên quan đến tác vụ của bạn. Đây là anti-pattern lớn nhất trong việc khám phá kho mã.

Đúng: Khám phá theo cách tăng dần. Bắt đầu hẹp. Chỉ mở rộng khi cần thiết.

1. Grep để tìm điểm bắt đầu. Tìm kiếm tên hàm, tên class, hoặc thông báo lỗi làm điểm neo cho cuộc điều tra của bạn. Điều này cho bạn biết file nào liên quan.

2. Read để theo dõi import và truy vết luồng xử lý. Sau khi biết file nào quan trọng, hãy Read chúng để hiểu cấu trúc mã. Theo dõi các câu lệnh import để phát hiện file liên quan.

3. Grep lại để truy vết cách sử dụng. Nếu bạn tìm thấy một hàm wrapper hoặc re-export, hãy Grep tên đó trên toàn bộ kho mã để tìm mọi nơi sử dụng.

4. Chỉ Read những gì bạn cần. Mỗi file bạn đọc nên được lý giải bởi những gì bạn phát hiện ở bước trước.

Cách tiếp cận này dùng context tối thiểu để đạt được sự hiểu biết tối đa. Bạn khám phá cấu trúc kho mã một cách dần dần, chỉ tốn token vào những file liên quan đến tác vụ của bạn.

Truy vết cách sử dụng hàm qua các module wrapper

Một mẫu hình phổ biến trong kho mã: một hàm được định nghĩa trong một module, được re-export qua một wrapper, và được sử dụng thông qua tên của wrapper đó. Grep đơn giản cho tên hàm gốc sẽ bỏ lỡ những nơi sử dụng import qua wrapper.

Cách tiếp cận đúng:

1. Grep cho định nghĩa hàm để tìm nơi nó được định nghĩa
2. Read file định nghĩa để xác định các tên được export
3. Grep cho từng tên được export trên toàn bộ kho mã để tìm mọi nơi sử dụng
4. Nếu hàm được re-export qua một barrel file (ví dụ index.ts), Grep tên module của barrel file để tìm những nơi import từ đó

Việc truy vết nhiều bước này kỹ lưỡng hơn một lần Grep đơn lẻ và bắt được cả những nơi sử dụng gián tiếp mà một tìm kiếm đơn giản có thể bỏ lỡ.

Tình huống loại bỏ (deprecation)

Tình huống này xuất hiện thường xuyên trong quá trình ôn thi: tìm tất cả file gọi một hàm đã bị loại bỏ VÀ tìm các file test kiểm tra hàm đó. Trình tự tool đúng:

1. Grep tên hàm — tìm mọi file có nội dung tham chiếu đến hàm đó, bao gồm cả các test import trực tiếp (tìm kiếm nội dung)
2. Glob cho các file test liền kề — tìm file test tương ứng với mỗi nơi gọi theo quy ước đặt tên, ví dụ OrderProcessor.ts → OrderProcessor.test.tsx, ngay cả khi test kiểm tra hàm đó một cách gián tiếp qua module nguồn (khớp đường dẫn)
3. Grep lại cho tên wrapper — khi một nơi gọi lộ hàm đó thông qua một wrapper (ví dụ applyLegacyOrder gọi processLegacyOrder bên trong), hãy Grep tên wrapper để tìm các test bao phủ hàm đó một cách gián tiếp qua wrapper

Ví dụ, nếu Grep cho thấy OrderProcessor.ts và RefundHandler.ts gọi hàm đã bị loại bỏ, hãy Glob cho **/OrderProcessor.test.* và **/RefundHandler.test.* để lấy về các file test liền kề của chúng, ngay cả khi các test đó không hề nhắc đến processLegacyOrder theo tên. Nếu một trong các file nguồn bọc hàm đó dưới một tên mới, hãy Grep tên wrapper đó để bắt thêm các test khác.

Đây là Grep, rồi Glob, rồi Grep lại — tìm kiếm nội dung cho tham chiếu trực tiếp, khớp đường dẫn cho các test liền kề, tìm kiếm nội dung cho phạm vi bao phủ gián tiếp. Không phải Glob trước.

Bẫy thi

Tình huống luyện tập

Không tìm thấy câu hỏi luyện tập "q-2-5-001".

Bài tập thực hành

Nguồn tham khảo

• Claude Certified Architect Foundations Exam Guide — Domain 2, Task Statement 2.5 — Anthropic
• Claude Code Documentation — Built-in Tools — Anthropic
• Building with Claude API — Anthropic — Anthropic