Prompt cho Claude Code: bộ khung ra lệnh cho dev (kèm 10 mẫu)

Prompt cho Claude Code khác prompt chat ở một điểm cốt lõi: bạn không chỉ mô tả kết quả mong muốn mà còn phải đưa cho Claude một cách tự kiểm chứng việc mình vừa làm. Một prompt tốt gồm bốn phần — chỉ rõ file hoặc phạm vi, nêu bối cảnh, mô tả yêu cầu cụ thể, và giao một phép kiểm để Claude tự chạy rồi sửa cho tới khi qua.

Tóm tắt nhanh

• Ràng buộc lớn nhất khi làm việc với Claude Code là cửa sổ ngữ cảnh: nó đầy rất nhanh, và chất lượng giảm khi càng đầy.
• Khác biệt lớn nhất giữa prompt kém và prompt tốt không phải độ dài mà là có phép kiểm chứng hay không — test, lệnh build, linter hoặc ảnh chụp màn hình để đối chiếu.
• Quy trình được khuyến nghị là bốn pha: khám phá → lập kế hoạch → viết code → commit, dùng plan mode để tách giai đoạn nghiên cứu khỏi giai đoạn sửa file.
• Nếu đã sửa lưng Claude quá hai lần cho cùng một vấn đề, đừng sửa tiếp — /clear rồi viết lại prompt tốt hơn.
• Dùng @ để nạp thẳng file vào hội thoại, dán ảnh lỗi, hoặc đẩy dữ liệu qua ống lệnh kiểu cat error.log | claude.
• Giao việc nghiên cứu cho subagent để phần đọc file không chiếm ngữ cảnh chính của bạn.

Vì sao prompt cho code khác prompt chat thông thường?

Vì Claude Code không trả lời rồi dừng lại — nó đọc file, chạy lệnh, sửa mã và tự làm việc tiếp. Tài liệu chính thức mô tả đây là môi trường lập trình dạng agentic: thay vì bạn viết code rồi nhờ Claude review, bạn mô tả thứ mình muốn và Claude tự tìm cách dựng.

Hệ quả là hai thứ trở nên quan trọng hơn hẳn so với chat thường.

Thứ nhất là ngữ cảnh. Cửa sổ ngữ cảnh chứa toàn bộ hội thoại: mọi tin nhắn, mọi file Claude đọc, mọi kết quả lệnh. Một phiên gỡ lỗi hay một lượt dò codebase có thể ngốn hàng chục nghìn token. Tài liệu nói thẳng rằng khi ngữ cảnh gần đầy, Claude bắt đầu “quên” chỉ dẫn ban đầu và mắc lỗi nhiều hơn. Gần như mọi thực hành tốt đều xuất phát từ ràng buộc này.

Thứ hai là điều kiện dừng. Claude dừng khi công việc trông có vẻ xong. Nếu không có phép kiểm nào để chạy, “trông có vẻ xong” là tín hiệu duy nhất nó có, và bạn trở thành vòng lặp kiểm chứng — mọi sai sót đều phải chờ bạn phát hiện. Đưa cho nó một thứ trả về đạt hoặc không đạt, vòng lặp tự khép lại.

Khung bốn phần: phạm vi – bối cảnh – yêu cầu – phép kiểm

Đây là khung mình dùng cho mọi prompt lập trình. Bốn phần, không cần dài dòng.

Tài liệu Anthropic đưa vài cặp đối chiếu rất rõ tác dụng của khung này. Thay vì “thêm test cho foo.py”, họ khuyên viết “viết test cho foo.py phủ trường hợp biên khi người dùng đã đăng xuất, tránh dùng mock”. Thay vì “sửa lỗi đăng nhập”, viết “người dùng báo đăng nhập thất bại sau khi phiên hết hạn; kiểm luồng xác thực trong src/auth, đặc biệt phần làm mới token; viết một test thất bại tái hiện lỗi rồi sửa”.

Điểm chung của các bản viết lại: đều bổ sung phạm vi cụ thể và một tiêu chí để biết khi nào xong.

Quy trình bốn pha: khám phá, lập kế hoạch, viết code, commit

Để Claude nhảy thẳng vào code dễ dẫn tới việc giải sai bài toán. Quy trình được khuyến nghị tách nghiên cứu ra khỏi thực thi.

1. Khám phá. Bật plan mode bằng cách bấm Shift+Tab tới khi thanh trạng thái hiện chế độ kế hoạch, hoặc khởi động bằng claude --permission-mode plan. Ở chế độ này Claude đọc file và trả lời câu hỏi nhưng không sửa gì.
2. Lập kế hoạch. Yêu cầu Claude viết kế hoạch triển khai chi tiết: cần sửa những file nào, luồng dữ liệu ra sao. Bấm Ctrl+G để mở kế hoạch trong trình soạn thảo và sửa trực tiếp trước khi cho chạy.
3. Viết code. Duyệt kế hoạch hoặc bấm Shift+Tab để thoát plan mode, rồi yêu cầu Claude triển khai đúng theo kế hoạch, viết test và chạy bộ test.
4. Commit. Yêu cầu Claude commit kèm mô tả rõ ràng và mở pull request.

Đừng áp quy trình này cho mọi việc. Tài liệu cũng lưu ý plan mode có chi phí phụ trội: với việc phạm vi rõ và sửa nhỏ — sửa lỗi chính tả, thêm một dòng log, đổi tên biến — cứ bảo Claude làm thẳng. Nguyên tắc mình dùng: nếu bạn mô tả được toàn bộ thay đổi trong một câu, bỏ qua bước lập kế hoạch.

10 mẫu prompt dùng được ngay

Mười mẫu dưới đây bám theo các công thức trong tài liệu chính thức, mình viết lại bằng tiếng Việt và bổ sung phép kiểm cho từng mẫu. Claude Code làm việc tốt với prompt tiếng Việt, nên bạn không cần dịch sang tiếng Anh; chỉ giữ nguyên tên file, tên hàm và thông báo lỗi đúng như trong mã nguồn.

1. Hiểu codebase mới: “Cho mình tổng quan codebase này: kiến trúc chính, các model dữ liệu quan trọng, và luồng xác thực đang được xử lý ở đâu.”
2. Tìm đúng chỗ cần sửa: “Tìm các file xử lý đăng nhập người dùng, giải thích chúng phối hợp với nhau ra sao, rồi lần theo luồng đăng nhập từ giao diện xuống cơ sở dữ liệu.”
3. Sửa lỗi có thông báo cụ thể: “Build đang hỏng với lỗi sau: [dán lỗi]. Sửa và xác nhận build chạy được. Xử lý nguyên nhân gốc, không che lỗi đi.”
4. Sửa lỗi mơ hồ theo triệu chứng: “Người dùng báo form gửi được cả khi bỏ trống. Kiểm phần kiểm tra dữ liệu trong @src/forms/. Viết một test thất bại tái hiện lỗi trước, rồi mới sửa.”
5. Viết hàm kèm tiêu chí nghiệm thu: “Viết hàm validateEmail. Ví dụ ca kiểm thử: user@example.com trả về true, invalid trả về false, user@.com trả về false. Viết xong thì chạy test luôn.”
6. Bám theo mẫu có sẵn trong dự án: “Xem cách các widget hiện có được viết ở trang chủ để nắm quy ước — HotDogWidget.php là ví dụ tốt. Theo đúng mẫu đó, viết một widget lịch cho phép chọn tháng và chuyển tới lui theo năm. Không thêm thư viện nào ngoài những thư viện dự án đang dùng.”
7. Refactor an toàn: “Tìm chỗ đang dùng API đã bị khai tử trong dự án. Sau đó refactor utils.js sang cú pháp hiện đại nhưng giữ nguyên hành vi, rồi chạy test cho phần vừa sửa.”
8. Bổ sung test cho phần chưa phủ: “Tìm các hàm trong @src/services/notifications.js chưa được test phủ. Sinh khung test theo đúng framework dự án đang dùng, thêm ca cho điều kiện biên, rồi chạy và sửa các test hỏng.”
9. Truy lịch sử để hiểu quyết định cũ: “Đọc lịch sử git của ExecutionFactory và tóm tắt vì sao API của nó thành ra như hiện nay.”
10. Tổng kết và mở PR: “Tóm tắt những thay đổi mình đã làm ở module xác thực, rồi tạo pull request với mô tả nêu rõ rủi ro và điểm cần chú ý khi review.”

Với người làm web ở Việt Nam, mẫu số 6 là mẫu mình dùng nhiều nhất. Phần lớn dự án WordPress và PHP nội địa có quy ước riêng tích tụ nhiều năm, không nằm trong tài liệu nào. Chỉ cho Claude một file mẫu “làm đúng chuẩn nhà” rồi bảo nó bám theo cho kết quả sát hơn nhiều so với việc mô tả quy ước bằng lời.

Làm sao để Claude tự phát hiện và sửa lỗi của chính nó?

Bằng cách gắn phép kiểm vào prompt, ở một trong bốn mức chặt dần.

Một mẹo nhỏ nhưng hiệu quả: yêu cầu Claude trình bằng chứng thay vì tuyên bố đã xong — kết quả test, lệnh đã chạy và thứ nó trả về, hoặc ảnh chụp màn hình. Đọc bằng chứng nhanh hơn tự chạy lại phép kiểm, và cách này dùng được cả cho những phiên bạn không ngồi xem.

Với review độc lập, tài liệu có một cảnh báo đáng giá: một reviewer được giao nhiệm vụ tìm thiếu sót thì gần như luôn tìm ra thứ gì đó, kể cả khi công việc đã ổn — vì đó chính là việc bạn giao. Chạy theo mọi phát hiện dẫn tới over-engineering: thêm lớp trừu tượng thừa, code phòng thủ và test cho những tình huống không thể xảy ra. Nên nói rõ với reviewer rằng chỉ báo những thiếu sót ảnh hưởng tới tính đúng đắn hoặc yêu cầu đã nêu.

Cấp thêm ngữ cảnh cho Claude bằng cách nào?

Có bốn kênh, và biết dùng đúng kênh tiết kiệm rất nhiều lượt qua lại.

• Tham chiếu file bằng @ thay vì mô tả code nằm ở đâu. Gõ @ sẽ mở gợi ý đường dẫn; tham chiếu thư mục thì chỉ hiện danh sách file chứ không nạp nội dung.
• Dán ảnh trực tiếp — kéo thả hoặc dán vào dấu nhắc. Rất hợp cho ảnh chụp lỗi, mockup giao diện và sơ đồ.
• Đưa đường dẫn tài liệu để Claude tự đọc, kèm cho phép sẵn tên miền hay dùng.
• Đẩy dữ liệu qua ống lệnh, ví dụ cat error.log | claude, để gửi thẳng nội dung file.

Với những quy ước lặp lại ở mọi phiên, đừng dán lại mỗi lần — ghi vào file CLAUDE.md ở gốc dự án. Chạy /init để sinh file khởi điểm rồi tinh gọn dần. Nguyên tắc lọc nội dung: với mỗi dòng, tự hỏi “bỏ dòng này đi thì Claude có mắc lỗi không?” — nếu không thì cắt. Tài liệu cảnh báo file CLAUDE.md phình to khiến Claude bỏ qua chính những chỉ dẫn quan trọng của bạn. Còn kiến thức chỉ thỉnh thoảng mới cần thì đóng gói thành Claude Skills, vì Skills nạp theo nhu cầu chứ không chiếm chỗ ở mọi phiên.

Prompt cho refactor, test và debug khác nhau chỗ nào?

Ba loại việc này cần ba loại ràng buộc khác nhau.

Refactor cần ràng buộc “giữ nguyên hành vi”. Prompt nên nêu rõ phạm vi file, đích đến của cú pháp, yêu cầu giữ tương thích ngược nếu cần, và chạy test sau khi sửa. Làm theo từng bước nhỏ có thể kiểm chứng được thay vì một cú lớn.

Test cần nói rõ bạn muốn kiểm chứng hành vi nào, chứ không phải “viết test cho file này”. Claude sẽ đọc các file test sẵn có để bắt chước phong cách, framework và kiểu assert đang dùng, nên bạn không cần mô tả lại quy ước. Thứ đáng thêm vào prompt là yêu cầu chỉ ra những ca biên bạn có thể đã bỏ sót.

Debug cần triệu chứng, vị trí nghi ngờ và định nghĩa “đã sửa xong”. Kèm theo lệnh tái hiện lỗi và stack trace nếu có, nói rõ lỗi xảy ra thường xuyên hay chập chờn. Mẫu mạnh nhất là yêu cầu viết một test thất bại tái hiện lỗi trước khi sửa — làm vậy thì phép kiểm tự sinh ra cùng với bản sửa.

Với việc lớn còn mơ hồ, có một mẫu ít người biết mà rất hiệu quả: bảo Claude phỏng vấn ngược bạn. Mô tả ngắn thứ muốn xây, yêu cầu Claude hỏi kỹ về triển khai kỹ thuật, giao diện, ca biên và đánh đổi, hỏi tới khi phủ hết rồi ghi toàn bộ ra một file đặc tả. Sau đó mở phiên mới để thực thi đặc tả đó — ngữ cảnh sạch, tập trung hoàn toàn vào phần triển khai.

Những sai lầm khiến prompt tốt vẫn cho kết quả tệ

Năm kiểu thất bại phổ biến, gần như đều liên quan tới ngữ cảnh chứ không phải câu chữ.

• Phiên làm việc thập cẩm. Bắt đầu bằng một việc, hỏi sang việc không liên quan, rồi quay lại việc đầu. Ngữ cảnh đầy thông tin thừa. Cách sửa: /clear giữa các việc khác nhau.
• Sửa lưng vòng vo. Claude làm sai, bạn sửa, vẫn sai, bạn sửa tiếp. Ngữ cảnh nhiễm đầy hướng tiếp cận thất bại. Sau hai lần sửa không ăn thua, /clear rồi viết lại prompt tốt hơn dựa trên thứ vừa học được.
• File CLAUDE.md quá dài. Quy tắc quan trọng chìm trong nhiễu. Nếu có một chỉ dẫn Claude cứ bỏ qua, thêm nhấn mạnh cho riêng dòng đó — nhấn mạnh mọi dòng thì chẳng dòng nào nổi bật.
• Tin mà không kiểm. Claude cho ra bản triển khai trông rất hợp lý nhưng không xử lý ca biên. Luôn kèm phép kiểm; không kiểm được thì đừng đưa lên production.
• Khám phá vô tận. Bảo Claude “nghiên cứu” mà không giới hạn phạm vi, nó đọc hàng trăm file và lấp đầy ngữ cảnh. Thu hẹp phạm vi, hoặc giao cho subagent để phần đọc file nằm ở ngữ cảnh khác.

Mẹo cuối liên quan tới subagent đáng nhắc riêng vì nó giải quyết đúng ràng buộc gốc. Khi bạn viết “dùng subagent để tìm hiểu hệ thống xác thực xử lý việc làm mới token thế nào”, subagent đọc file trong cửa sổ ngữ cảnh riêng của nó và chỉ trả về bản tóm tắt. Ngữ cảnh chính của bạn vẫn sạch để dành cho phần triển khai.

Câu hỏi thường gặp

Viết prompt bằng tiếng Việt có kém hơn tiếng Anh không?
Không đáng kể trong thực tế. Điều quan trọng hơn ngôn ngữ là độ cụ thể: nêu đúng tên file, dán nguyên văn thông báo lỗi và nói rõ tiêu chí nghiệm thu. Tên hàm, tên biến và thông báo lỗi thì giữ nguyên gốc, đừng dịch.

Prompt nên dài bao nhiêu?
Đủ để nêu bốn thành phần trong khung: phạm vi, bối cảnh, yêu cầu, phép kiểm. Thường là hai tới bốn câu. Dài hơn thế mà không thêm ràng buộc mới thì chỉ tốn ngữ cảnh.

Khi nào nên dùng prompt mơ hồ?
Khi bạn đang thăm dò và chấp nhận chỉnh hướng sau. Một câu như “theo bạn thì file này nên cải thiện chỗ nào?” có thể lộ ra những thứ bạn không nghĩ tới để mà hỏi.

Lỡ để Claude sửa sai thì làm sao?
Bấm Esc để dừng giữa chừng, ngữ cảnh vẫn được giữ nên bạn chỉnh hướng ngay được. Bấm Esc hai lần hoặc chạy /rewind để mở menu quay lui, khôi phục lại trạng thái hội thoại và mã nguồn trước đó. Lưu ý điểm khôi phục chỉ theo dõi thay đổi do công cụ sửa file của Claude tạo ra, không thay thế được git.

Có nên gộp nhiều yêu cầu vào một prompt không?
Với việc phức tạp thì nên tách thành các bước đánh số rõ ràng trong cùng một prompt, để Claude thực hiện tuần tự. Nhưng nếu các việc không liên quan tới nhau, hãy tách ra thành các phiên riêng và /clear ở giữa.

Chạy Claude Code trong script tự động thì prompt viết khác không?
Khác ở chỗ phải nêu rõ định nghĩa thành công và cách xử lý kết quả, vì phiên chạy không tương tác không hỏi lại được. Dùng claude -p "câu lệnh" để chạy một lượt rồi thoát, thêm --output-format json khi cần kết quả cho script đọc.

Kết luận

Cải thiện lớn nhất bạn có thể làm ngay hôm nay không phải học thuộc mẫu prompt, mà là thêm một dòng phép kiểm vào cuối mọi yêu cầu. “Chạy test và sửa cho tới khi qua” — chỉ một câu đó đã đổi cách Claude Code kết thúc công việc.

Nếu bạn chưa cài công cụ, bắt đầu từ bài hướng dẫn cài đặt Claude Code trên Windows và macOS. Muốn xem toàn cảnh hệ công cụ và cách chúng ghép với nhau thì đọc bài trụ Claude Code là gì? Hướng dẫn từ A–Z, sau đó nối thêm dữ liệu thật cho Claude qua MCP.

Nguồn tham khảo

• Claude Code Docs — Best practices — ràng buộc cửa sổ ngữ cảnh, nguyên tắc cấp phép kiểm, quy trình bốn pha, bảng đối chiếu prompt kém và prompt tốt, các kiểu thất bại phổ biến (truy cập 09/09/2026).
• Claude Code Docs — Common workflows — công thức prompt cho khám phá codebase, sửa lỗi, refactor, viết test, tạo pull request, tham chiếu file bằng @.
• Claude Code Docs — Quickstart — mẹo cho người mới, cách chia yêu cầu phức tạp thành các bước, các lệnh phiên cơ bản.
• Claude Code Docs — CLAUDE.md — nơi đặt file, cú pháp nhập file khác, nguyên tắc giữ file ngắn gọn.
• Claude Code Docs — Subagents — cách subagent chạy trong ngữ cảnh riêng và trả về tóm tắt.
• Claude Code Docs — Non-interactive mode — chạy claude -p trong script và CI, các định dạng đầu ra.