Prompt cho Claude Code: chỉ nói điều nó không tự thấy, “be ambitious” và để Claude phỏng vấn bạn

"Fix the login bug" và "user báo đăng nhập lỗi sau khi session hết hạn; xem phần refresh token trong src/auth/, viết test tái hiện lỗi rồi sửa": hai prompt cho cùng một việc, nhưng prompt thứ hai thường tiết kiệm một vòng sửa qua lại. Trang best practices của Claude Code tóm gọn nguyên tắc này: chỉ nói với Claude những gì nó không tự thấy được. Model hiện nay đọc code rất giỏi, nên phần còn thiếu nằm ở thông tin chỉ có trong đầu bạn. Bài này gom các mẹo prompt thực dụng từ tài liệu đó.

Prompt cụ thể: trước và sau

Ba thứ nên có trong prompt sửa lỗi: file/khu vực, triệu chứng, và "đã sửa" trông như thế nào. Nếu bạn có sở thích giữa hai cách làm đều hợp lý, nói ngay từ đầu, vì Claude không đọc được điều đó từ code.

Đưa thứ bạn đang có, đừng mô tả lại

• File: gõ @ và đường dẫn để đưa nội dung file vào tin nhắn (nạp luôn cả CLAUDE.md của thư mục đó).
• Ảnh: dán screenshot lỗi hoặc mockup thiết kế trực tiếp vào prompt.
• Output lệnh: pipe từ shell:

cat error.log | claude -p "chuyện gì đang xảy ra ở đây?"
git log --oneline -20 | claude -p "tóm tắt các commit gần đây"

"be ambitious": khi bạn muốn bản đầy đủ

Claude có xu hướng đọc yêu cầu một cách thận trọng và làm phiên bản nhỏ nhất đáp ứng được, vì nó không biết bạn kỳ vọng tới đâu. Khi muốn bản hoàn chỉnh, nói thẳng:

build the settings page from the mockup. be ambitious: empty and error
states, the save flow wired up, keyboard navigation, not just the layout

Đây là thông tin về phạm vi, thứ chỉ bạn biết, chứ không phải yêu cầu "nghĩ kỹ hơn".

"think step by step" không còn là từ khoá

Theo tài liệu, những cụm như "think step by step" hay "be thorough" giờ chỉ là chữ thường trong prompt. Núm điều khiển chính cho độ sâu suy nghĩ là mức effort (/effort hoặc trong /model). Câu chữ có thể "đẩy nhẹ" trong phạm vi effort hiện tại, nhưng không nâng được lên quá mức đó.

Để Claude phỏng vấn bạn

Khi chưa rõ mình muốn gì, đừng cố nghĩ xong rồi mới prompt. Nhờ Claude hỏi:

Tôi muốn thêm rate limiting cho public API nhưng chưa nghĩ kỹ.
Hãy phỏng vấn tôi cho đến khi đủ để viết spec, rồi ghi vào SPEC.md.

Claude sẽ hỏi dạng trắc nghiệm những điểm bạn chưa chốt: giới hạn theo user hay theo key, request vượt ngưỡng xử lý ra sao, cái gì ngoài phạm vi. Khi SPEC.md đã có, mở phiên mới để build từ đó: context sạch, có định nghĩa "xong" bằng văn bản, và đó cũng là file để reviewer đối chiếu sau này.

Khi nào prompt mơ hồ vẫn ổn?

Khi bạn đang khám phá chứ không sửa việc cụ thể, câu kiểu "file này có gì nên cải thiện?" là hoàn toàn hợp lý. Đánh đổi là bạn sẽ phải chỉnh hướng nhiều hơn trên đường đi. Lưu ý về chi phí: yêu cầu kiểu "cải thiện codebase" kích hoạt quét diện rộng, đọc nhiều file, nên tốn token hơn hẳn.

Kết nối công cụ thay vì giải thích

• Hệ thống có CLI (gh, aws…): cài và đăng nhập là Claude tự dùng. CLI lạ thì chỉ cần bảo nó đọc --help.
• Hệ thống không có CLI: dùng MCP, nhưng tắt server không cần vì tên tool và hướng dẫn vẫn chiếm context.
• Ngôn ngữ có type: cài plugin code intelligence để nhảy thẳng tới định nghĩa thay vì đọc nhiều file.

Áp dụng thế nào?

• Dev: Tập công thức "vị trí + triệu chứng + định nghĩa xong + ràng buộc". Dùng @file và pipe thay vì copy-paste mô tả.
• Tech Lead: Với tính năng mới, áp dụng quy trình "phỏng vấn → SPEC.md → phiên mới để build → review theo spec".
• PM: Prompt phỏng vấn là cách nhanh để biến ý tưởng mơ hồ thành spec có câu hỏi mở rõ ràng, trước khi đưa cho team.