Best Practices — Viết prompt hiệu quả

Quy tắc số 1: Cho Claude cách tự kiểm tra

Đây là điều quan trọng nhất bạn có thể làm. Claude hoạt động tốt hơn rất nhiều khi nó có thể tự verify — chạy test, so screenshot, kiểm tra output.

Không có tiêu chí kiểm tra → Claude tạo code “trông đúng” nhưng không chạy. Bạn thành vòng feedback duy nhất.

Ví dụ thực tế

Thêm tính năng thanh toán:

Thay vì: “add a payment flow”

Nói rõ: “implement Stripe checkout cho subscription plans. viết integration tests cho: thanh toán thành công, thẻ bị từ chối, duplicate subscription. chạy tests sau khi implement”

Sửa giao diện:

Thay vì: “make the dashboard look better”

Nói rõ: “[paste screenshot] implement đúng design này. chụp screenshot kết quả, so sánh với bản gốc. liệt kê khác biệt rồi fix”

Fix lỗi build:

Thay vì: “the build is failing”

Nói rõ: “build fail với error này: [paste error]. fix root cause, đừng suppress error. verify build thành công sau khi fix”

💡 Tip: Verification có thể là test suite, linter, hoặc một bash command kiểm output. Đầu tư vào verification chất lượng — nó tiết kiệm rất nhiều thời gian debug.

Explore trước, Plan, rồi mới Code

Cho Claude nhảy thẳng vào code → dễ giải sai bài toán. Dùng Plan Mode để tách research khỏi implementation.

4 bước workflow

1. Explore — Bật Plan Mode (Shift+Tab). Claude đọc files, trả lời câu hỏi, không thay đổi gì.

đọc /src/auth và giải thích cách handle sessions và login.
xem thêm cách quản lý environment variables cho secrets.

2. Plan — Yêu cầu Claude lập kế hoạch chi tiết.

Mình muốn thêm Google OAuth. File nào cần thay đổi?
Session flow thế nào? Lập plan chi tiết.

Nhấn Ctrl+G để mở plan trong editor, chỉnh sửa trực tiếp trước khi Claude thực thi.

3. Implement — Chuyển Normal Mode, Claude code theo plan.

implement OAuth flow theo plan. viết tests cho callback handler,
chạy test suite và fix failures.

4. Commit — Claude commit và tạo PR.

commit với message mô tả rõ ràng và mở PR

⚠️ Lưu ý: Planning không phải lúc nào cũng cần. Fix typo, thêm log line, rename biến → hỏi thẳng. Planning hữu ích khi bạn không chắc approach, thay đổi nhiều file, hoặc chưa quen codebase.

Viết prompt cụ thể

Claude đoán được intent, nhưng không đọc được suy nghĩ bạn. Chỉ rõ file, constraint, và pattern mẫu.

Scope rõ task

Thay vì: “thêm tests cho foo.py”

Nói rõ: “viết test cho foo.py, cover edge case user bị logged out. không dùng mocks — mình cần integration test thật”

Chỉ nguồn thông tin

Thay vì: “tại sao API của ExecutionFactory kỳ lạ vậy?”

Nói rõ: “xem git history của ExecutionFactory, tóm tắt API evolve thế nào theo thời gian”

Tham chiếu pattern có sẵn

Thay vì: “thêm calendar widget”

Nói rõ: “xem cách widgets đang implement trên home page. HotDogWidget.php là ví dụ tốt. follow pattern đó để tạo calendar widget mới — chọn tháng, paginate tới/lui chọn năm. không dùng library ngoài”

Mô tả triệu chứng cụ thể

Thay vì: “fix login bug”

Nói rõ: “users báo login fail sau session timeout. check auth flow trong src/auth/, đặc biệt token refresh. viết failing test reproduce issue, rồi fix”

💡 Tip: Prompt mơ hồ đôi khi cũng hữu ích — khi bạn đang explore và có thể course-correct. “File này cần cải thiện gì?” có thể phát hiện điều bạn không nghĩ tới.

Cung cấp context phong phú

Nhiều cách đưa data cho Claude:

• @ reference file — thay vì mô tả file ở đâu, Claude tự đọc trước khi trả lời
• Paste ảnh trực tiếp — copy/paste hoặc kéo thả vào prompt
• Đưa URL — tài liệu, API reference. Dùng /permissions để allowlist domain hay dùng
• Pipe data — cat error.log | claude gửi nội dung file thẳng vào
• Để Claude tự lấy — bảo Claude pull context bằng Bash, MCP tools, hoặc đọc file

# Pipe error log trực tiếp
cat error.log | claude

# Hỏi nhanh không cần session
claude -p "giải thích project này làm gì"

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

Với feature lớn, thay vì bạn nghĩ hết mọi thứ, để Claude hỏi bạn:

Mình muốn build [mô tả ngắn]. Phỏng vấn mình chi tiết
dùng AskUserQuestion tool.

Hỏi về technical implementation, UI/UX, edge cases, concerns,
và tradeoffs. Đừng hỏi chuyện hiển nhiên, đào sâu vào
những phần khó mình có thể chưa nghĩ tới.

Phỏng vấn đến khi cover hết, rồi viết spec đầy đủ vào SPEC.md.

Xong spec → mở session mới để implement. Session mới có context sạch, tập trung hoàn toàn vào implementation.

💡 Tip: Claude hỏi những thứ bạn chưa nghĩ tới — technical implementation, edge cases, tradeoffs. Đây là cách “brainstorm với senior engineer”.